指标已死？Monitorama 之后的一些思考

作者：Paul Dix / 产品，用例，开发者
2017年6月1日

上周我参加了在俄勒冈州波特兰举行的 Monitorama。这是一个专注于……（您猜对了）监控的年度会议。内容与赞助商的重点大多集中在 DevOps 监控上，但并不局限于这一点。许多演讲都适用于其他监控应用，如用户分析或，越来越多地，传感器数据。今年大会的主题是“指标已死”以及“跟踪和事件是现在/未来”。我想花些时间来探讨为什么我认为指标永远不会消失，并回顾 Monitorama 的其他部分。

日志、指标和跟踪

在过去一年左右的时间里，监控社区已经确定了我喜欢称之为“监控的圣三一”。那就是，日志、指标和跟踪。日志用于非结构化的深层根本原因分析，指标用于汇总和时序数据，跟踪用于跟踪分布式系统和微服务架构中的性能和问题。我见过 APM 被放入指标或跟踪的类别，这取决于你与谁交谈或你查看的详细程度。

会议上的许多演讲都提到了这三个监控焦点。跟踪似乎是最热门的主题，有多个演讲都致力于它。还有一个重点是通过跟踪离散事件来更好地进行根本原因分析。想法是，你需要高保真数据来跟踪分布式系统中的问题。

这就是“指标已死”争论出现的地方。尽管我知道演讲者大多是开玩笑的，但有一个潜在的观点：指标是有损失的，当你失去精度时，你无法确定问题的原因，并且可能无法有效地监控问题发生。然而，指标有损失的事实正是它们在任何监控或分析工具箱中始终是有用工具的原因。让我解释一下。

指标（我所说的常规时间序列）实际上是对某些底层分布或不规则时间序列的总结。常规时间序列是指在固定时间间隔内有样本的时间序列，例如每10秒一次。跟踪CPU利用率是DevOps领域的绝佳例子。不规则时间序列只是与相关时间戳和值相关联的事件集合。例如，对API的单独请求及其响应时间。可以通过在固定时间间隔或时间窗口上应用最小值、平均值或百分位数等采样或聚合函数，从不规则时间序列中诱导出常规时间序列。

如果您处理的数据量较低或深入到非常具体的内容，完整的事件日志非常有用。然而，当查看大量数据时，总结变得至关重要。以每天有数百万请求的API为例。作为操作员，您完全无法评估那么多的请求。您甚至可能无法评估表现最差的请求。在那个数量级上，您每天可能有数百或数千个不符合规范的请求。

指标和常规时间序列为您提供了一种总结数据的方法，以便您可以在规模上有效地可视化和分析数据。此外，在特定规模上，尝试存储原始事件流可能变得过于昂贵。至少，使用总结来创建基线将允许您更智能地采样事件流中的异常值。处理即使是中等规模的数据时，指标和总结都非常重要。

来自意外地方的监控灵感

我最喜欢的会议演讲是第一个：John Rauser在“Tidyverse和监控工具链的未来”上的演讲。John是一位优秀的演讲者，这并不是我发现他的演讲吸引人的唯一原因。他谈论了来自Tidyverse，特别是ggplot2和dplyr包的想法，如何应用于监控领域。John展示了ggplot2如何创建一个词汇表和API来指定图形属性，这正是我们正在考虑的，基于我们在Chronograf上的工作来创建一个开源图形库。当我思考InfluxDB查询语言的未来演变时，dplyr用于转换和塑造数据的示例仍然让我印象深刻。我无法为这场演讲做出公正的评价，所以你自己看看吧

[embed]https://youtu.be/P8dc-rLnLr0[/embed]

闭幕词

我应该提到，在第一天的晚上，由于地下火灾，波特兰市中心的某些区域发生了24小时的停电。这导致了场馆的电力中断，使得无法按计划在剧院举行第二天的事件。通过英勇的努力，Jason Dixon、其他组织者、志愿者和Gerding剧院的员工在不到12小时内将会议的第二天转移到新的场馆。我仍然对他们能够做到这一点感到惊讶。

回到我作为会议主要主题感受到的内容，跟踪可能是监控领域的新热点，但我认为其受众最终是有限的。在分布式/微服务环境中，跟踪是无价的，但大多数构建的应用程序将继续是单体。在单体中，指标、事件和日志是您最好的工具。大多数人不需要微服务，但这将是另一篇博客文章的主题。

总体来说，这次会议是一次精彩的盛会，我很享受与用户、监控领域的其他构建者以及甚至我们的竞争对手交流和交谈。我对主办方未来的唯一请求是，增加更多休息时间，以便我们能有更多的时间进行交流。无论如何，我肯定会参加未来的Monitorama活动。