如何用 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;httpsrelabel_configs 里 action: keep 表示只有匹配 regex 的目标才保留labelmap 则常用于把发现侧的元数据比如节点标签映射成正式指标标签。带完整注释的版本可以看仓库里的 Kubernetes 示例配置所有采集字段都在配置文档里有说明。数据如何不失不假Prometheus 高可用部署与远程存储本地 TSDB 是单机存储新样本先写进内存中的 head靠写前日志WAL保证重启后不丢最近的数据但它没有集群复制磁盘坏了数据就没了。对监控自己不能先挂的团队金融、交易类系统尤其如此通行做法是三件事多个 Prometheus 实例抓同一批目标每个实例挂不同的 external_labels 区分来源数据天然冗余任一实例故障不影响查询remote_write 把数据推到后端。Thanos、Cortex、Mimir 这类项目都提供接收端点长期数据放对象存储查询走统一入口。保留策略也随之改变本地只留最近几天供快速查询数月以上的历史交给远程存储配合降采样把密集数据点按固定窗口聚合成稀疏数据点压成本规模再往上走考虑联邦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 }}srecording 与 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 常见配置坑⚠️ 这些坑基本每个团队都踩过一遍集中列在这里坑典型现象处理relabel 漏配 keep 过滤目标数远超预期抓取量和序列数膨胀服务发现后显式 keep/labelmap只留需要的对象告警规则不写 for指标抖一下就 firing恢复后又反复按业务容忍度加 for必要时配合 keep_firing_for 防抖动告警不分级所有告警挤同一条通知链路值班人麻木用 severity 标签分 page/ticket交给路由区分本地保留期设太长TSDB 磁盘被慢慢占满查询也变慢本地只留短窗口长数据走 remote_write只盯 up 指标进程活着但接口已经报错监控却全绿补业务指标告警和黑盒探测规模继续扩大时下一站通常是 Thanos、Mimir 这类长期存储以及 agent 模式做边缘轻量采集查询侧还可以评估聚合层与降采样策略。一套监控系统是否成熟最终不看功能多不多而看数据进来之后多快能变成一次正确的动作。【免费下载链接】prometheusThe Prometheus monitoring system and time series database.项目地址: https://gitcode.com/GitHub_Trending/pr/prometheus创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考