日志不是垃圾，是运维的宝藏
很多人觉得服务器日志就是一堆没人看的文本文件，占硬盘、难管理。但真正做过运维的人都知道，当系统突然卡住、接口大面积超时、数据库连接爆满的时候，第一个打开的，永远是那几行密密麻麻的日志。
比如某天早上，用户反馈登录不了，监控显示服务正常，CPU 和内存也没报警。这时候翻应用日志，可能就看到一条重复出现的错误：Failed to connect to Redis: Connection refused。顺着这条线索查下去，发现是 Redis 实例所在机器磁盘满了，自动停止服务。问题定位不到十分钟。
故障排查：从“猜”到“看”
没有日志的运维就像闭着眼修车。以前遇到服务崩溃，只能靠经验“猜”哪里出问题——是不是数据库慢了？是不是网络抖动？现在不用猜，直接看日志里有没有异常堆栈、超时记录、重试次数暴增的情况。
像 Nginx 的 access.log 能告诉你哪个接口被频繁调用，error.log 则能暴露 502、504 这类网关错误。结合时间线，很容易判断是上游服务挂了，还是自身资源不足。
性能优化有据可依
某个接口响应时间从 200ms 慢到 2s，光看监控图没头绪。但如果在日志里加了埋点，记录每个关键步骤的耗时，比如数据库查询、远程调用、缓存读取，就能一眼看出瓶颈在哪。
例如：
INFO — [requestId=abc123] Step: query_db took 1800ms, result_count=1一看就知道是数据库查得太久，而不是代码逻辑问题。接下来就可以去查慢查询日志，甚至直接交给 DBA 优化索引。
安全事件也能追查
某台服务器半夜 CPU 突然飙高，查看系统日志 /var/log/auth.log，发现大量 SSH 登录失败记录，来源 IP 高度集中。基本可以判定是暴力破解攻击。有了这些信息，防火墙规则马上就能加上封禁策略。
再比如 Web 应用日志里频繁出现 ../ 或 union select 这类字符串，很可能就是 SQL 注入尝试。虽然防御机制拦住了，但日志记录下来，就能评估攻击频率和来源，及时加固防护。
集中化日志让管理更轻松
小项目还能直接 ssh 上去 tail -f 日志文件，但微服务一多，几十个容器分布在不同机器上，再这么搞就疯了。这时候就得上 ELK（Elasticsearch + Logstash + Kibana）或者 Loki + Promtail + Grafana 这类方案。
所有服务统一把日志发到中心平台，按服务名、时间、关键字过滤，还能做聚合统计。比如“过去一小时 5xx 错误最多的接口是哪个”，点两下鼠标就有结果。
一个真实场景：某次发布后订单服务报错率上升，通过 Kibana 查日志，发现大量 Invalid payment token 错误。一查代码，原来是新版本把 token 校验逻辑改严了，老客户端兼容没做好。半小时回滚，问题解决。
日志设计本身也很关键
日志不是越多越好。太多无意义的 info 级别日志会淹没关键信息。合理的日志级别划分很重要：debug 给开发看，info 记关键流程，warn 表示潜在问题，error 才是真出错了。
结构化日志也越来越普及。比起纯文本：
User login failed for userId=123 at 2024-03-15T10:23:01换成 JSON 格式更容易处理：
{"level":"warn", "event":"login_failed", "userId":123, "timestamp":"2024-03-15T10:23:01"}字段清晰，方便搜索和告警规则设置。
日志分析不是锦上添花的功能，而是现代运维的基础设施。它把看不见的运行状态变成可读、可查、可分析的数据，让问题不再神秘，也让决策更有底气。