第 11 章：故障排除：在大海捞针
本章聚焦云原生环境下的故障排除，系统性梳理日志、监控和分布式跟踪的关键方法，帮助读者掌握在动态分布式系统中定位和解决问题的实用策略。
本章要点
- 临时环境中服务的应用程序日志记录
- 临时环境中服务的应用程序监控
- 分布式跟踪
云原生环境下的可观察性挑战
早在 2013 年，我与 Cloud Foundry 的企业客户合作时，客户工程师曾形象地比喻：“你给我一台没有仪表盘的法拉利”。这句话道出了可观察性在生产环境中的重要性。传统软件运维实践多集中于评估系统健康和故障识别，但云原生架构带来了新的挑战：高度分布式和环境短暂性。
在云原生环境中，容器和服务实例频繁变化，传统依赖运行时环境的故障排查手段已不再适用。分布式架构下，单个请求可能涉及数十甚至数百个下游服务，如何还原调用链成为新的难题。
本章将围绕日志、指标和分布式跟踪三大主题展开，介绍适应云原生环境的故障排查方法。
应用程序日志
日志记录是软件开发的基本要求，但日志管理应与应用代码解耦。日志输出位置应由部署环境决定，而非应用本身。主流框架如 Logback 支持将日志发送到 stdout/stderr，便于平台统一收集。
在云原生环境下，建议：
- 禁止直接写入本地文件，避免因容器消失导致日志丢失。
- 统一采用 stdout/stderr，避免供应商和操作系统绑定。
- 利用流式日志接口，便于后续处理和聚合。
Kubernetes 提供了日志流转能力，开发者只需关注日志内容，平台负责日志收集和聚合。对于多实例应用，Kubernetes 支持聚合所有实例日志，便于排查分布式故障。
例如，使用 kubectl logs 命令可查看指定 Pod 或标签下所有实例的日志。日志内容通常包含时间戳、服务实例标识（如 IP 地址）等信息，建议通过平台或框架自动注入实例标识，避免应用代码耦合。
日志聚合平台如 ELK（Elasticsearch、Logstash、Kibana）或商业产品 Splunk，可实现大规模日志收集、搜索和分析。只要日志输出到 stdout/stderr，并包含实例标识，即可实现强大的可观察性。
应用程序度量指标
除了日志，度量指标（metrics）为应用健康监控提供结构化数据。指标通常包括内存、CPU、HTTP 交互、垃圾回收等信息。主流框架如 Spring Boot 可通过 /actuator/metrics 端点暴露标准和自定义指标。
例如，访问 /actuator/metrics 可获取如下指标数据：
- 内存使用情况
- 线程数
- 类加载器状态
- HTTP 请求统计
- 自定义业务指标
指标收集有两种模式：
基于拉模式（Pull）
指标聚合器定期从每个服务实例拉取指标数据，并存储于时间序列数据库。此模式要求聚合器能直接访问所有实例，常见方案如在 Kubernetes 集群内部署 Prometheus，通过服务发现自动发现实例并拉取数据。
基于推模式（Push）
每个服务实例定期将指标推送至聚合器。通常通过代理组件实现，代理作为依赖编译进应用，负责将指标发送到指定地址。服务网格（如 Istio/Envoy）可作为代理，屏蔽指标收集服务的变化，简化配置和运维。
无论哪种模式，指标收集都需适应实例动态变化，确保数据在运行环境消失后仍可访问。
分布式跟踪
分布式跟踪用于还原分布式系统中的调用链，帮助定位复杂故障。传统单进程环境可通过调用堆栈调试，但云原生架构下请求跨越多个服务和容器，需借助分布式跟踪技术。
主流方案如 Zipkin 基于 Google Dapper 论文，核心包括：
- 在请求和响应中插入唯一跟踪 ID
- 控制平面收集跟踪数据，重建调用链
服务间调用时，跟踪 ID 在下游传播，并可写入日志或指标。结合时间戳等信息，可还原请求流转路径。
跟踪数据采集与分析
Spring Cloud Sleuth 框架可自动生成和传播跟踪 ID、span ID，并将数据发送至 Zipkin。只需在项目中添加相关依赖，并配置 Zipkin 服务地址和采样率，无需修改业务代码。
采样率建议设置为较低值（如 1%），避免高负载下资源消耗过大。Zipkin 提供可视化界面，支持查询和分析调用链，快速定位故障点和性能瓶颈。
故障模拟与排查
通过模拟网络中断等故障场景，可观察分布式跟踪数据的变化。例如，断开数据库连接后，Zipkin 显示请求重试、超时等异常，帮助运维人员快速定位问题。
总结
- 云原生环境下，日志和指标需主动从运行时环境中提取，避免因实例消失导致数据丢失。
- 日志聚合和指标收集平台（如 ELK、Prometheus、Zipkin）是实现可观察性的关键。
- 分布式跟踪技术为故障排查和性能分析提供了强大支持，建议在微服务架构中广泛应用。
- 应用开发应专注于业务逻辑，运维关注点可交由平台和服务网格统一处理。