指标监控系统和日志采集系统区别

这两个系统虽然都属于"可观测性"范畴，但解决的问题完全不同。下面从多个维度详细对比：

本质区别

维度	指标监控系统	日志采集系统
数据类型	数值（CPU 85%、内存 4.2GB）	文本（"Connection refused"、堆栈信息）
数据量级	小（每台主机每秒几条）	大（每台主机每秒数百到数千行）
数据结构	天生结构化（指标名 + 数值 + 时间戳）	天生非结构化（自由文本，需解析才结构化）
查询模式	"过去1小时CPU平均值是多少？"	"昨天下午3点有没有出现'Connection refused'？"
存储引擎	时序数据库（InfluxDB/Prometheus）	全文检索引擎（Elasticsearch）
核心价值	发现异常	定位根因

指标监控系统：看"发生了什么"

典型场景

• 资源监控：CPU、内存、磁盘、网络流量是否异常

• 服务健康：进程是否存活、端口是否监听、HTTP 接口是否返回 200

• 容量规划：磁盘使用率趋势预测，判断何时需要扩容

• SLA 保障：接口响应时间 P99 是否超过 500ms

• 告警触发：CPU > 80% 持续 5 分钟 → 触发告警

特点

• 数据量小，存储成本低

• 查询快，聚合计算高效

• 适合做趋势分析和阈值告警

• 但只能告诉你"CPU 飙高了"，无法告诉你为什么飙高

日志采集系统：查"为什么发生"

典型场景

• 故障排查：服务报错时，查看完整的异常堆栈

• 安全审计：谁在什么时间登录了系统，执行了什么命令

• 业务分析：统计各接口的调用量、成功率、响应时间分布

• 合规留存：满足法规要求，日志保留 180 天以上

• 链路追踪：通过 trace_id 串联一次请求经过的所有服务日志

特点

• 数据量大，存储成本高

• 支持全文检索和模糊匹配

• 适合做根因分析和事后追溯

• 但数据量太大，不适合做实时告警

一个完整的故障排查流程

假设线上服务突然变慢，两个系统如何配合：

1. 指标监控发现异常：Grafana 大盘显示某台主机 CPU 使用率从 20% 飙升到 95%

2. 触发告警：通过钉钉通知值班人员

3. 跳转到日志系统：在 Kibana 中筛选该主机、该时间段的日志

4. 定位根因：发现大量 "Deadlock detected" 错误日志，定位到是某个数据库查询导致的死锁

5. 修复问题：优化 SQL，重启服务

6. 验证恢复：回到指标监控，确认 CPU 回落到正常水平

指标监控是眼睛，帮你发现问题；日志系统是显微镜，帮你分析问题。

选型建议

你的需求	选择
只想知道服务器是否健康、是否需要告警	指标监控系统就够了
需要排查线上故障、分析业务行为	必须上日志采集系统
生产环境，要求快速发现 + 快速定位	两个都要，配合使用
团队小、资源有限，只能选一个	优先上指标监控（投入产出比更高），日志先用 tail -f + grep 临时解决

总结

指标监控回答的是 "What"（发生了什么异常），日志采集回答的是 "Why"（为什么发生）。两者不是二选一的关系，而是互补协作的关系。成熟的运维体系一定是"指标 + 日志 + 链路追踪"三位一体。