c# - 高度可扩展的分布式系统的应用程序/自定义性能计数器日志记录?

标签 c# azure azure-service-fabric azure-application-insights etw

我正在构建一个具有高规模要求的系统(每秒 > 100 万个请求)。我正在使用 Azure 服务结构集群构建此应用程序。

我已经阅读并观看了有关 ETW 日志记录的视频 - https://blogs.msdn.microsoft.com/vancem/2012/08/13/windows-high-speed-logging-etw-in-c-net-using-system-diagnostics-tracing-eventsource/

http://answers.flyppdevportal.com/MVC/Post/Thread/b0302547-7ffb-4ff2-aef6-6e15ebe695b3?category=azureservicefabric

https://learn.microsoft.com/en-us/azure/service-fabric/service-fabric-diagnostics-event-aggregation-wad

我仍然不确定登录系统的长期选择是什么。我的一些问题 -

  1. ETW 速度很快,但它支持所有日志记录功能吗?记录性能计数器、日志级别即。调试、信息、警告、错误等
  2. 对于我的规模要求(每秒超过 100 万个请求),应用程序洞察力是否足够好?为什么我应该使用 ETW 日志记录而不是应用洞察?
  3. 哪些内容是我无法从 ETW 日志记录中获得的应用洞察中获得的?
  4. 就应用程序线程/进程的开销而言,ETW 明显优于应用程序洞察,还是相似?

最佳答案

我认为您试图将苹果与橙子进行比较,让我解释一下原因。

人工智能

Application Insights (AI) 是一个接收器,这意味着您使用 SDK 记录一些内容,它会将其发送到 AI。 AI会缓冲写入的事件,并每隔一段时间(我相信默认是30秒)使用http调用将它们发送到云端。

人工智能绝不适合用于大规模、大规模的日志记录。如果您查看定价,您会发现当大量数据传入时,您会付出高昂的代价。

ETW

ETW 并不是真正的接收器。您可以将任何内容记录到事件源,但只要没有附加监听器,您的事件就不会发生。监听器确定事件记录到的位置。

对于大规模指标日志记录,团队扩展了 EventSource,支持 EventCounters(请参阅 this doc)

ETW 的好处是您可以在同一进程中附加一个监听器,该监听器也写入 EventSource,或者您可以在单独的进程(在同一台计算机上)中创建监听器,然后您可以配置日志记录的位置到。这可以是稍后分析或处理的 ETL 文件,也可以转到 Azure EventHub 等大规模数据摄取端点,然后从那里转到数据湖或 Blob 存储等以进行进一步分析。

问题

ETW is fast, but does it support all logging features viz. logging performance counters, log levels viz. Debug, Info, Warn, Error etc.

是的,确实如此。您可以按严重性级别和/或关键字启用日志记录。

For my scale requirements (>1million requests per sec) Is application insights good enough ? Why should I used ETW logging over App insights ?

正如所解释的,我认为人工智能在性能和价格方面并不适合这种规模。尽管数据是在单独的线程中收集/缓冲的,但它并不是为处理这种负载而设计的。限制为每秒 32K 事件 ( source )

What can I not get from application insights that I can get from ETW logging ?

记录事件结束位置的性能和灵 active 。

In terms of overhead on application thread/process is ETW significantly better than application insights or they are similar ?

不,它们不相似,ETW 的开销要低得多。它的支持是在操作系统中内置的,而且速度非常快。

您可以使用EventFlow正如评论中所建议的,它确实支持进程内和进程外的 EventSource 监听器。

如果您最终使用其他日志记录框架,请选择一个支持 structured logging 的框架正如 ETW 所做的那样。

最终想法

我认为你应该首先考虑你想要记录什么以及你想用它做什么。将异常和一些指标记录到 AI 是完全可以接受的,这样您就可以实时监控应用程序,并将其他指标或使用详细信息记录到另一个存储(例如 Azure 表)以进行非实时分析。不要把所有的钱都放在一个水槽上,而是首先确定日志策略。

人工智能的优势在于丰富的可视化,但这是有代价的。 Azure Data Lake 分析不支持开箱即用的可视化,但在 PB 级日志数据上使用 u-sql 对于其他场景可能很有用。我希望你明白我的意思。

关于c# - 高度可扩展的分布式系统的应用程序/自定义性能计数器日志记录?,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/50440234/

相关文章:

c# - 当我在 ServiceFabric 群集上使用 EventFlow 监听 ETW 事件时出现“系统资源不足”

c# - 如何临时禁用/关闭 ReSharper 2016?

c# - 使用 AzCopy C# 复制文件

c# - linq选择日期之间的位置

azure - 如何在 Azure SQL MI 实例上设置针对已用存储空间百分比的警报?

php - 在php中获取azure存储中的Blob目录名称

具有 Service Fabric 的 Azure 应用程序网关

powershell - 使用 AzureAD 身份验证部署 ServiceFabric 应用程序

c# - 显示不带小数点的数字

c# - 使用 C# 编辑 XML 文档