Prometheus 最佳实践
Prometheus 的稳定性首先来自规范，而不是更多机器。指标命名、标签约束、规则评审、容量预算和演练机制应成为平台能力的一部分。
1. Metric 设计规范
- 使用清晰的领域前缀，例如
checkout_、payment_。 - Counter 以
_total结尾，时长使用_seconds，容量使用_bytes。 - 指标描述业务含义和单位，不用模糊的
value、status或混合单位。 - 对请求延迟使用 Histogram，并根据 SLO 设计桶边界。
- 指标变更视为兼容性变更，提前通知 Dashboard 和规则负责人。
2. Label 设计规范
保留有限、稳定且可枚举的标签，例如 cluster、environment、service、namespace、method、code。禁止用户 ID、订单 ID、请求 ID、完整 URL、异常信息和随机 UUID。新增标签前评估可能的值数量、组合数和生命周期。
3. PromQL 最佳实践
- Counter 使用
rate()、increase()，不要直接对累计值做平均。 - 比率计算前先对齐分子、分母标签维度。
- 高成本表达式写成 Recording Rule，避免多个看板重复执行。
- 告警使用稳定的时间窗口与
for，避免irate()造成短时误报。 - 为关键查询建立测试样本和预期结果，规则发布前执行
promtool test rules。
4. 存储容量规划
容量由活跃时间序列、抓取频率、样本大小、WAL 峰值和保留周期共同决定。持续观察 prometheus_tsdb_head_series、磁盘使用量、compaction、查询时长与远端写入队列。为磁盘和 inode 留出安全余量，按趋势扩容而不是写满后抢修。
5. 性能优化
优先减少无效采集和高基数，限制 Dashboard 的默认时间范围和变量范围，使用 Recording Rule 统一重查询。随后再评估 CPU、内存、磁盘 IOPS、分片、Remote Write 或长期存储。扩容无法修复无限增长的标签基数。
6. 企业生产实践
| 领域 | 最低要求 |
|---|---|
| 配置发布 | Git 管理、代码评审、promtool 校验、预发验证与可回滚发布 |
| 安全 | UI/API 经 HTTPS 与 SSO 或内网保护，数据源/Exporter 使用最小权限 |
| 告警 | 规则有团队、严重度、运行手册与演练；Alertmanager 有分组、抑制和维护流程 |
| 可靠性 | Prometheus、Alertmanager、通知渠道和关键数据源均有独立健康检查 |
| 恢复 | 配置、规则、数据与 Secret 引用可恢复，并定期演练 |
| 治理 | 指标/标签准入、成本审查、容量趋势与版本生命周期清晰可追溯 |
生产实践的目标不是收集更多数据，而是在故障发生时让正确的人看到可行动、可信且有上下文的信号。