在 Cloud Monitoring 中监控 Pub/Sub

您可以使用 Google Cloud 控制台或 Cloud Monitoring API 用于监控 Pub/Sub。

本文档介绍如何在 Google Cloud 控制台中监控 Pub/Sub 使用情况， 使用 Monitoring 访问 Google Cloud 控制台。

  • 您不仅想查看其他 Google Cloud 资源中的指标 Pub/Sub 指标，请使用 Monitoring。

  • 您也可以使用 Pub/Sub。请参阅监控主题 以及监控订阅。

有关在 Google Ads 中使用指标的 自动伸缩，请参阅将 Pub/Sub 指标用作伸缩信号的最佳实践。

准备工作

在使用 Monitoring 之前，请确保您已准备好以下内容：

  • Cloud Billing 账号

  • 启用了结算功能的 Pub/Sub 项目

确保同时获得这两个 ID 的一种方法就是 快速入门：使用 Cloud 控制台。

查看现有信息中心

借助信息中心，您可以在同一页面上查看和分析不同来源的数据 上下文。Google Cloud 提供预定义和自定义信息中心。对于 您可以查看预定义的 Pub/Sub 信息中心 信息中心，其中显示了指标数据、提醒政策和 Pub/Sub

如需使用 Cloud Monitoring 监控 Pub/Sub 项目，请执行以下操作： 请执行以下步骤：

  1. 在 Google Cloud 控制台中，转到 Monitoring 页面。

    转到“监控”

  2. 选择您的项目名称（如果尚未在页面顶部选择该名称）。

  3. 点击导航菜单中的信息中心。

  4. 在信息中心概览页面中，创建一个新的信息中心 或选择现有的 Pub/Sub 信息中心。

    要搜索现有的 Pub/Sub 信息中心，请在 所有信息中心下，选择名称属性，然后输入 Pub/Sub。

有关如何创建、修改和管理 自定义信息中心，请参阅管理自定义信息中心。

查看单个 Pub/Sub 指标

使用以下代码查看单个 Pub/Sub 指标： Google Cloud 控制台，请执行以下步骤：

  1. 在 Google Cloud 控制台中，转到 Monitoring 页面。

    转到“监控”

  2. 在导航窗格中，选择 Metrics Explorer。

  3. 在配置部分中，点击选择指标。

  4. 在过滤条件中，输入 Pub/Sub。

  5. 在有效资源中，选择 Pub/Sub 订阅 或 Pub/Sub 主题。

  6. 深入了解特定指标，然后点击应用。

    特定指标的页面将会打开。

您可以参阅 Cloud Monitoring 文档，详细了解监控信息中心。

查看 Pub/Sub 指标和资源类型

监控配额用量

对于给定项目，您可以使用 IAM 和管理员配额信息中心 查看当前配额和用量。

您可以使用以下指标查看历史配额用量：

这些指标使用 consumer_quota 受监控的资源类型。如需了解更多与配额相关的指标，请参阅 指标列表。

例如，以下 Monitoring 查询语言 查询会创建一个图表，其中包含每个区域中正在使用的发布者配额的比例：

fetch consumer_quota
| filter resource.service == 'pubsub.googleapis.com'
| { metric serviceruntime.googleapis.com/quota/rate/net_usage
    | filter metric.quota_metric == 'pubsub.googleapis.com/regionalpublisher'
    | align delta_gauge(1m)
    | group_by [metric.quota_metric, resource.location],
        sum(value.net_usage)
  ; metric serviceruntime.googleapis.com/quota/limit
    | filter metric.quota_metric == 'pubsub.googleapis.com/regionalpublisher'
    | group_by [metric.quota_metric, resource.location],
        sliding(1m), max(val()) }
| ratio

如果您预计用量会超出默认配额限制，请为所有相关配额创建提醒政策。这些 提醒时触发。对于 例如，以下 Monitoring Query Language 查询会在发生以下情况时触发提醒政策： 任何 Pub/Sub 配额用量超过 80% 的情况：

fetch consumer_quota
| filter resource.service == 'pubsub.googleapis.com'
| { metric serviceruntime.googleapis.com/quota/rate/net_usage
    | align delta_gauge(1m)
    | group_by [metric.quota_metric, resource.location],
        sum(value.net_usage)
  ; metric serviceruntime.googleapis.com/quota/limit
    | group_by [metric.quota_metric, resource.location],
        sliding(1m), max(val()) }
| ratio
| every 1m
| condition gt(val(), 0.8 '1')

如需有关配额指标的更多自定义监控和提醒，请参阅 使用配额指标。

如需详细了解配额，请参阅配额和限制。

保持健康的订阅

为了保持订阅状况良好，您可以监控多个订阅 使用 Pub/Sub 提供的指标指定属性。例如，您可以 监控未确认消息的量、消息的过期 例如确认时限等等 您还可以检查订阅的状况是否足以达到 消息传送延迟时间较短。

请参阅接下来的部分，详细了解具体指标。

监控消息积压

为了确保订阅者跟上消息流，您可以创建 信息中心信息中心可以显示以下积压指标（按 资源：

创建提醒政策，在这些值不在 您系统可以接受的范围例如，绝对 未确认消息的数量不一定有意义。有 那么每秒 100 万条消息 订阅，但对于每秒发送一条消息的订阅不可接受。

常见的积压问题

表现 问题 解决方案
oldest_unacked_message_age 和 num_undelivered_messages 同时增长。 订阅者未跟上消息量
  • 添加更多订阅者线程或进程。
  • 添加更多订阅者机器或容器。
  • 查找代码中是否存在阻止其成功运行的 bug 迹象 确认消息或及时处理消息。 请参阅监控确认时限到期。
如果积压输入量很稳定，数量较少，并且数量稳定 不断增加 oldest_unacked_message_age，可能会有一些消息无法处理。 消息卡住了
  • 检查应用日志，了解某些消息 导致代码崩溃的问题不太可能，但有可能 — 违规邮件被卡在 Pub/Sub，而不是在您的客户端中。提出 支持支持请求 您的代码成功处理了每条消息。
  • 如果某些邮件导致代码崩溃，请考虑转发 将这些消息 死信主题。
oldest_unacked_message_age超出了订阅金额 消息保留时长。 数据永久丢失
  • 设置在消息失效之前触发的提醒 保留时长。

监控递送延迟时间健康状况

在 Pub/Sub 中，传送延迟时间是指 将消息传递给订阅方 如果您的消息积压不断增加，您可以使用递送延迟时间健康状况 得分 (subscription/delivery_latency_health_score)，以检查哪些因素导致延迟时间增加。

此指标衡量单个订阅在滚动 10 分钟的窗口期。通过该指标，您可以深入了解以下条件 这是订阅实现一致的低延迟所必需的：

  • 可忽略的跳转请求。

  • 可忽略的负面确认消息（短缺）消息。

  • 已过期的消息确认截止期限可忽略不计。

  • 一致的确认延迟时间少于 30 秒。

  • 持续的低利用率，意味着订阅持续 有足够的容量来处理新消息。

“递送延迟时间健康得分”指标报告的得分是 0 或 1 每个指定的条件1 分表示健康状况良好， 0 分表示健康状况不佳。

  • 还原请求：如果订阅在过去的时间段内有任何还原请求 10 分钟，则得分设置为 0。跳转 订阅可能会导致旧消息在首次发送很长时间后重放 这使得它们的投放延迟时间变长了。

  • 否定确认（NACK）消息：如果订阅存在任何 负面确认 (nack) 请求的数量，得分为 设置为 0。否定确认会导致消息 且递送延迟时间增加。

  • 确认截止期限已过：如果订阅有任何已过期 确认截止时间，则得分设置为 0。私信数量 且其确认截止期限已过，则客户会重新传送其 延迟时间

  • 确认延迟时间：如果所有确认消息中的第 99.9 百分位数 过去 10 分钟的延迟时间超过 30 秒， 设为 0。确认延迟时间较长意味着订阅方客户端 处理消息的时间过长。此得分可能表示存在 bug 或订阅方客户端的某些资源限制。

  • 低利用率：各资源的利用率计算不同 订阅类型。

    • StreamingPull：如果未打开足够的流，则将得分设置 设置为 0。请开放更多信息流，确保您有足够的容量来接收新消息。

    • 推送：如果向推送端点发送的消息过多， 得分设为 0。为推送端点增加更多容量， 新邮件的容量。

    • 拉取：如果没有足够的未完成拉取请求，则得分为 设置为 0。开放更多并发拉取请求，确保已准备好接收 新邮件。

要查看该指标，请在 Metrics Explorer， 选择投放延迟时间健康状况 得分指标。将 过滤条件，以便一次只选择一个订阅。选择堆积面积图 图表并指向特定时间，即可查看 订阅。

以下屏幕截图显示的是指标在一小时内使用 堆叠面积图每天凌晨 4:15，综合健康得分最高提高到 5 分， 1 分。之后，总分降至 4， 凌晨 4:20，此时利用率得分降至 0。

传送延迟时间指标的屏幕截图

Monitoring Query Language：提供基于文本的富有表现力的界面， Cloud Monitoring 时间序列数据。以下 MQL 查询 创建一个图表，以衡量订阅的传送延迟时间健康得分。

fetch pubsub_subscription
| metric 'pubsub.googleapis.com/subscription/delivery_latency_health_score'
| filter (resource.subscription_id == '$SUBSCRIPTION')
| group_by 1m,
   [value_delivery_latency_health_score_sum:
     sum(if(value.delivery_latency_health_score, 1, 0))]
| every 1m

监控确认时限到期

为了缩短消息传送延迟时间，Pub/Sub 允许 订阅者客户端在限定时间内确认（确认）给定 消息。此时间段称为确认时限。如果您的订阅者 确认消息太长，消息会重新传送，从而导致 个订阅者看到了重复消息。不同的 原因：

  • 订阅者预配不足（您需要更多线程或机器）。

  • 每条消息的处理时间都比消息确认长 。Cloud 客户端库通常 单个消息的截止期限（不超过可配置的上限）。不过，客户端库延长消息时限也有上限。

  • 某些消息一直导致客户端崩溃。

您可以衡量订阅者错过确认时限的比率。 具体指标取决于订阅类型：

过高的确认时限到期率可能会导致系统成本效率低下。您需要为每次重新传送以及重复尝试处理每条消息付费。反之，失效率较低（例如 0.1–1%） 可能健康状况良好

监控消息吞吐量

拉取订阅和 StreamingPull 订阅者 每个拉取响应中批量的消息； 推送订阅在每个推送请求中接收一条消息。您可以使用这些指标监控订阅者正在处理的批量消息吞吐量：

您可以监控单条消息或未批量处理的消息吞吐量， 您的订阅者在这一指标中 subscription/sent_message_count 按“delivery_type”标签过滤。

监控推送订阅

对于推送订阅，请监控以下指标：

  • subscription/push_request_count

    按 response_code 和 subcription_id 对指标进行分组。 由于 Pub/Sub 推送订阅使用的是 作为隐式消息确认，请务必注意 监控推送请求响应代码。由于推送订阅在遇到超时情况或错误时会以指数方式退避，因此积压输入量可能会根据端点响应情况而快速增长。

    请考虑设置高错误率提醒，因为这些错误率会导致 以及不断增加的积压输入量。您可以创建按以下条件过滤的指标 。不过，推送请求计数可能更有用 一款用于调查不断增长的积压输入量和老化时间的工具。

  • subscription/num_outstanding_messages

    Pub/Sub 通常会限制未完成消息的数量。目标中的未完成消息应少于 1,000 条 大多数情况下都符合条件。在吞吐量达到 每秒 10,000 条消息，该服务会调整 未完成消息。此限制是以 1,000 为增量实现的。否 提供的特定保证超出了最大值，因此 1,000 就是很好的指导

  • subscription/push_request_latencies

    此指标有助于您了解推送端点的响应延迟时间分布。 由于未完成消息的数量存在限制，因此端点延迟时间会影响订阅吞吐量。如果每条消息需要 100 毫秒来处理，则吞吐量上限可能是每秒 10 条消息。

如要使用更高的未完成邮件数量上限，请按以下步骤操作： 推送订阅者必须确认收到的消息中超过 99% 的消息。

您可以使用监控查询语言计算订阅者确认的消息所占的比例。以下 MQL 查询会创建一个图表，其中包含订阅者在订阅时确认的消息所占的比例：

fetch pubsub_subscription
| metric 'pubsub.googleapis.com/subscription/push_request_count'
| filter
    (resource.subscription_id == '$SUBSCRIPTION')
    | filter_ratio_by [], metric.response_class == 'ack'
    | every 1m

使用过滤条件监控订阅

如果您对订阅配置过滤器，Pub/Sub 自动确认不匹配的消息 过滤条件。您可以监控此自动确认。

积压指标仅包含消息 所有与过滤条件匹配的值

如需监控与过滤条件不匹配的自动确认消息的比率，请使用 subscription/ack_message_count 指标（delivery_type 标签设置为 filter）。

监控与 过滤条件，请使用 subscription/byte_cost operation_type标签设置为 filter_drop。有关这些邮件的费用的更多信息，请参阅 Pub/Sub 价格页面。

监控转发的无法递送的邮件

监控 Pub/Sub 中无法传送的消息 死信主题，请使用 subscription/dead_letter_message_count 指标。此指标显示 Pub/Sub 从订阅转发的无法递送消息数量。

要验证 Pub/Sub 是否转发无法递送的消息， 可以将subscription/dead_letter_message_count指标与 topic/send_request_count 指标。比较死信主题 Pub/Sub 会转发这些消息。

您还可以将订阅附加到死信主题，然后监控 使用以下指标转发此订阅中的无法递送消息：

维持运营状况良好的发布商

发布者的主要目标是快速保留消息数据。监控此项 性能 topic/send_request_count ，按response_code分组。借助此指标，您可以了解 Pub/Sub 运行状况是否良好以及是否正在接受请求。

可重试错误的后台发生率（低于 1%）不属于 因为大多数 Cloud 客户端库都会重试 消息失败。调查大于 1% 的错误率。 由于不可重试的代码是由应用（而不是客户端库）处理的，因此您应检查响应代码。如果发布者应用没有一种较好的途径表明运行状况不佳，请考虑针对 topic/send_request_count 指标设置提醒。

在发布客户端中跟踪失败的发布请求同样重要。 虽然客户端库通常会重试失败的请求，但不能保证 。请参阅发布消息，了解 使用 Cloud 客户端时检测永久性发布失败的方法 库。您的发布者应用必须至少记录永久性发布错误。如果您将这些错误记录到 Cloud Logging 中，可以使用提醒政策设置基于日志的指标。

监控消息吞吐量

发布者可以批量发送消息。您 您可以使用这些 指标：

  • topic/send_request_count： 发布者发送的批量消息量。

  • 答 计数 （共 topic/message_sizes 个）： 发布商发送的（未批处理）消息的数量。

    您可以通过将计数聚合器应用于此指标或使用 Monitoring Query Language 来计算正在发送的消息数。以下 MQL 查询会创建一个图表，其中包含单个 关于某个主题的消息：

    fetch pubsub_topic
| metric 'pubsub.googleapis.com/topic/message_sizes'
| filter
    (resource.topic_id == '$TOPIC')
| align delta(1m)
| every 1m
| group_by [], [row_count: row_count()]

后续步骤

  • 如需针对特定指标创建提醒，请执行以下操作： 请参阅管理基于指标的提醒政策。

  • 详细了解如何使用 MQL 构建 监控图表，请参阅使用查询编辑器。

  • 如需详细了解 Monitoring API 的 API 资源（例如指标）， 受监控的资源、受监控的资源组和提醒政策， 请参阅 API 资源。