语言运行时标准库JIT编译编译器【免费下载链接】runtime.NET is a cross-platform runtime for cloud, mobile, desktop, and IoT apps.项目地址https://gitcode.com/GitHub_Trending/runtime6/runtime点击查看免费下载Microsoft.Extensions.Diagnostics.Abstractions是 .NET 诊断Diagnostics体系的抽象层它定义了指标Metrics与跟踪Tracing两大子系统对外暴露的接口与规则类型具体实现则由Microsoft.Extensions.Diagnostics及其他诊断包提供。本文以该包为线索结合 dotnet/runtime 仓库本仓库即 .NET 运行时源码中的真实实现讲解如何通过IMetricsBuilder、IMetricsListener、InstrumentRule、ITracingBuilder、TracingRule等核心类型配置应用的指标采集与活动跟踪读完你能够独立完成自定义指标监听器、规则式启停与跟踪采样的落地。一、包定位接口与实现分离的抽象层Microsoft.Extensions.Diagnostics.Abstractions是诊断功能的抽象层abstractions其核心设计思想是接口定义与实现类分离本包中定义的接口由Microsoft.Extensions.Diagnostics以及 OpenTelemetry 等第三方诊断包实现。这样应用代码只依赖抽象即可在运行期替换或叠加不同的指标/跟踪后端。该包的官方定位说明来自 README.mdMicrosoft.Extensions.Diagnostics.Abstractionsprovides abstractions of diagnostics. Interfaces defined in this package are implemented by classes inMicrosoft.Extensions.Diagnosticsand other diagnostics packages.从仓库结构可以清晰看到这一分层Microsoft.Extensions.Diagnostics.Abstractions/src 下分为Metrics/与Tracing/两个目录全部是接口、规则与选项类型Microsoft.Extensions.Diagnostics/src 下则是MetricsSubscriptionManager、DefaultMeterFactory、DebugConsoleMetricListener、DefaultActivitySourceFactory等具体实现。该包的 API 与功能自 .NET 8 起新增并会持续演进详见后文Contribution Bar。二、指标Metrics核心抽象指标子系统解决的核心问题是以规则Rule驱动的方式决定哪些 Meter/Instrument 被哪些 Listener 订阅。README 列出的常用类型全部集中在Microsoft.Extensions.Diagnostics.Metrics命名空间下面逐一展开。2.1 IMetricsBuilder指标系统的配置入口IMetricsBuilder 是整个指标配置的入口它只暴露一个属性public interface IMetricsBuilder { // 应用的服务集合扩展方法通过它注册服务 IServiceCollection Services { get; } }它的职责正如源码注释所述Configures the metrics system by registering IMetricsListeners and using rules to determine which metrics are enabled.——通过注册IMetricsListener并利用规则决定哪些指标被启用。所有的AddListener、EnableMetrics、DisableMetrics等扩展方法最终都通过builder.Services完成服务注册或选项配置。2.2 IMetricsListener指标监听器契约IMetricsListener 定义了自定义指标监听器必须实现的生命周期方法成员作用string Name监听器名称用于规则配置中定位该监听器void Initialize(IObservableInstrumentsSource source)由运行时调用一次提供用于拉取可观测Observable指标数据的源bool InstrumentPublished(Instrument instrument, out object? userState)当新 Instrument 被创建且被匹配规则启用时调用返回true表示该监听器要订阅此 Instrument并通过userState携带监听器私有状态void MeasurementsCompleted(Instrument instrument, object? userState)当 Instrument 被生产者禁用或规则变更导致停用时调用MeasurementHandlers GetMeasurementHandlers()返回该监听器支持的测量处理回调集合整个生命周期设计非常清晰Initialize只发生一次InstrumentPublished/MeasurementsCompleted随 Instrument 的发布与停用成对出现GetMeasurementHandlers声明监听器能处理哪些数值类型。2.3 InstrumentRule决定谁监听什么的规则InstrumentRule 是一组用于匹配 Instrument 与监听器的参数。未指定的参数匹配一切其匹配优先级从高到低为MeterName精确匹配或最长前缀匹配仅考虑完整段匹配即按.分段InstrumentName精确匹配ListenerName精确匹配对应IMetricsListener.NameScopes作用域限定。规则的五个构造参数与属性参数类型语义meterNamestring?Meter.Name或其前缀null匹配所有 MeterinstrumentNamestring?Instrument.Namenull匹配该 Meter 下所有 InstrumentlistenerNamestring?IMetricsListener.Namenull匹配所有监听器scopesMeterScope位组合的作用域MeterScope.None会被构造函数直接抛出ArgumentOutOfRangeExceptionenablebooltrue表示对该监听器启用匹配到的 Instrument需要特别注意的是Scopes属性在构造函数中的校验逻辑InstrumentRule.cs传入MeterScope.None会立刻抛出异常强制要求必须指定Global、Local或两者组合。2.4 MeterScope区分 Global 与 Local 两种 Meter 来源MeterScope 是一个[Flags]枚举用于在规则中区分两类 MeterGlobal通过Meter构造函数直接创建的 MeterLocal通过依赖注入IMeterFactory.Create(MeterOptions)创建的 Meter。[Flags] public enum MeterScope { None 0, // 未指定不应使用 Global, // 通过 Meter 构造函数创建 Local // 通过 DI 的 IMeterFactory.Create 创建 }由于是 Flags 枚举默认值通常写作MeterScope.Global | MeterScope.Local表示两种来源都考虑。2.5 MetricsOptions规则集合的承载者MetricsOptions 结构非常简单只包含一个规则列表public class MetricsOptions { public IListInstrumentRule Rules { get; } new ListInstrumentRule(); }它通过IOptions机制与配置系统打通既可以用代码EnableMetrics/DisableMetrics添加规则也可以在appsettings.json中声明式配置由Microsoft.Extensions.Diagnostics的MetricsBuilderConfigurationExtensions提供配置绑定支持。2.6 MetricsBuilderExtensions规则与监听器的编程式配置MetricsBuilderExtensions.Listeners.cs 提供监听器注册 APIAddListenerT()以单例形式注册T类型T : class, IMetricsListener到 DI 容器使用TryAddEnumerable避免重复注册AddListener(listener)注册一个现成的IMetricsListener实例ClearListeners()调用RemoveAllIMetricsListener()清空所有监听器注册。MetricsBuilderExtensions.Rules.cs 则提供规则配置 API典型用法所有参数都可选null即匹配全部// 启用指定 Meter 的全部 Instrument作用于所有监听器 builder.EnableMetrics(MyCompany.MyApp); // 更细粒度指定 meter、instrument、listener 与作用域 builder.EnableMetrics( meterName: MyCompany.MyApp, instrumentName: request.duration, listenerName: console, scopes: MeterScope.Global | MeterScope.Local); // 禁用某类指标 builder.DisableMetrics(MyCompany.MyApp, unused.counter);从实现上看EnableMetrics最终调用私有方法ConfigureRule它本质上是builder.Services.Configure(options ...)即把规则写入MetricsOptions配置MetricsOptions.EnableMetrics/DisableMetrics则直接向options.Rules追加InstrumentRule。因此编程式配置与配置文件配置最终汇合到同一条规则列表。2.7 测量数据通路MeasurementHandlers 与 IObservableInstrumentsSource指标数据最终通过两类抽象到达监听器MeasurementHandlers声明监听器支持的数值类型回调。它包含ByteHandler、ShortHandler、IntHandler、LongHandler、FloatHandler、DoubleHandler、DecimalHandler七个可空属性对应MeasurementCallbackT。如果某个处理器为null对应类型的测量数据会被直接跳过因此监听器应按需设置。IObservableInstrumentsSource通过IMetricsListener.Initialize注入监听器监听器可随时调用其唯一方法RecordObservableInstruments()主动拉取当前启用可观测 Instrument 的测量值。三、跟踪Tracing核心抽象除指标外该包还包含一组较新的跟踪抽象Microsoft.Extensions.Diagnostics.Tracing命名空间其设计与指标侧高度对称Builder Rule Options 扩展方法。3.1 ITracingBuilder 与 ActivityListenerBuilderITracingBuilder 与IMetricsBuilder一样仅暴露IServiceCollection Services负责注册ActivityListener并用规则决定哪些ActivitySource/Activity被启用。ActivityListenerBuilder 是跟踪监听器底层对应System.Diagnostics.ActivityListener的用户可配置面包含以下可设属性属性类型含义Namestring名称供规则按监听器过滤SampleSampleActivityActivityContext?从ActivityContext采样 Activity 时的回调SampleUsingParentIdSampleActivitystring?从父标识字符串采样时的回调ActivityStartedActionActivity?采样后的 Activity 启动时回调ActivityStoppedActionActivity?采样后的 Activity 停止时回调ExceptionRecorderExceptionRecorder?在采样 Activity 上记录异常时的回调从源码注释可以了解其内部设计该 Builder刻意不暴露ShouldListenTo、RefreshSources与Dispose——订阅过滤完全由规则集接管底层监听器的生命周期由跟踪基础设施持有委托属性在注册时被快照snapshot注册后再修改 Builder 不会影响已注册的监听器。3.2 TracingRule 与 ActivitySourceScopesTracingRule 与InstrumentRule对应匹配优先级为ListenerName精确匹配SourceName精确匹配、最长前缀匹配或使用单个*的通配模式OperationName精确匹配对应Activity.OperationNameScopes约束更紧的作用域优先于Global | Local。当多个规则同等具体时后添加的规则优先the rule added last takes precedence。值得注意的一个实现细节TracingRule的构造函数会急切校验sourceName中是否包含多个*通配符TracingRule.cs多于一个直接抛出ArgumentException。源码注释解释了这个设计动机指标侧的InstrumentRule把同类校验延迟到逐事件匹配路径配置错误可能到任意 Instrument 操作时才暴露而跟踪是较新的 API因此选择在绑定/构造阶段就暴露配置错误避免问题进入StartActivity热路径。ActivitySourceScopes 是与MeterScope对称的[Flags]枚举None0、Global1、Local2用于区分通过构造函数创建的ActivitySourceGlobal与通过ActivitySourceFactory经 DI 创建的ActivitySourceLocal。3.3 TracingBuilderExtensions跟踪规则编程式配置TracingBuilderExtensions.Rules.cs 提供与指标侧对称的 API// 启用所有来源、所有监听器的活动全参均可省略 builder.EnableTracing(); // 带通配符的来源匹配 指定监听器 builder.EnableTracing( sourceName: MyCompany.*, operationName: HandleRequest, listenerName: otlp); // 禁用某类活动 builder.DisableTracing(sourceName: MyCompany.Deprecated);与指标侧一样EnableTracing/DisableTracing通过builder.Services.Configure(...)把规则写入TracingOptions.RulesTracingOptions.cs 持有IListTracingRule编程配置与配置文件配置殊途同归。四、从抽象到实现结合 Microsoft.Extensions.Diagnostics 验证调用关系抽象层本身只定义契约真正的行为验证需要看同仓库的实现包。在 Microsoft.Extensions.Diagnostics/src 中MetricsSubscriptionManager.cs 与 ListenerSubscription.cs 负责把规则解析结果落实到每个监听器的订阅规则变更时动态调用IMetricsListener.InstrumentPublished/MeasurementsCompleted这正是InstrumentRule注释中rule changes触发停用的落地实现DefaultMeterFactory.cs 实现IMeterFactory.Create(MeterOptions)即MeterScope.Local所指的 DI 创建路径DebugConsoleMetricListener.cs 是IMetricsListener的开箱即用实现把指标输出到调试控制台其Name通常为console可作为自定义监听器的参考范本跟踪侧的 DefaultActivitySourceFactory.cs 与ActivitySourceScopes.Local对应。由此可以推断完整的数据流应用通过IMeterFactory/ActivitySourceFactory创建 Instrument/Source →MetricsSubscriptionManager依据MetricsOptions.Rules中的InstrumentRule匹配监听器 → 匹配成功后调用监听器的InstrumentPublished完成订阅 → 测量发生时通过监听器返回的MeasurementHandlers回调派发数据。五、测试用例佐证规则语义仓库内置的测试验证了上述规则行为可作为理解 API 语义的活文档InstrumentRuleTests.cs验证InstrumentRule各参数的匹配语义与MeterScope.None的异常行为MetricsBuilderExtensionsRulesTests.cs验证EnableMetrics/DisableMetrics生成的规则是否正确写入MetricsOptionsMetricsBuilderExtensionsListenersTests.cs验证AddListener/ClearListeners对 DI 容器注册的影响TracingBuilderExtensionsRulesTests.cs验证跟踪规则的构建与校验含通配符约束。六、Contribution Bar 与演进状态README 中明确给出了该包的贡献门槛Contribution Bar接受新特性、新 API、Bug 修复与性能改进遵循 库的 Primary BarAPI 与功能自 .NET 8 起新增并将继续开发。这意味着该包属于活跃演进的 API 面使用时应关注版本差异跟踪Tracing子系统的若干类型如ActivityListenerBuilder、TracingRule相对指标侧更新其行为设计如通配符急切校验已在源码注释中说明了与指标侧的取舍。七、部署方式共享框架与 OOB 双通道README 的 Deployment 一节说明了该包的发布形态随 ASP.NET Core 共享框架内置ASP.NET Core 应用无需显式引用即可使用同时以 out-of-bandOOB形式发布任何项目都可以直接引用 NuGet 包Microsoft.Extensions.Diagnostics.Abstractions获得这些抽象类型。结合 csproj 可以确认它是一个可独立打包的库项目实现侧还提供了 Microsoft.Extensions.Diagnostics.csproj包含AddMetrics/AddTracing等服务注册扩展见MetricsServiceExtensions、TracingServiceExtensions负责把上述抽象接入IServiceCollection。小结Microsoft.Extensions.Diagnostics.Abstractions是理解 .NET 8 诊断体系的钥匙指标与跟踪共用Builder 入口 → Rule 匹配 → Listener/Handler 消费的统一抽象。无论是接入 OpenTelemetry 等第三方后端还是编写自定义控制台指标监听器只需实现IMetricsListener并注册规则即可。要深入探究规则解析与订阅管理的细节建议直接阅读本仓库中 Abstractions 包的 Metrics/Tracing 源码 与其实现包 Microsoft.Extensions.Diagnostics 的对应实现以及上文列出的测试用例。赞分享语言运行时标准库JIT编译编译器【免费下载链接】runtime.NET is a cross-platform runtime for cloud, mobile, desktop, and IoT apps.项目地址https://gitcode.com/GitHub_Trending/runtime6/runtime点击查看免费下载相关推荐.NET 缓存抽象层完全指南深入 Microsoft.Extensions.Caching.Abstractions 接口设计与实践.NET 缓存抽象层完全指南深入 Microsoft.Extensions.Caching.Abstractions 接口设计与实践 Microsoft.Ex语言运行时标准库JIT编译编译器深入解析 .NET 配置系统Microsoft.Extensions.Configuration 的抽象模型与 Provider 机制深入解析 .NET 配置系统Microsoft.Extensions.Configuration 的抽象模型与 Provider 机制 导读 本文基于 .NE语言运行时标准库JIT编译编译器G-Helper华硕笔记本的轻量级控制神器从入门到精通的全方位指南G Helper华硕笔记本的轻量级控制神器从入门到精通的全方位指南 还在为Armoury Crate的臃肿和资源占用而烦恼吗G Helper就像是你电脑的桌面应用系统编程创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考