如何设计 Prometheus 中的 metric？

在使用 Prometheus 进行监控时，合理设计 metric 是关键。本文将介绍 metric 的命名规范、标签选择以及不同类型的选择方法。

部署与运维 中等 Prometheus 监控系统 metric设计

Prometheus 是一款开源的监控系统，metric 设计核心遵循可扩展、直观和高价值原则。以下是具体设计方法：

  1. 遵循基础设计规范
    • metric 命名：使用简洁、描述性的英文名称（如 http_request_duration_seconds），避免使用特定业务标识符以确保通用性。 强调：
      • metric 名称匹配表达式：[a-zA-Z_:][a-zA-Z0-9_:]*
      • 标签名称匹配表达式：[a-zA-Z_][a-zA-Z0-9_]*
      • 保留双下划线 __ 开头标签供内部用，用户自定义不可使用
    • 标签选用：用于多维数据切片（如 API 路径或错误类型）但控制基数（避免过高标签值导致资源消耗），例如： 
        api_requests_total{method="GET", endpoint="/api/users", status="200"} // 标签提升查询灵活性

  2. 选择合适 metric 类型

    类型 适用场景 特点 示例
    Counter 累计增长计数型 只增不减（reset=0例外） http_requests_total (请求总数)
    Gauge 可上下波动性测量 任意增减、连续观察 current_connections (实时连接数)
    Histogram 长尾分布观测指标 生成直方图统计 request_latency_seconds_bucket (延迟桶)
    Summary 关键分位点测量（P99/P95等） 不聚合、高精度时序性能观测 query_duration_seconds_quantile (查询分位数)
  3. 工程化最佳实践
    • 清晰职责划分：区分系统指标（如HTTP延迟）与业务指标（如订单数），参考业务案例： 
        // C# 中定义业务 metric
  static readonly Counter ordersCreatedCounter = Metrics.CreateCounter("order_created_total", "订单创建总数");

      触发时调用：ordersCreatedCounter.Inc()（计数递增）

    • 数据模型权衡：
      • 高基数标签影响性能（单metric标签值过多致高TSDB存储消耗）
      • 合理平衡：例如应用分页接口不应单设page_id标签以保障健壮性

    • 端到端配置结合：配合Pushgateway（适配老系统采集）部署方式，并用PromQL扩展表达式覆盖复杂告警逻辑：

        sum(http_requests_total{method="GET"}[5m]) //时间窗口聚合查询

核心要义：优先保障稳定、可度量的系统状态抽象能力；避免冗余设计，指标粒度结合监控需求弹性定制。