Prometheus 监控体系的设计实践：从指标建模到告警策略，云原生可观测性的核心基石

一、监控体系的设计哲学：从数据采集到决策支撑

监控系统的核心目标不是"采集尽可能多的指标"，而是"为运维决策提供有效信息"。过多的指标导致信息过载，过少的指标导致盲区。监控体系设计的核心哲学是"以问题驱动指标"——先定义需要回答的问题（如"服务是否正常""性能是否达标""容量是否充足"），再选择能回答这些问题的指标。

Prometheus 的指标模型分为四种类型：Counter（只增计数器）、Gauge（可增可减仪表盘）、Histogram（分布直方图）、Summary（分位数摘要）。选择正确的指标类型是监控设计的第一步——用 Counter 记录请求总数、用 Gauge 记录当前连接数、用 Histogram 记录延迟分布。

二、Prometheus 监控体系的分层设计

监控体系按层次分为：基础设施层（节点/网络）、平台层（K8s/中间件）、应用层（业务指标）、以及用户体验层（端到端延迟）。

flowchart TD
    subgraph 基础设施层
        A1[CPU/内存/磁盘/网络]
        A2[节点可用性/负载]
    end
    subgraph 平台层
        B1[K8s: Pod 状态/资源请求率]
        B2[中间件: Redis/MySQL/Kafka 指标]
    end
    subgraph 应用层
        C1[RED 指标: Rate/Error/Duration]
        C2[USE 指标: Utilization/Saturation/Errors]
    end
    subgraph 用户体验层
        D1[端到端延迟: 首屏/接口响应]
        D2[可用性: 成功率/SLA 达标率]
    end

    A1 --> B1
    A2 --> B1
    B1 --> C1
    B2 --> C1
    C1 --> D1
    C2 --> D2

2.1 应用指标埋点

// metrics.go — Go 应用的 Prometheus 指标埋点
// 设计意图：实现 RED（Rate/Error/Duration）指标体系，
// 覆盖 HTTP 请求的速率、错误率和延迟分布

package metrics

import (
	"strconv"
	"time"

	"github.com/prometheus/client_golang/prometheus"
	"github.com/prometheus/client_golang/prometheus/promauto"
)

var (
	// 请求速率: 每秒请求数（按路径和方法分组）
	httpRequestsTotal = promauto.NewCounterVec(
		prometheus.CounterOpts{
			Name: "http_requests_total",
			Help: "HTTP 请求总数",
		},
		[]string{"method", "path", "status"},
	)

	// 请求延迟: 响应时间分布（直方图）
	httpRequestDuration = promauto.NewHistogramVec(
		prometheus.HistogramOpts{
			Name:    "http_request_duration_seconds",
			Help:    "HTTP 请求延迟分布",
			Buckets: []float64{0.01, 0.025, 0.05, 0.1, 0.25, 0.5, 1, 2.5, 5, 10},
		},
		[]string{"method", "path"},
	)

	// 当前在处理请求数: Gauge 类型
	httpRequestsInFlight = promauto.NewGaugeVec(
		prometheus.GaugeOpts{
			Name: "http_requests_in_flight",
			Help: "当前正在处理的 HTTP 请求数",
		},
		[]string{"method"},
	)

	// 业务指标: 订单处理
	ordersProcessed = promauto.NewCounterVec(
		prometheus.CounterOpts{
			Name: "orders_processed_total",
			Help: "已处理的订单总数",
		},
		[]string{"status"},  // success/failed
	)

	// 资源指标: 数据库连接池
	dbPoolStats = promauto.NewGaugeVec(
		prometheus.GaugeOpts{
			Name: "db_pool_stats",
			Help: "数据库连接池状态",
		},
		[]string{"state"},  // active/idle/waiting
	)
)

// HTTPMiddleware — Prometheus 指标采集中间件
func HTTPMiddleware(next http.Handler) http.Handler {
	return http.HandlerFunc(func(w http.ResponseWriter, r *http.Request) {
		method := r.Method
		path := normalizePath(r.URL.Path)

		// 增加在处理请求数
		httpRequestsInFlight.WithLabelValues(method).Inc()
		defer httpRequestsInFlight.WithLabelValues(method).Dec()

		// 记录开始时间
		start := time.Now()

		// 包装 ResponseWriter 以捕获状态码
		wrapped := &responseWriter{ResponseWriter: w, statusCode: 200}
		next.ServeHTTP(wrapped, r)

		// 记录延迟
		duration := time.Since(start).Seconds()
		httpRequestDuration.WithLabelValues(method, path).Observe(duration)

		// 记录请求总数
		status := strconv.Itoa(wrapped.statusCode)
		httpRequestsTotal.WithLabelValues(method, path, status).Inc()
	})
}

type responseWriter struct {
	http.ResponseWriter
	statusCode int
}

func (rw *responseWriter) WriteHeader(code int) {
	rw.statusCode = code
	rw.ResponseWriter.WriteHeader(code)
}

func normalizePath(path string) string {
	// 将路径中的动态参数替换为占位符
	// /users/123 → /users/:id
	// /orders/456/items → /orders/:id/items
	return path
}

2.2 告警规则设计

# alerting-rules.yaml — Prometheus 告警规则
# 设计意图：基于 RED 指标设计告警规则，
# 覆盖错误率、延迟和可用性三个维度

groups:
  # 错误率告警
  - name: error_rate_alerts
    rules:
      - alert: HighErrorRate
        expr: |
          (
            sum(rate(http_requests_total{status=~"5.."}[5m])) by (service)
            /
            sum(rate(http_requests_total[5m])) by (service)
          ) > 0.05
        for: 3m
        labels:
          severity: critical
        annotations:
          summary: "服务 {{ $labels.service }} 错误率过高"
          description: "5xx 错误率 {{ $value | humanizePercentage }}，超过 5% 阈值"

  # 延迟告警
  - name: latency_alerts
    rules:
      - alert: HighP99Latency
        expr: |
          histogram_quantile(0.99,
            sum(rate(http_request_duration_seconds_bucket[5m])) by (le, service)
          ) > 2
        for: 5m
        labels:
          severity: warning
        annotations:
          summary: "服务 {{ $labels.service }} P99 延迟过高"
          description: "P99 延迟 {{ $value }}s，超过 2s 阈值"

  # 可用性告警
  - name: availability_alerts
    rules:
      - alert: ServiceDown
        expr: up{job="kubernetes-pods"} == 0
        for: 1m
        labels:
          severity: critical
        annotations:
          summary: "服务 {{ $labels.instance }} 不可达"
          description: "Prometheus 无法抓取指标超过 1 分钟"

  # 资源告警
  - name: resource_alerts
    rules:
      - alert: PodCrashLooping
        expr: rate(kube_pod_container_status_restarts_total[15m]) > 0
        for: 5m
        labels:
          severity: warning
        annotations:
          summary: "Pod {{ $labels.namespace }}/{{ $labels.pod }} 持续重启"

三、生产级实践：Grafana 仪表盘与 SLO 监控

// grafana-dashboard.json — SLO 监控仪表盘配置
// 设计意图：基于 SLI（Service Level Indicator）构建 SLO 仪表盘，
// 展示服务的可用性和延迟达标情况

{
  "dashboard": {
    "title": "SLO 监控仪表盘",
    "panels": [
      {
        "title": "可用性 SLO（30 天窗口）",
        "type": "gauge",
        "targets": [
          {
            "expr": "1 - (sum(rate(http_requests_total{status=~\"5..\"}[30d])) / sum(rate(http_requests_total[30d])))"
          }
        ],
        "fieldConfig": {
          "defaults": {
            "thresholds": {
              "steps": [
                {"value": 0.999, "color": "green"},
                {"value": 0.995, "color": "yellow"},
                {"value": 0.99, "color": "red"}
              ]
            },
            "unit": "percentunit"
          }
        }
      },
      {
        "title": "错误预算消耗",
        "type": "stat",
        "targets": [
          {
            "expr": "1 - (sum(rate(http_requests_total{status=~\"5..\"}[30d])) / sum(rate(http_requests_total[30d]))) / 0.999"
          }
        ]
      }
    ]
  }
}

四、监控体系设计的权衡与边界

指标基数爆炸：高基数标签（如 user_id、request_id）会导致 Prometheus 的时间序列数量爆炸，消耗大量存储和查询资源。建议将高基数信息从标签移到日志中，Prometheus 只保留低基数标签（如 service、method、status_code）。

告警规则的可维护性：随着服务增长，告警规则数量可能达到数百条，维护成本极高。建议将告警规则模板化，基于服务标签自动生成规则，而非为每个服务手写规则。

长窗口查询的性能：30 天窗口的 SLO 查询需要扫描大量数据，在 Prometheus 中可能超时。Recording Rules 可以预计算长窗口指标，但增加了存储开销。建议对 SLO 指标使用 Recording Rules 预计算，其他指标使用即时查询。

Pull 模式的覆盖局限：Prometheus 的 Pull 模式无法覆盖短生命周期任务（如批处理作业、Serverless 函数），因为这些任务可能在 Prometheus 抓取前就已结束。Pushgateway 可以解决，但引入了单点故障风险。

五、总结

Prometheus 监控体系的设计核心是"以问题驱动指标"，通过 RED 和 USE 指标体系覆盖服务的速率、错误、延迟和资源利用率。落地建议：应用层使用 RED 指标（Rate/Error/Duration），基础设施层使用 USE 指标（Utilization/Saturation/Errors）；避免高基数标签，将 user_id 等信息放在日志中；告警规则模板化，基于服务标签自动生成；SLO 指标使用 Recording Rules 预计算，避免长窗口查询超时。