GCP PubSub未投递消息与死信消息指标差异

你的认知偏差核心是把「暂时未投递成功的积压消息」和「已经触发死信转发规则的消息」混为一谈了，这两个指标统计语义、数据类型、统计维度完全不同，正常场景下数值根本不会一致：

两个指标的具体定义 #

• subscription/num_undelivered_messages
  这是瞬时存量值（Gauge类型），统计的是当前时刻留在该订阅消息backlog（积压队列）里、还没被消费者成功确认（ack）的消息总数。
  只要消息还没被成功消费、没被过期清理、没达到死信转发阈值，不管它是刚入队还没第一次投递，还是已经重试了几次还没成功，都会被算在这个指标里。它是用来监控普通消费积压的核心指标，和死信没有强绑定关系。
• subscription/dead_letter_message_count
  这是累计增量值（Counter类型），统计的是从订阅创建至今，已经满足死信触发条件、成功转发到绑定死信主题的消息总次数。
  注意这个值是只增不减的累计值，哪怕死信里的消息后续被消费处理了，这个计数也不会下降；而且只有转发动作真的成功完成，才会被计入。

两者数值不会一致的核心原因 #

不是所有未投递消息都会进入死信，死信转发有严格的触发前提：

• 订阅必须显式开启死信转发配置，没开的情况下，消息达到最大投递次数后会被直接丢弃，根本不会产生死信计数，此时dead_letter_message_count始终为0，但消费卡住时num_undelivered_messages会持续上涨。
• 就算开了死信配置，消息只有达到设置的max_delivery_attempts（最大投递尝试次数）阈值，才会触发转发。没达到阈值的重试消息，哪怕暂时投递失败，也只会留在原订阅的backlog里继续等待重试，只会被计入num_undelivered_messages，不会算在死信计数里。
• 就算消息达到了重试阈值，如果因为权限不足、死信主题被删除等原因导致转发失败，消息也不会被计入死信计数，会回到原订阅backlog继续重试。

死信告警的实用配置建议 #

如果你要搭建死信队列告警，不要直接用原业务订阅的这两个指标：

• 要监控死信的实际积压量，应该取死信主题对应的消费订阅上的num_undelivered_messages指标，这个值才是真正留在死信队列里没被处理的消息存量。
• 原业务订阅的dead_letter_message_count适合配置增量告警，比如统计5分钟内的指标增量，超过阈值就触发告警，用来感知短时间内大量消息投递失败转死信的异常。
• 原业务订阅的num_undelivered_messages只用来做普通消费积压告警，数值升高只代表消费者处理能力不足，不代表已经有消息进入死信。

内容的提问来源于stack exchange，提问作者osumatu