一、日志巡检概述：背景、重要性、常见场景
1.1 什么是日志巡检？
说实话，很多刚入行的运维同学会把日志巡检等同于“看日志”。但在我眼里，这两者差得远了。
日志巡检，不是等你系统出问题了，再去翻文件搜关键字。它是一种主动的、持续的行为——定时或实时扫描日志流，从中发现异常、趋势、安全威胁和性能瓶颈。
你想想看，为什么大活儿都卡在日志查错上？
因为日志本身只是一个“流水账”，没有分析、没有聚合、没有告警。做巡检，就是把这张流水账变成一份财务报表——你知道哪里赚了、哪里亏了、哪里快崩了。
| 对比项 | 传统查日志 | 日志巡检 |
|---|---|---|
| 触发方式 | 被动，等用户反馈或服务挂了 | 主动，定时或实时扫描 |
| 关注点 | 单条错误 #error 找原因 | 趋势、频率、模式、关联 |
| 工具 | grep、tail、less | ELK、Loki、Graylog、自研脚本 |
| 产出物 | 一段报错截图 | 巡检报告、告警通知、趋势图 |
| 效率 | 小时级定位 | 秒级或分钟级发现 |
1.2 日志巡检为什么越来越重要？
我记得刚做运维那会儿，线上就两台服务器，出了问题直接 ssh 上去 tail -f 看。但现在，你一个微服务架构可能几百个 Pod，全是容器，天天滚动重启。手动查？不现实。
咱们聊三个最现实的驱动力：
- 规模爆炸：节点数从个位数到成百上千，日志量每天几十 GB 甚至 TB 级。人力根本看不过来。
- 复杂依赖：一个请求可能经过 5-8 个服务。单节点日志根本拼不出全貌，需要全链路聚合。
- SLA 压力：老板要求 99.99% 可用性。你不能再等用户骂了才去查日志——慢 5 分钟可能就是几十万损失。
我个人的经验是：日志巡检不是运维的“加分项”，而是“保命项”。 没有它，你就是在黑灯瞎火里修电路。
1.3 日志巡检解决的核心问题
说白了就是三件事——
- 可见性：系统在干什么？哪些服务在报错？错误率是上升还是下降？
- 可预警：别等到硬盘写满了才告诉我。每天凌晨巡检一次，能早 8 小时发现满盘风险。
- 可追溯：线上出事故了，能不能 10 分钟内还原完整时间线？日志巡检做得好，答案是可以。
L1 - 存活巡检：服务是否在跑，日志是否在写。
L2 - 异常巡检：ERROR、WARN 级别是否超过基线。
L3 - 业务巡检：交易成功率、响应延迟是否符合预期。
第一天就做 L3 很容易劝退，建议从 L2 起步。
1.4 常见的日志巡检场景
这里我列几个我最常遇到的场景，你大概率也会碰见。
1.4.1 故障排查与根因分析
前几天我帮一个团队排查线上 P1 故障。用户反馈支付失败，但 APM 面板显示成功率 99.5%，看起来问题不大。我直接把支付服务的 ERROR 日志拉出来做了个时间序列分析——发现每整点后 5 分钟，支付接口报错量会陡增 3 倍。最后定位到是定时任务脚本锁表导致的。如果只看 APM 摘要，你永远不知道。
所以我说，APM 告诉你“生病了”，日志告诉你“怎么病的”。
1.4.2 安全审计与入侵检测
安全场景的核心逻辑很简单：不正常的行为一定有痕迹。比如同一个 IP 在 1 分钟内尝试登录 50 次、凌晨 3 点 root 登录、access.log 里出现 SQL 注入特征参数。这些都是巡检规则可以覆盖的。
1.4.3 合规审计与报表生成
金融行业、医疗行业有明确要求：操作日志必须保留 180 天以上，且每月输出合规报告。日志巡检工具不光要“查”，还要“存”和“算”——谁、什么时候、做了什么、有没有越权。用脚本写出来也能用，但维护成本极高。我建议早点上专业工具。
1.4.4 性能趋势与容量预测
我记得有一次巡检日志，发现某个微服务的 GC 日志里 Full GC 频率从每天 1 次增长到每小时 3 次，持续了一周。当时还没触发告警，但我直接在周报里写了“建议扩容内存，预计下周会 OOM”。结果第三天真的 OOM 了。这就是做趋势分析的价值——不等故障发生再修。
| 巡检场景 | 典型日志源 | 关注指标 | 触发频率 |
|---|---|---|---|
| 故障排查 | 应用日志、中间件日志 | ERROR 频率、堆栈出现次数 | 实时 / 近实时 |
| 安全审计 | 系统日志、访问日志、堡垒机日志 | 登录失败次数、异常 IP 频率 | 每天 / 每小时 |
| 合规审计 | 操作日志、数据变更日志 | 敏感操作记录、权限变更 | 每月 / 每周 |
| 性能趋势 | GC 日志、慢查询日志、Nginx access log | 平均响应时间、QPS、GC 停顿 | 每小时 / 每天 |
1.5 本章知识体系总览
下面这张图浓缩了整个第 1 章的核心结构。它从“为什么要做日志巡检”出发，落到 4 个具体场景，最后指向 3 层核心价值。你看完其实就能回答一个问题：日志巡检到底帮我解决什么实际问题？
1.6 什么样的人需要学这门课？
不是所有人都有必要看这门课，但以下三类人我觉得非常对路：
- 初级运维 / SRE：你还在用 tail -f 和 grep 排查问题？是时候升级到自动化巡检了。
- 后端研发：你的微服务天天被用户投诉慢？日志巡检能帮你把“我感觉”变成“数据证明”。
- 安全运维：你需要从海量日志里挖出可疑行为？手动规则够用，但开源工具效率提升 10 倍。
我给你的第一条避坑指南：不要急着加规则，先把噪音比降到可控范围内。否则巡检工具就是另一种混沌。
1.7 小結：你应该带走什么？
到这里，第一章其实就讲清楚了四件事：
- 日志巡检≠查日志，它是主动、结构化、规则驱动的行为。
- 规模、复杂性、SLA 这三座大山逼着你必须上巡检。
- 落地时先做 L2（异常巡检），再逐步延伸到业务巡检。
- 故障排查、安全审计、合规报表、性能趋势——这四个场景每个团队都会遇到。