南光集团的贸易系统需良好的可观测性，请设计日志、追踪、监控体系（如使用ELK+Prometheus+Jaeger），说明如何实现全链路追踪（从用户请求到系统内部组件），并确保问题定位快速。
南光集团信息技术类难度：中等
答案
1) 【一句话结论】通过ELK链路日志收集+Prometheus指标监控+Jaeger分布式追踪，以链路ID贯穿全链路，实现从用户请求到内部组件的完整追踪，结合日志、指标、追踪多维度数据，快速定位问题根源。
2) 【原理/概念讲解】同学们，咱们先讲清楚这几个核心组件的作用：
- 日志（ELK）：日志是系统的“行为记录”，像侦探的笔录，记录每个请求的操作、时间、状态等信息。ELK（Elasticsearch+Logstash+Kibana）负责收集（Logstash）、存储（Elasticsearch）、查询（Kibana）日志，结构化日志能快速检索关键信息。
- 追踪（Jaeger）：分布式追踪系统，解决微服务中请求的跨服务传递问题。通过Span（单个请求的片段）和Trace（整个请求链路）来追踪，Jaeger负责生成、存储、查询追踪数据，能可视化链路结构。
- 监控（Prometheus）：指标监控，通过采集系统指标（如CPU、内存、请求延迟、错误率），实时监控系统状态。Prometheus负责指标采集、存储、告警，能及时发现性能异常。
三者协同：日志提供详细操作信息，追踪提供链路结构，监控提供实时状态，共同构成可观测性体系。
3) 【对比与适用场景】
| 组件 | 定义 | 特性 | 使用场景 | 注意点 |
|---|---|---|---|---|
| ELK（日志） | 集成日志收集、存储、查询的解决方案 | 结构化日志、多源收集、实时查询 | 日志分析、故障排查、合规审计 | 日志量过大时需分片，结构化日志需统一规范 |
| Jaeger（追踪） | 分布式追踪系统，用于追踪请求在微服务间的流动 | 跨服务追踪、链路可视化、分布式调用分析 | 微服务架构、复杂业务流程、性能瓶颈定位 | 需要服务间通信支持（如HTTP/HTTPS），链路ID穿透 |
| Prometheus（监控） | 开源监控系统，用于采集、存储、查询指标 | 时间序列数据、告警、仪表盘 | 系统性能监控、资源使用、业务指标 | 指标采集需配置，告警规则需合理 |
4) 【示例】
假设用户访问“贸易系统-下单”接口，流程如下：
- 用户请求到达API网关，生成链路ID（如trace_id: abc123）。
- API网关记录日志（trace_id: abc123, method: GET, path: /order, status: 200）。
- API网关调用服务A（order-service），传递trace_id。
- 服务A记录日志（trace_id: abc123, service: order-service, method: processOrder, status: 200），并调用服务B（inventory-service）。
- 服务B记录日志（trace_id: abc123, service: inventory-service, method: checkStock, status: 200），查询库存。
- 服务B返回结果给服务A，服务A记录日志（trace_id: abc123, service: order-service, method: updateOrder, status: 200），更新订单。
- 服务A返回结果给API网关，API网关记录日志（trace_id: abc123, method: GET, path: /order, status: 200）。
- Jaeger生成Trace（包含多个Span：网关->服务A、服务A->服务B、服务B->服务A、服务A->网关），Prometheus采集指标（如order-service的请求延迟、错误率）。
- 若服务B查询库存失败（status: 500），则日志中记录错误，追踪中显示该Span异常，监控中指标（如inventory-service错误率）上升，触发告警。
5) 【面试口播版答案】
“面试官您好，针对南光集团贸易系统的可观测性需求，我设计了一套基于ELK+Prometheus+Jaeger的体系，核心是通过链路ID贯穿全链路，实现从用户请求到内部组件的完整追踪，快速定位问题。
首先，日志层面，使用ELK收集链路日志，每个请求生成唯一链路ID（trace_id），记录操作、时间、状态等信息，便于后续关联。比如用户下单时，每个服务节点都会记录包含trace_id的日志，通过Kibana可以按trace_id查询完整操作链。
然后，追踪层面，引入Jaeger，通过Span和Trace机制，将用户请求从API网关到服务A、服务B的调用过程可视化，当某个服务（如库存服务）出现异常时，能快速定位到对应的Span，查看延迟或错误原因。
监控层面，用Prometheus采集系统指标，如服务响应时间、错误率、资源使用情况，结合日志和追踪数据，当指标异常（如库存服务错误率飙升）时，能快速关联到具体的trace_id和日志，定位问题根源。
三者协同下，当出现问题时，通过trace_id关联日志、追踪和监控数据，能快速定位到问题所在的服务节点和具体操作，提升问题定位效率。”
6) 【追问清单】
- 链路ID如何穿透微服务？
回答要点：通过HTTP头传递trace_id，每个服务节点解析并传递给下一个服务，确保链路ID贯穿全链路。 - 日志结构如何设计？
回答要点：采用结构化日志（如JSON格式），包含trace_id、service、method、status、timestamp等字段，便于ELK解析和查询。 - 监控指标如何定义？
回答要点：定义关键业务指标（如下单成功率、平均响应时间）和系统指标（如CPU、内存、错误率），通过Prometheus采集并设置告警规则。 - 数据存储如何考虑？
回答要点：日志存储在Elasticsearch，追踪数据存储在Jaeger的存储（如Cassandra），监控指标存储在Prometheus的时间序列数据库，确保数据可持久化。 - 跨团队协作如何保障？
回答要点：制定日志、追踪、监控的数据规范和接口文档，定期培训，建立问题定位流程，确保各团队协同工作。
7) 【常见坑/雷区】
- 只说组件不解释协同：避免只罗列ELK、Prometheus、Jaeger，不说明三者如何配合，导致面试官认为不理解整体设计。
- 忽略链路ID穿透：如果没提到链路ID如何传递和穿透微服务，会显得对全链路追踪理解不深。
- 日志结构不统一：如果没说明日志结构化设计，会导致日志查询困难，影响问题定位效率。
- 监控指标不相关：如果监控指标与业务无关（如只监控系统资源，不监控业务指标），会显得设计不符合需求。
- 数据孤岛：如果没考虑日志、追踪、监控数据的关联，会导致数据分散，无法快速定位问题。