第二章 日志告警系统基础：采集、规则、级别与处置流程
做密码改造项目，头一件事就是把日志告警系统理清楚。我见过不少团队，上来就写告警规则，结果采集源头都没对齐，告警铺天盖地全是垃圾。今天就从头梳理一遍核心基础知识。
本章核心脉络：日志怎么来的 → 规则怎么定的 → 级别怎么分 → 告警来了怎么处理。四个环节串成一条线，缺一个环节都会崩。
2.1 日志采集：告警的“原料”
没有日志，告警就是无源之水。密码改造场景下，日志源主要有三类：密码服务平台自身日志、周边系统日志（如LDAP/KDC）、网络设备日志。采集方式我归纳了四种主流手段：
| 采集方式 | 典型应用场景 | 优点 | 我在项目里踩过的坑 |
|---|---|---|---|
| Agent采集 | 服务器端应用日志（如Java应用log4j） | 细粒度、可过滤 | Agent版本和OS不兼容，导致采集中断 |
| Syslog/UDP/TCP | 网络设备、Linux系统日志 | 标准协议、兼容性好 | 默认UDP丢包严重，改TCP后丢包率降到0.1% |
| API/REST拉取 | 云服务、第三方密码平台 | 无侵入、安全可控 | API限频导致漏采，需要用队列缓冲 |
| SNMP Trap | 网络交换机、防火墙 | 实时性高 | Community字符串泄露是安全隐患 |
我个人习惯的做法：先梳理所有密码系统生成日志的路径——是写文件？是发Syslog？还是调API？列成清单，然后针对每条路径选采集方式。千万不敢凭经验拍脑袋，你得去现场看。
小技巧：日志采集链路里一定要加“健康检查”指标。我曾经遇到Agent进程OOM killed，三天没日志，告警系统还在显示“正常”——因为采集程序没挂，只是没吐出新日志。这是一个非常隐蔽的故障。
2.2 告警规则定义：把“噪音”变成“信号”
日志采集上来之后，我们要靠规则从中提取有意义的事件。规则定义是告警系统的“大脑”。说白了，就是写条件判断：事件A出现超过阈值B，且持续C时间，就触发告警。
一个标准的告警规则包含以下要素：
- 数据源：来自哪个采集通道（例如：syslog-for-mq-server）
- 过滤条件：关键字匹配、正则表达式（例如：
.*密码验证失败.*） - 聚合窗口：多长时间内统计（例如：5分钟滑动窗口）
- 阈值：达到多少次数触发（例如：>= 10次）
- 静默期：同一规则重复触发的间隔（避免告警轰炸）
- 告警级别：触发后标注哪个级别（后面会详细讲）
重要提醒：规则定义最容易犯的错是“阈值设得太低”。我经历过一个项目，把“SQL注入尝试”的阈值设为1次/分钟，结果扫描器一跑整个运维群炸了——全是误报。一定要结合基线数据来设。
举个实际例子：密码服务登录失败检测规则（JSON格式示意）：
{
"ruleName": "密码服务暴力破解检测",
"source": "pwd-service-agent",
"filter": "log.message contains 'Login failed'",
"aggregate": {
"window": "5m",
"count": 5
},
"interval": 300,
"severity": "high"
}2.3 告警级别：分清轻重缓急
级别如果不分清楚，运维人员要么被淹死，要么对高等级告警麻木。我一般把告警分为四级，直接跟处置时限挂钩：
| 级别 | 颜色标记 | 定义 | 处置时限 | 典型场景举例 |
|---|---|---|---|---|
| 紧急 | 红色 | 核心功能中断、已影响用户 | ≤ 15分钟 | 密码服务完全挂掉、密钥库不可访问 |
| 高 | 橙色 | 功能受损但用户未被直接阻断 | ≤ 1小时 | 登录超时率>20%、证书即将过期 |
| 中 | 黄色 | 异常但不影响核心流程 | ≤ 4小时 | 单节点CPU>90%、审计日志写入积压 |
| 低 | 蓝色 | 信息性通知、潜在风险 | ≤ 24小时 | 磁盘空间使用率达到75%、备份任务延迟 |
一个经验：级别不是拍脑袋定，而是根据“影响范围 × 恢复难度”来算。密码改造项目中，密钥轮换失败看起来危害很大，但如果你有备用密钥机制，它可能只是“高”级而非“紧急”级。定级之前一定要跟业务方对过应急预案。
2.4 处置流程：从告警到闭环
告警触发之后，怎么做？没有标准流程的告警系统就是个喇叭，响了没人动。
我建议把流程画成闭环的“处置四步”：接收 → 确认 → 处置 → 关闭。每一步都要有明确角色和时限。
我再说说每个步骤的注意点：
- 接收告警：保证通知能到达正确的人，不要全量推送。密码改造项目中我建议分“值班组”和“二线组”，紧急告警直接电话+群@所有人，普通告警只发群消息。
- 确认/定级：确认人要在5分钟内响应。如果未确认，自动升级。我曾经遇到过告警发了没人看，结果一个小时过去了才知道是紧急事件——从那以后我坚持加“未确认自动再通知一次”的机制。
- 分析处置：要有标准化排查模板。例如“密码服务登录失败告警”的排查步骤：先看数据库连接池→再看证书有效期→再查并发数。不能只给告警，不给指引。
- 关闭形成：关闭前必须确认根本原因已消除，并且写一条处置记录。这条记录会成为后续自愈脚本的基础数据。
避坑指南：处置流程里最容易忽略的是“回归验证”。我见过运维人员重启服务后直接关告警，结果三分钟后又触发了同一告警。正确的做法：关闭前执行一次“告警是否仍然存在”的检测，确认没问题再close。自动化平台可以做自动verify。
2.5 告警系统基础架构总结
我把本章核心整理成一张知识结构表，方便你对照搭建自己的告警体系：
| 模块 | 关键组件 | 注意事项 |
|---|---|---|
| 日志采集 | Agent、Syslog Server、API Gateway、消息队列 | 采集点全覆盖 + 健康检测，避免“死采集” |
| 规则引擎 | 流式计算框架（如Flink/Spark Streaming）、规则库 | 阈值需基于基线校准，静默期防重复 |
| 告警分级 | 级别定义表、分派策略 | 与业务方对齐影响范围，避免定级失当 |
| 处置流程 | 工单系统、自动升级、知识库 | 每个步骤都要有时限，闭环可追溯 |