Prometheus 看指标（性能/状态） ，ELK 看日志（报错/详情）
两者完全不冲突，各司其职，缺一不可
Alertmanager 只是 Prometheus 的「告警配件」，替代不了 ELK
一、先分清：两个体系管的东西完全不一样
1. Prometheus + Grafana + Alertmanager
只负责：监控指标、性能、健康度、告警
你文中说的：
- CPU、内存、磁盘
- JVM 堆内存、GC、线程
- HTTP 成功率、QPS、接口延迟 P95/P99
- 服务器/容器负载
👉 特点：
- 看宏观数据、趋势、性能指标
- 适合：看「服务慢不慢、挂没挂、资源够不够」
- 数据精简、定时采集、适合画图、告警
❌ 致命缺点：不存详细日志
报错了，它只会告诉你：接口报错率飙升
但不知道为啥错、报错堆栈、入参、SQL、业务上下文
2. ELK 栈（Elasticsearch + Logstash + Kibana）
只负责：全量日志收集、存储、检索、排查
收集：
- 应用控制台日志
- 错误堆栈
- 接口入参/出参
- SQL 日志
- 异常信息
- 微服务分布式链路日志
👉 特点：
- 存海量原始文本日志
- 关键词搜索、过滤、排查问题
- 适合：线上报错、查原因、定位代码BUG
❌ 缺点：
不做性能指标监控，不看CPU/JVM/延迟
二、线上排障完整流程（一看就懂）
- Prometheus 告警
短信/钉钉报警：
订单服务 P99 延迟过高、错误率暴涨
-
你打开 Grafana
确认：CPU正常、JVM频繁GC、接口大量500
✅ 只知道「出问题了、哪里异常」
-
打开 Kibana（ELK）
搜索：500、异常类名、用户ID、请求ID
查到：
- 具体报错堆栈
- 哪行代码炸了
- 当时请求参数
- 数据库报错SQL
✅ 真正定位根因
三、为什么不能只用 Prometheus？
举个例子：
Prometheus 只能告诉你：
接口错误率 30%
但不知道：
- 是空指针？
- 数据库超时？
- 参数非法？
- 第三方接口挂了？
没有 ELK，线上报错只能瞎猜。
四、ELK 是标配吗？
1. 大厂/中大型项目 / 微服务架构
✅ 必装 ELK（或替代方案）
微服务实例几十上百个，日志分散在无数容器里，
不集中收集，根本没法查日志
2. 小项目/单体应用/个人项目
❌ 可以不用
直接看容器日志、服务器日志就行，没必要太重。
3. ELK 平替（现在很多公司用）
成本更低、轻量：
EFK （Filebeat + Elasticsearch + Kibana）
Loki（搭配 Grafana，轻量日志方案）
- Prometheus+Grafana：
盯着服务性能、资源、接口快慢、健康状态，出问题及时告警 - ELK：
把所有微服务日志全部汇总起来，方便查报错、排BUG、审计
| 组件 | 核心数据 | 用途 | 能不能互相替代 |
|---|---|---|---|
| Prometheus | 指标(数值) | 性能监控、告警、看板 | 不能 |
| ELK | 日志(文本) | 问题排查、错误溯源 | 不能 |
| Alertmanager | 告警分发 | 只是Prometheus的通知工具 | 不算独立体系 |
ELK三个组件分别干啥（大白话）
1. L 👉 Logstash（日志搬运+清洗工）
入口、加工、过滤
- 从各个微服务/容器收集原始日志
- 过滤无用日志、脱敏（手机号/密码）
- 格式化、拆分字段、打标签（服务名、环境、IP）
- 清洗完，统一发给 Elasticsearch
类比：快递分拣中心，拆开包裹、分类、贴标签
2. E 👉 Elasticsearch（日志仓库+搜索引擎）
存日志、存海量数据、快速检索
- 海量日志持久化存储
- 支持按关键词、报错、用户ID、链路ID快速搜索
- 分布式，能无限加机器扛日志量
类比：超大智能仓库，存所有快递，搜东西秒查
3. K 👉 Kibana（可视化页面）
看图、查日志、操作ES
- 网页界面，查询日志、筛选报错
- 日志图表、统计、大屏
- 管理 ES 索引、权限
类比：仓库前台查询系统，你在上面查快递、看数据
完整日志流转链路
应用/容器 → Filebeat（轻量采集） → Logstash（清洗） → Elasticsearch（存储检索） → Kibana（查看）
现在企业基本不用 Logstash 做采集，改用更轻的 Filebeat
所以新版常叫 EFK，更轻量。