监控不就是监控吗？它不包括日志记录、可视化和时间序列数据吗？
多年来，围绕监控的术语引起了很多困惑，并导致出现了一些糟糕的工具，这些工具标榜能够以一种格式完成所有事情。可观测性倡导者认识到，观察系统有很多层次。指标聚合主要是时间序列数据，这正是我们将在本文中讨论的内容。
时间序列数据的特性
计数器
计数器是一种指标，表示一个只会增加的数值。（换句话说，计数器永远不应减少。）计数器累积值并在请求时显示当前总数。这些通常用于诸如 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 条评论