企业官网建设流程全解析

如何用 Prometheus 搭建企业级监控系统：从指标接入到告警闭环的完整指南

【免费下载链接】prometheusThe Prometheus monitoring system and time series database.项目地址: https://gitcode.com/GitHub_Trending/pr/prometheus

凌晨三点被手机摇醒，告警群刷了两百条消息，真正的故障藏在第三十条里；或者线上已经出事，监控系统里却没有任何数据可查。这两种情况都指向同一件事：数据链路没管好。Prometheus 是目前用得最多的开源监控系统之一，围绕时序指标的采集、存储、查询与告警设计：服务暴露 /metrics 端点，它周期性拉取，按标签组织成时间序列，再用 PromQL（一套面向多维时序数据、按标签做聚合的查询语言）分析，异常时交给 Alertmanager 通知到人。这篇文章不罗列功能，而是沿一条指标的生命周期——怎么进、怎么存、怎么算、怎么报——讲每个环节企业落地时真正要做对的几件事。

指标怎么进得来：Prometheus 服务发现与采集配置

采集的第一个决策是"目标列表从哪来"。写死在 static_configs 里最简单，但目标一变就要改配置、重载实例；集群环境里 Pod 起起落落，静态列表根本追不上。常见做法是交给服务发现：Kubernetes 场景用 kubernetes_sd_configs，按 role 选择发现对象（endpoints、pod、node 等）；文件发现和 HTTP 发现则适合目标由其他系统产出的场合。

以电商平台为例：数百个微服务跑在 K8s 里，扩缩容是常态。服务发现让新 Pod 起来后自动成为抓取目标，关键是配合 relabel 把不需要的东西过滤掉——发现出来的原始目标往往比实际需要的多得多，不加 keep 过滤，序列数会先涨一截，查询也跟着变慢。下面这段保留了抓 API server 的最小形态：

scrape_configs: - job_name: "kubernetes-apiservers" kubernetes_sd_configs: - role: endpoints scheme: https authorization: credentials_file: /var/run/secrets/kubernetes.io/serviceaccount/token relabel_configs: - source_labels: [__meta_kubernetes_namespace, __meta_kubernetes_service_name, __meta_kubernetes_endpoint_port_name] action: keep regex: default;kubernetes;https

relabel_configs 里 action: keep 表示只有匹配 regex 的目标才保留；labelmap 则常用于把发现侧的元数据（比如节点标签）映射成正式指标标签。带完整注释的版本可以看仓库里的 Kubernetes 示例配置，所有采集字段都在配置文档里有说明。

数据如何不失不假：Prometheus 高可用部署与远程存储

本地 TSDB 是单机存储：新样本先写进内存中的 head，靠写前日志（WAL）保证重启后不丢最近的数据，但它没有集群复制，磁盘坏了数据就没了。对"监控自己不能先挂"的团队（金融、交易类系统尤其如此），通行做法是三件事：

1. 多个 Prometheus 实例抓同一批目标，每个实例挂不同的 external_labels 区分来源，数据天然冗余，任一实例故障不影响查询；
2. remote_write 把数据推到后端。Thanos、Cortex、Mimir 这类项目都提供接收端点，长期数据放对象存储，查询走统一入口。保留策略也随之改变：本地只留最近几天供快速查询，数月以上的历史交给远程存储，配合降采样（把密集数据点按固定窗口聚合成稀疏数据点）压成本；
3. 规模再往上走，考虑联邦（federation）或 agent 模式。联邦让上层 Prometheus 只拉取下层实例聚合后的指标，把"全局视图"和"细节数据"分层；agent 模式则本地只保留最近窗口、原始数据全部 remote write 出去，适合边缘机房这类"本地不需要完整查询"的采集端。

global: scrape_interval: 15s external_labels: monitor: "dc-primary" remote_write: - url: "http://storage-backend:19291/api/v1/receive"

下图是 agent 模式下的数据流：采集端负责发现与抓取，原始时序 remote write 到全局层，告警链路独立走 Alertmanager。

存储细节（block、WAL、保留参数）见存储文档，层级扩展见联邦文档，agent 的最小配置在示例文件里。

数据怎么变成决策：PromQL 规则预计算与告警降噪

数据进来了，但"能查"不等于"能决策"。两个常见手段：

规则预计算。高频看板里那些复杂聚合（比如 5 分钟平均延迟）如果每次打开面板都现算，查询延迟和负载都会上去。recording rules 的思路是把这类表达式按 evaluation_interval 周期算好，存成新序列，查询时直接引用，命名习惯上通常写成 job:metric:aggregation 的形式。

告警降噪。规则写得激进，告警就是噪音。降噪音不是靠"少写规则"，而是靠结构：用 for 子句要求条件持续一段时间才触发，滤掉瞬时抖动；用 severity 标签区分等级，让后续路由有据可依。游戏公司做实时对战时，玩家侧延迟的毛刺很常见，for 设短一点（一两分钟）保证响应快；而电商的订单成功率回落到阈值之下，往往值得多观察几分钟再叫人，避免误报消耗值班人的信任。

groups: - name: api-latency rules: - record: job:http_request_latency_seconds:avg5m expr: avg_over_time(http_request_latency_seconds[5m]) - alert: HighRequestLatency expr: job:http_request_latency_seconds:avg5m > 0.5 for: 10m labels: severity: page annotations: summary: "{{ $labels.job }} 延迟升高，当前 {{ $value }}s"

recording 与 alerting 规则的完整写法，包括 annotations 里的模板变量，参考告警规则文档和记录规则文档。

告警怎么送到对的人：Alertmanager 路由与值班流程

Prometheus 只负责判断"现在什么坏了"，把告警变成"谁该看、看哪个"是 Alertmanager 的事。它在两者之间加了几层处理：分组（同类告警合并成一条通知）、抑制（上游故障时压掉必然跟着来的下游告警，比如机器 down 时抑制这台机器上所有实例的告警）、静默（计划内发布期间临时屏蔽）、限速（repeat_interval 控制重复通知频率）。

路由的核心是 receiver 分级。比较稳的划分是两档：severity: page 的告警直接呼叫 on-call（电话或即时消息），代表"现在就要人处理"；severity: ticket 的进工单系统，工作时间处理。金融场景下核心交易链路的延迟、对账差异属于 page 类，而容量水位、证书临期这类进 ticket 更合理。分组键一般选 alertname 加来源集群，保证同一故障只产生一条通知。

route: group_by: ['alertname', 'cluster'] group_wait: 30s repeat_interval: 4h routes: - matchers: ['severity = page'] receiver: oncall - matchers: ['severity = ticket'] receiver: ticket-system receivers: - name: oncall - name: ticket-system

一个经验：告警规则上线前先问两个问题——"它响了，值班人第一步做什么？"和"它响过的每一次都是真问题吗？"答不上来的规则要么补 runbook，要么降级成 ticket，别让它在通知里占位置。

落地前先看一眼：Prometheus 常见配置坑

⚠️ 这些坑基本每个团队都踩过一遍，集中列在这里：

规模继续扩大时，下一站通常是 Thanos、Mimir 这类长期存储，以及 agent 模式做边缘轻量采集；查询侧还可以评估聚合层与降采样策略。一套监控系统是否成熟，最终不看功能多不多，而看数据进来之后，多快能变成一次正确的动作。

【免费下载链接】prometheusThe Prometheus monitoring system and time series database.项目地址: https://gitcode.com/GitHub_Trending/pr/prometheus