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