.NET 8从AppMetrics迁移至OpenTelemetry Meter后CPU占用过高求助

我们在代码中监控部分方法的执行时长与错误率，此前使用AOP Attribute（基于Postsharp）结合AppMetrics将指标存储至PostgreSQL服务器，运行一切正常。近期决定从AppMetrics迁移至OpenTelemetry，改用System.Diagnostics的Counter和Histogram实现指标统计。

系统需监控约300个方法，指标关联包含租户代码的标签（多租户方案），理论上需处理21000个不同指标序列，且这些属性被应用于每秒调用量极高的核心方法。迁移完成后，服务器进程CPU占用率达100%，移除Meter/Histogram相关代码后CPU恢复正常。

请问可能的原因是什么？System.Diagnostics是否不适用于此类量级的指标场景？

补充说明 #

• 每个被监控的方法会实例化一次AOP Attribute（共约300次）。
• 标签包含以下字段：
  • "TenantCode"
  • "Assembly"
  • "Namespace"
  • "Class"
  • "Method"

代码示例 #

指标定义代码 #

private static readonly Histogram<double> DurationHistogram = Meter.CreateHistogram<double>("measure_execution_time_duration", "ms", "Duration of method execution in milliseconds"); 
private static readonly Counter<long> SuccessCounter = Meter.CreateCounter<long>("measure_execution_time_success", "calls", "Total number of successful calls"); 
private static readonly Counter<long> ErrorCounter = Meter.CreateCounter<long>("measure_execution_time_error", "calls", "Total number of error calls"); 

指标上报代码 #

var tags = BuildTags(args); 
SuccessCounter.Add(1, tags); 

核心原因 #

System.Diagnostics.Metrics本身可以支撑大规模指标场景，但你的实现存在几个关键性能瓶颈：

1. 重复创建Meter实例
   每个AOP Attribute实例都调用Meter.CreateXXX，会导致创建大量重复名称的Meter（共300组Counter/Histogram，对应300个Meter）。Meter的创建和管理会带来额外的CPU开销，尤其是在高并发场景下，多个Meter同时处理指标会加剧资源竞争。

2. 标签序列的高频创建与哈希计算
   每次调用BuildTags生成新的标签集合，且Add方法会对标签键值对进行哈希计算以区分不同的指标序列。21000个不同的指标序列意味着每次调用都要处理唯一的标签组合，高并发下哈希计算和标签对象的频繁GC会占用大量CPU。

3. 未优化的标签存储方式
   如果BuildTags返回的是IEnumerable<KeyValuePair<string, object>>或临时创建的集合，每次调用都会生成新的对象，加剧GC压力；同时，标签键的字符串重复创建也会增加内存和CPU开销。

解决方案 #

1. 全局复用单个Meter实例
   不要在每个Attribute中创建Meter，而是全局共享一个Meter实例，所有指标都通过该Meter创建：

   // 全局静态类中定义
   public static class MetricConstants
   {
       public static readonly Meter GlobalMeter = new Meter("Your.Application.Metrics", "1.0.0");
   }
   
   // Attribute中使用
   private static readonly Histogram<double> DurationHistogram = MetricConstants.GlobalMeter.CreateHistogram<double>("measure_execution_time_duration", "ms", "Duration of method execution in milliseconds"); 
   

2. 缓存标签组合
   对高频出现的标签组合（比如租户+方法的固定组合）进行缓存，复用已创建的标签集合，避免重复计算哈希和创建对象：

   private static readonly ConcurrentDictionary<string, KeyValuePair<string, object>[]> _tagCache = new ConcurrentDictionary<string, KeyValuePair<string, object>[]>();
   
   private KeyValuePair<string, object>[] BuildCachedTags(MethodExecutionArgs args)
   {
       // 生成唯一缓存键，比如拼接TenantCode+Assembly+Namespace+Class+Method
       var cacheKey = $"{args.TenantCode}_{args.Method.DeclaringType.Assembly.GetName().Name}_{args.Method.DeclaringType.Namespace}_{args.Method.DeclaringType.Name}_{args.Method.Name}";
       return _tagCache.GetOrAdd(cacheKey, key => new[]
       {
           new KeyValuePair<string, object>("TenantCode", args.TenantCode),
           new KeyValuePair<string, object>("Assembly", args.Method.DeclaringType.Assembly.GetName().Name),
           new KeyValuePair<string, object>("Namespace", args.Method.DeclaringType.Namespace),
           new KeyValuePair<string, object>("Class", args.Method.DeclaringType.Name),
           new KeyValuePair<string, object>("Method", args.Method.Name)
       });
   }
   

3. 使用结构化标签类型
   改用TagList（来自System.Diagnostics.Metrics）替代普通键值对集合，TagList是为性能优化设计的结构体，减少GC开销：

   var tags = new TagList
   {
       { "TenantCode", args.TenantCode },
       { "Assembly", args.Method.DeclaringType.Assembly.GetName().Name },
       { "Namespace", args.Method.DeclaringType.Namespace },
       { "Class", args.Method.DeclaringType.Name },
       { "Method", args.Method.Name }
   };
   SuccessCounter.Add(1, tags);
   

4. 调整指标导出频率
   如果使用OpenTelemetry Exporter，降低导出频率（比如从1秒改为5秒），减少指标序列化和网络传输的CPU开销。

5. 验证指标基数
   21000个指标序列属于较高基数，但System.Diagnostics.Metrics可以支撑，不过需要确保导出器（比如OTLP Exporter）配置了合适的基数限制，避免因导出器处理不过来导致的CPU飙升。

结论 #

System.Diagnostics.Metrics完全适用于大规模指标场景，你的问题是实现方式的性能瓶颈导致的，通过优化Meter复用、标签缓存和使用高性能标签类型，即可解决CPU占用过高的问题。

内容的提问来源于stack exchange，提问作者luke77