为什么微服务的日志这么难找
你有没有遇到过这种情况：线上突然报错，用户说功能不能用，你打开系统一看，一脸懵。查服务A，没问题；查服务B，也没报错。结果折腾半小时，才发现是服务C里一条不起眼的日志在凌晨三点默默记录了数据库连接超时。
这就是微服务的现实——服务拆得越细，出问题的地方就越分散。每个服务都在自己写日志，文件存本地，命名还不统一。想找条关键错误？就像在十个快递站里找一张发错货的订单小票。
集中式日志收集的基本思路
解决办法其实不复杂：不让日志留在原地，统一收上来。常见做法是每个服务把日志输出到标准输出（stdout），然后用日志采集工具自动抓取、打标签、传到中央存储。
比如你在 Spring Boot 服务里配置：
<configuration>
<appender name="STDOUT" class="ch.qos.logback.core.ConsoleAppender">
<encoder>
<pattern>%d{yyyy-MM-dd HH:mm:ss} [%thread] %-5level %logger{36} - %msg%n</pattern>
</encoder>
</appender>
<root level="INFO">
<appender-ref ref="STDOUT" />
</root>
</configuration>这样日志就都往 stdout 写了，接下来交给采集工具处理。
常用技术组合：ELK + Filebeat
ELK 是 ElasticSearch、Logstash、Kibana 的合称，搭配 Filebeat 能跑得很稳。Filebeat 装在每台服务器或容器里，监听日志输出，转发给 Logstash 做解析和过滤，再存进 ElasticSearch，最后用 Kibana 查看。
举个场景：订单服务调用支付服务失败。你在 Kibana 里搜索 trace_id，一下子就能看到整个链路的日志流，从下单开始，到库存扣减，再到支付回调失败，全过程串在一起。
如果不用这套，你可能得登录三台机器，翻三个不同的 log 文件，再手动拼时间线。
别忘了加唯一标识
微服务之间来回调用，光看时间戳对不上上下文。这时候需要在请求入口生成一个全局唯一的 trace_id，并通过 HTTP header 或消息头一路透传下去。
Java 项目里可以用 Sleuth：
spring.application.name=order-service
spring.sleuth.sampler.probability=1.0加上之后，每条日志自动带上 trace_id 和 span_id，Kibana 里点一下就能追踪完整调用链。
避免日志污染和性能拖累
不是所有东西都该往日志里写。有人喜欢在 debug 时打印整个用户对象，结果日志文件暴涨，ES 存储一天涨 50GB。更糟的是，敏感信息比如手机号、身份证直接裸奔。
建议做几件事：一是结构化日志，用 JSON 格式输出关键字段；二是加日志级别控制，生产环境关掉 DEBUG；三是敏感字段脱敏处理。
比如输出日志时：
{"level":"INFO", "service":"user-service", "action":"login", "userId":"10086", "ip":"192.168.1.1", "success":true}这样一搜 action:login 就能批量分析登录行为，也不怕泄露隐私。
容器环境下更要提前规划
用 Docker 或 Kubernetes 部署时，本地日志文件随时会消失。Pod 一重启，之前的日志就没了。所以从一开始就得设计好日志外送路径。
K8s 里推荐用 DaemonSet 部署 Filebeat，自动挂载容器日志目录，实时采集。或者直接用云厂商的日志服务，比如阿里云 SLS、腾讯云 CLS，配置几个 annotation 就能自动接入。
上线前没搞这一步，等真出问题了再去补，往往已经错过了黄金排查期。