日志不是垃圾，是系统的“说话”方式
你有没有遇到过这样的情况：公司内部的报销系统突然打不开，用户一个接一个打电话来抱怨，可开发人员一查代码，说是“运行正常”。这时候，真正能说真话的，往往是那一堆没人愿意看的日志文件。
应用日志就像系统的“日记”，记录着每一次请求、每一次错误、每一次用户操作。关键是怎么读懂它，怎么从中找出真正的问题线索。下面这个分析流程，是我们日常排查中最常用的套路。
第一步：收集日志，别让数据飞走
很多小团队一开始没做集中日志管理，服务器各写各的，出了问题还得一台台登录去看。建议尽早把日志统一收集起来，比如用 ELK（Elasticsearch + Logstash + Kibana）或者轻量点的 Loki + Promtail + Grafana 组合。
举个例子，你家楼下便利店装了监控，但如果每台摄像头的录像都存在本地硬盘，抓小偷时就得挨个拔卡，效率极低。集中存储就是把所有录像传到云端，随时调取。
第二步：过滤噪音，锁定关键信息
应用日志动不动就几千行，90%是“心跳”类的常规输出，比如 INFO: User login success。真正有用的往往是那几条 ERROR 或 WARN。
可以用 grep 快速筛选：
grep "ERROR" app.log | grep "500"或者在 Kibana 里设置查询条件：level: ERROR AND response_code: 500，一下子就能看到异常高峰出现在什么时间。
第三步：关联时间线，还原事故现场
有一次我们发现支付接口超时，查日志发现是数据库连接池满了。但为什么突然满了？继续往前翻，发现在出问题前两分钟，有个定时任务拉了全量用户数据，占满了连接。
这时候就要把多个服务的日志按时间对齐。比如：
[2024-03-15 08:12:01] ORDER-SVC: Request timeout to PAYMENT-SVC
[2024-03-15 08:12:00] PAYMENT-SVC: DB connection pool exhausted
[2024-03-15 08:10:30] BATCH-JOB: Starting full user sync...时间线一拉，因果关系就清楚了。
第四步：结构化分析，让机器帮你找规律
人工翻日志只能应付小问题。如果每天产生上GB日志，就得靠结构化处理。把日志按字段拆解，比如 timestamp、level、service、trace_id，导入分析平台后，就能做统计聚合。
比如发现某个接口的错误率在凌晨2点飙升，结合部署记录，原来是那天更新了缓存策略，导致冷启动时大量穿透到数据库。
第五步：建立告警，别等用户来告诉你
最被动的运维，就是等用户投诉才行动。我们可以基于日志设定规则自动告警。比如：
- 每分钟 ERROR 日志超过 10 条
- 包含 “Connection refused” 的日志连续出现
- 特定接口响应时间 P95 超过 2 秒
用 Prometheus + Alertmanager 或者直接在 Grafana 里配阈值，手机马上就能收到通知。
就像你家的烟雾报警器，不是等火烧大了才响，而是刚有焦味就提醒，这才是真正的监控意义。