简体   繁体   English

Azure 事件网格中的死字不起作用

[英]dead lettering in Azure event grid does not work

As per the Microsoft documentation , Event Grid does not implement retry on specific errors like 400, 413, 401. In such cases Event Grid will either perform dead-lettering on the event or drop the event if dead-letter isn't configured.根据Microsoft 文档,事件网格不会对特定错误(如 400、413、401)实施重试。在这种情况下,事件网格将对事件执行死信处理或在未配置死信时丢弃事件。

So I enabled dead letter on my webhook (receiver endpoint) and produced a 400 error.所以我在我的 webhook(接收端点)上启用了死信并产生了 400 错误。 But it is still not captured in dead letter logs container.但它仍然没有被捕获到死信日志容器中。 Is there something I am missing?有什么我想念的吗?

Please have a look at the Event Grid message delivery and retry - Dead-letter events documentation and see if your configuration is correct.请查看事件网格消息传递和重试 - 死信事件文档并查看您的配置是否正确。

By default, Event Grid doesn't turn on dead-lettering.默认情况下,事件网格不会打开死字。 To enable it, you must specify a storage account to hold undelivered events when creating the event subscription.要启用它,您必须在创建事件订阅时指定一个存储帐户来保存未传递的事件。 You pull events from this storage account to resolve deliveries.您从此存储帐户中提取事件以解决交付问题。

[...] [...]

Before setting the dead-letter location, you must have a storage account with a container.在设置死信位置之前,您必须有一个带有容器的存储帐户。 You provide the endpoint for this container when creating the event subscription.您在创建事件订阅时为此容器提供端点。 The endpoint is in the format of: /subscriptions/<subscription-id>/resourceGroups/<resource-group-name>/providers/Microsoft.Storage/storageAccounts/<storage-name>/blobServices/default/containers/<container-name>终结点的格式为:/subscriptions/<subscription-id>/resourceGroups/<resource-group-name>/providers/Microsoft.Storage/storageAccounts/<storage-name>/ /subscriptions/<subscription-id>/resourceGroups/<resource-group-name>/providers/Microsoft.Storage/storageAccounts/<storage-name>/blobServices/default/containers/<container-name> /default/containers/<container- /subscriptions/<subscription-id>/resourceGroups/<resource-group-name>/providers/Microsoft.Storage/storageAccounts/<storage-name>/blobServices/default/containers/<container-name>

Also, take into account that另外,请考虑到

There's a five-minute delay between the last attempt to deliver an event and when it's delivered to the dead-letter location.从最后一次尝试传递事件到传递到死信位置之间有五分钟的延迟。 This delay is intended to reduce the number of Blob storage operations.此延迟旨在减少 Blob 存储操作的数量。 If the dead-letter location is unavailable for four hours, the event is dropped.如果死信位置在四个小时内不可用,则删除该事件。

声明:本站的技术帖子网页,遵循CC BY-SA 4.0协议,如果您需要转载,请注明本站网址或者原文地址。任何问题请咨询:yoyou2525@163.com.

相关问题 GCP 中的确认截止日期、消息保留期限、死信和重试策略 - Ack Deadline, Message Retention Duration, Dead Lettering and Retry Policy in GCP 网格行单击是否在 Azure 工作簿中实际起作用? - Does grid row click actually work in Azure Workbooks? Azure 事件网格 | 每个事件的主题 - Azure Event Grid | Topic per event 事件网格触发器未触发 Azure 函数 - Event Grid Trigger Not Firing For Azure Functions Azure 具有事件网格触发器扩展的功能 - Azure Functions with Event Grid Trigger Scale Up Azure Cosmos Change Feed 馈入事件网格 - Azure Cosmos Change Feed feeding into Event Grid Azure 事件网格主题的应用程序网关后端池 - Azure Application Gateway backendpool to Event Grid Topic 配置 Azure 事件网格以进行循环分配 - Configure Azure Event Grid for round-robin distribution 路由查询在 Azure IoT 中心事件网格中不起作用 - Routing Query Not Working in Azure IoT Hub Event Grid 事件源映射(对于 AWS MSK-Lambda)是否将消息发送到 aws lambda 中的死信队列? - Does Event Source Mapping (For AWS MSK-Lambda) send messages to dead letter queue in aws lambda?
 
粤ICP备18138465号  © 2020-2024 STACKOOM.COM