“排队”的 Azure 事件网格 Blob 触发器事件消息存储在哪里，如何清除它们？

Posted 2023-03-28

【中文标题】“排队”的 Azure 事件网格 Blob 触发器事件消息存储在哪里，如何清除它们？

【英文标题】：Where are "queued" Azure Event Grid Blob trigger event messages stored and how can I clear them?

【发布时间】：2019-02-09 22:25:40

【问题描述】：

如果我的术语有点不对，请见谅；我是新手。

我创建了一个 Azure 事件网格订阅，每当我将文件上传到 Blob 存储时，它都会触发一个事件。我有一个响应此事件的 Azure 函数。我终于让这一切正常工作了，但是我有一些来自以前（坏）上传的遗留消息，这些消息定期失败（从 Azure 门户中的“日志”窗口查看相关的 Azure 函数）。就好像它们被存储在某个队列中并定期重试，尽管我不确定它是否是这样工作的。

无论如何，我希望能够清除任何在途或排队的事件，但我不知道在哪里可以找到它们来执行此操作。据我所知，它们只是漂浮在以太中。

我怎样才能清除这些事件，使它们不会在随机时间触发我的 Azure 函数？

【参考方案1】：

如果在尝试传递时返回的不是 200 或 202（OK/Accepted），事件网格将自动重试传递消息。默认情况下，它将重试 24 小时，并使用指数备份，在每个请求之间增加额外的时间，直到它放弃。您看到的是默认进程正在运行。 （您还可以使用存储帐户配置死信处理，以便在最终失败时将未传递的消息存储在某处）。

您可能要查找的是在创建订阅时可以创建的重试策略。可以肯定的是，您可以将最大传递尝试次数设置为 1，这样它就不会重试（并且如果没有打开死信支持，消息基本上会被丢弃）。更多详情请访问https://docs.microsoft.com/en-us/azure/event-grid/manage-event-delivery#set-retry-policy

如果没有该重试策略，我不知道有任何方法可以“出列”已提交的消息 - 您可能必须删除并重新创建对该事件网格主题的订阅。

【讨论】：

非常感谢，这确实澄清了一些事情。尽管目前似乎存在一个错误，其中任何更改超时的尝试都将完全破坏我的事件网格订阅、删除其过滤器等，而让它再次工作的唯一方法是从 Azure Functions 区域重新创建它门户。

删除并重新创建订阅并没有解决我的问题。以前失败的事件显然仍在重试队列中，事件网格试图运行它们。

【参考方案2】：

除了@JoshCarlisle 的回答和更清楚的Event Grid message delivery and retry 文档：

死信在重试策略逻辑中启用了一种特殊情况。 如果死信是开启并且订阅者因 HttpStatusCode.BadRequest 而失败，事件网格将停止重试过程并将事件发送到死信端点。此错误代码表明，交付永远不会成功。

以下代码 sn-p 显示了死信消息中的一些属性：

"deadLetterReason": "UndeliverableDueToHttpBadRequest",
"deliveryAttempts": 1,
"lastDeliveryOutcome": "BadRequest",
"lastHttpStatusCode": 400,

以下列表显示了事件网格将在重试过程中继续的一些状态代码：

HttpStatusCode.ServiceUnavailable
HttpStatusCode.InternalServerError
HttpStatusCode.RequestTimeout
HttpStatusCode.NotFound
HttpStatusCode.Conflict
HttpStatusCode.Forbidden
HttpStatusCode.Unauthorized
HttpStatusCode.NotImplemented
HttpStatusCode.Gone

一些死信属性的例子，当HttpStatusCode.RequestTimeout：

"deadLetterReason":"MaxDeliveryAttemptsExceeded",
"deliveryAttempts":3,
"lastDeliveryOutcome":"TimedOut",
"lastHttpStatusCode":408,

现在，您可以看到 deadLetterReason 属性中描述的上述两种不同情况，例如“UndeliverableDueToHttpBadRequest” vs “MaxDeliveryAttemptsExceeded”

还有一件事：

当死信打开时，事件网格将

不

立即将死信消息传递到死信端点，但在大约 300 秒之后。我希望这是一个错误，很快就会修复。 实际上，如果订阅者失败，例如 HttpStatusCode.BadRequest，我们不能等待 5 分钟来自容器存储的事件，它必须是接近实时的事件驱动。

【讨论】：

死信消息的 5 分钟缓冲区是设计使然。

@dbarkol 延迟 5 分钟的原因是什么？我的测试表明，这不是批处理过程，为什么不能只是 60 秒？我们可以配置它吗？

这是为了帮助减少blob操作的数量。没有办法配置它。

@dbarkol MSDN文档中缺少这部分，所以我刚刚创建了一个问题，github.com/MicrosoftDocs/azure-docs/issues/14706谢谢