Azure Event Grid至Event Hub事件投递失败求助

问题背景 #

• 架构：事件推送至Azure Event Grid端点，订阅者配置为Event Hubs
• 核心症状：多数场景运行正常，偶发事件投递失败
• 当前困境：联系Azure支持4天仅得到“问题似乎在您这边”的反馈；Azure原生诊断工具易用性不足，排查无进展
• 关键诉求：保障零事件丢失

针对性排查与临时兜底方案 #

1. 优先排查Event Hubs侧限流与瓶颈 #

• 核对Event Hubs的**吞吐量单位（TU）**配额：瞬时流量超出TU上限会触发限流，查看Event Hubs指标中的ThrottledRequests维度，确认是否存在周期性限流峰值
• 检查分区负载均衡：若事件发送热点集中在少数分区，会导致单分区限流，通过PartitionId拆分投递失败事件的指标，定位过载分区

2. 拆解Event Grid投递失败的具体错误类型 #

• 忽略诊断工具的易用性问题，聚焦Event Grid指标中的DeliveryFailures，按ErrorType拆分分析：
  • Timeout：大概率是Event Hubs端处理延迟过高，同步检查Event Hubs的IncomingBytes、OutgoingBytes及ProcessorLag指标，确认是否存在消费端堆积
  • Unauthorized：即使已配置权限，也要排查Event Grid的系统身份/访问密钥是否临时过期，或是否存在RBAC权限变更
  • BadRequest：偶发失败可能源于个别事件格式异常（如缺失id/eventTime必填字段、字段格式不符合规范），需对发布的事件做格式校验

3. 启用死信机制兜底防丢失 #

• 配置Event Grid订阅的死信存储（关联存储账户容器），将投递失败的事件暂存至死信队列，避免直接丢失
• 定期导出死信事件，对比正常事件的内容、大小、发布时间，总结失败规律

4. 补充自定义日志缩小排查范围 #

• 事件发布端：为每条事件生成唯一ID，记录发布时间、Event Grid响应状态码及响应信息
• Event Hubs消费端：记录收到的事件ID，对比发布端日志，确认是投递环节丢失还是消费端未捕获

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