Azure Event Grid过期事件处理咨询：能否对过期事件执行操作？

你好！针对你提到的两个需求——记录事件未交付的事实、创建等效死信队列，结合Azure Event Grid的现有功能，我给你整理了可行的方案，同时也说说你遇到的API相关限制：

一、记录事件未交付的事实 #

Event Grid本身提供了诊断日志功能，这是记录未交付（包括过期）事件最直接的方式：

• 你可以在Azure门户里找到你的Event Grid资源，进入「诊断设置」，新增一个设置，勾选「DeliveryFailures」「DeadletteredEvents」这类日志类别，把日志发送到存储账户、Log Analytics工作区或者事件中心。这些日志会详细记录事件的过期时间、交付失败原因、目标端点等信息，完全能满足你留存未交付事实的需求。
• 如果需要通过代码获取这些数据，可以用Azure Monitor的日志查询API来拉取诊断日志内容，但目前确实没有专门的API可以直接轮询"过期事件交付"的列表，得通过诊断日志的查询接口来实现。

二、创建等效的死信队列 #

其实Event Grid原生就支持死信功能，刚好匹配你要的"等效死信队列"需求：

• 在创建Event Grid订阅时，进入「高级配置」选项，启用死信功能，指定目标的存储容器或者服务总线队列/主题。当事件过期或者重试次数耗尽后，就会自动被转发到你配置的死信位置。
• 要是你已经创建了订阅，也可以通过Azure CLI、PowerShell或者ARM模板来更新死信配置，比如Azure CLI的命令示例：

  az eventgrid event-subscription update --name <你的订阅名称> --source-resource-id <事件源的资源ID> --deadletter-endpoint <存储容器URL或服务总线队列ID>
  

• 如果你想自定义死信逻辑（比如不用原生功能自己实现），可以在事件处理端点里判断事件的expirationTime字段，如果事件已过期，就手动把它转发到你自己的队列或存储中，但这种方式需要你自己处理端点的接收和判断逻辑，效率不如原生死信高。

关于API的限制说明 #

你提到的专门用于通知或轮询过期事件交付的API，目前Azure Event Grid确实没有提供。所有关于未交付、过期事件的信息，官方都是推荐通过诊断日志或者死信存储来获取，这是当前的标准处理路径。

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