在 Cloud Monitoring 中监控 Pub/Sub

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

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

• 如果您想查看 Pub/Sub 指标以外的其他 Google Cloud 资源的指标，请使用 Monitoring。

• 否则，您可以使用 Pub/Sub 中提供的监控信息中心。请参阅监控主题和监控订阅。

如需了解在自动伸缩中使用指标的最佳实践，请参阅将 Pub/Sub 指标用作伸缩信号的最佳实践。

准备工作

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

• Cloud Billing 账号

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

确保您已获得这两项资格的一种方法是完成快速入门：使用 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 指标

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

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

   转到“监控”

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

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

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

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

6. 展开特定指标，然后点击应用。

   系统会打开特定指标的页面。

如需详细了解监控信息中心，请参阅 Cloud Monitoring 文档。

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

• 如需查看 Pub/Sub 向 Cloud Monitoring 报告的指标，请参阅 Cloud Monitoring 文档中的 Pub/Sub 指标列表。

• 如需详细了解 pubsub_topic、pubsub_subscription 或 pubsub_snapshot 受监控的资源类型，请参阅 Cloud Monitoring 文档中的受监控的资源类型。

访问 MQL 编辑器

Metrics Explorer 是 Cloud Monitoring 中的一款界面，旨在探索和直观呈现指标数据。在指标浏览器中，您可以使用 Monitoring Query Language(MQL) 查询和分析 Pub/Sub 指标。

如需在使用 Metrics Explorer 时访问 MQL 编辑器，请参阅访问代码编辑器。

构建 MQL 查询

下面是构建 Pub/Sub 指标 MQL 查询的一些基本规则。

1. 以 fetch pubsub_topic 或 fetch pubsub_subscription 开头。这行代码会告知编辑器您要查询哪种类型的 Pub/Sub 资源，例如主题或订阅。

2. 选择指标。使用 | metric 'metric_name' 指定要分析的指标。Pub/Sub 指标示例为 pubsub.googleapis.com/subscription/ack_message_count（适用于已确认的消息）。

3. 使用 | filter 缩小数据范围。常见过滤条件包括：

   • resource.project_id == 'your-project-id'
   • resource.topic_id == 'your-topic-id'
   • resource.subscription_id == 'your-subscription-id'

4. 使用 | align 和 | group_by 将数据汇总到有意义的间隔和分组中。

5. 使用其他子句来优化数据。MQL 还提供了各种其他子句，例如 | every（用于设置查询执行频率）、| within（用于指定时间范围）等。

以下是用于监控向特定订阅发送的消息的每小时计数的查询示例：

fetch pubsub_subscription
| metric 'pubsub.googleapis.com/subscription/sent_message_count'
| filter resource.project_id == 'your-project-id'
&& resource.subscription_id == 'your-subscription-id'
| align delta(1h)
| every 1h
| group_by [], [value_sent_message_count_aggregate: aggregate(value.sent_message_count)]

监控配额使用情况

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

您可以通过以下指标查看历史配额使用情况：

• serviceruntime.googleapis.com/quota/rate/net_usage
• serviceruntime.googleapis.com/quota/limit

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

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

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

如果您预计用量会超出默认配额限制，请为所有相关配额创建提醒政策。当您的用量达到上限的一小部分时，系统会触发这些提醒。例如，当任何 Pub/Sub 配额超过 80% 时，以下 Monitoring 查询语言查询会触发提醒政策：

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 提供的指标监控多个订阅属性。例如，您可以监控未确认消息的数量、消息确认期限的到期时间等。您还可以检查订阅是否足够稳定，以实现较短的消息传送延迟时间。

如需详细了解特定指标，请参阅以下部分。

监控消息积压

为了确保订阅者跟上消息流，请创建一个信息中心。该信息中心可以显示所有订阅的以下积压工作指标（按资源聚合）：

• 未确认的消息 (subscription/num_undelivered_messages)，用于查看未确认消息的数量。

• 最早的未确认消息的存在时间 (subscription/oldest_unacked_message_age)，用于查看订阅积压工作中最早的未确认消息的存在时间。

• 递送延迟时间健康状况得分 (subscription/delivery_latency_health_score)，用于检查与递送延迟时间相关的整体订阅健康状况。如需详细了解此指标，请参阅本文档的相关部分。

创建提醒政策，以便在系统上下文中的这些值超出可接受范围时触发。例如，未确认消息的绝对数量不一定有意义。对于每秒传送一百万条消息的订阅，一百万条消息的积压输入量是可以接受的，但对于每秒传送一条消息的订阅却是无法接受的。

常见的积压问题

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

在 Pub/Sub 中，传送延迟时间是指从发布消息到将消息传送给订阅者所用的时间。如果消息积压量不断增加，您可以使用传送延迟时间健康评分 (subscription/delivery_latency_health_score) 检查导致延迟时间增加的因素。

此指标用于衡量单个订阅在 10 分钟滚动时间范围内的运行状况。该指标可深入了解以下条件，这些条件对于订阅实现一致的低延迟至关重要：

• 忽略的跳转请求。

• 忽略的未确认消息 (nacked) 消息。

• 消息确认截止期限过期时间可以忽略不计。

• 一致的确认延迟时间不超过 30 秒。

• 始终处于较低的利用率，这意味着订阅始终有足够的容量来处理新消息。

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

• 跳转请求：如果订阅在过去 10 分钟内有任何跳转请求，则得分设为 0。查找订阅可能会导致在旧消息首次发布后很长时间内重放这些消息，从而增加其传送延迟时间。

• 收到否定确认 (nack) 的消息：如果订阅在过去 10 分钟内收到了任何否定确认 (nack) 请求，则得分会设为 0。否定确认会导致系统重新递送消息，并延长递送延迟时间。

• 已过期的确认时限：如果订阅在过去 10 分钟内有任何已过期的确认时限，则得分会设为 0。确认截止期限已过的消息会重新传送，并且传送延迟时间会增加。

• 确认延迟时间：如果过去 10 分钟内所有确认延迟时间的 99.9 百分位数曾经超过 30 秒，则得分会设为 0。确认延迟时间过长表明订阅方客户端在处理消息时花费的时间异常长。此得分可能表明订阅方客户端存在 bug 或一些资源限制。

• 利用率偏低：系统会针对每种订阅类型采用不同的利用率计算方式。

  • StreamingPull：如果您没有打开足够的串流，则得分会设为 0。打开更多串流，以确保您有足够的容量来处理新消息。

  • 推送：如果您有太多待处理的消息发送到推送端点，则得分会设为 0。为您的推送端点增加容量，以便有足够的容量来处理新消息。

  • 拉取：如果您没有足够的待处理拉取请求，则得分会设为 0。打开更多并发拉取请求，确保您已准备好接收新消息。

如需查看该指标，请在 Metrics Explorer 中，为 Pub/Sub 订阅资源类型选择传送延迟时间健康评分指标。添加过滤条件，以便一次只选择一个订阅。选择堆叠面积图，然后将光标指向特定时间，查看相应时间点订阅的条件得分。

以下屏幕截图显示了使用堆叠面积图绘制的一小时时间段的指标。到凌晨 4:15，综合健康得分达到 5 分，每项标准的分数均为 1 分。之后，在凌晨 4:20 时，利用率得分降至 0，而综合得分也降至 4。

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 会为订阅者客户端留出一段有限的时间来确认（ACK）给定消息。此时间段称为 ACK 截止期限。如果订阅者长时间无法确认消息，则消息会重新传送，从而导致订阅者看到重复消息。导致重新提交的原因有很多：

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

• 每条消息的处理时间超过消息确认时限。Cloud 客户端库通常会延长个别消息的时限（最长为可配置的上限）。不过，客户端库延长消息时限也有上限。

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

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

• 拉取和 StreamingPull：subscription/expired_ack_deadlines_count

• 推送：subscription/push_request_count 按 response_code != "success" 过滤

过高的确认时限到期率可能会导致系统成本效率低下。您需要为每次重新传送以及重复尝试处理每条消息付费。相反，较低的到期率（例如 0.1-1%）可能属于正常情况。

监控消息吞吐量

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

• 拉取：subscription/pull_request_count（请注意，此指标可能还包括返回了无消息的拉取请求）

• StreamingPull： subscription/streaming_pull_response_count

您可以使用按 delivery_type 标签过滤的指标 subscription/sent_message_count 监控订阅者正在处理的个别或非批量消息吞吐量。

以下 MQL 查询会生成一个时间序列图表，显示每 10 分钟向特定 Pub/Sub 订阅发送的消息总数。将 $PROJECT_NAME 和 $SUBSCRIPTION_NAME 的占位符值替换为您的实际项目和主题标识符。

fetch pubsub_subscription
| metric 'pubsub.googleapis.com/subscription/sent_message_count'
| filter resource.project_id == '$PROJECT_NAME'
&& resource.subscription_id == '$SUBSCRIPTION_NAME'
| align delta(10m)
| every 10m
| group_by [],
[value_sent_message_count_aggregate: aggregate(value.sent_message_count)]

监控推送订阅

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

• subscription/push_request_count

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

  您可以考虑针对较高的错误率设置提醒，因为这些错误率会导致传送速度变慢并且导致积压输入量不断增长。您可以创建按响应类别过滤的指标。不过，推送请求计数可能更适合作为调查积压输入量大小和时长不断增长的工具。

• subscription/num_outstanding_messages

  Pub/Sub 通常会限制未完成消息的数量。在大多数情况下，未完成消息的数量最好应少于 1,000 条。当吞吐量达到每秒 1 万条消息的数量级后，该服务会调整未处理消息数量的上限。此限制以 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。

如需监控与过滤条件不匹配的自动确认消息的吞吐量和费用，请使用将 operation_type 标签设置为 filter_drop 的 subscription/byte_cost 指标。如需详细了解这些消息的费用，请参阅 Pub/Sub 定价页面。

监控转发的无法传送的消息

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

如需验证 Pub/Sub 是否正在转发无法传送的消息，您可以将 subscription/dead_letter_message_count 指标与 topic/send_request_count 指标进行比较。针对 Pub/Sub 将这些消息转发到的死信主题进行比较。

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

• subscription/num_undelivered_messages

  订阅中累积的转发消息数

• subscription/oldest_unacked_message_age

  订阅中最早转发的消息的存在时间

确保发布商状况良好

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

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

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

监控消息吞吐量

发布商可能会批量发送消息。您可以使用以下指标监控发布商发送的消息吞吐量：

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

• topic/message_sizes 计数：发布者正在发送的个别（非批量）消息的数量。

如需获取已发布消息的确切计数，请使用以下 MQL 查询。此 MQL 查询可有效检索在指定时间间隔内发布到特定 Pub/Sub 主题的个别消息的数量。将 $PROJECT_NAME 和 $TOPIC_ID 的占位符值替换为您的实际项目和主题标识符。

fetch pubsub_topic
| metric 'pubsub.googleapis.com/topic/message_sizes'
| filter resource.project_id == '$PROJECT_NAME'
&& resource.topic_id == '$TOPIC_ID'
| align delta(60m)
| every 60m
| group_by [resource.topic_id],
[value_message_sizes_sum: count(value.message_sizes)]

为了更好地直观呈现数据（尤其是每日指标），请考虑以下事项：

• 查看更长时间段内的数据，以便更好地了解每日趋势。

• 使用条形图来表示每日消息数。

后续步骤

• 如需为特定指标创建提醒，请参阅管理基于指标的提醒政策。

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

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