Prometheus
Prometheus 是 CNCF 毕业的指标（metrics）监控事实标准——它用拉取（Pull）模型主动从应用暴露的 /metrics 端点采集时序数据，存进内置时序数据库（TSDB），再用强大的PromQL做聚合/计算/告警/可视化。它的设计哲学是「简单、可靠、自我维护」：单机部署即可百万级样本/秒，没有外部依赖（不像 ELK 要先搭 ES），数据天然按时间对齐，适合白盒监控（埋点暴露内部指标）。在云原生/Kubernetes 生态里，Prometheus 几乎是默认的监控底座——K8s 控制平面、节点、Pod、Ingress、业务服务都暴露 Prometheus 格式指标，Alertmanager 把告警路由到邮件/钉钉/PagerDuty，Grafana 接 Prometheus 做大盘——三者构成「采集 → 存储 → 告警 → 可视化」的完整闭环。
Prometheus 的全部考点围绕指标体系与采集架构展开：①数据模型（metric name + labels 多维标签 + 数值 + 时间戳，counter/gauge/histogram/summary 四大类型）；②Pull 模型（主动拉取 vs Pushgateway 中转短任务、抓取间隔/超时/标签重标记）；③PromQL（即时查询、范围查询、聚合、rate/irate、向量匹配、子查询——监控面板与告警规则的核心语言）；④告警（Recording/Alerting Rule + Alertmanager 路由/分组/抑制/静默）；⑤Service Discovery（静态配置、Kubernetes/Consul/DNS 动态发现、relabel 重写）；⑥架构与存储（TSDB 分块存储、远程读写、联邦集群、与 Grafana 集成）。本叶是可观测性监控层的总览与地基，讲清它的设计取舍、Pull/Push 之争、PromQL 核心用法、告警流水线——后续 4 叶（Grafana/ELK/Sentry/Jaeger）从可视化、日志、错误、追踪维度补齐可观测性拼图。
评价
优点
- Pull 模型透明可控：Prometheus 主动拉取，应用只需暴露
/metrics，监控端知「谁在被监控、抓取是否成功」，比 Push 模型易诊断 - 多维标签：每个指标带任意
label=value，可任意切片聚合（按 pod、env、status_code 维度切），远比维度单一的 statsd 灵活 - PromQL 表达力强：原生支持
rate/histogram_quantile/向量运算/子查询，一条 query 能算「过去 5 分钟 P99 延迟按接口分组」 - 自包含、易部署：单二进制 + 内置 TSDB，无外部依赖（无需先搭 ES/Kafka），本地与 K8s 部署门槛极低
- 云原生生态一等公民：K8s、Istio、etcd、Node Exporter 都原生暴露 Prometheus 指标，开箱即用
缺点
- 只做指标（metrics），不做日志/追踪：日志归 ELK/Loki，追踪归 Jaeger/Tempo，Prometheus 不包打天下
- Pull 不适合短任务：批处理/Cron 等短生命周期进程来不及被抓就退出，要用 Pushgateway 中转（增加复杂度）
- 本地存储扩展性有限：单机 TSDB 默认 15 天保留、单节点无水平扩展，长期存储/高基数需远程存储（Thanos/Mimir/Cortex）
- 无聚类去重（原版）：原版 Prometheus 不做副本去重，高可用要靠外部 Thanos/Mimir 做；告警有重复风险
- 学习曲线：PromQL、relabel、Recording Rule 的语法和心智模型对新人有门槛
本叶地图
- 入门 —— Prometheus 是什么、Pull vs Push、指标四大类型、PromQL 入门、告警流水线、Service Discovery
- 指标与 PromQL —— counter/gauge/histogram/summary 详解、PromQL 即时/范围查询、rate vs irate、聚合与向量匹配、Alertmanager 告警路由
- 架构与服务发现 —— TSDB 分块存储、Pull 采集、Service Discovery（K8s/Consul/DNS）、relabel、远程读写、与 Grafana 集成、联邦集群
- 参考 —— 指标类型速查、PromQL 函数清单、告警规则模板、易错点