本文定位：面向正在建设微服务监控告警体系的平台、SRE 和应用团队，重点解释 Prometheus 各组件如何协同，而不是逐项罗列配置参数。
Prometheus架构的核心不是“一个监控数据库”，而是一条从应用指标暴露、目标发现、周期采集、时序写入、规则计算到告警通知的数据流。理解这条链路后，团队才能判断为什么某个服务没有指标、为什么告警延迟、为什么标签基数过高，以及为什么同一条告警在不同渠道里重复出现。
一、Prometheus架构先看数据如何流动
Prometheus 采用拉取模型。应用、Exporter 或中间件暴露 `/metrics` 端点，Prometheus Server 根据静态配置或服务发现得到目标列表，然后按 scrape interval 周期性抓取指标。抓取结果会写入本地 TSDB，并提供给 PromQL 查询、仪表盘和告警规则使用。
图1：Prometheus 从目标发现、指标采集到告警通知的主
这条主链路可以拆成四个阶段：
- 暴露指标：应用埋点、Node Exporter、数据库 Exporter、服务网格代理等提供可抓取指标。
- 发现目标：Prometheus 通过静态配置、Kubernetes 服务发现或其他发现机制得到抓取对象。
- 采集与存储：Server 周期拉取样本，按 metric name、label 和 timestamp 写入时序数据库。
- 查询与告警：PromQL 支撑仪表盘、临时排查和规则计算，告警结果再发送给 Alertmanager。
如果团队正在做微服务整体可观测性规划，可以把本文与站内的 微服务可观测性怎么规划 结合起来看：Prometheus 负责指标主链路，日志、链路追踪和 SLO 需要在它之外继续补齐。
二、指标暴露层决定后续能看到什么
Prometheus 能采集什么，首先取决于目标是否正确暴露指标。微服务场景里常见指标来源包括：
- 应用指标：请求量、错误率、延迟分布、队列长度、业务状态等。
- 基础设施指标：节点 CPU、内存、磁盘、网络、容器资源使用情况。
- 中间件指标：数据库连接池、消息堆积、缓存命中率、网关流量。
- 平台组件指标：Kubernetes API Server、Scheduler、Controller、Ingress Controller、服务网格控制面等。
这里最容易出现的误区，是只把指标理解成“越多越好”。生产环境更应关注指标是否可解释、标签是否可控、单位是否稳定、语义是否一致。比如 `http_requests_total` 适合做请求量和错误率，延迟则更适合 histogram 或 summary；如果把用户 ID、订单号、请求路径原始参数放进 label，TSDB 很快会被高基数拖慢。
指标设计至少检查：
- 命名是否稳定：同一类指标不要在不同服务里混用不同命名。
- 标签是否可聚合：保留 service、namespace、status、method 等治理维度，避免无限增长标签。
- 单位是否清楚：秒、字节、计数器和比例不要混淆。
- 采集成本是否可控：高频变化且价值低的指标不应进入核心链路。
三、服务发现让动态目标进入采集列表
在微服务和 Kubernetes 环境中，实例会扩缩容、重启、迁移，Prometheus 不适合靠人工维护 IP 列表。服务发现的作用，是把“当前有哪些目标可以抓取”自动转换成 target 列表，再交给 scrape 任务处理。
图2：服务发现、relabel 和 scrape 任务如何生成
以 Kubernetes 为例，Prometheus 可以从 Pod、Service、Endpoints、Node 等对象中发现目标。发现后的原始元数据通常还需要通过 relabel 处理：保留需要抓取的对象、丢弃无关端口、重写 instance 标签、补充 namespace 或 workload 标签。这样做的价值不是让配置更复杂，而是让采集范围和查询维度更符合平台治理口径。
服务发现阶段常见问题包括：
- 目标没有进入列表：注解、ServiceMonitor、PodMonitor 或选择器不匹配。
- 目标进入但抓取失败：端口、路径、TLS、鉴权或网络策略阻断。
- 标签混乱：同一服务在不同环境里 label 不一致，导致聚合查询不准确。
- 抓取过宽：把无关端点全部纳入采集，造成样本量膨胀。
对服务数量多、治理规则复杂的团队，Prometheus 的目标发现最好和服务目录、命名规范、命名空间边界一起设计，而不是每个业务团队各写一套注解。服务注册、发现和治理的基础思路，也可以参考站内 服务治理怎么做 中的注册发现与流量治理部分。
四、采集与时序存储是 Prometheus 的核心边界
Prometheus Server 按配置周期拉取指标，抓取成功后把样本写入本地 TSDB。每条样本由指标名、标签集合、时间戳和值组成。查询时，Prometheus 会根据 label matcher 找到对应时间序列，再进行 rate、sum、histogram_quantile 等计算。
从架构角度看，本地 TSDB 的优势是部署简单、查询直接、适合单集群或单区域快速落地；边界是长期存储、跨集群聚合和大规模高可用需要额外设计。很多团队在早期只部署单个 Prometheus Server，后续才引入分片、联邦、remote write 或兼容 Prometheus 的长期存储系统。
| 关注点 | 架构含义 | 常见处理方式 |
|---|---|---|
| 抓取周期 | 决定指标新鲜度和样本量 | 核心服务短周期，低价值指标长周期 |
| retention | 决定本地保留时间 | 本地保留近期数据，长期数据 remote write |
| label cardinality | 决定 TSDB 压力 | 控制动态标签，统一 relabel 策略 |
| 高可用 | 决定故障时是否丢监控 | 双副本抓取，查询层或存储层去重 |
存储设计不能只看磁盘容量
Prometheus 的容量压力往往来自序列数量和写入速率，而不只是磁盘空间。一个指标如果带有过多动态标签，可能产生大量时间序列；即使每条样本很小，也会增加内存索引、查询扫描和压缩成本。生产环境应定期查看活跃序列数量、最高基数 label、scrape duration 和 dropped samples，而不是等磁盘告警后再处理。
五、PromQL 把原始样本变成可观察信号
Prometheus 采集到的是原始时间序列，真正用于排障和告警的通常是 PromQL 表达式。例如：
sum(rate(http_requests_total{status=~"5.."}[5m])) by (service)
/
sum(rate(http_requests_total[5m])) by (service)这类表达式把计数器转换成错误率，再按服务聚合。仪表盘、临时查询和告警规则都依赖 PromQL，因此查询语义会直接影响团队对系统状态的判断。
PromQL 设计建议从三个层次入手：
- 原始指标层：保证指标含义准确，counter、gauge、histogram 使用正确。
- 录制规则层：把高频复杂查询预计算，降低仪表盘和告警计算成本。
- 业务视图层：把服务、环境、版本、错误类型等维度组合成可读面板。
对微服务而言，指标不应只停留在 CPU 和内存。更有价值的是 RED 或 USE 视角：请求速率、错误率、耗时分布，资源利用率、饱和度和错误。这些指标可以和日志、追踪共同解释故障，而不是相互割裂。
六、告警规则和 Alertmanager 分工不同
Prometheus 负责计算告警规则，Alertmanager 负责处理告警通知。两者分工清楚，排障时也应分开看：如果表达式没有触发，问题在规则或数据；如果规则已触发但没有通知，问题多半在 Alertmanager 的路由、抑制、分组或接收器配置。
图3：告警从规则计算、分组抑制到通知渠道的处理路径
一个生产可用的告警链路通常包含：
- 规则表达式：定义什么状态算异常。
- for 持续时间：避免短暂抖动直接通知。
- labels：携带 severity、team、service、environment 等路由信息。
- annotations：提供摘要、影响范围、排查入口和仪表盘链接。
- route：按团队、严重级别、环境或服务发送到不同渠道。
- inhibit：上游故障触发时，抑制下游重复告警。
告警治理的重点不是让所有异常都响，而是让真正需要行动的异常及时到达正确的人。否则，Prometheus架构即使采集完整，也会因为告警噪声过高而失去可信度。
七、微服务场景下的落地建议
微服务系统组件多、调用链长、发布频繁，Prometheus 落地时应避免一次性追求“大而全”。更稳妥的顺序是：
- 先统一基础指标：节点、容器、Kubernetes 控制面、Ingress、网关和核心中间件。
- 再补应用指标：每个服务至少覆盖请求量、错误率、延迟、依赖调用和关键业务状态。
- 建立命名和标签规范：service、namespace、environment、team、version 等标签要稳定。
- 沉淀录制规则和面板：让常见查询变成团队共享口径。
- 逐步治理告警：先做少量高价值告警，再做分级、抑制和负责人路由。
如果团队已经在使用服务网格，可以把代理层指标与应用指标一起看，但不要把服务网格当成全部答案。服务网格能补充流量、延迟和错误指标，应用自身仍要暴露业务状态和依赖状态。相关边界可继续参考站内服务网格是什么。
八、常见架构风险与检查清单
上线前至少检查：
- 采集目标：核心服务是否都能在 targets 页面看到，状态是否为 up。
- 指标质量：是否存在明显高基数 label，是否有无意义指标大量增长。
- 查询性能：常用面板是否出现慢查询，录制规则是否必要。
- 告警有效性：每条 P1/P2 告警是否有 owner、影响说明和处理入口。
- 通知路由：团队、环境和严重级别是否能路由到正确渠道。
- 高可用：Prometheus 和 Alertmanager 故障时是否影响核心告警。
这些检查不需要一次性做到完美，但要形成持续治理机制。Prometheus 的价值来自“指标、查询、告警、责任人”四者闭环，而不是部署完成后无人维护的一组监控面板。
小结
Prometheus架构可以理解为一条清晰的数据流水线：目标暴露指标，服务发现生成抓取对象，Prometheus Server 周期采集并写入时序数据库，PromQL 将原始样本转化为可观察信号，告警规则计算异常状态，Alertmanager 再完成分组、抑制和通知路由。真正影响生产效果的，不只是组件是否安装成功，而是指标设计、标签治理、查询口径和告警责任是否一致。
常见问题
1. Prometheus架构适合所有监控场景吗？
不一定。Prometheus 很适合指标采集、短周期查询和告警规则计算，但它不是日志系统，也不是完整的链路追踪系统。长期大规模存储、跨区域统一查询和审计报表通常需要 remote write、长期存储或其他可观测平台能力配合。
2. Prometheus 为什么默认采用拉取模式？
拉取模式让 Prometheus 能主动控制采集周期、目标状态和失败可见性，也方便在 targets 页面直接看到哪些对象抓取失败。对于临时任务、批处理或受网络限制的场景，可以通过 Pushgateway 或网关方式补充，但不建议把 Pushgateway 当成所有服务的通用采集方式。
3. 告警已经触发但没有通知，应该先查哪里？
先确认 Prometheus 里的 alert 状态是否为 firing。如果没有 firing，检查 PromQL、for 持续时间和数据是否存在；如果已经 firing，再检查 Alertmanager 的 route、receiver、silence、inhibit 和分组配置。两段分开查，效率会高很多。
4. 如何判断 Prometheus 是否需要分片或长期存储？
可以从活跃序列数量、写入速率、查询延迟、本地保留时间和跨集群查询需求判断。如果单实例内存压力明显、查询变慢，或业务要求保留数月数据，就应评估分片、联邦、remote write 或长期存储方案，而不是只扩大磁盘。
