围绕监控的术语近年来引起了很多混乱，导致一些糟糕的工具宣称能够以一种格式完成所有事情。可观测性的支持者认识到观察一个系统有许多层次。度量标准聚合中最主要的是时间序列数据，这里有许多工具可用，包括开源和商业。我们将专注于开源工具，但其中有包含带有付费组件的开放核心模型。
Prometheus
这是原生云应用程序中最受认可的时间序列监控解决方案。目前它由Cloud Native Computing Foundation 基金会（CNCF）托管，但之前是由Matt Proud和Julius Volz创建，由SoundCloud赞助，很多早期的贡献者也提供了帮助。
Prometheus是一个基于拉的系统，它使用本地配置来描述要收集的端点以及收集所需的间隔。每个端点都有一个客户端收集数据并在每次请求时更新该代理人（或者配置客户端）。收集此数据并将其保存在本地磁盘上的高效存储引擎中。存储系统每个度量标准使用仅附加文件。这种存储不是有损的，这意味着一年前数据的保真度与您今天收集的数据一样高。但是，您可能不希望在本地保留那么多数据。幸运的是，有一个远程存储选项可用于长期保留和分析。
Prometheus包含一种高级表达式语言名为PromQL，用于选择和显示数据。数据可以通过REST API以图形方式，表格方式或由外部系统使用。表达式语言允许用户创建回归，分析实时数据或趋势历史数据。标签也是过滤和查询数据的绝佳工具。标签可以与每个度量标准名称相关联。
Prometheus还提供联邦模式，通过允许团队拥有自己的Prometheis来鼓励更多的本地化控制，而中央团队也可以拥有自己的Prometheis。中央系统可以抓取与本地Prometheis相同的端点，但它们也可以获取本地Prometheis正在收集的聚合数据。这减少了端点上的开销。此联合模型还允许本地实例相互收集数据。
Prometheus附带AlertManager来处理警报。该系统允许聚合警报以及更复杂的流量以限制发送警报的时间。
假设在同一时间10个节点突然关闭。您可能不需要发送有关10个节点的警报，因为接收它们的每个人在修改交换机之前可能无法执行任何操作。使用AlertManager，可以仅向交换机的网络团队发送警报，并包含有关可能受影响的其他系统的其他信息。也可以向系统团队发送电子邮件（而不是页面），以便他们知道这些节点已关闭。除非系统在交换机修复后没有出现，否则他们不需要响应。如果发生这种情况，则AlertManager将重新激活由交换机警报抑制的那些警报。
Graphite
Graphite已经存在很长时间了，James Turnbull出版的“监测艺术”一书详细介绍了Graphite。Graphite已经在该行业中普遍存在，许多大公司大规模使用它。
Graphite是一个基于推送的系统，通过让应用程序将数据推送到Graphite的Carbon组件中，从应用程序接收数据。Carbon将此数据存储在Whisper数据库中，Graphite Web组件读取该数据库和Carbon，允许用户在浏览器中绘制数据图或通过API提取数据。一个非常酷的功能是能够将这些图形导出为图像或数据文件，以便将它们轻松嵌入到其他应用程序中。
Whisper是一个固定大小的数据库，可以随时间快速，可靠地存储数字数据。它是一个有损数据库，这意味着您的指标的解决方案会随着时间的推移而降低。它将为最新的集合提供高保真度量标准，并逐渐降低保真度。
Graphite还使用点分隔命名，这意味着维度。此维度允许对指标和指标之间的关系进行一些创造性聚合。这样就可以跨不同版本或数据中心聚合服务，并且（更具体地说）在特定Kubernetes集群中的一个数据中心中运行的单个版本。还可以进行粒度级比较以确定特定群集是否表现不佳。
Graphite的另一个有趣功能是能够存储应该与时间序列指标相关的任意事件。特别是，可以在Graphite中添加和跟踪应用程序或基础架构部署。这允许操作员或开发人员对问题进行故障排除，以获得有关正在调查的异常行为的环境中发生的事情的更多上下文。
Graphite还有大量可应用于度量的函数。但是，它缺乏强大的查询语言，它还缺少警报功能或内置警报系统。
InfluxDB
InfluxDB是一个相对较新的参赛者，比Prometheus更新。它使用开放核心模型，这意味着有额外的扩展和集群成本。InfluxDB是更大的TICK堆栈（Telegraf，InfluxDB，Chronograf和Kapacitor）的一部分，因此我们将在此分析中包含所有这些组件的功能。
InfluxDB使用名为tags的键值对为度量添加维度，类似于Prometheus和Graphite。结果类似于我们之前讨论的其他系统。度量标准数据可以是float64，int64，bool和具有纳秒分辨率的字符串。这个范围比这个领域的大多数其他工具更广泛。事实上，TICK堆栈更像是一个事件聚合平台而不是本机时间序列指标聚合系统。
InfluxDB使用类似于日志结构合并树的系统进行存储。在此上下文中，它被称为时间结构合并树。它使用预写日志和一组只读数据文件，这些文件类似于排序字符串表，具有系列数据而不是纯日志数据。这些文件按时间块进行分片。要了解更多信息，请在InfluxData网站上查看这个优秀的资源。
TICK堆栈的体系结构根据它是开源还是商业版本而有所不同。开源InfluxDB系统是独立于一个主机中的，而商业版本质上是分布式的。其他中心组件也是如此。在开源版本中，一切都在一台主机上运行。外部系统上没有存储任何数据或配置，因此管理起来相当容易，但它不如商业版那么强大。
InfluxDB包含一种类似SQL的语言，名为InfluxQL，用于查询数据库中的数据。查询数据的主要方法是HTTP API。查询语言没有像Prometheus那样多的内置辅助函数，但熟悉SQL的人可能会对这种语言感觉更舒服。
TICK堆栈还包括警报系统。该系统可以进行一些温和的聚合，但不具备Prometheus的AlertManager的全部功能。但它确实提供了许多集成。此外，为了减少InfluxDB的负载，可以安排连续查询来存储Kapacitor将采取警报的查询结果。
OpenTSDB
正如其名称所暗示的，OpenTSDB是一个开源时间序列数据库。它在这个工具集中是独一无二的，因为它将其指标存储在Hadoop中。这意味着它具有固有的可扩展性。如果您已经拥有Hadoop集群，那么对于您希望长期存储的指标，这可能是一个不错的选择。如果您没有Hadoop集群，那么运营开销可能会给您带来太大的负担。但是，OpenTSDB现在支持Google的Bigtable作为后端，这是一种您无需操作的云服务。
OpenTSDB与其他系统共享许多功能。它使用键值配对系统，它调用标签来识别指标和添加维度。它有一种查询语言，但它比Prometheus的PromQL有限。但是，它有几个内置功能，有助于学习和使用。API是查询的主要入口点，类似于InfluxDB。除非在HBase中设置了生存时间，该系统还可以永久存储所有数据，因此您不必担心保真度降低。
OpenTSDB不提供警报功能，这将使您很难与事件响应流程集成。这种类型的系统可能对于长期Prometheus数据存储和执行更多历史分析以揭示系统性问题非常有用，而不是作为快速识别和响应急性问题的工具。