自定义 Metrics 设计规范业务指标和技术指标的层级划分一、监控面板 80 个指标但故障时不知道看哪个运维团队花了两个月建了监控系统各种指标应有尽有GC 次数、线程数、文件描述符、内存碎片率、连接池使用率……面板上有 80 多个指标。但真正故障时大家翻了几分钟面板都没找到关键信号——信息多不等于信息有用。指标体系的设计不是越多越好而是要有清晰的层级和关联。哪些指标是服务是否健康的一线信号哪些是为什么出问题的排查信号哪些是业务好不好的趋势信号没有分层80 个指标就是 80 个噪音。二、四层指标体系架构flowchart TD subgraph L1[第一层: 业务指标 5-8个] B1[日活用户数] B2[核心流程转化率] B3[业务错误率] B4[用户平均响应时间] end subgraph L2[第二层: SLI/SLO 指标 4-6个] S1[可用性: 99.9%] S2[P99延迟目标] S3[错误预算剩余] S4[吞吐量 SLA] end subgraph L3[第三层: 技术指标 10-15个] T1[QPS 错误率] T2[P50/P95/P99 延迟] T3[资源: CPU/内存/磁盘] T4[依赖: DB/缓存/MQ] end subgraph L4[第四层: 诊断指标 20-30个] D1[GC 暂停时间] D2[连接池状态] D3[Goroutine 数量] D4[慢查询数量] D5[缓存命中率] end B1 -.-|告警| ALERT{业务异常} S1 -.-|告警| ALERT_SLO{SLO 偏离} ALERT -- INVESTIGATE[排查: 从上往下看] INVESTIGATE -- L3 INVESTIGATE -- L4四层指标的金字塔原则上层指标少而精告警只用前两层、下层指标多而全排查用三四层、告警不看第四层避免告警风暴。三、Go 实现自定义 Metrics 体系package custommetrics import ( github.com/prometheus/client_golang/prometheus github.com/prometheus/client_golang/prometheus/promauto ) // 第一层业务指标管理层关注 var ( // 核心业务指标每日活跃 Agent 数 ActiveAgentsDaily promauto.NewGauge(prometheus.GaugeOpts{ Name: business_active_agents_daily, Help: 每日活跃的 Agent 实例数, }) // 核心业务指标任务完成率 TaskCompletionRate promauto.NewGauge(prometheus.GaugeOpts{ Name: business_task_completion_rate, Help: Agent 任务完成率 (0-1), }) // 核心业务指标用户满意度通过反馈收集 UserSatisfactionScore promauto.NewHistogram(prometheus.HistogramOpts{ Name: business_user_satisfaction_score, Help: 用户满意度评分分布, Buckets: []float64{1, 2, 3, 4, 5}, }) ) // 第二层SLI/SLO 指标运维技术管理 var ( // 服务可用性按滚动 28 天窗口计算 ServiceUptime promauto.NewGauge(prometheus.GaugeOpts{ Name: slo_service_uptime_ratio, Help: 服务可用性比例28天滚动窗口, }) // 错误预算剩余 ErrorBudgetRemaining promauto.NewGauge(prometheus.GaugeOpts{ Name: slo_error_budget_remaining_percent, Help: 错误预算剩余百分比SLO 99.9% → 允许 0.1% 错误, }) // P99 延迟是否达标 LatencySLOMet promauto.NewGaugeVec(prometheus.GaugeOpts{ Name: slo_latency_p99_met, Help: P99 延迟是否满足 SLO1达标, 0未达标, }, []string{endpoint}) ) // 第三层技术指标开发/运维日常关注 var ( // RED 指标Rate RequestRate promauto.NewCounterVec(prometheus.CounterOpts{ Name: tech_http_requests_total, Help: HTTP 请求总数, }, []string{method, path, status}) // RED 指标Errors RequestErrors promauto.NewCounterVec(prometheus.CounterOpts{ Name: tech_http_errors_total, Help: HTTP 请求错误数, }, []string{method, path, error_type}) // RED 指标Duration RequestDuration promauto.NewHistogramVec(prometheus.HistogramOpts{ Name: tech_http_duration_seconds, Help: HTTP 请求延迟, Buckets: []float64{.005, .01, .025, .05, .1, .25, .5, 1, 2.5, 5, 10}, }, []string{method, path}) // 大模型 API 调用指标 LLMCallTotal promauto.NewCounterVec(prometheus.CounterOpts{ Name: tech_llm_calls_total, Help: 大模型 API 调用总数, }, []string{model, status}) LLMTokenUsage promauto.NewCounterVec(prometheus.CounterOpts{ Name: tech_llm_token_usage_total, Help: 大模型 Token 消耗总数, }, []string{model, type}) // type: input, output ) // 第四层诊断指标深度排查用 var ( // GC 统计 GCPauseDuration promauto.NewHistogram(prometheus.HistogramOpts{ Name: diag_gc_pause_duration_seconds, Help: GC 暂停时间分布, Buckets: []float64{.0001, .0005, .001, .005, .01, .05, .1}, }) // Goroutine 数量 GoroutineCount promauto.NewGauge(prometheus.GaugeOpts{ Name: diag_goroutine_count, Help: 当前 Goroutine 数量, }) // 数据库连接池 DBConnPoolUsage promauto.NewGaugeVec(prometheus.GaugeOpts{ Name: diag_db_conn_pool_usage, Help: 数据库连接池使用率, }, []string{db_name, type}) // type: active, idle, total // Agent 特定指标 AgentTaskQueueDepth promauto.NewGauge(prometheus.GaugeOpts{ Name: diag_agent_task_queue_depth, Help: Agent 任务队列深度, }) AgentToolCallLatency promauto.NewHistogramVec(prometheus.HistogramOpts{ Name: diag_agent_tool_call_seconds, Help: Agent 工具调用延迟, Buckets: []float64{.1, .5, 1, 2, 5, 10, 30}, }, []string{tool_name}) ) // 指标命名规范 // 命名规范{层级}_{领域}_{指标名}_{单位} // // 层级前缀 // business_ → 业务指标管理层 // slo_ → SLO 指标运维 // tech_ → 技术指标开发 // diag_ → 诊断指标排查用 // // 示例 // business_task_completion_rate → 业务: 任务完成率 // slo_error_budget_remaining_percent → SLO: 错误预算剩余 // tech_http_duration_seconds → 技术: HTTP 延迟 // diag_db_conn_pool_usage → 诊断: 数据库连接池 // PromQL 告警规则示例 // 第一层告警业务异常仅告警最核心指标 // business_task_completion_rate 0.8 → P1 告警 // // 第二层告警SLO 偏离 // slo_error_budget_remaining_percent 50 → P1 告警预算消耗过半 // slo_error_budget_remaining_percent 10 → P0 告警预算即将耗尽 // // 第三层技术异常 // rate(tech_http_errors_total[5m]) / rate(tech_http_requests_total[5m]) 0.01 // → P1 告警 // // 第四层不设告警仅在排查时查看 // 仪表板设计原则 // Dashboard 分层 // 1. Executive Dashboard管理层 // 5-8 个面板日活、完成率、满意度、月度成本 // // 2. Operation Dashboard值班运维 // 10-15 个面板可用性、P99延迟、错误率、错误预算 // // 3. Technical Dashboard开发 // 20-30 个面板QPS、延迟分布、错误详情、资源使用 // // 4. Deep Dive排查 // 按服务/依赖组织的详细面板四、指标设计的边界与反模式不要把所有指标都设告警。第四层的诊断指标永远不应该触发告警——告警只应该从第一层业务异常和第二层SLO 偏离发出。如果一个 GC 暂停 10ms 就告警值班工程师会被告警风暴淹没。指标不是越多越好。每新增一个指标都要问这个指标的异常会触发什么行动如果答案是不知道或者看着好玩那就不需要。指标命名要遵循团队约定。http_requests_totalvsrequestCountvstotalHttpRequests——没有统一命名规范写 PromQL 时会反复查字典。建议团队制定命名规范{层级}_{领域}_{指标名}_{单位}。指标的基数Cardinality是 Prometheus 的隐形杀手。在标签中使用用户 ID、订单号等高基数字段会在短时间内产生数万条时间序列压垮 Prometheus。每个标签值组合都是一条独立的时间序列。五、总结指标体系设计不是技术活而是管理活。四层金字塔结构业务指标 5-8 个看趋势 → SLI/SLO 4-6 个看健康 → 技术指标 10-15 个看运行 → 诊断指标 20-30 个看细节。告警只需前两层排查才用到后两层。每季度做一次指标清理哪些指标六个月来没有任何人看过删掉。