1. 日志异常检测概述与 ML 应用场景
讲日志异常检测，咱们得先聊聊什么是“日志”。说白了，日志就是系统运行时的“黑匣子”。你想想看，每次应用报错、用户登录、数据库查询，背后都会留下一串文本记录。这些记录，就是日志。
我刚开始做运维那会儿，每天的工作就是盯着终端，用 grep 和 awk 翻日志。那时候觉得这活儿挺酷，后来发现哪是酷啊，纯体力活。尤其系统一复杂，日志量一涨，人工根本盯不住。嗯，这也是为什么我们需要“异常检测”。
1.1 什么是日志异常检测
日志异常检测，就是自动从海量日志里找出“不对劲”的那部分。哪些算不对劲？比如：
- 系统报错：
OutOfMemoryError、Connection refused - 性能劣化：响应时间突然变慢，请求队列堆积
- 安全入侵：短期内大量失败的登录尝试
- 业务异常：订单创建失败率持续升高
传统做法靠人写规则。比如：“如果出现 5 次 NullPointerException，就告警。” 这方法简单，但问题也明显——你永远想不到所有异常模式。我在项目中就遇到过这种情况：某个节点内存泄露，表现不是报错，而是响应时间“温和地”变慢。规则没命中，监控系统看了个寂寞。
⚠️ 避坑指南
我曾经靠写正则规则做日志检测，结果新版本上线后，日志格式变了，1000 多条规则一夜之间全废。自那以后，我开始认真考虑 ML。
我曾经靠写正则规则做日志检测，结果新版本上线后，日志格式变了，1000 多条规则一夜之间全废。自那以后，我开始认真考虑 ML。
1.2 为什么需要 ML 来做这件事
传统方法的问题，说白了就三点：
- 覆盖不全：你不知道异常长什么样，规则自然写不出来
- 维护成本高：规则越堆越多，改一个可能导致全盘崩
- 无法适应变化：版本升级、配置变更，规则就得重写
ML 恰好能解决这些问题。它不依赖你事先定义“什么是异常”，而是从历史数据里自己学。举个例子，我最近帮一家电商做日志检测，他们的日志一天能产 50 亿条。人工查？别想了。用 ML 模型，只需要喂几天正常日志，模型就能自动记住“常见模式”。只要出现偏离，立马标红。
为什么会这样？因为 ML 看的是分布、概率和相似度，不是匹配。它更聪明，也更灵活。
1.3 ML 日志异常检测的核心流程
整个流程看起来简单，但每一步都有讲究。我用自己的实践经验，画了一个框架图。
1.4 ML 在日志异常检测中的应用场景
聊完了概念和流程，我归纳了几个最常用的 ML 场景。这些场景我基本都亲手做过，踩过坑，也尝过甜头。
| 应用场景 | 核心任务 | 常见算法 | 我的体验 |
|---|---|---|---|
| 系统故障检测 | 识别宕机、OOM、内存泄漏 | 孤立森林、LSTM | 初期阈值调不好，误报率超60%。后来改用分位数，好多了。 |
| 安全入侵检测 | 暴力破解、SQL注入、异常登录 | K-Means、Autoencoder | 模型没调好前，把正常的大促流量当成了攻击… |
| 性能瓶颈定位 | 慢查询、响应时间飙升 | 异常点检测、变点检测 | 这个场景用无监督方法更省心。 |
| 业务指标监控 | 订单失败率、PV/UV异常波动 | Seasonal Decompose、Prophet | 带周期性的数据一定要先做季节分解。 |
| 日志模式归纳 | 自动提取日志模板，减少无效告警 | Drain、LogCluster | 模板归纳是“祛噪”的第一步，这步做不好，后面全是白费。 |
💡 经验之谈
我个人习惯在项目启动前，先花2-3天梳理日志来源和格式。多花点时间在“数据理解”上，后期调模型会轻松很多。你想想看，数据有偏，模型再强也是白搭。
我个人习惯在项目启动前，先花2-3天梳理日志来源和格式。多花点时间在“数据理解”上，后期调模型会轻松很多。你想想看，数据有偏，模型再强也是白搭。
1.5 本章小结
这一章我们聊了三件事：
- 日志异常检测是干啥的，为什么传统方法不够用
- ML 的核心流程：采集 -> 解析 -> 特征 -> 训练 -> 检测 -> 反馈 -> 迭代
- 5 个最常见 ML 应用场景，以及我踩过的坑