Pub/Sub API 通过 Cloud Monitoring 导出指标。Cloud Monitoring 允许您以编程方式创建监控信息中心和提醒政策或访问指标。
查看指标
要查看 Cloud Monitoring 信息中心或定义提醒政策，请转到 Google Cloud Console 中的 Monitoring：
您还可以使用 Cloud Monitoring API 来查询和查看订阅和主题的指标。
指标和资源类型
- 要查看 Pub/Sub 向 Cloud Monitoring 报告的使用情况指标，请查看 Cloud Monitoring 文档中的指标列表。
- 如需详细了解
pubsub_topic、pubsub_subscription或pubsub_snapshot受监控的资源类型，请查看 Cloud Monitoring 文档中的受监控的资源类型。
监控主题或订阅配额利用率
您可以使用 API 和服务配额信息中心来监视给定主题或订阅的当前利用率。
这些指标是：
pubsub.googleapis.com/topic/byte_costpubsub.googleapis.com/subscription/byte_cost
请注意，这些指标以字节为单位，而配额则以千字节为单位衡量。
确保订阅者状况良好
监控积压输入量
为了确保订阅者跟上消息流，请创建一个信息中心，用于显示所有订阅的以下指标（按资源聚合）：
subscription/num_undelivered_messagessubscription/oldest_unacked_message_age
创建提醒政策，以便在系统上下文中的这些值异常大时触发。例如，未传送消息的绝对数量不一定有意义。对于每秒传送一百万条消息的订阅，一百万条消息的积压输入量是可以接受的，但对于每秒传送一条消息的订阅却是无法接受的。
| 表现 | 问题 | 解决方案 |
|---|---|---|
oldest_unacked_message_age 和 num_undelivered_messages 同时增长。 |
订阅者未跟上消息量 |
|
如果积压输入量很稳定，数量也少，并且 oldest_unacked_message_age 增长稳定，可能会有少量消息无法得到处理。 |
消息卡住了 | 检查应用日志，了解某些消息是否导致代码崩溃。一种不太可能（但确实有可能发生）的情况是，异常消息卡在 Pub/Sub（而不是客户端）上。一旦您确信代码成功处理了每条消息，请提交支持案例。 |
oldest_unacked_message_age 超出了订阅的消息保留时长。 |
数据永久丢失 | 设置提醒，以便在订阅的消息保留时长到期之前触发。 |
监控确认时限到期
为了缩短消息传送的端到端延迟时间，Pub/Sub 在重新传送给定消息之前，会为订阅者客户端留出一段有限的时间（称为“确认时限”）来确认该消息。如果订阅者长时间无法确认消息，则消息会重新传送，从而导致订阅者看到重复消息。造成这种情况的原因有很多：
订阅者预配不足（您需要更多线程或机器）。
每条消息的处理时间超过消息确认时限。Google Cloud 客户端库通常会延长个别消息的时限（最长为可配置的上限）。不过，客户端库延长消息时限也有上限。
某些消息一直导致客户端崩溃。
测量订阅者对确认时限的错过率可能很有用。具体指标取决于订阅类型：
拉取和流式拉取：
subscription/pull_ack_message_operation_count按response_code != "success"过滤推送：
subscription/push_request_count按response_code != "success"过滤
过高的确认时限到期率可能会导致系统成本效率低下。您需要为每次重新传送以及重复尝试处理每条消息付费。相反，较低的到期率（例如 0.1-1%）可能属于正常情况。
监控推送订阅
对于推送订阅，您还应监控以下指标：
subscription/push_request_count您可以按
response_code和subcription_id对指标分组。由于 Pub/Sub 推送订阅将响应代码用作隐式消息确认，因此监控推送请求响应代码很重要。由于推送订阅在遇到超时情况或错误时会以指数方式退避，因此积压输入量可能会根据端点响应情况而快速增长。您可以考虑针对较高的错误率设置提醒（创建一个按响应类别过滤的指标），因为这些错误率会导致传送速度变慢并且导致积压输入量不断增长。不过，推送请求计数可能更适合作为调查积压输入量大小和时长不断增长的工具。
subscription/num_outstanding_messagesPub/Sub 通常会限制未完成消息的数量。在大多数情况下，未完成消息的数量最好应少于 1000 条。通常，一旦吞吐量达到每秒一万条消息的数量级，服务就会根据订阅的总体吞吐量调整限制（以 1000 为增量）。除了最大值之外，系统不会提供任何具体的保证，因此您不妨将 1000 作为参考数量。
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 会自动确认与过滤条件不匹配的消息。您可以监控这些消息的数量、大小和费用。
如需监控与过滤条件不匹配的消息数量，请使用带有 delivery_type 标签和 filter 值的 subscription/ack_message_count 指标。
如需监控与过滤条件不匹配的消息的大小和费用，请使用带有 operation_type 标签和 filter_drop 值的 subscription/byte_cost 指标。如需详细了解这些消息的费用，请参阅 Pub/Sub 定价页面。
监控死信主题
如要监控转发到死信主题的消息，请使用具有死信主题的订阅中的 subscription/dead_letter_message_count 指标。
要验证是否已成功收到转发的消息，请将 subscription/dead_letter_message_count 与死信主题的 topic/send_message_operation_count 指标进行比较。
您还可以使用订阅死信主题的指标来监视死信主题接收的转发消息：
subscription/num_undelivered_messages如果订阅仅接收转发到死信主题的消息，则此指标记录的是订阅者应用未处理的转发消息数。
subscription/oldest_unacked_message_age如果订阅仅接收转发了死信主题的消息，则此指标指示转发到死信主题的消息是否即将过期。
确保发布者状况良好
发布者的主要目标是快速保留消息数据。您可以使用 topic/send_request_count（按 response_code 分组）监控此性能。借助此指标，您可以了解 Pub/Sub 运行状况是否良好以及是否正在接受请求。
由于大多数 Google Cloud 客户端库会针对消息失败而重试，因此可重试的后台错误率（远低于 1%）通常不会导致问题。您应调查大于 1% 的错误率。由于不可重试的代码是由应用（而不是客户端库）处理的，因此您应检查响应代码。如果发布者应用没有一种较好的途径表明运行状况不佳，请考虑针对 send_request_count 指标设置提醒。
此外，在发布客户端中跟踪失败的发布请求也同样重要。虽然客户端库通常会重试失败的请求，但并不能保证发布。请参阅发布消息，了解在使用 Google Cloud 客户端库时检测永久性发布失败的方法。发布者应用至少应记录永久性发布错误。如果您将这些错误记录到 Cloud Logging 中，可以使用提醒政策设置基于日志的指标。