Google 会使用 AI 技术将内容翻译成您偏好的语言。AI 翻译可能包含错误。

在 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 指标作为伸缩信号的最佳实践。

准备工作

在使用监控功能之前，请确保您已做好以下准备：

Cloud Billing 账号
启用了结算功能的 Pub/Sub 项目

确保您已获得这两项权限的一种方法是完成快速入门：使用 Cloud 控制台。

查看现有信息中心

通过信息中心，您可以在同一上下文中查看和分析来自不同来源的数据。Google Cloud 提供预定义信息中心和自定义信息中心。例如，您可以查看预定义的 Pub/Sub 信息中心，也可以创建自定义信息中心来显示与 Pub/Sub 相关的指标数据、提醒政策和日志条目。

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

在 Google Cloud 控制台中，前往 Monitoring 页面。

转到“监控”
选择您的项目名称（如果尚未在页面顶部选择该名称）。
点击导航菜单中的信息中心。
在信息中心概览页面中，创建新信息中心或选择现有的 Pub/Sub 信息中心。

如需搜索现有的 Pub/Sub 信息中心，请在所有信息中心的过滤条件中选择名称属性，然后输入 Pub/Sub。

如需详细了解如何创建、修改和管理自定义信息中心，请参阅管理自定义信息中心。

查看单个 Pub/Sub 指标

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

在 Google Cloud 控制台中，前往 Monitoring 页面。

转到“监控”
在导航窗格中，选择 Metrics Explorer。
在配置部分，点击选择指标。
在过滤条件中，输入 Pub/Sub。
在活跃资源中，选择 Pub/Sub 订阅或 Pub/Sub 主题。
向下钻取到特定指标，然后点击应用。

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

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

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

如需查看 Pub/Sub 向 Cloud Monitoring 报告的指标，请参阅 Cloud Monitoring 文档中的 Pub/Sub 指标列表。
如需查看 pubsub_topic、pubsub_subscription 或 pubsub_snapshot 受监控的资源类型的详细信息，请参阅 Cloud Monitoring 文档中的受监控的资源类型。

访问 PromQL 编辑器

Metrics Explorer 是 Cloud Monitoring 中的一个界面，旨在帮助您探索和直观呈现指标数据。在 Metrics Explorer 中，您可以使用 Prometheus 查询语言 (PromQL) 查询和分析 Pub/Sub 指标。

如需在 Metrics Explorer 中访问代码编辑器并使用 PromQL 查询 Cloud Monitoring 指标，请参阅使用 PromQL 代码编辑器。

例如，您可以输入 PromQL 查询，以监控在过去 1 小时内发送到特定订阅的消息数量：

sum(
  increase({
    "__name__"="pubsub.googleapis.com/subscription/sent_message_count",
    "monitored_resource"="pubsub_subscription",
    "project_id"="your-project-id",
    "subscription_id"="your-subscription-id"
  }[1h])
)

监控配额用量

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

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

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

例如，以下 PromQL 查询会创建一个图表，其中显示每个区域中使用的发布商配额的比例：

sum by (quota_metric, location) (
  rate({
    "__name__"="serviceruntime.googleapis.com/quota/rate/net_usage",
    "monitored_resource"="consumer_quota",
    "service"="pubsub.googleapis.com",
    "quota_metric"="pubsub.googleapis.com/regionalpublisher"
  }[${__interval}])
)
/
(max by (quota_metric, location) (
  max_over_time({
    "__name__"="serviceruntime.googleapis.com/quota/limit",
    "monitored_resource"="consumer_quota",
    "service"="pubsub.googleapis.com",
    "quota_metric"="pubsub.googleapis.com/regionalpublisher"
  }[${__interval}])
) / 60 )

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

sum by (quota_metric, location) (
  increase({
    "__name__"="serviceruntime.googleapis.com/quota/rate/net_usage",
    "monitored_resource"="consumer_quota",
    "service"="pubsub.googleapis.com"
  }[1m])
)
/
max by (quota_metric, location) (
   max_over_time({
    "__name__"="serviceruntime.googleapis.com/quota/limit",
    "monitored_resource"="consumer_quota",
    "service"="pubsub.googleapis.com"
  }[1m])
)
> 0.8

如需详细了解如何更精细地监控配额指标并发出提醒，请参阅使用配额指标。

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

保持健康的订阅

为了保持订阅的健康状态，您可以使用 Pub/Sub 提供的指标监控多个订阅属性。例如，您可以监控未确认消息的数量、消息确认截止期限的到期情况等。您还可以检查订阅是否足够健康，以实现较低的消息传送延迟时间。

如需详细了解具体指标，请参阅下文。

监控消息积压

为确保订阅者及时了解消息流，请创建一个信息中心。该信息中心可以显示以下积压工作指标（按资源汇总），适用于您的所有订阅：

未确认的消息 (subscription/num_unacked_messages_by_region)，以查看未确认的消息数量。
最早的未确认消息的存在时长 (subscription/oldest_unacked_message_age_by_region)，可用于查看订阅积压中最早的未确认消息的存在时长。
递送延迟时间健康状况得分 (subscription/delivery_latency_health_score)，用于检查订阅在递送延迟时间方面的总体健康状况。如需详细了解此指标，请参阅本文档的相关部分。

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

使用指标的区域版本，而不是全球版本

Pub/Sub 提供用于监控订阅积压的指标的区域级和全球级版本。请务必使用带有 by_region 后缀的区域版本：

subscription/num_unacked_messages_by_region（而不是 subscription/num_undelivered_messages）
subscription/oldest_unacked_message_age_by_region（而不是 subscription/oldest_unacked_message_age）

如果您希望监控信息中心和提醒政策能够灵活应对单区域服务中断，请勿使用这些指标的全球版本。这些指标的全局版本需要计算已知有消息的所有区域的积压，这意味着单个区域的不可用会导致数据缺口。相比之下，by_region 版本的指标会按区域计算和报告积压情况。如果无法计算单个区域的积压工作量，该指标仍会报告其他区域的值。

常见的积压问题

表现	问题	解决方案
`oldest_unacked_message_age_by_region` 和 `num_unacked_messages_by_region` 同时增长。	订阅者无法及时处理大量消息	添加更多订阅者线程或进程。添加更多订阅者机器或容器。查找代码中阻止其成功确认消息或及时处理消息的 bug 迹象。请参阅监控确认时限到期。
如果积压任务大小稳定且较小，但 `oldest_unacked_message_age_by_region` 稳步增长，则可能存在一些无法处理的消息。	消息卡住了	检查应用日志，了解是否有某些消息导致代码崩溃。虽然不太可能，但违规消息有可能卡在 Pub/Sub 中，而不是在您的客户端中。在您确信代码可以成功处理每条消息后，请提交支持请求。如果某些消息导致您的代码崩溃，请考虑将这些消息转发到死信主题。
`oldest_unacked_message_age_by_region` 超过了订阅消息保留时长。	数据永久丢失	设置在消息保留时长即将到期之前触发的提醒。

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

在 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。之后，当利用率得分降至 0 时，综合得分在凌晨 4:20 降至 4。

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

PromQL 为 Cloud Monitoring 时序数据提供了一个功能强大的基于文本的界面。以下 PromQL 查询会创建一个图表，用于衡量订阅的递送延迟时间健康状况得分。

sum_over_time(
  {
    "__name__"="pubsub.googleapis.com/subscription/delivery_latency_health_score",
    "monitored_resource"="pubsub_subscription",
    "subscription_id"="$SUBSCRIPTION"
  }[${__interval}]
)

监控确认时限到期

为了缩短消息传送延迟时间，Pub/Sub 允许订阅方客户端在有限的时间内确认 (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 监控订阅者正在处理的个别（即非批量）消息吞吐量。

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

sum(
  increase({
    "__name__"="pubsub.googleapis.com/subscription/sent_message_count",
    "monitored_resource"="pubsub_subscription",
    "project_id"="$PROJECT_NAME",
    "subscription_id"="$SUBSCRIPTION_NAME"
  }[10m])
)

监控推送订阅

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

subscription/push_request_count

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

建议您针对高错误率设置提醒，因为这些错误率会导致传送速度缓慢，并导致积压的邮件越来越多。您可以创建按响应类别过滤的指标。不过，推送请求计数可能更适合用于调查不断增加的积压大小和积压时间。
subscription/num_outstanding_messages

Pub/Sub 通常会限制未完成消息的数量。在大多数情况下，待处理消息的数量应少于 1,000 条。当吞吐量达到每秒 10,000 条消息的速率时，该服务会调整未处理消息数量的限制。此限制以 1,000 为增量。除了最大值之外，我们不提供任何具体保证，因此 1,000 条未处理的消息是一个不错的参考值。
subscription/push_request_latencies

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

如需使用更高的未处理消息限额，推送订阅者必须确认其收到的 99% 以上的消息。

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

rate({
  "__name__"="pubsub.googleapis.com/subscription/push_request_count",
  "monitored_resource"="pubsub_subscription",
  "subscription_id"="$SUBSCRIPTION",
  "response_class"="ack"
}[${__interval}])
/
rate({
  "__name__"="pubsub.googleapis.com/subscription/push_request_count",
  "monitored_resource"="pubsub_subscription",
  "subscription_id"="$SUBSCRIPTION"
}[${__interval}])

使用过滤条件监控订阅

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

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

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

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

使用 SMT 监控订阅

如果您的订阅包含会滤除消息的 SMT，那么在 SMT 实际运行之前，积压指标会包含被滤除的消息。这意味着，积压量可能会显得更大，最早的未确认消息的存在时间可能会显得比将传送给订阅者的消息更长。如果您使用这些指标来自动扩缩订阅者，请务必牢记这一点。

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

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

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

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

subscription/num_unacked_messages_by_region

订阅中累积的转发消息数量
subscription/oldest_unacked_message_age_by_region

订阅中最旧的转发消息的存在时长

确保发布者状况良好

发布者的主要目标是快速保留消息数据。使用 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 的计数：发布者正在发送的个别（非批量）消息的数量。

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

sum by (topic_id) (
  increase({
    "__name__"="pubsub.googleapis.com/topic/message_sizes_count",
    "monitored_resource"="pubsub_topic",
    "project_id"="$PROJECT_NAME",
    "topic_id"="$TOPIC_ID"
  }[${__interval}])
)

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

查看更长时间段的数据，以便更全面地了解每日趋势。
使用条形图表示每日消息数量。

后续步骤

如需为特定指标创建提醒，请参阅管理基于指标的提醒政策。
如需详细了解如何使用 PromQL 构建监控图表，请参阅使用 PromQL 代码编辑器。
如需详细了解 Monitoring API 的 API 资源（例如指标、受监控的资源、受监控的资源组和提醒政策），请参阅 API 资源。

在 Cloud Monitoring 中监控 Pub/Sub 使用集合让一切井井有条 根据您的偏好保存内容并对其进行分类。

准备工作

查看现有信息中心

查看单个 Pub/Sub 指标

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

访问 PromQL 编辑器

监控配额用量

保持健康的订阅

监控消息积压

使用指标的区域版本，而不是全球版本

常见的积压问题

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

监控确认时限到期

监控消息吞吐量

监控推送订阅

使用过滤条件监控订阅

使用 SMT 监控订阅

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

确保发布者状况良好

监控消息吞吐量

后续步骤

在 Cloud Monitoring 中监控 Pub/Sub