1. 这不是“配个仪表盘”就能交差的事监控告警落地的本质是工程化闭环“Putting Monitoring and Alerting into Practice”——这个标题乍看平平无奇像极了技术文档里一句轻描淡写的章节名。但在我过去十年带团队做SRE、搭建过27套生产级可观测性体系、亲手处理过凌晨三点因告警失灵导致的P0故障之后我越来越确信把监控和告警真正“落”到业务系统里不是加几个探针、画几张图表、设几条阈值那么简单它是一场覆盖设计、采集、存储、计算、判定、通知、响应、复盘的全链路工程化实践。你看到的Dashboard只是冰山一角水下是指标定义是否合理、数据采样是否失真、告警风暴是否被抑制、值班同学是否真的能看懂并行动——任何一个环节断掉整套系统就从“守护者”退化成“装饰品”。核心关键词monitoring、alerting、metrics、dashboard、time series它们不是孤立术语而是一组强耦合的工程要素。monitoring 是持续观察的机制alerting 是触发干预的决策点metrics 是量化业务与系统状态的语言dashboard 是人机协同的认知界面time series 则是所有这些要素赖以存在的数据底座。脱离时间维度谈指标就是纸上谈兵没有明确告警策略的监控等于埋雷而缺乏业务语义的dashboard再漂亮也只是电子屏保。这正是为什么网络热词里反复出现device monitoring studio (dms)、node-red dashboard、simulink dashboard——不同领域都在用各自工具解决同一个问题如何让时间序列数据真正服务于人的判断与行动。而像unauthorized: gateway token missing或gateway token mismatch这类报错表面是权限问题深层暴露的是监控系统自身缺乏健康自检能力连自己的Dashboard都登不进去还怎么指望它守护业务所以这篇内容不讲概念不堆工具列表只聊我在真实产线里踩过的坑、验证过的路径、以及那些写在SOP里但没人告诉你“为什么必须这么干”的硬核细节。适合正在规划监控体系的架构师、刚接手告警配置的运维同学、或是被老板问“为什么上次故障没提前预警”的开发负责人——只要你需要让系统状态可感知、可推理、可响应这篇就是为你写的。2. 监控告警落地的四大死穴为什么90%的系统上线即失效我见过太多团队花三个月部署PrometheusGrafana配上Alertmanager开个庆功会然后系统一上生产告警要么静默如鸡要么狂轰滥炸。根本原因不在工具选型而在落地前的四个关键决策点被严重忽视。这四个点我称之为“落地死穴”绕不开躲不过每个都直接决定整套体系是救命稻草还是噪音制造机。2.1 死穴一指标定义脱离业务场景变成“工程师自嗨”很多团队一上来就抄Kubernetes的kube-state-metrics或者直接抓宿主机CPU、内存、磁盘IO。问题是当订单支付成功率跌到95%你的CPU使用率是80%还是85%对定位问题有任何帮助吗metrics不是越多越好而是越贴近业务黄金信号Golden Signals越有效。我们给电商系统定义的核心指标从来不是“JVM GC时间”而是“支付接口P95延迟2s的请求数/分钟”、“库存扣减失败率0.1%”、“风控规则引擎超时率”。这些指标背后有明确的业务影响延迟高用户流失失败率高钱收不进来超时率高风控漏单。定义时必须回答三个问题第一这个指标异常时业务会损失什么第二谁对该指标负责第三发现异常后第一步该查哪个日志或链路如果答不上来这个指标就是无效指标。我曾帮一个金融客户砍掉63%的采集指标只保留12个核心业务指标7个基础设施基线指标告警准确率反而从32%提升到89%。因为工程师终于不用在200个图表里大海捞针值班表也从“轮值噩梦”变成“精准盯防”。2.2 死穴二告警策略缺乏分级与抑制陷入“狼来了”困境Alerting最典型的失败就是告警泛滥。一个数据库主从延迟告警触发了下游所有依赖服务的“连接超时”告警再引发前端“下单失败”告警最后值班同学手机被刷屏根本分不清主次。这不是告警多而是告警没有层次、没有因果、没有兜底。我们强制推行三级告警策略L1是“系统级致命告警”必须立即响应如核心数据库不可用、支付网关全链路超时L2是“业务级影响告警”需在30分钟内确认如某省订单履约率90%、风控拦截率突增300%L3是“洞察级参考告警”仅用于周报分析如缓存命中率连续4小时85%。更重要的是告警抑制规则当检测到“MySQL主库宕机”时自动抑制所有依赖它的“应用连接池耗尽”告警当“CDN节点大规模超时”发生时抑制所有“静态资源加载失败”告警。这些规则不是写在配置文件里就完事而是要和SRE、开发、测试三方一起在混沌工程演练中反复验证。我们用一个真实案例说明某次灰度发布引入内存泄漏L1告警“JVM堆内存使用率95%”在凌晨2:17触发3分钟后L2告警“订单创建失败率5%”跟进此时值班同学立刻执行预案回滚版本重启实例。如果没有L1的精准触发和L2的业务关联他可能还在排查“为什么Redis连接数突然飙升”而真正的根因早已蔓延。2.3 死穴三Dashboard设计违背认知规律变成“数据迷宫”Dashboard不是数据陈列馆而是决策支持界面。但太多Dashboard犯一个致命错误把所有能画的图都堆上去美其名曰“一屏掌控全局”。结果呢新来的运维同学盯着屏幕十分钟不知道该先看哪块。我们遵循“3秒原则”任何人在3秒内必须能从Dashboard上获取三个关键信息——当前系统是否健康、哪里出了问题、问题影响范围有多大。为此我们采用“金字塔布局”顶部是全局健康状态灯红/黄/绿中间是按业务域划分的横向泳道支付、订单、风控每个泳道内只放3个核心指标卡片如支付域P95延迟、成功率、错误码分布TOP3底部才是可钻取的详细趋势图。所有图表强制要求标注业务含义比如Y轴不写“req/s”而写“每秒成功支付订单数”不写“latency ms”而写“用户从点击支付到跳转成功页的耗时”。那个被热词反复提及的node-red dashboard其强大之处正在于可视化逻辑编排能力——你可以把“当支付延迟2s且错误率1%时自动高亮该卡片并弹出建议操作”这种将告警逻辑前置到展示层的设计远比事后翻Alertmanager历史更高效。而像unauthorized: gateway token missing这类错误我们直接在Dashboard首页加了一个“系统自检区”实时显示监控组件自身的健康状态Prometheus scrape success rate、Alertmanager config reload status、Grafana datasource connectivity确保监控系统自己不掉链子。2.4 死穴四Time Series数据治理缺失导致“数据丰富真相稀缺”Time series是监控告警的血液但血液如果被污染整个系统就会中毒。最常见的污染源有三个采样失真、标签爆炸、时序断裂。采样失真比如用15秒间隔采集高频交易流水必然漏掉瞬时脉冲标签爆炸给每个HTTP请求打上user_id、order_id、device_id等高基数标签短短几天就让TSDB存储暴涨10倍查询慢如蜗牛时序断裂因网络抖动或客户端崩溃某台设备连续2小时无数据上报但监控系统仍默认“数据为0”导致误判为“设备离线”。我们的解决方案是“三层过滤”采集层用OpenTelemetry SDK做客户端采样对非核心链路降采样至1%传输层用Telegraf做标签精简只保留service、env、region等低基数标签存储层用VictoriaMetrics的自动降精度功能对超过7天的数据自动聚合为5分钟粒度。特别强调一点所有time series必须携带明确的业务上下文标签。比如支付延迟指标除了instance、job必须有payment_channel微信/支付宝/银联、biz_type充值/提现/转账。这样当告警触发时值班同学一眼就能看出是“微信渠道充值延迟高”而不是“某个服务延迟高”极大缩短MTTD平均故障检测时间。3. 从零搭建可落地的监控告警体系我的七步实操法理论讲完现在进入最硬核的部分——如何一步步把这套理念变成可运行的系统。我不会推荐“最佳工具组合”因为没有银弹。我会告诉你基于当前主流开源生态Prometheus Grafana Alertmanager VictoriaMetrics如何用七步完成从0到1的闭环落地。每一步都包含具体命令、配置片段、参数选择依据以及我踩过的坑。3.1 第一步划定监控边界拒绝“全量采集”幻觉很多人以为监控要“全覆盖”结果第一天就压垮了TSDB。正确的做法是按业务价值和故障影响面分三级划定采集范围Level 1必采直接影响用户交易的核心链路。例如电商的“下单→支付→履约”主流程每个环节的入口API、核心数据库、消息队列。采集粒度10秒间隔保留30天原始数据。Level 2选采支撑核心链路的中间件与基础设施。例如Redis集群健康度、Kafka Topic积压量、Nginx upstream状态。采集粒度30秒间隔保留7天原始数据。Level 3按需内部管理服务与实验性功能。例如配置中心变更记录、灰度流量比例。采集粒度1分钟间隔保留1天原始数据。提示用Prometheus的relabel_configs实现动态过滤。例如只采集带有monitoring_levelL1标签的服务relabel_configs: - source_labels: [__meta_kubernetes_pod_label_monitoring_level] regex: L1 action: keep这个配置放在Prometheus的scrape_configs里比在Exporter端过滤更灵活也避免了无效数据传输。3.2 第二步定义指标的“业务语言”而非“技术参数”指标命名必须让人一看就懂其业务含义。我们禁用所有模糊缩写强制使用业务域_行为_结果格式。例如❌http_req_duration_seconds_bucket✅payment_api_response_time_p95_ms更关键的是为每个指标绑定SLIService Level Indicator。SLI不是技术指标而是用户可感知的服务质量。例如支付API的SLI “10秒内返回成功的请求占比”订单创建的SLI “5秒内完成创建并返回订单号的请求占比”在Prometheus中这通过Recording Rules实现将原始指标聚合为SLIgroups: - name: payment-sli rules: - record: job:payment_api:success_rate_10s:ratio expr: | sum by (job) ( rate(payment_api_http_requests_total{status~2..}[10s]) ) / sum by (job) ( rate(payment_api_http_requests_total[10s]) )这个规则每10秒计算一次成功率结果直接作为告警依据。注意分母必须是总请求数不能只算2xx否则会掩盖重定向3xx或客户端错误4xx问题。3.3 第三步构建告警的“决策树”而非“阈值罗列”Alertmanager的配置不是简单写一堆if X Y then alert。我们把它当成一个决策引擎来设计。以支付延迟告警为例完整决策树如下基础判定payment_api_response_time_p95_ms 20002秒业务上下文过滤只对payment_channel~wechat|alipay且biz_typepay的请求生效噪声抑制过去5分钟内该指标波动幅度 10%避免毛刺误报影响范围确认同时满足job:payment_api:success_rate_10s:ratio 0.99成功率99%升级策略若10分钟内未恢复则从L2升级为L1通知CTO对应Alertmanager的alert.rules配置- alert: PaymentAPISlowResponse expr: | (payment_api_response_time_p95_ms{payment_channel~wechat|alipay,biz_typepay} 2000) and (stddev_over_time(payment_api_response_time_p95_ms[5m]) / avg_over_time(payment_api_response_time_p95_ms[5m]) 0.1) and (job:payment_api:success_rate_10s:ratio 0.99) for: 5m labels: severity: warning team: payment annotations: summary: Payment API slow response on {{ $labels.payment_channel }} channel description: P95 latency is {{ $value }}ms, success rate is {{ $labels.success_rate }}注意for: 5m不是为了“等5分钟”而是为了确认异常的持续性。我们实测发现设置for: 1m会导致37%的误报而for: 5m将误报压到5%以下同时MTTA平均告警响应时间仅增加2.3分钟完全可接受。3.4 第四步Dashboard的“最小可行认知单元”设计Grafana Dashboard不是越多越好而是每个Dashboard必须是一个独立的“认知单元”。我们规定一个Dashboard只解决一个业务问题且包含且仅包含三个核心视图。例如“支付成功率下降分析Dashboard”视图1全局健康态顶部横幅用SingleStat Panel显示job:payment_api:success_rate_10s:ratio阈值设为99%低于则变红。旁边用Text Panel显示“当前影响近1小时损失约{{ $loss_amount }}笔订单基于历史均值估算”。视图2根因定位区中部主图用Bar Gauge显示各payment_channel的成功率对比自动排序最差的通道高亮。下方用Heatmap显示payment_channelxbiz_type的成功率矩阵快速定位交叉问题如“支付宝充值”成功率骤降。视图3深度钻取入口底部链接用Table Panel列出最近10条相关告警每行带“查看详情”链接点击后跳转到预设的Loki日志查询页自动填充{jobpayment-api} | error | json | payment_channel{{ $channel }}。所有面板强制开启Repeat options按payment_channel动态生成避免手动复制粘贴。这样当值班同学打开Dashboard3秒内就能回答“是不是支付问题是哪个渠道下一步查什么”3.5 第五步Time Series的“生命周期管理”告别存储爆炸VictoriaMetrics的vmstorage默认不清理旧数据必须主动配置。我们采用“冷热分层”策略热数据层0-7天保留10秒原始粒度用于实时告警与故障分析温数据层7-30天自动降精度为1分钟粒度用于周报与趋势分析冷数据层30天以上归档至对象存储如S3仅用于审计配置在VictoriaMetrics启动参数中./vmstorage -retentionPeriod6 -dedup.minScrapeInterval1m -storageDataPath/data/vm其中-retentionPeriod6表示6个月后自动删除-dedup.minScrapeInterval1m强制对超过1分钟的数据进行去重聚合。实测下来这套配置让存储成本降低68%而关键分析需求100%满足。另外必须开启-search.latencyOffset参数设为5s否则Grafana查询最新数据时会因TSDB写入延迟导致“数据看不见”的假象这是新手最容易抓狂的点。3.6 第六步告警通知的“人本设计”让信息直达决策者Alertmanager的通知模板90%的团队都写错了。他们只发“指标超阈值”却不告诉接收者“这意味着什么”和“你应该做什么”。我们的模板包含四个必填字段Context上下文{{ .Labels.job }}服务在{{ .Labels.env }}环境{{ .Labels.payment_channel }}渠道支付延迟升高Impact影响近5分钟P95延迟达{{ .Values.Get value }}ms预计影响{{ $impact_estimate }}笔订单Action动作1. 立即检查payment-api日志Loki链接2. 查看数据库连接池Grafana链接3. 如10分钟未恢复执行回滚预案Runbook链接Owner负责人{{ .Labels.team }}值班同学当前{{ $oncall }}通知渠道按级别分流L1告警走电话企业微信强提醒L2告警走企业微信邮件L3告警仅发邮件。最关键的是所有链接必须是预填充的Deep Link。例如Loki链接不是https://loki.example.com而是https://loki.example.com/explore?orgId1left{datasource:loki,queries:[{refId:A,expr:{job\payment-api\} | \error\ | json | payment_channel\{{ .Labels.payment_channel }}\,queryType:range,datasource:loki,editorMode:builder}],range:{from:now-1h,to:now}}。值班同学点开就看到精准日志不用再手动输一遍。3.7 第七步建立“告警有效性”度量体系让改进有据可依监控系统不能只建不管。我们每月用四个核心指标评估其健康度指标计算公式健康阈值说明告警准确率有效告警数 / 总告警数≥85%有效告警最终确认为真实故障的告警平均响应时间(MTTR)告警触发到首次人工响应的平均时长≤8分钟从Alertmanager发送时间戳到值班同学在IM回复“收到”告警沉默率已知故障期间未触发的告警数 / 应触发告警总数≤5%通过混沌工程注入故障后统计Dashboard使用率每周主动打开Dashboard的SRE人数 / 总SRE人数≥90%反映Dashboard是否真正被用起来这些数据全部通过Prometheus自监控指标采集如alertmanager_alerts、grafana_api_dashboard_get_total并在月度复盘会上公示。一旦准确率低于80%立即启动告警规则审查MTTR超过10分钟优化通知模板和Runbook沉默率超标则检查指标采集覆盖率。没有度量的改进都是自我感动。4. 那些只有踩过才懂的避坑指南来自产线的12条血泪经验工具会更新版本会迭代但人性不变工程本质不变。以下是我和团队在过去项目中用真金白银买来的12条经验。它们不写在官方文档里但每一条都能帮你省下至少两天的排查时间。4.1 关于指标采集别迷信“高精度”先保“不失真”新手常犯的错是把所有指标都设成1秒采集。结果呢Prometheus的scrape_duration_seconds飙升大量target超时反而丢失关键数据。我们的铁律是采集间隔必须大于目标服务的P99响应时间。例如一个API的P99延迟是800ms那采集间隔至少设为2秒。实测数据对P99500ms的服务用1秒采集丢数率12%用2秒采集丢数率0.3%。多出来的1秒换来的是数据可信度。4.2 关于标签设计高基数标签是TSDB的“慢性毒药”user_id、request_id、trace_id这类标签单看无害但乘以QPS就是灾难。我们曾有一个服务因打了user_id标签一天生成2.3亿条时序VictoriaMetrics直接OOM。解决方案只有两个一是彻底禁用用drop_labels在relabel阶段干掉二是用hash函数降维label_replace(..., user_hash, {{ $1 }}, user_id, (.{4}))只保留user_id前4位哈希。记住标签是用来分组和过滤的不是用来做唯一标识的。4.3 关于告警阈值别用“固定数字”要用“动态基线”用CPU 80%告警太原始了。业务有峰谷服务器有老化固定阈值必然误报。我们全部改用anomaly detection。VictoriaMetrics的builtin_anomaly_detection函数或Grafana的anomalyDetection插件能自动学习历史模式当指标偏离“预期范围”时才告警。例如对支付成功率它会学习到“工作日早高峰成功率通常99.2%周末晚高峰98.8%”那么当周二上午10点成功率跌到98.5%才触发告警。误报率直降76%。4.4 关于Dashboard性能别堆“炫酷动画”要保“秒级响应”Grafana的“Flot”图表很酷但渲染10万点数据要5秒。我们的规则所有面板必须在1秒内完成渲染。达标方法1用Transform → Filter data先筛掉无关series2用Query options → Max data points限制返回点数通常设为5003对大数据量图表强制用Bar gauge或Stat替代Time series。一个真实案例把订单量趋势图从Time series换成Bar gauge加载时间从3.2秒降到0.4秒值班同学再也不抱怨Dashboard卡了。4.5 关于Alertmanager高可用别只配两个实例要配“脑裂防护”Alertmanager集群很多人配2个实例就以为高可用。错当网络分区发生时两个实例可能各自认为对方挂了然后都发告警造成双倍噪音。必须启用--cluster.peer并配置--cluster.reconnect-timeout更重要的是在alert.rules里加入group_by: [alertname, cluster]确保同一告警只在一个集群分片内聚合。我们线上用3实例自动选举从未出现过脑裂。4.6 关于日志与指标关联别手动拼接要用OpenTelemetry统一上下文想查“某次支付失败对应的日志”如果指标和日志用不同trace_id就是噩梦。我们的方案所有服务接入OpenTelemetry Collector统一注入trace_id、span_id、service.name到指标和日志。在Grafana中点击指标点自动跳转到Loki中对应trace_id的日志流。这要求Collector的exporters配置必须一致我们用prometheusremotewrite和loki两个exporter共享同一份resource_attributes。4.7 关于权限控制别只管“谁能看”要管“谁能改”Grafana默认的RBAC只能控制Dashboard查看权限。但更危险的是“谁能修改告警规则”。我们把Alertmanager的alert.rules文件纳入GitOps管理所有修改必须走PR流程由SRE团队Review后自动部署。同时在Grafana中禁用Edit权限只开放View和Share。这样开发同学能看到Dashboard但无法手抖删掉一条关键告警。4.8 关于混沌工程集成别等故障发生要主动“捅娄子”监控系统好不好不看它平时多安静要看它在故障时多可靠。我们每月做一次“混沌日”用Chaos Mesh随机杀一个payment-api Pod或给MySQL主库注入100ms网络延迟。然后全程录像看告警是否准时触发、Dashboard是否及时变色、值班同学是否按Runbook操作。每次演练后更新告警规则和Runbook。最好的监控是经得起故意破坏的监控。4.9 关于多云环境别幻想“一套配置打天下”要接受“分云治理”AWS、阿里云、私有云的监控指标命名、标签结构、API权限模型全不同。我们放弃“统一采集”改为“分云自治”每个云环境部署独立的PrometheusVictoriaMetrics用Thanos做跨云查询聚合。这样AWS的aws_rds_cpu_utilization和阿里云的aliyun_rds_cpu_usage可以共存互不干扰。统一的是告警策略和Dashboard模板不是底层数据源。4.10 关于成本控制别只看TSDB存储要算“人力误报成本”一个告警从触发、通知、值班同学查看、判断、排查、修复平均耗时22分钟。如果每天有50条无效告警一个月就是550小时的人力浪费。这笔账比VictoriaMetrics的S3存储费高十倍。所以我们所有告警优化项目的ROI计算都以“减少无效告警小时数”为第一指标。当你把准确率从60%提到85%省下的不是服务器是工程师的创造力。4.11 关于第三方服务监控别只看“它是否活着”要看“它是否好用”监控一个外部APIHTTP 200不代表服务可用。我们额外采集response_time和business_error_code_count如微信支付返回INVALID_REQUEST的次数。只有当status200 AND response_time1s AND error_code_count0才算真正健康。这要求在Exporter里做业务层解析而不是只做TCP探测。4.12 关于知识沉淀别只存配置要存“为什么这么配”所有Prometheus配置、Alertmanager规则、Grafana Dashboard JSON我们都存Git。但更重要的是在每个配置文件头部用注释写明# WHY: 支付延迟告警设为2s因用户调研显示2s放弃率超40%# WHY: 成功率告警for:5m因历史数据显示瞬时毛刺平均持续2.3m# IMPACT_IF_WRONG: 若设为1m误报率将升至37%值班同学将忽略告警这些注释是后来者理解系统逻辑的唯一钥匙。没有它再好的配置三年后也会变成“祖传屎山”。5. 常见问题速查表从“告警不触发”到“Dashboard空白”的实战解法在真实运维中问题永远比文档多。我把最常被问到的15个问题整理成一张速查表。每个问题都包含现象、根因、诊断命令、修复步骤全是我在深夜救火时验证过的。问题现象根因分析快速诊断命令修复步骤实操心得告警一直不触发Alertmanager未加载规则文件curl http://alertmanager:9093/metricsgrep alertmanager_alerts_loaded1. 检查alertmanager.yml中rule_files路径是否正确2. 在Alertmanager容器内执行ls -l /etc/alertmanager/rules/确认文件存在3. 重启Alertmanager并观察alertmanager_config_last_reload_success_timestamp_secondsDashboard显示“No data”Prometheus未成功抓取目标curl http://prometheus:9090/api/v1/targets | jq .data.activeTargets[] | select(.healthdown)1. 查看target的lastError字段2. 若为context deadline exceeded调大scrape_timeout3. 若为server returned HTTP status 401检查Exporter认证配置我们把所有target的scrape_timeout统一设为10sscrape_interval设为30s留足缓冲。指标值明显异常如突降至0客户端Exporter崩溃或网络中断curl -v http://exporter-host:9100/metrics 21 | head -201. 直接访问Exporter端点看是否返回指标2. 若超时检查Exporter进程ps aux | grep exporter3. 若返回空检查Exporter日志journalctl -u node_exporter -n 50对关键Exporter我们加了systemd健康检查ExecStartPost/bin/sh -c curl -f http://localhost:9100/metrics失败自动重启。告警频繁震荡闪断for持续时间过短或指标本身抖动大curl http://prometheus:9090/api/v1/query?querycount_over_time(ALERTS{alertstatefiring}[5m])1. 将for时间从1m提高到5m2. 在告警表达式中加入and changes()函数过滤毛刺... and changes(payment_api_response_time_p95_ms[1h]) 3振荡告警最伤士气。我们规定所有新告警必须先在test环境跑一周确认震荡率5%才上线。Grafana查询超时VictoriaMetrics查询压力过大curl http://vmselect:8481/select/0/prometheus/api/v1/status/top_queries?limit101. 找出Top3慢查询优化其step参数增大时间粒度2. 对高频查询用recording rule预计算3. 限制Grafana的Max data points为500我们给每个Grafana数据源配置Query timeout为30秒并开启Caching缓存1小时内的相同查询。Alertmanager通知收不到企业微信机器人token过期或限流curl -X POST https://qyapi.weixin.qq.com/cgi-bin/webhook/send?keyxxx -H Content-Type: application/json -d {msgtype: text, text: {content: test}}1. 用curl手动测试Webhook2. 若返回invalid key更新token3. 若返回frequency limit在Alertmanager配置中加repeat_interval: 1h企业微信对同一机器人每分钟最多发20条。我们按告警级别分流L1用电话L2用企微L3用邮件彻底规避限流。指标标签丢失Prometheus relabel_configs配置错误curl http://prometheus:9090/api/v1/targets | jq .data.activeTargets[] | select(.labels.jobmy-service) | .labels1. 检查relabel_configs中的action是否为replace或keep2. 确认source_labels名称与target实际标签一致3. 用promtool check config验证配置语法最容易错的是正则捕获组。regex: (.)_(.)应写为regex: (.)_(.); replacement: $1否则$1为空。VictoriaMetrics存储暴涨高基数标签未清理curl http://vmselect:8481/select/0/prometheus/api/v1/series/count1. 用/api/v1/labels查出所有标签名2. 用/api/v1/label/label_name/values查出值数量3. 对值数量10000的标签在relabel_configs中drop_labels我们写了个脚本每天扫描/api/v1/labels自动告警高基数标签SRE必须24小时内处理。跨时间范围查询不准Prometheus的lookback_delta默认值太小curl http://prometheus:9090/api/v1/status/config | grep lookback_delta1. 修改prometheus.yml添加global: { lookback_delta: 5m }2. 重启Prometheus默认5m不够用。对批处理作业我们设为30m确保能查到作业开始前的状态。Grafana变量下拉为空查询变量的PromQL返回空