Prometheus 日常巡检：抓住采集延迟、基数和规则错误

Prometheus 日常巡检抓住采集延迟、基数和规则错误Prometheus 巡检先看采集是否按时完成再看标签基数和规则评估。图表正常不代表数据完整Target 延迟、丢样和规则错误都要单独报警。阈值以当前环境基线为准。1. Prometheus 性能劣化的根源高基数标签与慢查询日常巡检要优先处理以下三类监控问题高基数标签膨胀High Cardinality Explosion如果把user_id、email、client_ip或随机 UUID 写进 Label时间序列数量会随取值基数快速增加可能推高 TSDB Head Block 的内存与压缩开销。长周期慢 PromQL 拖垮 TSDB 引擎某些 Grafana 视图使用了形如rate(http_requests_total[30d])且未加 namespace 筛选的大范围查询导致 Prometheus 内存很快爆表。僵尸告警规则Stale Alert Rules已下线的服务配置依然保留在 PromQL 告警规则中导致 Alertmanager 持续刷新脏计算开销。2. 自动化巡检与治理流水线架构为少走弯路可以放弃了“人工定期点开 Grafana 检查”的传统做法设计一套基于 Prometheus HTTP API 的自动化诊断与巡检机器人。3. Prometheus 自动化巡检脚本实现以下是用 Python 编写的 Prometheus TSDB 存储与高基数标签自动化巡检脚本。该脚本通过调用 Prometheus 官方 REST API自动分析当前占用内存最大的前 10 个高基数指标并生成巡检汇总。#!/usr/bin/env python3 # -*- coding: utf-8 -*- import requests import json from typing import Dict, List class PrometheusHealthInspector: def __init__(self, prom_url: str): self.prom_url prom_url.rstrip(/) def inspect_tsdb_cardinality(self) - Dict: 调用 TSDB Status API分析内存中高基数指标 Top 10 url f{self.prom_url}/api/v1/status/tsdb try: resp requests.get(url, timeout10) if resp.status_code ! 200: return {error: f请求失败 HTTP {resp.status_code}} data resp.json().get(data, {}) head_stats data.get(headStats, {}) series_count_by_metric data.get(seriesCountByMetricName, []) label_value_count_by_name data.get(labelValueCountByLabelName, []) return { num_series: head_stats.get(numSeries, 0), num_label_pairs: head_stats.get(numLabelPairs, 0), top_cardinality_metrics: series_count_by_metric[:10], top_cardinality_labels: label_value_count_by_name[:10] } except Exception as e: return {error: str(e)} def inspect_unhealthy_targets(self) - List[Dict]: 检查抓取失败或响应超时的 Target url f{self.prom_url}/api/v1/targets unhealthy [] try: resp requests.get(url, timeout10) if resp.status_code 200: active_targets resp.json().get(data, {}).get(activeTargets, []) for target in active_targets: if target.get(health) ! up: unhealthy.append({ job: target.get(labels, {}).get(job, unknown), instance: target.get(discoveredLabels, {}).get(__address__, unknown), health: target.get(health), last_error: target.get(lastError, ) }) except Exception as e: print(f检查 Target 异常: {e}) return unhealthy def generate_report(self) - str: 生成 Markdown 格式的日常巡检报告 tsdb_data self.inspect_tsdb_cardinality() unhealthy_targets self.inspect_unhealthy_targets() md # Prometheus 监控体系日常自动化巡检报告\n\n if error in tsdb_data: md f❌ **TSDB 状态获取异常**: {tsdb_data[error]}\n return md md ## 一、 TSDB 内存与时间序列概览\n\n md f- **当前内存 Head Block 时间序列总数 (numSeries)**: {tsdb_data[num_series]:,}\n md f- **当前内存 Label Pair 总数**: {tsdb_data[num_label_pairs]:,}\n\n md ### ⚠️ 高基数指标 Top 10 (基数过高易引发 OOM)\n\n md | Metric 名称 | 时间序列数量 (Series Count) |\n md |-------------|-----------------------------|\n for item in tsdb_data[top_cardinality_metrics]: md f| {item[name]} | {item[value]:,} |\n md \n## 二、 不健康 Target 抓取节点\n\n if unhealthy_targets: md f发现 {len(unhealthy_targets)} 个 Down 状态节点\n\n md | Job | Instance Address | 错误详情 |\n md |-----|------------------|----------|\n for target in unhealthy_targets: md f| {target[job]} | {target[instance]} | {target[last_error]} |\n else: md ✅ 所有配置的 Metrics 抓取 Target 状态均正常 (UP)。\n return md if __name__ __main__: inspector PrometheusHealthInspector(http://localhost:9090) print(inspector.generate_report())4. 诊断工具与排障命令组合拳在巡检过程中发现 Prometheus TSDB 占用内存过高或慢查询时运维人员应当使用以下工具迅速诊断并下手清理。1. 现场诊断 Prometheus 内核元数据 API# 1. 极速查询 TSDB 存储引擎元数据列出全站前 10 个高基数指标 curl -s http://localhost:9090/api/v1/status/tsdb | jq .data.seriesCountByMetricName[0:10] # 2. 查询当前占用内存最多、数值变化最频繁的 Label 名称 curl -s http://localhost:9090/api/v1/status/tsdb | jq .data.labelValueCountByLabelName[0:10] # 3. 统计过去 1 小时内抓取产生 Samples 最多的 Job curl -s http://localhost:9090/api/v1/query?querytopk(10, count by (job) ({__name__~.})) | jq .2. 通过 Prometheus Relabeling 确定性裁剪脏标签如果在巡检中发现http_requests_total中包含大量脏标签user_id可以直接在抓取配置中加硬拦截策略# prometheus.yml scrape_configs: - job_name: api-service kubernetes_sd_configs: - role: pod metric_relabel_configs: # 强行删除包含高基数用户 ID 的危险 Label - action: labeldrop regex: user_id|client_ip|device_uuid # 将高频变化的动态路径收敛为统一占位符 - source_labels: [path] regex: /api/v1/user/[0-9] target_label: path replacement: /api/v1/user/:id5. 生产治理与架构调优收口根据日常自动化巡检积累的数据监控体系应当进行如下确定性收口日常巡检治理落地总结验证这套治理组合时先从 Prometheus 状态接口记录当前时间序列数再用相同抓取配置比较以下指标巡检人力成本降至零通过定时 CronJob 自动生成 Markdown 巡检报告并同步到钉钉/飞书群运维工程师不再需要手动抓数据和拼接视图。自动化脚本可以检查采集延迟、规则错误和标签基数。脚本自身也要有运行状态与报警避免监控失效却无人发现。