基于.NET框架的本地部署微服务架构日志方案咨询

一、核心选型原则 #

既然是客户本地部署的非云原生场景，核心要抓三个点：轻量易部署、本地化可管控、分布式链路可追踪，尽量复用.NET生态原生工具，减少额外学习成本。

二、日志收集与存储落地 #

• 基础日志框架：用Microsoft.Extensions.Logging做底层，搭配Serilog（推荐）或NLog扩展。这俩都支持结构化日志输出（比如JSON格式），能轻松把TraceId、服务名、API路径这些关键信息塞进日志里，方便后续检索。
• 存储方案分场景选：
  • 小规模部署（服务节点≤5）：直接用客户本地已有的SQL Server或PostgreSQL建日志表，结构化日志直接入库，用SQL就能查，不用额外搭新系统。
  • 中大规模部署：上本地版Elasticsearch集群，配合Filebeat做日志采集——每个微服务节点装个Filebeat，监听日志文件自动推送到ES，ES的全文检索能力能快速定位某一次API调用的所有日志。
• 日志格式强制标准化：所有服务必须输出包含TraceId、SpanId、ServiceName、ApiPath、HttpMethod、StatusCode、RequestDuration的日志，没有这个标准，跨服务追踪就是空谈。

三、API全链路追踪实现 #

• 分布式追踪用OpenTelemetry（OTel）：这是开源标准，完全支持本地部署，不需要依赖任何云服务。每个微服务里配置OTel的.NET SDK，自动注入追踪逻辑，生成的TraceId会自动通过HTTP请求头（traceparent）传递给下游服务，消息队列的话手动把TraceId塞进消息属性里就行。
• API自动埋点+手动补全：
  • Web API直接用OTel的AspNetCore自动 instrumentation，不用写代码就能捕获每个API的入参、出参、响应时间、异常信息。
  • 关键业务步骤手动加埋点：比如数据库查询、第三方服务调用，用Activity标记Span：

    using var activity = ActivitySource.StartActivity("Order_CreateDatabaseRecord");
    // 执行数据库写入逻辑
    

• 追踪数据存储与可视化：把OTel的追踪数据导出到本地部署的Jaeger或Zipkin，这俩工具自带UI，能直观看到全链路调用的路径、每个服务的耗时、依赖关系，排查API调用问题特别方便。

四、日志与追踪联动 #

把日志里的TraceId和追踪系统的TraceId保持一致，这样只要拿到一个TraceId，就能在ES里搜到该次API调用的所有日志，也能在Jaeger里看到完整的调用链路，实现日志和追踪的双向关联。比如在Serilog里把OTel的TraceId塞进日志上下文：

LogContext.PushProperty("TraceId", Activity.Current?.TraceId.ToString());

五、部署与运维细节 #

• 所有工具（ES、Jaeger、Filebeat）都用Docker容器化部署，给客户个docker-compose.yml文件，一键就能拉起整个日志追踪系统，不用折腾环境配置。
• 给客户提供可视化入口：用Kibana看日志的统计和检索，用Jaeger UI看链路追踪，都是开箱即用的界面，客户运维人员不用学复杂命令。
• 加日志清理策略：配置ES的索引生命周期管理（ILM），自动删除30天以上的旧日志，避免占满存储空间。

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