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

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

无法查看或创建指标

基于日志的指标仅适用于单个 Google Cloud 项目或 Google Cloud 项目中的日志记录存储桶。您无法为其他 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 中的日志条目。

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

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

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

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

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

资源类型为“未定义”。

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

突发事件未创建或为误报

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

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

由于日志条目可以延迟发送到 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

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

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

指标值不正确

您注意到，针对基于日志的指标报告的值有时为 与日志浏览器报告的日志条目数不同。

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

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

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

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

标签值被截断

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

无法删除自定义日志指标

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

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

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

  • 确定并删除任何监控基于日志的指标的提醒政策。确保基于日志的指标没有被提醒监控后 政策，请删除基于日志的指标。受监控的基于日志的指标 则不能删除。