应用程序/自定义性能计数器记录用于高度可扩展的分布式系统？
应用程序/自定义性能计数器记录用于高度可扩展的分布式系统？
我正在构建一个对规模要求很高的系统（每秒请求量> 100万）。我正在使用Azure服务群集构建这个应用程序。
我已经阅读过并观看了有关ETW日志记录的视频 -
我仍然不确定在我的系统中长期选择哪种日志记录方式。我有一些问题-
- ETW速度快，但它是否支持所有的日志记录功能，例如记录性能计数器，日志级别，如Debug、Info、Warn、Error等等？
- 对于我规模的需求（每秒>100万个请求），应用洞察是否足够好？为什么我应该选择ETW日志记录而不是应用洞察？
- 我可以从ETW日志记录中获得哪些应用洞察无法提供的信息？
- 在应用程序线程/进程方面，ETW相比应用洞察是否显著更好，还是它们相似？
在高度可扩展的分布式系统中，存在以下问题和解决方法：
问题1：ETW是否支持所有的日志功能，如性能计数器的记录，以及不同级别的日志（如Debug、Info、Warn、Error等）？
解决方法：是的，ETW支持根据严重性级别和关键字启用日志记录。
问题2：对于超过每秒一百万个请求的规模要求，应用洞察是否足够？为什么应该使用ETW日志记录而不是应用洞察？
解决方法：正如前面所述，应用洞察并不适用于这种性能和价格方面的大规模使用。应用洞察每秒最多只能处理32K个事件。
问题3：从应用洞察中无法获取到的内容有哪些可以从ETW日志记录中获取到？
解决方法：ETW日志记录提供了性能和灵活性，可以自由选择日志记录的目标。
问题4：ETW与应用洞察在应用程序线程/进程开销方面是否有显著差异？
解决方法：是的，ETW的开销要低得多。它的支持已经集成在操作系统中，速度非常快。
最后的思考：首先要考虑要记录的内容以及对其的处理方式。对于实时监控应用程序的异常和一些指标，将其记录到应用洞察中可能是可接受的，而将其他指标或使用情况的详细信息记录到其他存储（如Azure表格）中进行非实时分析可能更合适。不要把所有的资源都放在一个记录位置，而是确定一个日志策略。
应用洞察的优势在于其丰富的可视化功能，但这是有代价的。Azure数据湖分析不支持开箱即用的可视化功能，但使用Petabytes级别的日志数据进行u-sql分析可能对其他场景有用。
总之，ETW日志记录具有低开销和灵活性，适用于高度可扩展的分布式系统。