4

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

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

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

如何清除这些事件，以免它们在随机时间触发我的 Azure 函数？

4

2 回答 2

6

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

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

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

于 2018-09-04T21:12:56.690 回答
4

除了@JoshCarlisle 的回答和更清楚的事件网格消息传递和重试文档：

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

以下代码片段显示了死信消息中的一些属性：

"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 ”与“ MaxDeliveryAttemptsExceeded ”

还有一件事：

  • 当死信打开时，事件网格不会立即将死信消息传递到死信端点，而是在大约 300 秒之后。我希望这是一个错误，很快就会修复。实际上，如果订阅者失败，例如HttpStatusCode.BadRequest，我们不能等待来自容器存储的事件 5 分钟，它必须是接近实时的事件驱动。
于 2018-09-05T10:48:58.530 回答