排查基于日志的指标的问题

本页面提供了在 Cloud Logging 中使用基于日志的指标时的常见情况的问题排查信息。

无法查看或创建指标

基于日志的指标仅适用于单个 Google Cloud 项目或 Google Cloud 项目中的 Logging 存储桶。您无法为其他 Google Cloud 资源（例如结算账号或组织）创建基于日志的指标。基于日志的指标仅根据接收它们的 Google Cloud 项目或存储桶中的日志进行计算。

要创建指标，您需要正确的 Identity and Access Management 权限。如需了解详情，请参阅使用 IAM 进行访问权限控制：基于日志的指标。

指标缺少日志数据

在基于日志的指标中丢失数据有几种可能的原因：

  • 新日志条目可能与您的指标的过滤条件不匹配。基于日志的指标从创建指标后收到的匹配日志条目中获取数据。Logging 不会回填以前的日志条目中的指标。

  • 新的日志条目可能不包含正确的字段，或者数据的格式可能不正确，以至于分布指标无法提取。请检查您的字段名称和正则表达式是否正确。

  • 指标计数可能延迟了。即使是日志查看器中显示可计数的日志条目，系统也需要最长 10 分钟的时间才能在 Cloud Monitoring 中更新基于日志的指标。

  • 显示的日志条目的计数可能会延迟，或者可能根本不会计数，因为它们的时间戳距现在过于久远（过去或未来）。如果 Cloud Logging 在 24 小时之前或在未来 10 分钟内收到一条日志条目，则该日志条目将不会计入基于日志的指标中。

    延迟条目数记录在基于日志的指标 logging.googleapis.com/logs_based_metrics_error_count 中。

    示例：与基于日志的指标匹配的某个日志条目出现延迟。它的 timestamp 是 2020 年 2 月 20 日下午 2:30，而 receivedTimestamp 是 2020 年 2 月 21 日下午 2:45。此条目将不会计入基于日志的指标中。

  • 基于日志的指标是在指标可能统计的日志条目到达后创建的。基于日志的指标会评估存储在日志存储分区中的日志条目；这些指标不会评估存储在 Logging 中的日志条目。

  • 基于日志的指标中的数据存在缺口。由于处理基于日志的指标数据的系统无法保证每个指标数据点的持久性，因此出现一些数据缺口属于正常现象。出现数据缺口的情况通常很少见，而且持续时间很短。不过，如果您有监控基于日志的指标的提醒政策，则数据缺口可能会导致发送误报。您在提醒政策中使用的设置可以降低出现这种情况的可能性。

    示例：系统每 5 分钟写入一条“心跳”日志条目，而基于日志的指标会统计“心跳”日志条目数。提醒政策会对五分钟间隔内的计数进行求和，如果总计小于 1，则会向您发送通知。当时时序缺少数据点时，提醒政策会注入一个合成值（与最近的样本重复，并且很可能是零），然后评估条件。因此，即使缺失一个数据点，汇总值也可能会为零，这会导致此提醒政策发送通知。

    为降低发送误报的风险，请将政策配置为统计多个“心跳”日志条目，而不仅仅是一条。

Cloud Monitoring 中的资源类型为“未定义”

某些 Cloud Logging 受监控的资源类型不会直接映射到 Cloud Monitoring 受监控的资源类型。例如，当您首次根据基于日志的指标创建提醒政策或图表时，您可能会看到资源类型为“未定义”。

资源类型为“未定义”。

受监控资源类型映射到 global 或 Cloud Monitoring 中的其他受监控资源类型。请参阅适用于 Logging 专用资源的映射，确定您需要选择哪种受监控资源类型。

突发事件未创建或为误报

由于提醒政策的校准时间段太短，您可能会收到误报突发事件，或者监控不会根据基于日志的指标创建突发事件。在以下情况下，您可能会遇到误报：

  • 当提醒政策使用“小于”逻辑时。
  • 提醒政策基于分布指标的百分位数条件时。
  • 指标数据中存在缺口。

由于日志条目可以延迟发送到 Logging，因此可能会出现误报突发事件。例如，在某些情况下，日志字段 timestamp 和 receiveTimestamp 可以有几分钟的差异。此外，当 Logging 在日志存储分区中存储日志时，在日志条目生成和 Logging 接收日志条目之间存在固有的延迟。这意味着对于某个特定的日志条目，Logging 可能在日志条目生成后更晚的某个时间点才会有该日志的总数。这就是为什么使用“小于”逻辑或基于分布指标百分位条件的提醒政策可能会产生误报提醒：并非所有日志条目都已被计算在内。

不过，基于日志的指标是最终一致的，这是因为与基于日志的指标相匹配的日志条目可以使用明显早于或晚于日志的 receiveTimestamp 的 timestamp 发送到 Logging。

这意味着，在 Logging 已经接收到具有相同时间戳的现有日志条目之后，基于日志的指标还可以接收具有较早时间戳的日志条目。因此必须更新指标值。

为了保证提醒（包括准时数据）的准确性，我们建议您将条件的校准时间段设置为至少 10 分钟。具体而言，此值应足够大，以确保系统会统计与您的过滤条件匹配的多个日志条目。例如，如果基于日志的指标统计“心跳”日志条目（预计每 N 分钟生成一次），则将对齐周期设置为 2N 分钟或 10 分钟（以较大者为准）：

  • 如果您使用的是 Google Cloud 控制台，请使用滚动窗口菜单设置对齐周期。

  • 如果您使用的是 API，请使用条件的 aggregations.alignmentPeriod 字段设置对齐周期。

指标的时间序列过多

指标中的时间序列数取决于标签值的不同组合的数量。时间序列的数量称为指标的基数，不能超过 30000 个。

由于您可以为标签值的每个组合生成一个时间序列，因此，如果您有一个或多个包含大量值的标签，则超过 30000 个时间序列不难。您需要避免使用高基数指标。

随着指标基数的增加，指标可能会受到限制，因而某些数据点可能无法写入指标。显示指标的图表必须处理大量的时间序列，因此其加载速度可能会很慢。此外，查询时间序列数据的 API 调用可能会产生相关费用；如需了解详情，请参阅 Cloud Monitoring 费用。

要避免创建高基数指标，请执行以下操作：

  • 检查标签字段和提取器正则表达式是否与基数有限的值匹配。

  • 避免提取可随标签值而无限变化的文本消息。

  • 避免提取含有无边界基数的数值。

  • 仅从已知基数的标签中提取值；例如，具有一组已知值的状态代码。

这些系统（基于日志的）指标可帮助您衡量添加或移除标签对指标基数的影响：

检查这些指标时，您可以按指标名称进一步过滤结果。如需了解详情，请参阅选择指标：过滤。

指标名称无效

创建计数器或分布指标时，请选择对于 Google Cloud 项目中基于日志的指标而言唯一的指标名称。

指标名称字符串不得超过 100 个字符，并且只能包含以下字符：

  • A-Z
  • a-z
  • 0-9

  • 特殊字符 _-.,+!*',()%\/。

    正斜线 / 表示指标名称段的层级，不得用作名称的第一个字符。

指标值不正确

您注意到，基于日志的指标报告的值有时与 Logs Explorer 报告的日志条目数不同。

为尽可能减少差异，请执行以下操作：

  • 确保应用不会发送重复的日志条目。如果日志条目具有相同的 timestamp 和 insertId，则会被视为重复条目。日志浏览器会自动抑制重复的日志条目。不过，基于日志的指标会统计与指标的过滤条件匹配的每个日志条目。

  • 确保在时间戳小于 24 小时之前或小于 10 分钟后，将日志条目发送到 Cloud Logging。基于日志的指标不会统计时间戳不在这些边界内的日志条目。

您无法排除日志重复的可能性。如果在处理日志条目期间发生内部错误，Cloud Logging 会调用重试流程。重试过程可能会导致重复的日志条目。存在重复日志条目时，基于日志的指标的值可能会过大，因为这些指标会统计与指标的过滤条件匹配的每个日志条目。

标签值被截断

用户定义的标签的值不得超过 1024 个字节。

无法删除自定义日志指标

您尝试使用 Google Cloud 控制台删除自定义的基于日志的指标。删除请求失败，删除对话框会显示错误消息 There is an unknown error while executing this operation。

如需解决此问题，请尝试执行以下操作：

  • 刷新 Google Cloud 控制台中的基于日志的指标页面。由于内部时间问题，系统可能会显示错误消息。

  • 确定并删除任何监控基于日志的指标的提醒政策。确保基于日志的指标不受提醒政策监控后，删除基于日志的指标。无法删除受提醒政策监控的基于日志的指标。