如何查看EventHub流式摄入及事务性更新策略失败的数据？

API 探路者

2026-7-18

关于EventHub流式摄入及事务性更新策略失败数据的处理

1. 能否查看失败涉及的数据？怎么操作？

Kusto内置了专门的监控表来追踪摄入失败，直接查询即可获取详情：
- 查询IngestionFailedOperations表：这张表记录了所有摄入失败的操作，包括失败消息的来源（比如EventHub分区、偏移量）、错误原因、时间戳等。针对特定表筛选的示例语句：
```
IngestionFailedOperations
| where DatabaseName == "你的数据库名" and TableName == "你的表名"
| where OperationType == "StreamingIngest"
| project Timestamp, ErrorMessage, SourcePath, OperationId
```
- 若要排查事务性更新策略的失败，可结合TableOperations表，筛选OperationType为UpdatePolicy的记录，查看策略执行的报错细节。
此外，EventHub本身会保留未成功处理的消息（时长由你设置的消息保留期决定），你可以通过专属消费者组重新读取这些消息；如果配置了死信队列，重试失败的消息会被转移到那里，直接查看死信队列即可获取失败消息内容。

不会默认永久丢失，取决于两个关键配置：
- EventHub消息保留期：默认1天，最长可设为7天。保留期内，未被成功摄入的消息会留在EventHub分区中，只有超过保留期或被手动清理才会删除。
- 死信队列（DLQ）配置：如果启用了死信队列，多次重试失败的消息会被转入死信队列，队列的保留期同样可配置，消息会留存到被处理或过期。
但如果既没开死信队列，消息又超过了EventHub的保留期，这些失败消息就会被永久删除。

启用死信队列：在EventHub的命名空间或实体级别开启死信队列，Kusto流式摄入失败后，无法处理的消息会自动转入死信队列，后续可通过消费者读取这些消息做排查或重新处理。
基于Kusto监控表设告警：针对IngestionFailedOperations表创建告警规则，当出现更新策略错误或流式摄入失败时触发告警，及时知晓问题。
添加中间处理层：如果需要更灵活的控制，可在EventHub和Kusto之间加一层处理（比如Azure Function），先接收消息再调用Kusto摄入API，失败时将消息存入Azure Storage等持久化存储，之后再做重试或人工干预。

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