Prometheus 计数器（Counter）应该如何管理？
管理 Prometheus 计数器的要点：命名加 _total 后缀、重启归零用 rate() 自动处理、永远不要手动递减、高基数标签要克制、长期存储靠远端写。本文给出完整实践清单。
管理 Counter 的核心原则：命名带 _total 后缀、只增不減、查询一律用 rate()/increase() 处理重置、标签维度保持低基数——做好这四点，计数器就是最省心的指标类型。
命名与定义
from prometheus_client import Counter
http_requests = Counter('http_requests_total', 'Total HTTP requests', ['method', 'status'])
- 名称以
_total结尾（客户端库会自动补）； - 标签只放聚合维度（method/status），用户 ID、请求 ID 这类高基数值永远不要进标签。
处理重启归零
Counter 重启后从零开始，不要在代码里做持久化恢复——rate() 和 increase() 会自动检测重置点并修正：
rate(http_requests_total[5m]) # 重启前后曲线依然连续
运维层面的管理
- 保留期：本地 TSDB 默认存 15 天，长期数据用
--storage.tsdb.retention.time调整或接远端存储（Thanos/Mimir/观测云）； - 指标清理：废弃的 Counter 先在代码中下线，历史数据等其超过保留期自动淘汰；
- 成本监控：关注
prometheus_tsdb_head_series（活跃序列数），Counter 标签失控是高基数事故的头号来源。
观测云对照
把指标采集交给观测云 DataKit 后，计数器的存储、保留期、基数管理都由平台承担——DataKit 的 prom 采集器直接抓取现有 /metrics 端点即可平滑接入，DQL 查询内置速率计算，无需关心重置处理。
常见问题（FAQ）
Q：Counter 能减少吗？ 不能。可增可减的场景请用 Gauge。
Q：rate 结果出现尖刺？ 窗口太小或抓取间隔抖动，把窗口调到抓取间隔 4 倍以上。
Q：info 类指标算 Counter 吗？ 不算——xxx_info 是值为 1 的 Gauge，靠 group_left 提供标签。
