以下是你需要了解的有关时间序列数据和指标聚合工具的信息。
监控仅仅只是监控吗？它不包括日志记录，可视化和时间序列数据吗？
围绕监控的术语多年来引起了很多混乱，导致一些糟糕的工具宣称能够以一种格式完成所有事情。可观察性支持者认识到观察系统有很多层次。度量标准聚合主要是时间序列数据，这就是我们将在本文中讨论的内容。
时间序列数据的特征
计数器
计数器是表示仅增加的数值的度量。换句话说，计数器永远不会减少，计数器累积值并在请求时显示当前总数。这些通常用于诸如网络请求的总数，错误的数量，访问者的数量等事情。这类似于具有计数器设备的人站在事件的入口处，计算所有进入的人。通常没有选项可以在不重置计数器的情况下递减计数器。
仪表
仪表类似于计数器，因为它表示单个数值，但它也可以减少。它本质上是某个时间点某些价值的表示。温度计是仪表的一个很好的例子：它随温度上下移动并提供时间点读数。其他用途包括CPU使用率，内存使用率，网络使用率和线程数。
分位数
分位数不是一种度量标准，但它们与接下来的两个部分密切相关：直方图和汇总。让我们通过一个例子阐明我们对分位数的理解：
百分位数是一种分位数。百分位是我们经常看到的东西，它们应该帮助我们更容易理解一般概念。百分位数有100个“桶”值。我们经常看到它们与测试或性能相关，并且通常表示为某人得分，例如，在第85百分位数或其他值内。这意味着在该百分位数内得分的人具有落在第85百分位数和第86百分位数之间的实际值。这个人在所有学生中排名前15％。我们根据此指标不知道存储桶中的分数，但可以根据存储桶中所有分数的总和除以这些分数的计数得出。
分位数使我们能够比使用不考虑异常值和不均匀分布的均值或其他统计函数更好地理解我们的数据。
直方图
直方图比计数器或仪表稍微复杂一些。这是一个观察样本，它由一个计数器组成，该计数器计算所有观察值，并且基本上是一个对观测值进行求和的仪表。它使用“桶”或分组来对值进行分段，以便以有效的方式绑定数据集。通常可以看到与请求服务级别协议（SLA）相关的分位数。假设我们要确保95％的请求低于500毫秒。我们可以使用上限为0.5s的桶来收集500ms以下的所有值。然后，我们将能够确定有多少请求已落入该存储桶中。我们还可以确定我们与SLA的距离，但这很难做到（正如Prometheus文档中的解释更多）。
直方图是从多个实例累积到中央服务器的聚合度量。这提供了一个整体理解系统的机会，而不是逐个节点地理解系统。
汇总
汇总类似于直方图，因为它们是观察的样本，但聚合发生在服务器端。此外，分位数的估计比直方图更准确。汇总使用滑动时间窗口，因此它与直方图的情况略有不同，但通常用于相同类型的度量。我通常使用直方图，除非我需要非常精确的分位数测量。
推拉
如果不解决推送与拉动的争论，就不可能有关于指标聚合工具的文章。
争论的焦点是，你的度量聚合系统是将数据推送到，还是让你的度量聚合系统通过抓取端点来获取数据，这样做更好。多篇文章对此进行了讨论。我的观点是，这基本上无关紧要。额外的研究由读者自行决定。
工具选项
有许多工具可用，包括开源和商业。我们将专注于开源工具，但其中一些带有付费组件的开放工具。
其中一些工具具有可观察性的附加组件，主要是警报和可视化。这些将作为附加功能在本节中介绍，并且不会在后续文章中介绍。
1.Prometheus
这是云原生应用程序最受认可的时间序列监控解决方案。它由云原生应用基金会（CNCF）托管，但由Matt Proud和Julius Volz创建，由SoundCloud赞助，外部贡献者提前进入以帮助开发它。Robust Perception的Brian Brazil建立了帮助公司采用Prometheus的业务。他的网站上也有一个很棒的博客。 Prometheus文档非常广泛，为理解和使用该工具提供了大量详细信息。
Prometheus是一个基于拉的系统，它使用本地配置来描述要收集的端点以及收集所需的间隔。每个端点都有一个客户端收集数据并在每次请求时更新该表示（或者配置客户端）。收集此数据并将其保存在本地磁盘上的高效存储引擎中。存储系统每个度量标准使用仅附加文件。这种存储不是有损的，这意味着一年前数据的保真度与你今天收集的数据一样高。 但是，你可能不希望在本地保留那么多数据。幸运的是，有一个远程存储选项可用于长期保留和分析。
Prometheus包含一种高级表达式语言，用于选择和显示名为PromQL的数据。此数据可以通过REST API以图形方式，表格显示或由外部系统使用。表达式语言允许用户创建回归，分析实时数据或趋势历史数据。标签也是过滤和查询数据的绝佳工具。标签可以与每个度量标准名称相关联。
Prometheus还提供联邦模式，通过允许团队拥有自己的Prometheis来鼓励更多的本地化控制，而中央团队也可以拥有自己的Prometheis。中央系统可以抓取与本地Prometheis相同的端点，但它们也可以抽取本地Prometheis以获取本地实例正在收集的聚合数据。这减少了端点上的开销。此联合模型还允许本地实例相互收集数据。
Prometheus附带AlertManager来处理警报。该系统允许聚合警报以及更复杂的流量以限制发送警报的时间。
假设在开关关闭的同时10个节点突然下降。可能不需要发送有关10个节点的警报，因为接收它们的每个人在修改交换机之前可能无法执行任何操作。使用AlertManager，可以仅向交换机的网络团队发送警报，并包含有关可能受影响的其他系统的其他信息。也可以向系统团队发送电子邮件（而不是页面），以便他们知道这些节点已关闭，除非系统在交换机修复后没有出现，否则他们不需要响应。如果发生这种情况，则AlertManager将重新激活由交换机警报抑制的那些警报。
2.Graphite
Graphite已经存在了很长时间，James Turnbull最近出版的“监测艺术”一书详细介绍了Graphite。Graphite已经在该行业中普遍存在，许多大公司大规模使用它。
Graphite是一个基于推送的系统，通过让应用程序将数据推送到Graphite的Carbon组件中，从应用程序接收数据。Carbon将此数据存储在Whisper数据库中，Graphite Web组件读取该数据库和Carbon，允许用户在浏览器中绘制数据图或通过API提取数据。一个非常酷的功能是能够将这些图形导出为图像或数据文件，以便将它们轻松嵌入到其他应用程序中。
Whisper是一个固定大小的数据库，可以随时间快速，可靠地存储数字数据。它是一个有损数据库，这意味着你的指标的分辨率会随着时间的推移而降低。它将为最新的集合提供高保真度量标准，并逐渐降低保真度。
Graphite还使用点分隔命名，这意味着维度。此维度允许对指标和指标之间的关系进行一些创造性聚合。这样就可以跨不同版本或数据中心聚合服务，并且（更具体地说）在特定Kubernetes集群中的一个数据中心中运行的单个版本。还可以进行粒度级比较以确定特定群集是否表现不佳。
Graphite的另一个有趣功能是能够存储应该与时间序列指标相关的任意事件。特别是，可以在Graphite中添加和跟踪应用程序或基础架构部署。这允许操作员或开发人员对问题进行故障排除，以获得有关正在调查的异常行为的环境中发生的事情的更多上下文。
Graphite还有大量可应用于度量系列的函数。但是，它缺乏强大的查询语言，其他一些工具包括在内。它还缺少任何警报功能或内置警报系统。
3.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将采取警报的查询结果。
4.OpenTSDB
正如其名称所暗示的，OpenTSDB是一个开源时间序列数据库。它在这个工具集中是独一无二的，因为它将其指标存储在Hadoop中。这意味着它具有固有的可扩展性。如果你已经拥有Hadoop集群，那么对于你希望长期存储的指标，这可能是一个不错的选择。如果你没有Hadoop集群，那么运营开销可能会给你带来太大的负担。但是，OpenTSDB现在支持Google的Bigtable作为后端，这是一种你无需操作的云服务。
OpenTSDB与其他系统共享许多功能。它使用键值配对系统，它调用标签来识别指标和添加维度。它有一种查询语言，但它比普罗米修斯的PromQL更有限。但是，它有几个内置功能，有助于学习和使用。API是查询的主要入口点，类似于InfluxDB。该系统还可以永久存储所有数据，除非在HBase中设置了生存时间，因此你不必担心保真度降低。
OpenTSDB不提供警报功能，这将使你更难与事件响应流程集成。这种类型的系统可能对于长期Prometheus数据存储和执行更多历史分析以揭示系统性问题非常有用，而不是作为快速识别和响应急性问题的工具。
OpenMetrics标准
OpenMetrics是一个寻求为度量数据建立标准展示格式的工作组。 它受Prometheus的影响。如果这一举措取得成功，我们将拥有一个行业范围的抽象，使我们能够轻松地在工具和提供商之间切换。像Datadog这样的领先公司已经开始提供可以使用Prometheus博览会格式的工具，一旦发布，它将很容易转换为OpenMetrics标准。
同样重要的是要注意该项目的贡献者包括Google和InfluxData（以及其他）。这可能意味着InfluxDB最终将采用OpenMetrics标准。这也可能意味着如果谷歌的参与一个指标，三大云提供商之一将采用它。当然，浏览格式已经在谷歌创建的Kubernetes项目中使用。 SolarWinds，Robust Perception和SpaceNet也参与其中。
