问题描述

使用Azure的虚拟机集VMSS中部署应用程序，通过它的扩展WAD(Window Azure Diagnostic)来授权系统及应用层面的全部事件日志，并发送到Event Hub中。

只是，通过EventHub收集到的日志，发现丢失了一部分事件日志。并且在VMSS中收集到的日志文件中，可以发现下列错误信息：

1. Failed to publish data to event EventXXXXXXXXXXXXXXXXXXXXXX; event hub xxxxxxxxx.servicebus.chinacloudapi.cn\/xxxxxx is too busy
2. There are more than 50 batches in the queue for EventHub.
3. Operation could not be completed within the specified time

基于以上信息，是否是接收端Event Hub达到了瓶颈了呢？

问题解答

对于错误消息 event hub xxxx is too busy，初步判断是怀疑Event Hub服务端的瓶颈。因为Event Hub的吞吐量是存在限制的。

事件中心的吞吐量容量由“吞吐量单位”控制。 单个吞吐量单位限制为：

• 流入量：最高每秒 1 MB，或每秒 1000 个事件（以先达到的限制为准）。
• 流出量：最高每秒 2 MB，或每秒 4096 个事件。

当流入量受限，事件中心将引发 EventHubsException（“原因”值为 ServiceBusy）。

如果Event Hub服务端出现限流并报错Service Busy，会在Azure Event Hub门户指标上显示。但是，在WAD报错event hub xxxxxxxxx.servicebus.chinacloudapi.cn\/xxxxxx is too busy的时间点上，并没有发现Event Hub的Service Busy报错指标。

所以，在排除Event Hub服务端之后，回到WAD客户端的配置，根据 “There are more than 50 batches in the queue for EventHub.” 分析到50是WAD 客户端的源代码中硬编码，无法配置和修改。

如果WAD所在的实例上的日志数据数据量太大，在发送给Event Hub服务之前，在Queue中已经有50个batch后 (即本地缓存池已满，消息的生成速度 > 发送速度)，就会出现There are more than 50 batches in the queue for EventHub 报错信息。

如果是客户端生成的日志事件过多，合理的解决方案有：

1）增加VMSS中的实例数，让应用分配到更多实例上，减少单个实例上生产日志的速度。最终达到消息的生成速度<发送速度

2）修改WAD的 sinks 配置，对事件日志进行分类，减少单个sinks发送渠道压力

参考资料

吞吐量单位 ： https://docs.azure.cn/zh-cn/event-hubs/event-hubs-scalability#throughput-units

Send data from Microsoft Azure diagnostics extension to Azure Event Hubs : https://learn.microsoft.com/en-us/azure/azure-monitor/agents/diagnostics-extension-stream-event-hubs

当在复杂的环境中面临问题，格物之道需：浊而静之徐清，安以动之徐生。 云中，恰是如此!