微服务多了，日志去哪儿了？
你有没有遇到过这种情况：系统突然报错，你想查原因，结果发现用户操作涉及七八个服务，每个服务都在自己机器上写日志，翻来覆去找不到关键信息。这就是典型的微服务日志管理难题。
以前单体应用时代，所有逻辑都在一个程序里，日志直接写到本地文件，tail -f 看一下就完事。可现在一个用户下单动作，可能经过订单服务、库存服务、支付服务、通知服务，每个都记一笔，问题出在哪？全靠猜？
集中式日志收集的基本思路
解决办法就是“统一收上来”。不管服务部署在多少台机器上，也不管是 Java、Go 还是 Python 写的，都把日志发到一个集中的地方。常见的做法是服务只负责生成日志，然后通过轻量工具转发到日志中心。
比如用 Filebeat 抓取本地日志文件，发给 Logstash 做格式清洗，最终存进 Elasticsearch，再用 Kibana 查看。这套 ELK 组合在实际项目中很常见。
filebeat.inputs:
- type: log
enabled: true
paths:
- /var/log/order-service/*.log
output.elasticsearch:
hosts: ["http://es-server:9200"]
index: "logs-order-%{+yyyy.MM.dd}"结构化日志更省心
如果日志还是“用户下单失败，err=timeout”这种纯文本，就算集中了也难查。建议服务输出 JSON 格式的结构化日志，字段清晰。
{"time":"2024-04-05T10:30:22Z", "service":"order", "level":"error", "msg":"create order timeout", "user_id":12345, "order_id":"O202404051030"}这样一来，在 Kibana 里可以直接按 user_id 或 order_id 过滤，几分钟就能定位到某次请求的完整链路。
别忘了加上唯一追踪ID
跨服务调用时，如果每个日志条目都有同一个 trace_id，查问题就方便多了。通常入口网关生成一个全局ID，像快递单号一样，一路传下去。
比如用户请求进来，网关生成 trace_id=abc123，调用订单服务时带上这个ID，订单服务记日志时也写进去，后续每个环节都继承这个ID。你在日志系统里搜 abc123，整条链路的操作记录全出来了。
这种机制配合 OpenTelemetry 或 Zipkin 能实现更完整的链路追踪，但哪怕只是简单传递 trace_id，对排查问题也有大帮助。
小公司也能玩得转
有人觉得搞日志平台太重，小团队没必要。其实可以从轻量方案开始。比如所有服务把日志打到标准输出，用 Docker 日志驱动自动转发到云厂商的日志服务（如阿里云SLS、腾讯云CLS），不用自己搭ELK，也能快速检索。
关键是别让日志继续散落在各台机器上。只要集中起来，再逐步优化格式和查询方式，问题排查效率就能明显提升。