日志不是垃圾，是系统的“行车记录仪”
很多人觉得服务器日志就是一堆没人看的文本文件，堆在磁盘角落吃灰。直到线上突然报错，用户打不开页面，才想起翻日志。这时候手忙脚乱地 ssh 登上去，grep 一通，发现日志太多，关键词满屏飞，根本看不出哪条是关键。
其实，写得好的日志加上合理的分析手段，能让你像看回放一样还原整个请求链路。比如某个订单支付失败，通过日志可以清楚看到：用户发起请求 → 网关鉴权通过 → 下单服务调用库存接口超时 → 返回失败。每一步都有时间戳和状态标记，问题出在哪一环一目了然。
结构化日志让机器也能“读懂”
传统日志常是这样：2024-05-12 14:23:11 ERROR Failed to process order 12345。信息太少，想查上下文还得翻前几行。
换成 JSON 格式的结构化日志：
{"timestamp": "2024-05-12T14:23:11Z", "level": "ERROR", "service": "order-service", "trace_id": "abc123", "message": "failed to call inventory service", "order_id": 12345, "upstream_ip": "10.0.1.100"}字段清晰，可以直接被 ELK（Elasticsearch + Logstash + Kibana）这类工具消费，支持按 trace_id 聚合整条调用链，排查效率提升不止一个档次。
别在生产环境裸奔：日志级别要分清
开发时把 log.info 当 println 用，上线后全开 debug 级别，不出三天磁盘就爆了。合理使用日志级别是基本功。
error 级别留给异常中断类事件，比如数据库连接失败；warn 用于可恢复但需关注的情况，例如缓存未命中；info 记录关键流程节点，如“订单创建成功”；debug 则留给细节追踪，日常关闭即可。
Spring Boot 中可以通过配置动态调整某类服务的日志级别，不用重启应用：
logging.level.com.example.orderservice=DEBUG结合链路追踪，看得更远
微服务一多，一个请求经过七八个服务太常见。光看单个服务日志，就像只看一段监控录像。引入 OpenTelemetry 或 SkyWalking 后，每个请求生成唯一 trace_id，所有相关日志都带上这个 ID。
出问题时，在 Kibana 里搜一下 trace_id，就能串起全部服务的日志流。哪个环节耗时最长、哪个服务返回了 500，一眼就能定位。
别等出事才看日志，日常巡检很有必要
就跟开车不能只等故障灯亮才检查仪表盘一样。定期查看日志中的 error 和 warn 数量趋势，能提前发现潜在问题。比如某接口 warn 日增 50%，虽然还没挂，但可能是下游响应变慢的前兆。
可以设置简单的告警规则，比如“每分钟 error 日志超过 10 条发通知”，配合 Grafana 展示日志统计图表，做到心里有数。
日志分析不是高深技术，但它决定了你解决问题的速度。把日志当资源而不是负担，开发效率自然就上来了。