问题描述
使用Azure的虚拟机集VMSS中部署应用程序，通过它的扩展WAD(Window Azure Diagnostic)来授权系统及应用层面的全部事件日志，并发送到Event Hub中。
只是，通过EventHub收集到的日志，发现丢失了一部分事件日志。并且在VMSS中收集到的日志文件中，可以发现下列错误信息：
- Failed to publish data to event EventXXXXXXXXXXXXXXXXXXXXXX; event hub xxxxxxxxx.servicebus.chinacloudapi.cn\/xxxxxx is too busy
- There are more than 50 batches in the queue for EventHub.
- 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
当在复杂的环境中面临问题，格物之道需：浊而静之徐清，安以动之徐生。 云中，恰是如此!