awesome-software-architecture 可观测性专题.NET 微服务日志、指标与分布式追踪实践指南【免费下载链接】awesome-software-architecture A curated list of awesome articles, videos, and other resources to learn and practice software architecture, patterns, and principles.项目地址: https://gitcode.com/GitHub_Trending/aw/awesome-software-architecture可观测性Observability是微服务架构中定位故障、评估性能与还原调用链的核心能力。本指南以本仓库docs/microservices/observability/目录下的文档体系为骨架围绕 .NET / ASP.NET Core 技术栈系统讲解日志Logs、指标Metrics、分布式追踪Traces三大支柱及 OpenTelemetry、Prometheus、Grafana、Loki 等主流工具的组合落地方式。读完本文你将理解可观测性为何是分布式系统的刚需掌握 OpenTelemetry 统一插桩、Correlation ID 贯穿请求、Prometheus/Grafana 指标监控、Loki/ELK/EFK 日志聚合等一整套可复用的实战方案。一、可观测性到底是什么从监控到可观测性本仓库在 README.md 中对可观测性给出定位可观测性指微服务架构中监控与调试分布式系统的能力以及实现可观测性所需的不同技术与工具例如日志、追踪、健康检查与监控。这句话点出了可观测性的本质——它不是单一工具而是围绕分布式系统运行状态的一整套技术组合。传统监控回答的是系统现在是否正常而可观测性回答的是系统为什么变得不正常。两者最关键的差别在于监控建立在已知的告警阈值之上而可观测性允许我们在未知问题发生时通过日志、指标、追踪三类遥测数据的交叉比对回溯问题根源。这也正是Unpacking Observability: Understanding Logs, Events, Traces, and Spans 这类经典文章反复强调的观点可观测性由四类基础数据构成——Logs日志带时间戳的事件记录描述发生了什么适合事后排查与审计Events事件与日志相近但更结构化通常用于记录离散的业务或系统事件Traces追踪一次请求在多个服务间的完整路径回答请求去了哪里、每一步耗时多少Spans跨度Trace 的基本组成单元代表一次调用中的一段有名字、有耗时、有父子关系的操作片段。在微服务架构中一次用户请求会横跨多个服务、数据库、消息队列单靠某个服务的日志无法还原全貌必须依赖 Trace 把散落的 Span 串成完整链路。这也是分布式系统区别于单体应用的核心痛点相关讨论可参考本仓库的 微服务文档 与 微服务通信。二、本仓库可观测性知识地图一份体系化的学习索引docs/microservices/observability/目录是本仓库可观测性主题的核心资产它按主题 → 资源类型的方式组织每个文档都聚焦一个独立子主题形成完整的学习路线文档聚焦主题资源类型observability.md可观测性总览本文主线文章、视频monitoring.mdPrometheus / Grafana 指标监控文章、视频、课程、库、样例distributed-tracing.md分布式追踪与 OpenTelemetry资源、文章、视频、库、样例logging.md日志收集与聚合Loki、Serilog文章、视频、样例、库diagnostics.md.NET 诊断体系DiagnosticSource 等文章、视频、样例、库correlationId.mdCorrelation ID 贯穿请求文章、库tools/loki.mdGrafana Loki 日志聚合文章、视频、库、样例tools/elk.mdELKElasticsearch、Logstash、Kibana文章、视频、库、样例tools/efk.mdEFKElasticsearch、Fluentd、Kibana视频tools/fluent-bit.mdFluent Bit 日志处理器资源tools/fluentd.mdFluentd 日志收集器资源这套索引覆盖了可观测性的全部关键子领域且资源高度集中于 .NET / ASP.NET Core 生态官方文档、社区文章、视频教程、开源库与可运行样例项目一应俱全。下文将沿着原理 → 平台能力 → 统一标准 → 三大支柱落地 → 端到端组合的脉络展开。三、.NET 平台的可观测性根基DiagnosticSource、Activity 与 EventCounters在引入 OpenTelemetry 之前.NET 平台自身就拥有一套完整的诊断基础设施本仓库的 diagnostics.md 系统收录了这套体系的核心文档包括DiagnosticSource用户指南、Activity用户指南、EventSource用户指南等。理解这些底层机制是理解 OpenTelemetry .NET 实现原理的前提。3.1 DiagnosticSource 与 DiagnosticListenerDiagnosticSource是 .NET 中用于进程内发布/订阅诊断事件的机制是生产代码与诊断工具之间的桥梁。它的典型使用场景是监听出站 HTTP 请求——例如在 .NET Core 3 时代社区文章就展示了如何通过监听DiagnosticListener捕获HttpClient的出站请求事件从而在不修改业务代码的前提下注入观测能力。ASP.NET Core 的宿主Hosting与 Kestrel 服务器内部都通过EventSource暴露运行事件而DiagnosticSource则承担了请求级、细粒度的诊断数据分发。3.2 Activity分布式追踪的内建模型Activity是System.Diagnostics命名空间下的类它从 .NET 5 开始成为分布式追踪的核心抽象每个Activity对应一个 Span通过ActivitySource创建、ActivityListener监听并通过ActivityLink关联不同 trace 的跨度。.NET 官方在 .NET Core 3.0 起大幅改进了诊断能力后续又专门设计了ActivityAPI 的可观测性改进方案以对齐 OpenTelemetry 规范文档中收录了相关的设计提案与演进文章。值得一提的是.NET 的Activity与 W3C Trace Context 标准深度绑定它原生支持traceparent头的解析与注入这意味着不依赖任何第三方库.NET 应用之间也能传递追踪上下文。这是 .NET 在可观测性上的天然优势。3.3 EventSource 与 EventCounters运行时级指标EventSource是 .NET 面向 ETWWindows 事件追踪及跨平台事件的输出通道运行时的 GC、JIT、线程池等子系统都通过它发布计数指标。EventCounters则是在此之上构建的轻量性能计数器可用dotnet-counters工具实时查看 CPU、内存、GC 等运行时指标。本仓库 diagnostics.md 还收录了dotnet-trace、dotnet-dump、dotnet-gcdump、dotnet-monitor等 CLI 诊断工具与 sidecar 容器诊断方案构成从运行中采集到崩溃转储分析的完整工具链。四、OpenTelemetry统一日志、指标、追踪的遥测标准OpenTelemetry 是本仓库 observability.md 与 distributed-tracing.md 共同强调的核心主题——它是 CNCF 主导的遥测数据标准与 SDK 集合目标是用一套 API 一套协议统一三大信号SignalTraces追踪记录请求跨服务的调用路径与耗时由 Span 组成Metrics指标聚合性的数值度量如请求速率、延迟分布、错误率Logs日志带时间戳的结构化事件记录OpenTelemetry 通过日志 SDK 与 OTLP 协议统一收集。配套的还有语义约定Semantic Conventions为 HTTP、RPC、消息、数据库等常见场景定义统一的 Span 属性命名如 HTTP 方法的http.request.method、消息系统的messaging.system保证不同团队、不同服务产生的遥测数据可以互相对齐、聚合分析。OpenTelemetry 规范文档中明确列出了 trace、metrics 与 baggage 的语义约定仓库的 distributed-tracing.md 均有收录。4.1 上下文传播Context Propagation与 Baggage分布式追踪要跨越服务边界就必须在请求头中传递追踪上下文。OpenTelemetry 默认遵循W3C Trace Context 标准上游服务在出站请求中注入traceparent头携带 trace-id、parent-span-id 与采样标志下游服务解析该头并续接 Span从而把整条调用链拼接起来。Baggage则用于在服务间传递键值对形式的附加上下文如用户 ID、租户 ID但需注意其随请求头透传不宜放入敏感数据。社区有大量文章专门讲解 W3C Trace Context 在分布式追踪中的应用以及 Jaeger 客户端与 W3C 标准在混合环境下的共存策略本仓库 distributed-tracing.md 均做了收录。4.2 .NET 应用接入示例在 .NET 应用中接入 OpenTelemetry 的典型做法基于OpenTelemetry .NET SDK的通用模式仓库 distributed-tracing.md 收录了其官方 API 文档与 5 分钟入门指南using OpenTelemetry.Metrics; using OpenTelemetry.Trace; var builder WebApplication.CreateBuilder(args); builder.Services.AddOpenTelemetry() .WithTracing(tracing tracing .AddAspNetCoreInstrumentation() // 自动插桩 ASP.NET Core 请求 .AddHttpClientInstrumentation() // 自动插桩 HttpClient 出站调用 .AddSqlClientInstrumentation() // 自动插桩 SQL 客户端 .AddOtlpExporter()) // 通过 OTLP 协议导出到 Collector/后端 .WithMetrics(metrics metrics .AddAspNetCoreInstrumentation() .AddMeter(Microsoft.AspNetCore.Hosting) .AddOtlpExporter()); var app builder.Build(); app.Run();这种SDK 插桩库 导出器的三段式结构贯穿整个 OpenTelemetry .NET 生态插桩库Instrumentation Libraries负责自动捕获 ASP.NET Core、HTTP、gRPC、SqlClient、StackExchange.Redis 等组件的遥测数据导出器Exporter负责把数据送往 Jaeger、Prometheus、OTLP 等目的地opentelemetry-dotnet-contrib 则收纳了大量扩展组件。4.3 自动插桩容器化 .NET 应用的零代码观测手动在每处代码里创建 Span 成本高昂因此 OpenTelemetry 提供了自动插桩Automatic Instrumentation方案通过启动时注入 agent无需修改业务代码即可为 .NET 应用采集遥测数据。本仓库 observability.md 特别收录了针对容器化 .NET 应用自动插桩的专题文章Twilio 出品其思路是在容器镜像中配置 OpenTelemetry .NET 自动插桩包应用启动时自动挂载将请求追踪与指标采集零侵入地注入到既有服务中——这对存量系统改造尤其有价值。五、OpenTelemetry Collector遥测数据的统一入口OpenTelemetry 的架构中应用 SDK 通常不直接连接后端而是先把数据发给OpenTelemetry Collector——一个独立部署的、与语言无关的代理服务负责接收、处理、导出遥测数据。本仓库 observability.md 收录了被标注为 ⭐ 的《A Beginners Guide to the OpenTelemetry Collector》一文它系统地讲解了 Collector 的三大组件Receiver接收器定义数据从哪来如 OTLP、Jaeger、Prometheus 等协议Processor处理器对数据进行过滤、采样、批处理、属性改写等加工Exporter导出器定义数据送到哪如 Prometheus、Jaeger、Grafana Cloud、Loki 等。一个典型的 Collector 配置文件config.yaml结构如下通用示例receivers: otlp: protocols: grpc: http: processors: batch: # 批量打包降低后端压力 exporters: prometheus: endpoint: 0.0.0.0:8889 otlp: endpoint: tempo.example.com:4317 headers: Authorization: Basic xxx service: pipelines: traces: receivers: [otlp] processors: [batch] exporters: [otlp] metrics: receivers: [otlp] processors: [batch] exporters: [prometheus]Collector 的存在让应用与后端解耦切换后端只需改导出器配置无需改动应用代码同时它天然适合作为 Sidecar 或 DaemonSet 部署在 Kubernetes 中统一管理采样率与数据脱敏策略。仓库的 distributed-tracing.md 也收录了 Collector 架构设计与实践样例并提供了在 HashiCorp Nomad 上运行 Collector 的入门指南。六、日志支柱结构化日志与聚合方案日志是可观测性中最基础、最直觉的信号。在微服务场景下日志的核心诉求是集中化与可检索分散在各 Pod、各容器的日志必须被采集、汇聚到统一存储中。本仓库 logging.md 围绕 .NET 微服务日志给出了三条主流技术路线。6.1 Serilog Grafana LokiLoki的定位是像 Prometheus 一样处理日志——它基于标签Label索引而非全文索引成本低、与 Grafana 集成度极高。.NET 侧的典型组合是Serilog serilog-sinks-grafana-loki应用通过 Serilog 输出结构化日志sink 把日志事件发送到 Lokilogging.md 收录了 .NET Core 微服务对接 Loki 的完整实践文章以及 Grafana Loki 的入门视频Grafana Loki: Like Prometheus, But for logs。6.2 ELK 与 EFK 栈ELKElasticsearch、Logstash、KibanaElasticsearch 提供全文检索与聚合分析Logstash 负责采集加工Kibana 负责可视化。.NET 侧常用Serilog Elasticsearch sink或官方elasticsearch-net客户端写入tools/elk.md 收录了从 .NET 6 WebAPI 接入 ELK 的分步教程与可运行样例。EFKElasticsearch、Fluentd/Fluent Bit、Kibana把 Logstash 换成更轻量的FluentdRuby 编写的开源日志收集器或Fluent BitC 语言编写的轻量级处理器。Fluent Bit 内存占用极小、吞吐高特别适合在 Kubernetes 中以 DaemonSet 形态采集节点日志tools/efk.md 收录了 EFK 栈在 Docker 与 Kubernetes 上的部署视频tools/fluent-bit.md 与 tools/fluentd.md 则分别聚焦两者的入门。七、指标支柱Prometheus Grafana 监控体系指标监控回答系统是否健康、容量是否充足的问题。本仓库 monitoring.md 是 Prometheus/Grafana 在 .NET 生态落地的资料大全覆盖了从指标定义、采集到仪表盘构建、告警配置的完整链路。7.1 Prometheus 的四种指标类型理解 Prometheus 必须从指标类型入手monitoring.md 同时收录了 Tom Gregory 的通俗讲解与 Prometheus 官方 Metric Types 文档Counter计数器只增不减的累计值如请求总数、错误总数Gauge仪表可增可减的瞬时值如当前连接数、内存使用量Histogram直方图观测值分布可计算 P50/P95/P99 等分位数如请求延迟Summary摘要与直方图类似但在客户端侧预计算分位数。7.2 .NET 侧的指标采集路径在 .NET 中接入 Prometheus 指标有三条常用路径monitoring.md 均有覆盖.NET 内置 Metrics APISystem.Diagnostics.Metrics提供的Meter/Counter/Histogram等类型配合 OpenTelemetry .NET 的 Metrics SDK 与prometheusexporter 暴露给 Prometheus 抓取.NET 8 起 ASP.NET Core 内置了 HTTP 指标并提供了官方 Grafana 仪表盘prometheus-net成熟的第三方库通过中间件直接暴露/metrics端点EventCounters 桥接通过 prometheus-net-contrib 等库把 .NET 诊断监听器与计数器暴露为 Prometheus 指标。7.3 Grafana 仪表盘与告警采集到指标后Grafana负责可视化与告警monitoring.md 收录了基于 Prometheus 指标创建 Grafana 仪表盘的教程、.NET 8 引入 ASP.NET Core 指标与 Grafana 仪表盘的官方公告以及 Prometheus 告警规则的入门与实战文章。告警规则生态方面还收录了 samber/awesome-prometheus-alerts 这一高质量规则集。在存储层monitoring.md 也收录了 VictoriaMetrics高性能时序数据库与 Grafana Mimir水平扩展、多租户的 Prometheus 长期存储等替代方案可按规模与成本权衡选用。八、追踪支柱分布式追踪、消息链路与 Correlation ID8.1 从 OpenTracing 到 OpenTelemetry 的演进分布式追踪领域经历过一段标准分裂期OpenTracingAPI 标准与 OpenTelemetry 前后更迭。本仓库 distributed-tracing.md 完整记录了这条演进线并收录了 .NET 官方从 .NET Core 3.0 起对分布式应用监控能力的改进说明、W3C Trace Context 规范全文以及 Jaeger 从 OpenTracing 客户端走向原生支持 OTLP 的历程。如今的标准答案是用 OpenTelemetry 统一插桩用 OTLP 协议传输用 Jaeger/Tempo 等后端存储与展示。8.2 消息中间件的链路追踪微服务间不仅有 HTTP 调用还有消息传递。当请求经由RabbitMQ / Kafka等中间件流转时Trace 上下文必须随消息投递否则链路会在消息边界断裂。仓库收录了面向消息应用的分布式追踪专题.NET 侧可参考 MassTransit 的 OpenTelemetry 支持MassTransit v8 起深度集成 OpenTelemetry以及基于 RabbitMQ MassTransit 的 Correlation ID 追踪实践。对消息属性OpenTelemetry 规范还定义了专门的 Messaging 语义约定messaging.system、messaging.destination等distributed-tracing.md 均有收录。8.3 Correlation ID贯穿请求的生命线Correlation ID关联 ID是比完整追踪更轻量的一种请求贯穿手段在入口处为一次业务请求生成唯一 ID写入日志并随 HTTP 头如X-Correlation-ID向下游服务传递从而把跨服务的日志记录关联到同一次请求。本仓库 correlationId.md 围绕 .NET 给出了完整的实现素材生成与注入在 ASP.NET Core 中间件中生成或透传 Correlation ID日志关联通过 Serilog 的Enrich.WithCorrelationId之类机制把 ID 写入每条日志仓库收录了 .NET Core 日志关联 Request Id 及任意日志属性的系列文章跨服务传递使用HttpClient默认请求头或Microsoft.AspNetCore.HeaderPropagation库自动把入站请求头传播到出站调用correlationId.md 收录了该官方 NuGet 包消息场景在 RabbitMQ 消息属性中携带 Correlation ID实现 HTTP 消息混合链路的全程贯穿。在 OpenTelemetry 体系下Correlation ID 通常作为 Baggage 或 Span 属性随 Trace 传播两者可互为补充Trace 回答链路长什么样Correlation ID 让日志检索更直接。九、端到端组合Grafana Cloud OpenTelemetry 的 .NET 微服务可观测性把上述能力串联起来就得到本仓库 observability.md 中反复出现并被标记 ⭐的旗舰实践主题Observability with Grafana Cloud and OpenTelemetry in .NET microservices。这套组合的架构通常如下.NET 微服务 ├─ OpenTelemetry SDKTraces Metrics Logs │ └─ OTLP ──▶ OpenTelemetry CollectorSidecar │ ├─ traces ──▶ Grafana Tempo或 Jaeger │ ├─ metrics ─▶ Prometheus / Grafana Mimir │ └─ logs ────▶ Grafana Loki └─ 全部在 Grafana 统一可视化、告警它同时覆盖 monitoring.md 与 logging.md 中分别出现的 .NET 8 实践、容器化自动插桩等内容应用只负责通过 OTel SDK 输出三类信号Collector 负责路由与加工Grafana 生态Tempo 追踪 Prometheus/Mimir 指标 Loki 日志负责存储、检索与统一仪表盘。仓库为这一组合提供了丰富的可运行样例分布于 monitoring.md、distributed-tracing.md、logging.md 的 Samples 分类中包括展示 ASP.NET Core 结合 Prometheus、Loki、Grafana、OpenTelemetry Collector 的完整样例⭐ 推荐使用 OpenTelemetry Collector 的 .NET 可观测性实战仓库⭐ 推荐.NET Core 微服务 Prometheus Grafana 的指标监控教程仓库ASP.NET Core 指标专用 Grafana 仪表盘集合覆盖 React 前端到 .NET Core 后端的全栈分布式追踪与监控工作坊OpenTelemetry 官方微服务演示应用Astronomy Shop与 .NET 可观测性综合样例。这些样例项目覆盖了HTTP 消息 数据库的常见依赖组合可作为团队搭建可观测性基础设施的起点模板。十、学习路线图围绕本仓库的进阶顺序综合本仓库可观测性文档体系推荐的学习路径如下对应文档均已给出相对路径可随时回到仓库查阅原文建立概念先读本文与 observability.md重点理解 Logs/Events/Traces/Spans 四类数据的区别以及 ASP.NET Core 云原生应用的监控与可观测性总览类文章掌握 .NET 诊断底层通过 diagnostics.md 吃透 DiagnosticSource、Activity、EventSource/EventCounters 与dotnet-*诊断工具这是理解后续一切插桩原理的基础统一标准落地按 distributed-tracing.md 学习 OpenTelemetry 的 Traces/Metrics/Logs 三大信号、W3C Trace Context、语义约定、.NET SDK 入门、自动插桩与 Collector 配置分支柱实践分别按 monitoring.mdPrometheus 四类指标 Grafana 仪表盘 告警、logging.mdSerilog Loki、tools/elk.md 与 tools/efk.mdELK/EFK 栈落地贯穿与进阶用 correlationId.md 补上请求贯穿能力再对照各文档 Samples 分类中的完整样例项目尤其是 Grafana Cloud OpenTelemetry 与 Collector 实战两个 ⭐ 项目进行端到端演练。视频资源方面observability.md 推荐的《On .NET Live - Cloud Native Patterns for .NET Developers》以及 distributed-tracing.md 中 Jimmy Bogard 的《Distributed Tracing Made Easy with .NET Core and OpenTelemetry》、NDC 大会的《Practical OpenTelemetry for .NET》等演讲都是进阶理解分布式追踪与云原生模式的高质量补充。结语可观测性不是某个单一工具而是一套日志可查、指标可看、链路可追的体系化能力。本仓库docs/microservices/observability/目录把 .NET 生态下这条体系的学习资源做了精心编排——从底层诊断机制DiagnosticSource、Activity、EventCounters到统一标准OpenTelemetry再到三大支柱的落地工具Prometheus/Grafana、Loki、ELK/EFK、Jaeger/Tempo与贯穿手段Correlation ID最后落到 Grafana Cloud OpenTelemetry 的端到端组合与可运行样例。建议读者按概念 → 底层 → 标准 → 分支柱 → 端到端的顺序结合仓库中各文档的原文链接与样例项目逐步实践即可为你的 .NET 微服务体系搭建出一套完整、可扩展的可观测性基础设施。【免费下载链接】awesome-software-architecture A curated list of awesome articles, videos, and other resources to learn and practice software architecture, patterns, and principles.项目地址: https://gitcode.com/GitHub_Trending/aw/awesome-software-architecture创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
