问题从哪来？
想象一下，你负责的系统由十几个微服务组成，用户突然反馈某个功能打不开。你登录一台机器查日志，没发现异常；换另一台，看到一堆报错，但信息不全；再翻几个服务，时间对不上，上下文断了。这时候，靠人肉拼凑请求链路，就像在不同城市的监控录像里找同一个小偷，费劲又容易漏。
为什么集中处理日志成了刚需
单体架构时代，所有日志写在一个文件里，出问题翻一下就能定位。现在服务一拆，日志散落在各个节点，甚至跨机房、跨云平台。一个用户请求可能经过网关、订单、库存、支付多个服务，每个都可能出错。如果还用老办法逐个登录查，等找到原因黄花菜都凉了。
技术选型不是堆砌工具
很多人一上来就想着上 ELK（Elasticsearch + Logstash + Kibana），但光有工具不够。关键是怎么把分散的日志串起来。核心思路是：统一采集、带上上下文、集中存储、快速检索。
比如在服务入口生成一个唯一的 trace ID，随着请求传递到下游每个环节。每个服务在打日志时，把这个 ID 记进去。等出了问题，直接在日志平台搜这个 trace ID，所有相关记录一键拉出，整个调用链清晰可见。
实际配置示例
以 Spring Cloud 为例，在网关层注入 trace ID：
String traceId = UUID.randomUUID().toString().replace("-", "");
MDC.put("traceId", traceId);然后在日志格式中加入占位符：
<pattern>%d{yyyy-MM-dd HH:mm:ss} [%thread] %-5level %logger{50} - [traceId:%X{traceId}] %msg%n</pattern>这样每条日志都会自动带上当前线程绑定的 trace ID，后续通过 Filebeat 或 Logback 原生支持发送到 Kafka 或直接入 ES。
别忽视传输和存储成本
不是所有日志都要存一年。错误日志重要，保留久一点；调试日志量大，三天就够了。可以通过日志级别做索引生命周期管理。同时，网络带宽也得算清楚，尤其是跨区域传输，别让日志拖垮业务流量。
报警要精准，别制造噪音
有人喜欢设个“每分钟出现 Exception 就告警”，结果半夜被叫醒十几次，全是已知的第三方接口抖动。更好的做法是结合上下文判断，比如连续五分钟错误率超过 5%，或者特定错误码集中出现。用 Grafana 配合 Loki 或 ES 做趋势图，比单纯关键词匹配靠谱得多。
真实场景中的取舍
我们之前有个项目，初期为了省事，所有服务都往一个 ES 集群写日志，后来查询越来越慢。后来拆成两个集群：一个是核心交易链路，保留 30 天，高配索引；另一个是非核心服务，只留 7 天，低频存储。既控住了成本，又保障了关键路径的排查效率。
分布式错误日志整合不是一锤子买卖，得跟着业务走。开始可以简单点，先把日志收上来再说。等量上来了，再逐步加 trace ID、做结构化、优化查询体验。关键是别等到炸了才想起修防火墙。