指标已死？Monitorama 之后的思考
作者：Paul Dix / 产品, 用例, 开发者
2017 年 6 月 1 日
导航至
上周我参加了在俄勒冈州波特兰市举行的 Monitorama。这是一个年度会议，专注于……你猜对了，监控。大部分内容和赞助商的重点是 DevOps 监控，但并非完全专注于此。许多演讲都适用于其他监控应用，如用户分析或越来越多的传感器数据。今年的主要主题是“指标已死”，“追踪和事件是现在/未来”。我想花一些时间来探讨为什么我认为指标将永远不会消亡，并反思 Monitorama 的其他部分。
日志、指标和追踪
在过去一年左右的时间里，监控社区已经确定了我喜欢称之为“监控圣三位一体”的东西。即日志、指标和追踪。日志用于非结构化的更深层次的根本原因分析，指标用于汇总和时间序列数据，追踪用于跟踪分布式系统和微服务架构中的性能和问题。我看到 APM 被放入指标或追踪类别，这取决于您与谁交谈或您正在查看的详细程度。
会议上的许多演讲都提到了监控重点的这三个领域。追踪似乎是最热门的主题，有多个演讲专门讨论它。还有人关注跟踪离散事件以获得更好的根本原因分析。其思想是，您需要高保真数据来跟踪分布式系统中的问题。
这就是“指标已死”论点的由来。虽然我知道演讲者大多是在开玩笑，但有一个潜在的观点：指标是有损的，当您失去精度时，您无法确定问题的原因，并且可能无法有效地监控何时发生问题。然而，指标是有损的这一事实正是它们将始终是任何监控或分析工具箱中有用工具的原因。让我解释一下。
指标（我称之为常规时间序列）本质上是对某些底层分布或不规则时间序列的汇总。常规时间序列是指在规则时间间隔（例如每 10 秒一次）采样的序列。跟踪 CPU 利用率是 DevOps 领域的一个很好的例子。不规则时间序列只是具有关联时间戳和值的事件集合。例如，对 API 的单个请求及其响应时间。可以使用采样或聚合函数（如在规则时间间隔或时间窗口内应用的最小值、平均值或百分位数）从不规则时间序列中导出常规时间序列。
如果您处理的数据量较小或深入研究非常具体的内容，则完整事件日志非常有用。然而，当查看大量数据时，汇总变得至关重要。以每天收到数百万个请求的 API 为例。作为运营商，您完全无法评估如此多的请求。您也不太可能甚至能够评估性能最差的请求。在该数据量下，您每天可能会有数百或数千个请求超出某些标准。
指标和常规时间序列为您提供了一种汇总数据的方法，以便您可以有效地可视化或大规模分析数据。此外，在某些规模下，尝试存储原始事件流变得非常昂贵。至少，使用汇总创建基线将使您能够更智能地对事件流进行采样以查找异常值。当处理甚至中等规模的数据时，指标和汇总是至关重要的。
来自意想不到的地方的监控灵感
我最喜欢的会议演讲是第一个演讲：John Rauser 关于“Tidyverse 和监控工具链的未来”。John 是一位出色的演讲者，这并不是我发现他的演讲引人入胜的唯一原因。他谈到了如何将 Tidyverse 的思想，特别是 ggplot2 和 dplyer 包的思想带入监控领域。John 展示了 ggplot2 如何创建用于指定图形属性的词汇表和 API，这正是我们正在考虑的，以便在未来基于我们在 Chronograf 中的工作创建一个开源图形库。当我思考 InfluxDB 查询语言的未来发展时，使用 dplyer 转换和塑造数据的示例对我来说至关重要。我不可能公正地评价这次演讲，所以请自己观看
[embed]https://youtu.be/P8dc-rLnLr0[/embed]
结束语
我应该提到，在第一天晚上之后，波特兰市中心的部分地区因地下火灾而停电 24 小时。这导致会场停电，使得无法按计划在剧院举办第二天的活动。不知何故，通过英雄般的努力，Jason Dixon、其他组织者、志愿者和 Gerding 剧院的员工设法在不到 12 小时内将第二天的会议迁至新场地。我仍然对他们设法完成这件事感到惊讶。
回到我所理解的会议主要主题，追踪可能是监控领域的新热点，但我认为它的受众最终是有限的。追踪在分布式/微服务环境中非常宝贵，但构建的绝大多数应用程序将继续是单体架构。在单体架构中，指标、事件和日志是您最好的工具。大多数人不需要微服务，但这将在另一篇博文中讨论。
总的来说，这次会议是一次精彩的活动，我很高兴见到并与用户、监控领域的其他构建者，甚至我们的竞争对手交谈。我对组织者未来的唯一要求是增加更多的休息时间，以便我们可以在与会者之间进行更多的对话。无论如何，我肯定会参加未来的 Monitorama 活动。
