1. 这不是“教程合集”而是一份 Prometheus 实战生存手册你点开这个标题大概率正被三件事困扰刚接手公司监控系统发现一堆指标看不懂写告警规则时反复触发又误报半夜被电话叫醒或者——更常见的情况——在 Grafana 里看到满屏曲线却不知道哪条该盯、哪条该删。Prometheus 不是“装完就能用”的玩具它是一套精密运转的观测引擎而市面上绝大多数所谓“从入门到精通”的内容要么卡在curl http://localhost:9090/metrics就戛然而止要么直接跳进alert_rules.yml的语法迷宫中间那层“人怎么思考、系统怎么响应、故障怎么定位”的真实逻辑被彻底抹掉了。我过去三年带过七支不同规模的技术团队落地 Prometheus从 5 人初创公司的单节点监控到 200 微服务、跨 4 个可用区的金融级生产环境。踩过的坑比写过的配置还多凌晨三点因scrape_timeout设置不当导致全量指标丢失告警风暴把 Slack 频道刷成瀑布流Grafana 面板加载超时被业务方质疑“监控拖慢系统”。这些都不是配置错误而是对 Prometheus 底层设计哲学的误读。它不只是一套工具链更是一种观测范式——指标必须可聚合、标签必须有语义、采集必须可追溯、告警必须可闭环。本文不讲“怎么装”只讲“为什么这么装”不列命令只拆解每个参数背后的权衡不堆代码只还原真实故障现场中你是如何从一条rate(http_requests_total[5m])曲线一步步定位到某台 Kubernetes Node 上的 kube-proxy 内存泄漏的。如果你需要的是能立刻复制粘贴的 YAML这里没有但如果你需要的是下次故障发生时能独立判断是采集问题、存储问题还是业务逻辑问题的能力——这正是我们接下来要重建的底层认知。2. 核心设计哲学为什么 Prometheus 不是另一个 Zabbix2.1 拉取模型Pull vs 推送模型Push不只是通信方式的选择Zabbix、Nagios 这类传统监控工具采用“推送模型”Agent 主动把数据发给 Server。这看似简单但埋下了三个致命隐患第一Agent 崩溃或网络中断时Server 完全失联你甚至不知道自己已经“失明”第二当业务流量突增Agent 疯狂上报Server 端可能瞬间被压垮形成雪崩第三指标格式五花八门Server 端要做大量解析和归一化性能损耗大。Prometheus 反其道而行之强制采用“拉取模型”Server 主动、周期性地向目标Target发起 HTTP GET 请求获取/metrics端点的文本数据。这带来三个反直觉但关键的优势可观测性自证Server 每次拉取都记录up{jobapi, instance10.1.2.3:8080}指标。值为 1 表示拉取成功0 表示失败。你不需要额外探针up指标本身就在告诉你“我是否还能看到它”。这是监控系统的元监控是信任的起点。天然的背压机制Server 控制拉取频率scrape_interval和超时scrape_timeout。当 Target 负载高、响应慢时Server 会自动跳过本次拉取不会堆积请求。而 Agent 推送则可能因队列积压导致内存溢出。协议极简解析零成本Prometheus 要求/metrics返回纯文本格式严格定义如http_requests_total{methodPOST,code200} 12345。Server 端用状态机即可高效解析无 JSON/XML 解析开销。实测对比同等指标量下Prometheus 解析耗时比 Zabbix Agent 解析 JSON 低 60% 以上。提示拉取模型并非万能。对于短生命周期任务如批处理 Job它无法捕获执行过程中的指标。此时必须用 Pushgateway 作为中转——但这不是“推模式”而是将瞬时指标“暂存”后再由 Prometheus 拉取。滥用 Pushgateway 是新手最大误区它会破坏指标的时间序列连续性导致rate()计算失真。2.2 多维数据模型标签Labels才是灵魂不是装饰Zabbix 的指标是扁平的system.cpu.utilization。你要区分不同主机靠 Hostname 字段。要区分 CPU 核心得靠 Item Key 里的cpu0、cpu1。这种设计让聚合分析变得笨重查“所有 Web 服务器的平均 CPU 使用率”得先筛选 Hostgroup再遍历所有 Item。Prometheus 的指标是多维的cpu_usage_seconds_total{instanceweb-01:9100, jobnode-exporter, modeuser, clusterprod-us-east}。这里的{...}就是标签Labels它们不是附加属性而是指标身份的一部分。一个指标名 一组标签唯一确定一个时间序列Time Series。这意味着聚合即切片sum by (job) (rate(cpu_usage_seconds_total[5m]))—— 按job标签分组对每个分组内的所有时间序列计算每秒增长率再求和。一行表达式替代了 Zabbix 里需要创建多个 Trigger 和 Graph 的复杂操作。下钻无损当你发现jobapi的错误率飙升可以立刻加一层过滤rate(http_requests_total{jobapi, code~5..}[5m]) / rate(http_requests_total{jobapi}[5m])精准定位是哪个code导致。这个过程不损失任何原始数据粒度。语义即索引标签名必须有意义。instance存 IP端口job存采集任务名cluster存环境标识。禁止使用envprod这种模糊标签而应是environmentproduction。因为标签会成为查询的索引键模糊命名会导致索引失效查询变慢。注意标签 cardinality基数是性能杀手。user_id12345这种标签会让时间序列数爆炸式增长。正确做法是用户维度指标聚合到user_typepremium或regionus-west这种低基数标签上。我们曾因一个request_id标签让单个 Prometheus 实例内存暴涨 300%最终通过metric_relabel_configs在采集时丢弃了它。2.3 本地存储与 TSDB为什么不用 MySQL 或 Elasticsearch很多人第一反应是“把指标存到 ES 里不就能用 Kibana 查了” 这是个危险的误解。Prometheus 自研的 TSDBTime Series Database不是为了“替代数据库”而是为时序数据的特殊访问模式而生写入模式高频、小批量、追加写。TSDB 将数据按 2 小时一个 block 存储新数据写入内存中的 Head Block定期 flush 到磁盘。这比关系型数据库的随机写入快一个数量级。查询模式绝大部分查询是“按时间范围 标签过滤 聚合函数”。TSDB 的索引结构倒排索引 时间索引专为此优化。查rate(http_requests_total{jobfrontend}[1h])TSDB 先用倒排索引快速定位所有jobfrontend的时间序列 ID再用时间索引定位 1 小时内的数据块最后在内存中计算rate。整个过程毫秒级。压缩率TSDB 对浮点数采用 Gorilla 压缩算法实测压缩比达 10:1 以上。一个 100GB 的原始指标数据在 TSDB 中仅占 10GB 左右。而 ES 存储同样数据即使开启 best_compression也需 40GB且查询延迟高 3-5 倍。实操心得TSDB 的 retention保留时间不是越大越好。我们线上环境设为15d而非默认的15d。原因超过 15 天的数据99% 的场景下只用于“历史对比”而非实时诊断。将其归档到长期存储如 Thanos Object Storage更经济。强行延长本地 retention会导致 compaction数据合并压力剧增CPU 使用率飙升反而影响实时查询。3. 从零搭建一次真实的生产级部署复盘3.1 环境准备别在笔记本上“学”直接建最小可行集群很多教程教你用docker run -p 9090:9090 prom/prometheus启动单节点。这就像用玩具枪练射击——姿势再标准也打不中实战靶。生产环境必须是集群哪怕只有 2 个节点。我们以最简架构为例组件数量角色关键配置Prometheus Server2主备HA--web.external-urlhttp://prometheus-prod.internal--storage.tsdb.retention.time15dAlertmanager2告警去重、分组、路由--cluster.peerprom-alert-01:9094--config.file/etc/alertmanager/config.ymlGrafana1可视化--env GF_SERVER_ROOT_URLhttp://grafana-prod.internal/启用 LDAP 认证node-exporterN主机指标采集--collector.systemd启用 systemd 指标--no-collector.wifi禁用 WiFi 指标避免干扰注意Prometheus Server 本身不提供真正的 HA高可用。两个实例配置完全相同各自独立拉取、存储、告警。Alertmanager 才是 HA 的核心——它接收来自所有 Prometheus 的告警去重后统一发送。如果一个 Prometheus 挂了另一个继续工作Alertmanager 仍能收到告警。这才是符合云原生理念的“松耦合高可用”。3.2 配置文件详解prometheus.yml不是清单是策略声明一个典型的prometheus.yml文件核心是global、rule_files、scrape_configs三大部分。但新手常犯的错是把它当成“填空题”而不是“策略说明书”。global: scrape_interval: 15s # 全局拉取间隔非越小越好 evaluation_interval: 15s # 全局规则评估间隔必须与 scrape_interval 一致 scrape_timeout: 10s # 拉取超时必须 scrape_interval rule_files: - rules/*.yml # 告警规则文件路径支持通配符 scrape_configs: - job_name: prometheus # 任务名也是 job 标签的值 static_configs: - targets: [localhost:9090] # 目标地址格式host:port # 关键relabel_configs 是数据清洗流水线 relabel_configs: - source_labels: [__address__] # 从原始 target 地址提取 target_label: instance # 写入 instance 标签 replacement: $1 # 保持原值 - action: labelmap # 将 __meta_* 标签映射为普通标签 regex: __meta_kubernetes_node_label_(.) # 仅适用于 Kubernetes - job_name: node-exporter static_configs: - targets: [10.1.1.10:9100, 10.1.1.11:9100] metric_relabel_configs: # 在存储前对指标进行重标记 - source_labels: [__name__] regex: node_network_(.*) # 匹配 node_network_ 开头的指标 action: keep # 只保留匹配的指标丢弃其他scrape_interval: 15s这是心跳频率不是“采样精度”。业务指标变化远慢于此如订单量每分钟才变一次设成1s不仅浪费资源还会让 TSDB 的 Head Block 频繁 flush增加 I/O 压力。我们线上 API 服务设为30s基础设施node-exporter设为15s批处理 Job 设为5m。relabel_configsvsmetric_relabel_configs前者在拉取前修改 target 的标签如把__address__转成instance后者在拉取后、存储前修改指标本身的标签如丢弃无用指标。混淆二者会导致数据丢失。action: keep这是最易被忽视的性能优化点。node-exporter默认暴露 600 指标但你真正关心的可能不到 50 个。在metric_relabel_configs中keep你需要的比在 Grafana 里hide不需要的效率高出一个数量级。3.3 告警规则配置从“触发就报警”到“精准狙击”告警不是越多越好而是越少越准。一个健康的 Prometheus 告警体系应该满足100% 的告警都对应一个明确的、可执行的 SOP标准操作流程。否则就是噪音。我们以最常见的“API 错误率过高”为例展示如何写出一条“可行动”的告警groups: - name: api_alerts rules: - alert: HighHTTPErrorRate expr: | 100 * sum by (job, instance) ( rate(http_requests_total{code~5..}[5m]) ) / sum by (job, instance) ( rate(http_requests_total[5m]) ) 5 for: 10m labels: severity: critical team: backend annotations: summary: High error rate on {{ $labels.job }} ({{ $labels.instance }}) description: Error rate is {{ $value | printf \%.2f\ }}% for the last 5 minutes. runbook: https://runbook.internal/api-error-rateexpr解析rate(...[5m])计算每秒请求数sum by (...)按job和instance分组聚合再算百分比。为什么用5m因为rate()需要至少 2 个样本点5m窗口能覆盖scrape_interval15s下的多个周期避免偶发抖动误报。for: 10m这是告警的“冷静期”。指标超过阈值后必须持续 10 分钟才真正触发。这过滤了网络抖动、GC 暂停等瞬时异常。我们线上所有critical告警for时间不低于5mwarning告警不低于15m。annotations.runbook这是灵魂。点击告警必须直达一份文档里面明确写着现象确认检查http_requests_total{code500}是否持续上升。根因定位查看process_cpu_seconds_total和process_resident_memory_bytes判断是 CPU 过载还是 OOM。应急措施如果是 OOM立即扩容 Pod如果是慢 SQL执行kubectl exec -it pod -- psql -c SELECT * FROM pg_stat_activity WHERE state active;。验证方法观察rate(http_requests_total{code500}[1m])是否回落至 0。实操心得永远不要在expr中写 0这种绝对阈值。业务流量有峰谷白天 5% 错误率是灾难深夜 5% 可能是正常。我们采用动态基线avg_over_time(rate(http_requests_total{code~5..}[1h])[7d:1h]) * 3即过去 7 天每小时错误率的平均值的 3 倍。这需要 Recording Rules 预计算但换来的是告警准确率从 60% 提升到 92%。4. Grafana 深度整合让数据开口说话4.1 数据源配置不止是填 URL更是建立信任链在 Grafana 中添加 Prometheus 数据源表面看只需填URL和AccessBrowser/Server。但生产环境必须配置HTTP Auth启用 Basic Auth用户名密码由运维统一管理而非用admin/admin。TLS CA Cert如果 Prometheus 启用了 HTTPS必须上传 CA 证书否则 Grafana 无法验证服务端身份存在中间人攻击风险。Custom HTTP Headers添加X-Scope-OrgID: prod如果对接 Cortex/Thanos或Authorization: Bearer token如果 Prometheus 启用了 JWT 认证。最关键的是Query Timeout默认 60 秒。但在复杂 Dashboard如包含 20 个 Panel中一个 Panel 查询慢会拖垮整个页面。我们设为30s并配合Max Data Points最大数据点数限制为1000。这样即使某个 Panel 查询超时其他 Panel 仍能正常加载。提示Grafana 的Explore功能是调试利器。输入rate(http_requests_total[5m])点击Graph再点击View JSON你能看到 Grafana 发送给 Prometheus 的完整 HTTP 请求含start、end、step参数。这比翻文档更快理解查询行为。4.2 面板构建从“好看”到“好用”的四步法一个优秀的 Grafana 面板不是炫技的图表集合而是故障排查的导航仪。我们遵循四步法Step 1黄金信号Golden Signals先行每个服务 Dashboard 顶部必须有四个核心指标Latency延迟histogram_quantile(0.95, sum by (le) (rate(http_request_duration_seconds_bucket[5m])))—— 95 分位 P95 延迟。Traffic流量sum by (code) (rate(http_requests_total[5m]))—— 按状态码分组的 QPS。Errors错误sum by (code) (rate(http_requests_total{code~5..}[5m]))—— 5xx 错误 QPS。Saturation饱和度sum by (mode) (rate(node_cpu_seconds_total{mode!idle}[5m])) / count by (mode) (node_cpu_seconds_total)—— CPU 使用率。Step 2下钻路径Drill-down Path清晰点击Errors图表上的某个code500柱状图应自动跳转到一个新的 Dashboard其中第一行sum by (instance) (rate(http_requests_total{code500}[5m]))—— 定位到具体机器。第二行topk(3, sum by (path) (rate(http_requests_total{code500, instanceweb-01}[5m])))—— 定位到具体接口。第三行rate(process_cpu_seconds_total{instanceweb-01}[5m])—— 检查该机器 CPU。Step 3阈值可视化Threshold Visualization不要只画曲线。在 Latency 图表中添加ThresholdsCritical: 1000ms红色区域Warning: 500ms黄色区域OK: 500ms绿色区域这样一眼就能看出延迟是否进入危险区。Step 4状态卡片Status Card收尾面板底部放一个Stat类型 Panel显示up{jobapi} 1的布尔值。绿色表示一切正常红色表示采集中断。这是整个 Dashboard 的“健康指示灯”。实操心得避免使用Legend显示过多信息。{{instance}} - {{code}}在 20 个 Series 时图例会挤成一团。改用Tooltip鼠标悬停显示完整标签图例只显示{{code}}。同时开启Reduce options-Calculate-Last让 Stat Panel 显示最新值而非平均值。5. 告警治理从“告警疲劳”到“精准响应”5.1 Alertmanager 路由配置让告警找到对的人Alertmanager 的alertmanager.yml是告警的“交通指挥中心”。一个典型配置route: receiver: default-receiver group_by: [alertname, job, severity] # 相同告警名、job、严重级别的告警合并为一条 group_wait: 30s # 新告警等待 30s看是否有同类告警进来 group_interval: 5m # 同组告警每 5 分钟发送一次 repeat_interval: 4h # 同一告警4 小时后重复通知避免刷屏 receivers: - name: default-receiver email_configs: - to: oncallcompany.com send_resolved: true # 告警恢复时发送“已解决”邮件 slack_configs: - channel: #alerts-prod send_resolved: true text: {{ template slack.default . }} templates: - /etc/alertmanager/template/*.tmplgroup_by这是减少告警风暴的关键。HighHTTPErrorRate告警如果 10 台 API 实例同时触发group_by: [alertname]会合并成一条内容列出所有instance。但如果group_by: [alertname, job]则jobapi和jobauth的告警会分开避免混淆。send_resolved: true必须开启。否则你永远不知道告警是否已恢复只能手动去 Prometheus 查。这增加了 50% 的人工确认成本。repeat_interval: 4h对critical告警4 小时足够处理对warning告警可设为24h避免夜间打扰。5.2 告警抑制Inhibition防止“连环告警”引发恐慌当一个核心服务宕机下游所有依赖它的服务都会报错。如果不抑制你会收到上百条告警却找不到根因。抑制规则如下inhibit_rules: - source_match: alertname: InstanceDown # 源告警某台机器宕机 severity: critical target_match: alertname: HighHTTPErrorRate # 目标告警HTTP 错误率高 equal: [instance, job] # 当源和目标的 instance、job 相同时抑制目标告警意思是如果InstanceDown告警触发了且instancedb-01那么所有HighHTTPErrorRate告警中instancedb-01的那些全部被抑制。你只收到InstanceDown然后去修 DB修好后所有下游告警自然消失。注意抑制规则是单向的。InstanceDown抑制HighHTTPErrorRate但HighHTTPErrorRate不会抑制InstanceDown。确保source_match的条件比target_match更严格否则可能误抑制。5.3 告警分级与 SLO 对齐让技术指标驱动业务决策最高级的告警治理是与业务 SLOService Level Objective对齐。例如我们的支付服务 SLO 是99.9% 的请求在 2 秒内完成。我们定义SLO_Budget_Burn_RateSLO 预算消耗速率。1 - (success_rate / target_rate)当 1表示预算耗尽速度超过允许值。SLO_Budget_Remaining剩余预算百分比。告警规则- alert: SLOBudgetBurnRateCritical expr: 1 - (sum(rate(http_requests_total{code~2..}[5m])) / sum(rate(http_requests_total[5m]))) / 0.999 1.5 for: 15m labels: severity: critical slo: payment_api_latency annotations: summary: Payment API SLO budget burning at 150% rate! description: We are consuming SLO budget 1.5x faster than allowed. Immediate action required.当这条告警触发意味着业务已实质性受损必须启动 P1 级别事件响应。这比HighHTTPErrorRate更具业务意义也让技术团队和产品、运营团队有了共同语言。6. 故障排查实战一次完整的“从告警到修复”复盘6.1 场景还原凌晨 2:17Slack 弹出HighHTTPErrorRate告警告警内容High error rate on api-gateway (10.1.2.3:8080) - Error rate is 12.34% for the last 5 minutes.Step 1确认现象1 分钟打开 Grafana加载api-gatewayDashboard。确认Errors图表确实在 2:15 开始飙升code503占比 98%。Traffic图表显示 QPS 未明显下降说明不是流量突降导致。Latency图表 P95 延迟从 200ms 暴涨至 2000ms。结论不是业务异常是网关自身问题。Step 2定位组件3 分钟api-gateway是 Kubernetes Deployment副本数 3。检查up{jobapi-gateway}instance10.1.2.3:8080up0宕机instance10.1.2.4:8080up1instance10.1.2.5:8080up1问题聚焦到10.1.2.3这台 Node。Step 3检查 Node 状态2 分钟切换到node-exporterDashboard筛选instance10.1.2.3:9100node_load112.5远超 CPU 核数 4node_memory_MemAvailable_bytes仅剩 200MB总内存 16GBnode_filesystem_usage/var/lib/docker分区使用率 98%结论Node 内存和磁盘耗尽导致api-gatewayPod 被 OOMKilled。Step 4根因分析5 分钟登录10.1.2.3执行# 查看内存占用 top 进程 sudo docker stats --no-stream | sort -k3 -hr | head -10 # 发现一个名为 log-archiver 的容器内存使用 12GB # 查看磁盘 inode 使用 df -i /var/lib/docker # Inodes 100% 使用说明有海量小文件 # 进入 log-archiver 容器 sudo docker exec -it log-archiver sh ls -la /data/logs/ | wc -l # 输出 2,345,678根因log-archiver服务的一个 Bug导致它不断创建空日志文件未做清理占满磁盘和 inode。Step 5临时修复1 分钟# 清理旧日志保留最近 7 天 sudo find /var/lib/docker/volumes/log-archiver/_data/logs/ -name *.log -mtime 7 -delete # 重启 log-archiver 容器 sudo docker restart log-archiver5 分钟后10.1.2.3的up指标恢复为 1api-gateway错误率回落。Step 6长期修复后续修复log-archiver代码加入日志轮转和清理逻辑。在 Prometheus 中添加新告警node_filesystem_files_free{mountpoint/var/lib/docker, fstypexfs} 100000提前预警 inode 耗尽。为log-archiver添加 Resource Limitmemory: 2Gi,ephemeral-storage: 10Gi防止失控。实操心得整个过程耗时 12 分钟其中 8 分钟用于“看图说话”只有 4 分钟是命令行操作。这证明一个设计良好的监控体系80% 的故障定位靠的是 Dashboard 的直观性和下钻路径的合理性而不是 SSH 登录后的盲猜。这也是我们坚持“黄金信号前置”、“状态卡片收尾”的根本原因。7. 进阶能力超越基础监控的三大战场7.1 服务发现Service Discovery让监控随业务自动伸缩静态配置targets只适用于固定 IP 的环境。在 Kubernetes、Consul、EC2 等动态环境中必须用服务发现。以 Kubernetes 为例scrape_configs中- job_name: kubernetes-pods kubernetes_sd_configs: - role: pod namespaces: names: [default, backend] relabel_configs: - source_labels: [__meta_kubernetes_pod_annotation_prometheus_io_scrape] action: keep regex: true - source_labels: [__meta_kubernetes_pod_annotation_prometheus_io_path] action: replace target_label: __metrics_path__ regex: (.) - source_labels: [__address__, __meta_kubernetes_pod_annotation_prometheus_io_port] action: replace regex: ([^:])(?::\d)?;(\d) replacement: $1:$2 target_label: __address__role: pod监听所有 Pod 的变化。relabel_configs第一条只保留带有prometheus.io/scrape: true注解的 Pod。这是业务方自主控制监控开关的机制无需运维介入。最后一条将__address__Pod IP和注解中的端口如9090拼成10.1.2.3:9090供 Prometheus 拉取。注意Kubernetes 服务发现会产生海量 target每个 Pod 一个。必须配合relabel_configs过滤否则 Prometheus 会因 target 数过多而 OOM。我们线上通过__meta_kubernetes_pod_phase ! Pending过滤掉未就绪 Pod减少 30% 的无效 target。7.2 Recording Rules预计算把昂贵查询变成廉价读取rate(http_requests_total[5m])每次查询都要扫描 5 分钟内的所有样本计算斜率。如果 100 个 Dashboard 都用它Prometheus CPU 会飙升。Recording Rules 将其预计算为新指标groups: - name: recording-rules rules: - record: job: http_requests_total:rate5m expr: sum by (job, code) (rate(http_requests_total[5m])) - record: job: http_request_duration_seconds:histogram_quantile95 expr: histogram_quantile(0.95, sum by (le, job) (rate(http_request_duration_seconds_bucket[5m])))之后Dashboard 直接查询job:http_requests_total:rate5m性能提升 10 倍。这相当于数据库的物化视图。实操心得Recording Rules 的record名必须规范。我们约定scope: metric: functionwindow。scope是聚合维度jobmetric是原始指标名function是计算函数ratewindow是时间窗口5m。这样看到job:http_requests_total:rate5m就知道它是按 job 聚合的 5 分钟速率。7.3 Thanos 长期存储告别“15 天魔咒”Prometheus TSDB 的 15 天 retention 是硬伤。Thanos 提供了一套优雅的解决方案Sidecar每个 Prometheus 实例旁部署一个 Thanos Sidecar它定期将本地 TSDB 的 block 上传到对象存储如 S3、MinIO。Querier一个独立组件它既能查询本地 Prometheus也能查询对象存储中的历史数据对上层透明。Compactor对对象存储中的 block 进行压缩和降采样downsampling生成 5m、1h、1d 的聚合数据节省 90% 存储空间。部署后你在 Grafana 中查询rate(http_requests_total[30d])Querier 会自动从对象存储中拉取数据体验与查本地无异。注意Thanos 不是“插件”而是独立的分布式系统。它引入了新的运维复杂度Sidecar 部署、Querier 高可用、Compactor 调度。我们建议只有当历史数据分析需求