在公司做电商平台那会儿，系统拆成了二十多个微服务，订单、库存、支付、用户各管一块。刚开始觉得挺清爽，各自开发互不干扰。可没过多久，线上报了个问题：用户下单后状态不更新。查订单服务日志没问题，查支付回调也正常，愣是卡了两天才定位到是消息队列中间件的超时配置不对。
那次之后我才意识到，微服务拆得越细，链路越长，光看单个服务的日志根本找不到根子。真正的坑往往藏在服务之间的调用缝隙里。这时候就得靠统一的日志分析体系来兜底。
集中式日志收集是第一步
我们用的是 ELK（Elasticsearch + Logstash + Kibana），所有服务的日志通过 Filebeat 采集，集中推送到 ES。每个日志条目都加上 traceId 和 spanId，这样一次请求从网关进来，经过哪些服务、耗时多少，都能串起来查。
比如一个下单请求，在 Kibana 里搜一下 traceId，就能看到它从 API 网关 → 订单服务 → 库存服务 → 支付服务的完整路径。哪个环节响应慢、有没有抛异常，一目了然。
关键字段不能少
服务自己打日志的时候，得规范格式。我们用 JSON 格式输出，固定包含几个字段：
{"timestamp": "2024-04-05T10:23:15Z", "level": "INFO", "service": "order-service", "traceId": "abc123xyz", "spanId": "span-01", "message": "Order created successfully", "userId": "u_789", "orderId": "o_1001"}这些字段看着简单，真出问题时就是救命稻草。特别是 traceId，必须从入口服务生成，一路透传下去，不能断。
别等出事才查日志
我们设置了几个关键指标的监控告警：错误日志数量突增、特定异常关键词（比如 ConnectionTimeout）、慢请求比例超过阈值。一旦触发，自动发钉钉通知到值班群。
有次半夜报警，日志里突然冒出一堆数据库连接池耗尽的错误。翻记录发现是某个新上线的服务没配连接池大小，默认用了 10，扛不住流量。要不是日志监控及时拦住，第二天早高峰就得崩。
结合调用链更高效
光看日志还不够，我们搭了 SkyWalking 做 APM。它能自动生成服务拓扑图，点进去直接跳转到对应 traceId 的日志详情。有一次发现用户服务频繁调用认证服务，延迟高，结果一查是缓存没生效，重复走数据库验证。这个问题要是纯靠人工翻日志，估计得花几小时。
现在排查问题基本是这个流程：先看监控大盘 → 定位异常服务 → 拿 traceId 查调用链 → 跳转日志看上下文 → 修复并验证。一套下来，半小时内搞定常见问题。
权限和归档也得管
日志集中之后，安全也不能马虎。我们按部门和角色做了 Kibana 的访问控制，运维能看到全量日志，开发只能查自己负责的服务。敏感信息比如手机号、身份证号，打日志前就脱敏处理。
日志保留策略设了 30 天，冷数据自动归档到对象存储。既省成本，又满足审计要求。毕竟谁也不想因为一条日志丢了被追半年前的问题吧。