日志巡检需求分析：为什么需要自动化日志巡检？
做运维这些年，我越来越觉得一个道理：日志本身就是一座金矿，但大部分人只挖了个坑就跑了。你想想看，每天几百GB的日志堆在那里，几个人盯着看？传统巡检说白了就是人肉筛数据，既慢又容易漏。这一节我就跟你聊聊，为什么必须上自动化。
传统巡检的痛点：人扛不动了
我刚开始带团队那会儿，日志巡检全靠值班人员轮班。每人一台终端，打开 Kibana 或者直接 grep，翻来覆去找关键字。那种方式，说白了就是碰运气。
- 漏报是常态。 一个异常关键字被淹没在几千行 INFO 日志中，肉眼根本扫不到。我曾经遇到一次线上故障，事后翻日志才发现早三天就有 "connection refused" 的警告，但当天值班的人根本没注意到。
- 响应速度慢。 从日志产生到人工发现，中间往往隔了几个小时。你再往上查告警，再打电话叫同事，黄花菜都凉了。
- 人力成本高。 一个成熟的运维工程师，年薪几十万，每天却花 30% 的时间在刷日志上。你说亏不亏？
- 标准不统一。 张三查日志喜欢用 grep ERROR，李四喜欢看 status code 5xx。每个人心里一把尺，怎么定基线？
巡检的频率与目标：不是越快越好
很多人以为自动化就是“每秒钟扫一遍”，其实不是。频率要跟你业务的容忍度挂钩。我个人习惯分三类场景来定：
| 场景 | 巡检频率 | 目标 |
|---|---|---|
| 核心交易链路 | 实时 / 每分钟 | 发现即告警，延迟 ≤ 5s |
| 内部工单/报表系统 | 每 5~15 分钟 | 及时通知，容忍 10 分钟 |
| 离线分析、归档日志 | 每小时 / 每日 | 事后审计，无需实时 |
这里有个容易被忽视的点：巡检频率越高，对下游存储和计算的压力就越大。我记得有一次给客户做方案，对方要求核心链路做到“秒级巡检”。我一算，他们的日志量每秒 20 万条，如果每秒钟全量查询一次，光查日志就得消耗 8 核 16GB 的实例。后来我建议改用滑动窗口 + 增量聚合，频率降到每 10 秒一次，资源直接省了一半。
成本与性能的平衡：不能为了自动化烧钱
自动化不是不花钱。Serverless 按量付费的特性，其实是一把双刃剑。用好了省钱，用不好破产。我曾经见过一个团队，把全量日志每小时全库扫描一次，一个月日志存储费加查询费花了 8 万美金。老板差点没把运维负责人骂哭。
怎么做平衡？我总结了三板斧：
- 分层存储。 热日志（7 天内）放 SSD 或者高频存储，冷日志（7~30 天）放低频存储，超过 30 天的放归档。查询时只扫热层，冷数据只在必要时回拉。
- 预聚合。 别每次都全量扫原始日志。先做一轮流式聚合，把关键指标的统计结果（如每分钟 5xx 次数、平均响应时间）写入指标表。巡检直接查指标表，快又省。
- 查询限流。 给每个巡检任务分配固定的查询并发配额，避免一个任务把整个集群打满。我在项目中习惯用 Serverless 的预留并发 + 最大并发限制来兜底。
一个常见的误区： 很多人觉得“既然是 Serverless，那就不用管资源”。错。Serverless 只是帮你自动伸缩，但每一秒的计算都是钱。如果巡检脚本写得不好（比如每次都要扫描全量日志），云厂商的账单会让你心碎。
下面这张图把巡检需求分析的几个核心维度串了起来，你可以对照着梳理自己的场景。
这张图里，最核心的点是三个决策维度必须互相制衡。你想想看，如果追求秒级巡检，成本一定会往上窜；如果为了省钱把频率降到一天一次，那和没有巡检有什么区别？真正好的方案是在业务容忍度之内，找一个性价比最高的点。
从需求到设计：一句话总结
自动化日志巡检不是“上了就行”，而是要在频率、目标、成本三者之间找到你的平衡区。我个人的建议：先从业务容忍度最高的场景入手，比如非核心系统先做每小时巡检，积累经验后再逐步压榨频率。别一上来就追求极致实时，容易把预算做爆炸。