诊断 Azure 事件网格中的故障？

Posted 2023-04-13

【中文标题】诊断 Azure 事件网格中的故障？

【英文标题】：Diagnosing failures in azure event grid?

【发布时间】：2019-02-06 21:57:57

【问题描述】：

我没有找到太多解决 azure 事件网格中事件丢失场景的方法。

因此我就以下情况提出问题：

我们的代码将事件发布到域。 事件被传递到订阅中配置的网络挂钩。 这会持续一段时间。 消费者（拥有 Web 挂钩端点）抱怨说他没有收到一些事件，但大多数都通过了。 我们查看配置的死信队列，发现没有事件。已经超过一天，因此所有重试都已用尽。 因此我们假设所有事件都在传递，因为指标中没有失败的传递事件。 我们还确保确实将这些神秘事件提交到网格。 但消费者坚持认为问题所在，并证明他的身边没有问题。 现在我们需要确定其中一些事件是否被事件网格吞噬。

我该如何解决这种情况？

【问题讨论】：

想到两件事.. 只是建议，因为很难准确回答这一点.. 1) 事件交付指标。 查看计数.. 特别是 Delviery 成功，失败等等。这里有详细的步骤 - docs.microsoft.com/en-us/azure/event-grid/… 2) 确保你的死信配置没有问题。您可以尝试通过尝试发送到您自己的一个总是返回错误的端点（例如 500 或任何 400 系列）来模拟失败的传递，然后查看是否至少这些预期的失败事件显示在配置的 dead字母位置。

为了在模拟失败事件时让您的生活更轻松，您可以将重试策略设置为仅尝试一次或两次（而不是默认的 30） 并降低事件 ttl。详细命令在这里 - docs.microsoft.com/en-us/azure/event-grid/manage-event-delivery

查看我对 Roman 的回复。

【参考方案1】：

当前版本的 AEG 未集成诊断设置功能，该功能非常有助于流式传输指标和日志。

对于基于事件域的场景（仍处于公共预览版，请参阅limits）可以帮助Azure Monitoring REST API 查看特定事件域中的所有指标。

有效的指标是：

PublishSuccessCount,PublishFailCount,PublishSuccessLatencyInMs,MatchedEventCount,DeliveryAttemptFailCount,DeliverySuccessCount,DestinationProcessingDurationInMs,DroppedEventCount,DeadLetteredCount

以下示例是一个 REST GET 请求，用于获取事件域内特定时间跨度和间隔的所有指标值：

https://management.azure.com/subscriptions/mySubId/resourceGroups/myRG/providers/Microsoft.EventGrid/domains/myDomain/providers/Microsoft.Insights/metrics?api-version=2018-01-01&interval=PT1H&aggregation=count,total&timespan=2019-02-06T07:58:12Z/2019-02-07T08:58:12Z&metricnames=PublishSuccessCount,PublishFailCount,PublishSuccessLatencyInMs,MatchedEventCount,DeliveryAttemptFailCount,DeliverySuccessCount,DestinationProcessingDurationInMs,DroppedEventCount,DeadLetteredCount

根据响应值，您可以查看发布者端的 AEG 行为指标以及向订阅者传递的事件。对于您的生产版本，我建议使用轮询技术从 AEG 获取所有指标并将它们推送到事件中心以进行流式分析、警报等。基于查询参数（例如时间跨度、间隔等） ，可以接近实时。当 AEG 支持诊断设置时，此轮询和发布所有指标都已过时，可以继续分析流作业中的小修改。

另一点是为审计部分扩展您的事件模型。我确实推荐以下内容：

添加域范围订阅以捕获事件域中的所有事件并将它们推送到事件中心以进行流式传输。请注意，该事件域中的任何已发布事件都应在此已发布流管道中。

为死信消息添加存储订阅，并将它们推送到同一个事件中心以进行流式传输。

（可选）将死信存储的诊断设置（某些指标）添加到同一事件中心以用于流式传输。请注意，死信消息在尝试将其存储在 blob 容器中 4 小时后将被删除。该失败进程没有任何日志消息，只有指标计数器。

对于客户方面，我确实建议每个订阅者创建一个日志消息（例如标头 + 事件消息）用于审计和故障排除目的。它应该存储在 blob 容器中或本地然后上传等。关键是，此参考对于分析流作业以快速找出问题所在非常有用。

除了您的事件模型之外，您的发布者应该定期（例如每小时一次）探测事件域端点，并且还应该向探测主题发送探测事件消息以进行测试。该探测主题的事件订阅将配置死信选项。订阅者 webhook 处理程序应始终失败，并显示错误代码 = HttpStatusCode.BadRequest，例如没有重试操作。请注意，有 300 秒的延迟时间，死信消息将存储在存储中。换句话说，在探测事件 + 5 分钟后，死信消息应该在流管道中。您的事件模型中的这个探测场景将从视图的发布者和交付点探测 AEG 的功能。

上述解决方案显示在以下屏幕sn-p中：

【讨论】：

我知道我应该相信网格会做正确的事。如果它没有做正确的事情（出于某种原因）怎么办？这可能是由于他们的系统中的错误。如果事件网格实际上为已发布的事件消息提供了一个句柄（作为对发布的响应）并且以后可以使用该句柄来查询该特定事件消息的状态，这不是更简单吗？ azure 通知中心似乎遵循此模型。为什么不是事件网格？对句柄查询的响应可能是已交付、已排队、已失败等。

AEG 基于事件模型，没有数据（消息）管道。一旦事件消息由事件源（Publisher）发布到 AEG 端点，AEG 将根据其订阅保证其交付给订阅者。我希望，AEG 将集成到诊断设置功能中，以流式传输 AEG 的行为。因此，如果您的发布者收到来自事件域端点的 2xx 响应，则 AEG 开始向订阅者传递事件消息。出于审计和故障排除的目的，我们可以使用域订阅者，这是句柄事件的证明。