监控不就是监控吗？它不包括日志记录、可视化和时间序列数据吗？
多年来，围绕监控的术语已经造成了很多混乱，并导致了一些糟糕的工具，这些工具吹嘘能够以一种格式完成所有事情。可观察性支持者认识到，观察系统有很多层次。指标聚合主要是时间序列数据，这就是我们将在本文中讨论的内容。
时间序列数据的特征
计数器
计数器是一种指标，表示一个只会增加的数值。（换句话说，计数器永远不应该减少。）计数器累积值并在请求时呈现当前总数。它们通常用于诸如 Web 请求总数、错误数、访问者数等。这类似于一个人拿着计数设备站在一个活动的入口处，计算所有进入的人。通常没有减少计数器的选项，除非重置它。
仪表
仪表类似于计数器，因为它表示一个单一的数值，但它也可以减少。它本质上是在特定时间点对某个值的表示。温度计是仪表的一个很好的例子：它随着温度上下移动，并提供一个时间点的读数。其他用途包括 CPU 使用率、内存使用率、网络使用率和线程数。
分位数
分位数不是一种指标类型，但它们与接下来的两个部分有关：直方图和摘要。让我们用一个例子来澄清我们对分位数的理解
百分位数是一种分位数。百分位数是我们经常看到的东西，它们应该帮助我们更容易地理解一般概念。百分位数有 100 个“桶”的值。我们经常看到它们与测试或性能相关，并且通常表示为某人在第 85 个百分位数或其他某个值内得分。这意味着在该百分位数内得分的人有一个落在第 85 个百分位数和第 86 个百分位数之间的桶中的实际值。这个人也在所有学生中排名前 15%。我们不知道基于此指标的桶中的分数，但可以通过桶中所有分数的总和除以这些分数的计数来得出。
与使用不考虑异常值和不均匀分布的均值或其他一些统计函数相比，分位数可以让我们更好地理解我们的数据。
直方图
直方图比计数器或仪表稍微复杂一些。它是观测样本。它由一个计数器（计算所有观测值）和一个本质上是汇总观测值的仪表组成。它使用“桶”或分组来分割值，以便以有效的方式限制数据集。这通常与与请求服务级别协议 (SLA) 相关的分位数一起看到。假设我们想确保 95% 的请求低于 500 毫秒。我们可以使用一个上限为 0.5 秒的桶来收集所有低于 500 毫秒的值。然后，我们将能够确定有多少总请求落入了该桶中。我们还可以确定我们离 SLA 有多远，但这可能很难做到（如 Prometheus 文档 中所述）。
直方图是从多个实例累积到中央服务器的聚合指标。这提供了一个将系统作为一个整体来理解的机会，而不是在逐个节点的基础上。
摘要
摘要类似于直方图，因为它们是观测样本，但聚合发生在服务器端。此外，分位数的估计比直方图更准确。摘要使用滑动时间窗口，因此它服务的案例与直方图略有不同，但通常用于相同类型的指标。除非我需要非常准确地衡量分位数，否则我通常使用直方图。
推/拉
如果没有解决推与拉的争论，就无法撰写关于指标聚合工具的文章。
争论的焦点在于让指标聚合系统将数据推送到它，还是让指标聚合系统通过抓取端点来获取数据更好。多篇文章讨论了这一点（例如 这篇 和 这篇）。我的观点是这大多无关紧要。其他研究留给读者自行决定。
工具选项
有很多工具可用，包括开源和商业工具。我们将专注于开源工具，但其中一些工具具有带有付费组件的开放核心模型。
其中一些工具具有可观察性的附加组件——主要是警报和可视化。这些将在本节中作为附加功能介绍，不会在后续文章中介绍。
Prometheus
这是云原生应用程序最受认可的时间序列监控解决方案。它托管在 Cloud Native Computing Foundation (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 将重新激活那些被交换机警报抑制的警报。
Graphite
Graphite 已经存在很长时间了，James Turnbull 最近的书 监控的艺术 详细介绍了 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 使用一种称为标签 (tags) 的键值对系统来增加指标的维度，类似于 Prometheus 和 Graphite。结果与我们之前讨论的其他系统类似。指标数据可以是 float64、int64、bool 和 string 类型，并具有纳秒级分辨率。 这比该领域中的大多数其他工具更广泛。 事实上，TICK 技术栈更像是一个事件聚合平台，而不是一个原生的时间序列指标聚合系统。
InfluxDB 使用一种类似于日志结构合并树的系统进行存储。 在这种情况下，它被称为时间结构合并树。 它使用预写式日志 (write-ahead log) 和一组只读数据文件，这些文件类似于排序字符串表 (Sorted Strings Tables)，但具有序列数据而不是纯日志数据。 这些文件按时间块进行分片。 要了解更多信息，请查看 InfluxData 网站上的 这个很棒的资源。
TICK 技术栈的架构因是开源版本还是商业版本而异。 开源 InfluxDB 系统包含在单个主机中，而商业版本本质上是分布式的。 其他核心组件也是如此。 在开源版本中，一切都在单个主机上运行。 没有数据或配置存储在外部系统上，因此管理起来相当容易，但它不如商业版本那样健壮。
InfluxDB 包含一种类似 SQL 的语言，称为 InfluxQL，用于查询数据库中的数据。 查询数据的主要方式是 HTTP API。 该查询语言没有 Prometheus 那样多的内置辅助函数，但熟悉 SQL 的人可能会觉得这种语言更舒服。
TICK 技术栈还包括一个警报系统。 该系统可以进行一些轻微的聚合，但不具备 Prometheus 的 AlertManager 的全部功能。 但它确实提供了许多集成。 此外，为了减少 InfluxDB 上的负载，可以安排连续查询来存储查询结果，Kapacitor 将获取这些结果以进行警报。
OpenTSDB
OpenTSDB 是一个开源的时间序列数据库，正如其名称所示。 它在该工具集合中是独一无二的，因为它将其指标存储在 Hadoop 中。 这意味着它本质上是可扩展的。 如果你已经有一个 Hadoop 集群，这可能是一个不错的选择，用于存储你想要长期保存的指标。 如果你没有 Hadoop 集群，那么运营开销可能对你来说是一个太大的负担。 但是，OpenTSDB 现在支持 Google 的 Bigtable 作为后端，这是一种你无需运营的云服务。
OpenTSDB 与其他系统共享许多特性。 它使用一种称为标签 (tags) 的键值配对系统来识别指标并增加维度。 它有一种查询语言，但它比 Prometheus 的 PromQL 更有限。 但是，它确实有几个内置函数可以帮助学习和使用。 与 InfluxDB 类似，API 是查询的主要入口点。 该系统还会永久存储所有数据，除非在 HBase 中设置了生存时间 (time-to-live)，因此你无需担心保真度降低。
OpenTSDB 不提供警报功能，这将使其更难与你的事件响应流程集成。 这种类型的系统可能非常适合长期 Prometheus 数据存储以及执行更多的历史分析以揭示系统性问题，而不是作为一种快速识别和响应紧急问题的工具。
OpenMetrics 标准
OpenMetrics 是一个工作组，致力于为指标数据建立一个标准展示格式。 它受到 Prometheus 的影响。 如果这项倡议取得成功，我们将拥有一个行业范围的抽象，使我们能够轻松地在工具和提供商之间切换。 像 Datadog 这样的领先公司已经开始提供可以消费 Prometheus 展示格式的工具，一旦发布 OpenMetrics 标准，这些工具将很容易转换为 OpenMetrics 标准。
还需要注意的是，该项目的贡献者包括 Google 和 InfluxData (以及其他公司)。 这可能意味着 InfluxDB 最终会采用 OpenMetrics 标准。 如果 Google 的参与是一个指标，这可能也意味着三大云提供商之一将采用它。 当然，展示格式已经在 Google 创建的 Kubernetes 项目中使用。 SolarWinds、Robust Perception 和 SpaceNet 也参与其中。
5 条评论