4.2监控数据来源

Sources of Monitoring Data

监控数据来源

您将使用的具体监控数据源将被收集到您选择的监控系统上。本节讨论监视数据的两个常见来源: 日志和指标。还有其他有价值的监控源, 我们不会在这里讨论, 比如分布式跟踪和运行时自省。

指标是表示属性和事件的数值度量, 通常是通过在固定的时间间隔内收集多个数据点。日志是事件的追加记录。本章讨论的重点是结构化日志, 它们支持丰富的查询和聚合, 而不是纯文本日志。

谷歌的日志基础系统能处理大量的高粒度数据。事件发生的时间和可以查看日志的时间之间存在一些固有的延迟。对于没有时间敏感性的分析, 这些日志可以用批处理系统进行处理, 实现实时查询, 并用仪表板进行可视化。此工作流的一个示例是使用Cloud Dataflow处理日志、BigQuery进行查询查询、Data Studio制作仪表盘。

相比之下, 我们基于度量的监控系统, 从 Google 的每项服务中收集了大量的度量标准, 提供了更少的粒度信息, 但在时间上更加实时。这些特性在其他日志和基于度量的监视系统中是相当典型的, 尽管有一些例外, 例如实时日志系统或高基数指标。

我们的警报和仪表盘通常使用度量指标。我们基于度量的监控系统具备的实时性意味着工程师可以很快地收到问题通知。我们倾向于使用日志来查找问题的根本原因, 因为我们需要的信息通常无法作为度量值提供。

当报告对时间不敏感时, 我们通常会使用日志处理系统生成详细报告, 因为日志几乎总是能生成比度量指标更准确的数据。

如果您基于度量指标进行报警, 则很容易根据日志添加更多警报, 例如, 如果在出现单个异常事件时需要通知您。而在另外一种情况下, 我们仍然建议您基于度量指标的报警: 您可以在特定事件发生时递增计数器, 并根据该度量值配置报警。此策略将所有报警配置保持在一个地方, 从而更易于管理 (请参阅67页上的"管理您的监控系统")。

Examples

下面的实际示例说明了如何在监控系统之间进行选择。

Move information from logs to metrics

将信息从日志反应到度量指标

问题. HTTP 状态码是应用程序开发人员调试他们错误的重要信息。此信息在日志中可用, 但不在度量指标中。"度量指标" 面板只能提供所有错误的全局速率, 并且不包含有关确切错误代码或错误原因。因此, 以下是调试所涉及的问题的工作流:

查看全局错误图以确定发生错误的时间。

  • 读取日志文件查找包含错误的行。
  • 试图将日志文件中的错误与图表关联。

日志记录工具没有给出趋势感, 很难知道在一个日志行中看到的错误是否经常发生。日志中还包含许多其他不相关的行, 因此很难找到根本原因。

建议的解决方案. 应用程序开发团队可以选择将 HTTP 状态代码导出为通用标签 (例如, requests_total{status=404} 与 requests_total {status=500})。由于不同 HTTP 状态代码的数量相对有限, 因此不会将度量指标数据的标签数量增加到不切实际的大小, 从而使最相关的数据可用于图形和报警。

结果. 此新标签意味着团队可以升级图表以显示不同的错误类别和类型。现在, 用户可以根据暴露的错误代码快速地对可能出现的问题进行推测。我们现在也可以为客户端和服务器错误设置不同的警报阈值, 从而使警报更准确地触发。

Improve both logs and metrics

改进日志和度量指标

问题. 一个广告团队维护了50项服务, 服务用了多种不同的语言和框架编写。团队使用日志作为规范来源的SLO目标。为了评估错误量, 每个服务都使用日志处理脚本, 其中有许多服务于业务的特殊处理。下面是一个用于处理单个服务的日志项的示例脚本:

这些脚本很难维护, 而且用了度量指标监控系统无法使用的数据。由于度量指标驱动警报, 因此警报有时和用户遇到的问题对应不上。每个警报都需要一个显式的排查步骤来确定它是否是面向用户的, 这会减慢响应时间。

建议的解决方案. 团队创建一个库, 它与每个应用程序的框架语言逻辑挂钩。该库确定错误是否会在请求时间影响用户。在仪表盘中配置这个规则, 同时将其导出为一个度量, 提高一致性。如果度量指标显示服务返回了错误, 则日志中包含了确切的错误, 以及和请求相关的数据, 以帮助重现和调试问题。相应地, 任何出现在日志中影响SLO的错误信息也改变了SLI指标, 团队随后就可以对其进行预警。

结论。通过在多个服务中引入统一的控制页面, 团队重用了工具和警报逻辑, 而不是实现多个自定义解决方案。所有服务都得益于删除了复杂、服务特定的日志处理代码, 从而提高了可伸缩性。一旦警报直接与 SLOs 关联, 他们就会更清楚地去采取行动, 从而令干扰警报明显下降。

Keep logs as the data source

将日志保留为数据源

问题. 在调查生产问题时, SRE团队通常会查看受影响的实体id, 以确定影响的用户和根本原因。和之前的应用程序示例一样, 此次排查所需要的有用数据仅仅存在于日志中。在响应事件时, 团队需要对此执行一次完整的日志查询。此步骤增加了事件恢复的时间: 正确过滤出对应日志的时间加上遍历查询日志的时间。

建议的解决方案. 最初小组讨论度量指标是否应该取代他们的日志工具。与应用程序示例不同的是, 实体ID 可以包含上百万种不同的值, 因此它不像度量指标那么实用。

最终, 团队决定编写一个脚本来执行他们所需要的一次性日志查询, 并把需要运行的脚本记录在报警邮件中。然后, 如果需要, 他们可以把命令直接复制到终端。

结果. 团队可以不必具有具体业务一次性日志查询的认知负担。因此, 他们可以更快地获得所需的结果 (尽管不像基于度量指标的方法那样快)。他们还有一个备份计划: 一旦警报触发, 他们就可以自动运行该脚本, 并使用小型服务器定期查询日志, 以不断检索持续更新的新数据。