监控系统容量：控制指标基数与采集压力
应对大促或突发流量时，团队往往先关注业务 API 的限流熔断；监控系统也应纳入容量评估。高基数指标或突发写入可能先让Prometheus 监控系统本身失去可用性。
当业务请求量飙升 10 倍，某些研发人员在代码里盲目地把user_id或ip_address当作 Label 动态注入到自定义 Prometheus 指标中时，指标的基数（Cardinality）会呈指数级爆炸。数百万新产生的 Active Series 会瞬间塞爆 Prometheus 内存，引发严重的 OOM CrashLoopBackOff。
流量洪峰到来前，应为 Prometheus 补齐容量预算与采集端背压（Backpressure）措施。
1. 高基数 (High Cardinality) 内存爆破真相与容量估算公式
Prometheus 的 TSDB（时序数据库）将每个唯一指标 Label 组合视为一条“时间序列”（Active Series）。内存消耗与 Active Series 数量成线性强相关关系：
容量推导精确公式
针对一个拥有 1000 万 Active Series、采集间隔为 15 秒的集群，Prometheus 实例所需的最小 RAM 计算如下：
$$\text{Memory}{Bytes} = \text{Series}{Active} \times \left( \text{Bytes}{PerSeries} + \text{SampleRate} \times \text{Bytes}{PerSample} \right) \times 1.35$$
- 标称值：平均每条 Series 在 Head Block 中占用约 4 KB 物理内存；每个 Chunk 样本占用 1.3 字节。
- 计算推导：
$$\text{Memory} = 10,000,000 \times 4000 \text{ Bytes} \approx 40 \text{ GB}$$
再算上 PromQL 复杂查询（如histogram_quantile）所需的临时 Query Buffer 空间（通常需预留 35% 余量），物理内存必须配置54 GB 以上。若无法提供如此巨大的物理内存，就必须在采集入口强制实施背压丢弃。
2. 采集端背压控制：Metric Relabeling 动态丢弃与降采样
防范高基数爆破的最有效工程手段，是在prometheus.yml采集配置的metric_relabel_configs阶段直接丢弃非法 Label：
scrape_configs: - job_name: 'microservices-exporter' scrape_interval: 15s scrape_timeout: 10s metrics_path: '/metrics' kubernetes_sd_configs: - role: pod # 【采集端背压防线】在写入 TSDB 内存前强行过滤与丢弃 metric_relabel_configs: # 1. 拦截并丢弃包含 user_id, order_id, client_ip 等高基数危险标签的指标 - source_labels: [__name__] regex: "(http_requests_by_user_total|trace_span_duration_seconds)" action: drop # 2. 从保留指标中彻底剥离高基数的 Label，防止 Series 膨胀 - regex: "(user_id|client_ip|device_id|session_token)" action: labeldrop # 3. 对非核心高频指标实施强制丢弃 - source_labels: [__name__, status_code] regex: "debug_level_metric_total;200" action: drop3. 基于 Go 语言的自定义 Exporter 采集端背压限流器实现
对于团队内部自研的 Exporter，如果允许其无限制地产生 metrics 文本，依然会将 Prometheus 侧拉垮。我们需要在 Exporter 侧内置速率限制（Rate Limiting）与尺寸背压：
package main import ( "fmt" "net/http" "sync/atomic" "github.com/prometheus/client_golang/prometheus" "github.com/prometheus/client_golang/prometheus/promhttp" "golang.org/x/time/rate" ) // BackpressureExporter 自带背压保护的 Exporter type BackpressureExporter struct { rateLimiter *rate.Limiter activeRequests int64 reqCounter *prometheus.CounterVec } func NewBackpressureExporter(maxRPS float64) *BackpressureExporter { return &BackpressureExporter{ rateLimiter: rate.NewLimiter(rate.Limit(maxRPS), 2), reqCounter: prometheus.NewCounterVec( prometheus.CounterOpts{ Name: "app_business_requests_total", Help: "Total business requests with backpressure guard.", }, []string{"status_group"}, // 强行收敛 Label 只能为 2xx, 4xx, 5xx 高度有限的枚举值 ), } } func (e *BackpressureExporter) ServeHTTPWithBackpressure(w http.ResponseWriter, r *http.Request) { // 1. 限制 Prometheus 拉取 API 的频率，阻止短时间高频 Scrape 打爆 CPU if !e.rateLimiter.Allow() { http.Error(w, "Exporter Rate Limit Exceeded (Backpressure Triggered)", http.StatusTooManyRequests) return } // 2. 限制最大并发处理量 current := atomic.AddInt64(&e.activeRequests, 1) defer atomic.AddInt64(&e.activeRequests, -1) if current > 10 { // 最多只允许 10 个并发拉取 http.Error(w, "Exporter Concurrency Limit Exceeded", http.StatusServiceUnavailable) return } // 3. 安全交付标准 Metrics 接口 promhttp.Handler().ServeHTTP(w, r) } func main() { exporter := NewBackpressureExporter(1.0) // 1 秒最多允许 1 次抓取 http.HandleFunc("/metrics", exporter.ServeHTTPWithBackpressure) fmt.Println("[Exporter Engine] Server started on :9101 with Backpressure Protection.") http.ListenAndServe(":9101", nil) }4. 生产现场高基数排查与容量诊断命令集
当发现 Prometheus 物理内存使用率超过 80% 警戒线时，立即使用终端工具链定位并阻断“罪魁祸首”指标：
## 1. 找出高基数指标 curl -s http://prometheus:9090/api/v1/status/tsdb | jq '.data.seriesCountByMetricName[:10]' # 2. 查找产生最多 Label 名称组合的前 10 个危险 Label curl -s http://prometheus:9090/api/v1/status/tsdb | jq '.data.labelValueCountByLabelName[:10]' # 3. 使用 promtool 在本地对改写后的 prometheus.yml 进行语法与背压规则效验 promtool check config /etc/prometheus/prometheus.yml大促与高并发不是监控爆破的借口。严格计算时序数据内存容限，在采集入口硬核配置 Relabeling 丢弃规则，并在架构层演进至 VictoriaMetrics / Thanos 分布式集群，才能构建出抗击流量洪峰的坚固监控体系。
指标治理从命名开始
新指标进入采集前先说明用途、标签来源和保留时长。没有明确查询场景的标签不要加入，避免把排障便利建立在不可控的基数上。
补充说明
现场记录比结论更重要
运维变更最怕只留下一个“正常”。每次检查应保存对象范围、命令版本、时间窗和关键输出摘要；对异常结果，注明下一步由谁判断、什么条件下停止继续操作。脚本可以给出候选结论，但生产动作仍需要把原始指标、日志或事件链接回去。恢复以后也要核对队列、错误率和业务任务是否回到基线，避免只看进程存活就结束处理。
高基数治理从采集入口开始。新增标签前先问它是否用于告警或定位；若只为临时排查，优先写入日志或 trace。对已经膨胀的指标，先找出增长最快的标签组合，再以重命名、聚合或丢弃方式逐步处理。直接删除整条指标会让已有告警失明。
标签变更的复盘
标签治理改完后，不只看 Prometheus 是否恢复。还要检查告警表达式、看板查询和录制规则有没有失效，并观察一段时间的内存增长斜率。对于确实需要保留的高基数场景，优先将明细放入日志或链路，指标只保留聚合维度。
