微服务日志收集与请求追踪示例

使用唯一traceId实现请求追踪，结合结构化日志与ELK/EFK集中收集，再通过Sleuth+Zipkin等工具实现调用链可视化，提升微服务可观测性。

在微服务架构中，服务被拆分为多个独立部署的小型服务，每个服务负责特定的业务功能。这种架构提升了系统的灵活性和可维护性，但也带来了新的挑战——如何统一收集日志并追踪一次请求在多个服务间的流转过程。本文通过一个简单示例说明如何实现微服务的日志收集与请求追踪。

使用唯一请求ID实现请求追踪

当一个用户请求经过网关后，可能调用订单服务、用户服务、支付服务等多个微服务。为了追踪该请求在整个系统中的路径，需要为每次请求分配一个唯一的追踪ID（如 traceId）。

具体做法如下：

• 在请求进入系统入口（如API网关）时生成一个全局唯一的 traceId，例如使用 UUID 或雪花算法。
• 将 traceId 放入 HTTP 请求头中，如 X-Trace-ID。
• 每个下游服务在处理请求时，从请求头中读取 traceId，并在本地日志中打印该ID。
• 服务间调用时，需将 traceId 继续传递给下一个服务。

例如，用户请求创建订单：

集中式日志收集方案

每个微服务独立打印日志到本地文件不利于排查问题。应将日志集中收集到统一平台，常用技术栈包括 ELK（Elasticsearch + Logstash + Kibana）或 EFK（Fluentd 替代 Logstash）。

实施步骤：

万物追踪

AI 追踪任何你关心的信息

44

查看详情

• 各服务使用结构化日志格式（如 JSON），并在每条日志中包含 traceId、服务名、时间戳等字段。
• 在每个服务节点部署日志采集代理（如 Filebeat 或 Fluent Bit），实时读取日志文件并发送到消息队列（如 Kafka）或直接传入 Elasticsearch。
• 通过 Kibana 查询日志时，输入 traceId 即可查看该请求在各个服务中的执行轨迹。

例如，在 Spring Boot 服务中可通过 MDC（Mapped Diagnostic Context）将 traceId 写入日志上下文：

集成分布式追踪工具（如 Zipkin 或 Jaeger）

除了日志，还可以引入专业的分布式追踪系统，自动记录服务调用链路。这类工具不仅能显示请求路径，还能展示每个环节的耗时、错误状态等。

以 Spring Cloud 应用为例：

• 引入 Sleuth（生成 traceId 和 spanId）和 Zipkin 客户端依赖。
• 服务启动后，Sleuth 自动为请求生成 traceId 和 spanId，并通过 HTTP 头向下游传播。
• Zipkin Server 收集调用数据，提供可视化界面展示完整的调用链。

例如，Zipkin 界面会显示：gateway → order-service → user-service → payment-service，每段调用的耗时清晰可见。

基本上就这些。通过 traceId 贯穿请求、结构化日志输出、集中收集与可视化追踪工具结合，可以有效提升微服务系统的可观测性。关键在于统一规范和自动化注入，避免人工遗漏。不复杂但容易忽略。

以上就是微服务日志收集与请求追踪示例的详细内容，更多请关注php中文网其它相关文章！