azure - 诊断 azure 事件网格中的故障？

Question

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

因此我提出与以下场景相关的问题:

1. 我们的代码将事件发布到域。
2. 事件将传送到订阅中配置的网络 Hook 。
3. 这在一段时间内有效。
4. 消费者(拥有网络 Hook 端点)提示说，他没有收到某些事件，但大多数事件都已通过。
5. 我们查看配置的死信队列，发现没有事件。已经超过一天了，因此所有重试都已用尽。
6. 因此，我们假设所有事件都已交付，因为指标中没有失败的交付事件。
7. 我们还确保我们确实向网格提交了这些神秘事件。
8. 但消费者坚持认为这个问题是存在的，并证明他方没有任何问题。
9. 现在我们需要弄清楚其中一些事件是否被事件网格吞没。

如何解决此情况？

Answer 1

当前版本的 AEG 未集成诊断设置功能，该功能可以很好地帮助流式传输指标和日志。

对于基于事件域的场景(仍处于公共(public)预览版，请参阅 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 支持诊断设置时，这种轮询和发布所有指标的行为就会被废弃，并且可以继续对分析流作业进行小的修改。

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

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

2. 添加死信消息的存储订阅，并将其推送到同一事件中心以进行流式传输。

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

对于客户端，我确实建议每个订阅者创建一条日志消息(aeg header + 事件消息)以用于审核和故障排除目的。它应该存储在 blob 容器中或本地然后上传等。重点是，这个引用对于分析流作业以快速找出问题所在非常有用。

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

上述解决方案显示在以下屏幕片段中: