2.4　Prometheus的3大局限性

Prometheus固然强大，但它还是具有一定局限性的。

首先，Prometheus作为一个基于度量的系统，不适合存储事件或者日志等，它更多地展示的是趋势性的监控。如果用户需要数据的精准性，可以考虑ELK或其他日志架构。另外，APM更适用于链路追踪的场景。

其次，Prometheus认为只有最近的监控数据才有查询的需要，所有Prometheus本地存储的设计初衷只是保存短期（如一个月）的数据，不会针对大量的历史数据进行存储。如果需要历史数据，则建议使用Prometheus的远端存储，如OpenTSDB、M3DB等。

最后，Prometheus在集群上不论是采用联邦集群还是采用Improbable开源的Thanos等方案，都没有InfluxDB成熟度高，需要解决很多细节上的技术问题（如耗尽CPU、消耗机器资源等问题），这也是本章开头提到的InfluxDB在时序数据库中排名第一的原因之一。部分互联网公司拥有海量业务，出于集群的原因会考虑对单机免费但是集群收费的InfluxDB进行自主研发。因此，集群上究竟采用Prometheus还是直接使用InfluxDB需要结合实际场景来选择，这部分内容在第9章将详细介绍。

总之，使用Prometheus一定要了解它的设计理念：它并不是为了解决大容量存储问题，TB级以上数据建议保存到远端TSDB中；它是为运行时正确的监控数据准备的，无法做到100%精准，存在由内核故障、刮擦故障等因素造成的微小误差。