3. 数据采集基础：日志采集、API监控、数据库埋点与数据清洗流程
告警阈值设定的准确性，高度依赖底层数据的质量。如果采集的数据存在延迟、丢失或格式混乱，后续的阈值计算与异常定位将失去意义。本章系统讲解数据采集的三大核心来源——日志、API、数据库埋点，以及保障数据可用性的清洗流程。
3.1 日志采集：从文件到消息队列
日志是系统运行状态最直接的记录。生产环境中，日志采集通常采用 Agent → 传输层 → 存储层 的架构，以应对海量、高并发的写入场景。
核心原则： 日志采集必须保证 至少一次送达（At-Least-Once），并具备断点续传能力，避免因网络抖动导致数据丢失。
3.1.1 主流采集方案对比
| 组件 | 采集方式 | 适用场景 | 关键特性 |
|---|---|---|---|
| Filebeat | 监听文件变化，逐行读取 | 轻量级日志采集，容器化环境 | 内存占用低，支持多行合并 |
| Fluentd | 插件式输入/输出 | 复杂数据源（HTTP/TCP/Syslog） | 内置缓冲与重试机制 |
| Logstash | 消费消息队列，过滤转换 | 需要复杂数据清洗的场景 | 支持 Grok 正则解析 |
| Vector | 统一 Agent + 传输管道 | 需要同时处理日志、指标、Trace | 单一二进制，性能极高 |
3.1.2 日志采集典型架构
下图展示了一条 Nginx 访问日志从产生到进入 Elasticsearch 的完整链路：
避坑提示： 日志采集最常遇到的异常是 多行日志断裂（如 Java 堆栈信息被拆成多条记录）。Filebeat 的
multiline 配置必须按实际日志格式设置匹配模式，否则告警分析时无法还原完整错误上下文。
3.2 API 监控：主动探测与被动采集
API 监控分为 主动探测（模拟请求）和 被动采集（分析真实流量）两种模式。告警阈值设定通常依赖被动采集的延迟、错误率等指标。
3.2.1 被动采集关键指标
| 指标名称 | 采集方式 | 告警阈值参考 |
|---|---|---|
| P99 延迟 | 从响应头耗时字段提取 | > 2000ms 触发警告 |
| 5xx 错误率 | 状态码计数 / 总请求数 | > 1% 触发严重告警 |
| 请求量突降 | 滑动窗口对比前 10 分钟 | 下降 > 50% 触发异常 |
| 超时比例 | 响应时间 > 5000ms 的请求占比 | > 5% 触发告警 |
3.2.2 数据采集点设计
在 API 网关或反向代理层（如 Nginx、Kong、APISIX）统一采集是最佳实践，避免在每个微服务中重复埋点。
# Nginx 日志格式示例（采集 API 监控所需字段）
log_format api_monitor '$remote_addr - $remote_user [$time_local] '
'"$request" $status $body_bytes_sent '
'"$http_referer" "$http_user_agent" '
'$request_time $upstream_response_time '
'$upstream_status $upstream_addr';
注意： 被动采集依赖真实流量，当业务低峰期请求量极低时，错误率等百分比指标会剧烈波动。此时应结合 最小样本数（如每分钟至少 100 个请求）来抑制无效告警。
3.3 数据库埋点：慢查询与连接池监控
数据库是告警阈值设定的核心数据源之一，重点关注 慢查询日志 和 连接池状态。
3.3.1 慢查询日志采集
MySQL 慢查询日志记录了执行时间超过 long_query_time 的 SQL 语句。采集方案通常为：
- 方案 A： 开启 MySQL
slow_query_log，由 Filebeat 采集日志文件。 - 方案 B： 使用
performance_schema表直接查询，适合云数据库场景。 - 方案 C： 通过代理层（如 ProxySQL）统一记录慢查询。
3.3.2 连接池与活跃连接数
连接池耗尽会导致应用无法获取数据库连接，是生产环境的严重故障。以下为关键采集指标：
| 指标 | 采集命令/方式 | 告警阈值建议 |
|---|---|---|
| 活跃连接数 | SHOW PROCESSLIST |
> 80% 最大连接数 |
| 等待连接数 | 连接池监控接口 | > 10 持续 30 秒 |
| 慢查询数/分钟 | 慢查询日志计数 | > 50 次/分钟 |
| 死锁次数 | SHOW ENGINE INNODB STATUS |
> 0 立即告警 |
3.4 数据清洗流程：从原始数据到可用指标
原始采集数据通常包含脏数据、重复数据、格式异常等问题。数据清洗是告警阈值准确性的最后一道防线。
3.4.1 清洗流程步骤
- 格式标准化： 统一时间戳格式（如 ISO 8601）、IP 地址格式、状态码枚举值。
- 去重： 基于唯一 ID（如 request_id、trace_id）去除重复记录。
- 异常值过滤： 剔除明显不合理的数据（如延迟为负数、请求量为 0 但错误率不为 0）。
- 缺失值填充： 对缺失的数值型字段，使用前值填充或默认值（如 0）。
- 聚合降采样： 将秒级原始数据按 1 分钟/5 分钟窗口聚合，减少存储压力。
3.4.2 清洗前后数据对比
| 维度 | 清洗前 | 清洗后 |
|---|---|---|
| 时间戳 | 2024-01-15 10:30:22 +0800 | 2024-01-15T02:30:22Z |
| 请求延迟 | -1（异常值） | 剔除（不参与聚合） |
| 状态码 | 200, 200, 200, 500, 200 | 200, 200, 200, 500, 200 |
| 重复记录 | 2 条相同 request_id | 保留 1 条 |
3.4.3 清洗流程架构
以下为基于 Flink 的实时数据清洗管道设计：
关键实践： 数据清洗规则必须版本化管理，并记录每次清洗的丢弃率。如果丢弃率突然升高（如 > 5%），说明上游数据源或清洗规则可能存在问题，需要及时排查。
3.5 本章小结
- 日志采集 采用 Agent → 消息队列 → 清洗 → 存储的架构，重点保障断点续传与多行合并。
- API 监控 以被动采集为主，关注 P99 延迟、错误率、请求量突降等指标，注意低流量时的统计波动。
- 数据库埋点 聚焦慢查询日志与连接池状态，连接池耗尽需立即告警。
- 数据清洗 是告警准确性的保障，包含标准化、去重、异常过滤、聚合四个核心步骤。