Prometheus 计数器（Counter）应该如何管理？
管理 Prometheus 计数器的要点：命名加 _total 后缀、rate() 修正可观察重置但不能补齐全部漏采事件、永远不要手动递减、高基数标签要克制、长期存储按后端配置 remote_write 或块上传等架构。本文给出完整实践清单。
管理 Counter 的核心原则：命名带 _total 后缀、只增不減、查询一律用 rate()/increase() 处理重置、标签维度保持低基数——做好这四点，计数器就是最省心的指标类型。
命名与定义
from prometheus_client import Counter
http_requests = Counter('http_requests_total', 'Total HTTP requests', ['method', 'status'])
- Counter 暴露名称惯用 _total，Python 客户端会规范化该后缀；其他客户端行为需按实现核对；
- 标签只放聚合维度（method/status），用户 ID、请求 ID 这类高基数值永远不要进标签。
处理重启归零
Counter 重启后从零开始，普通进程指标通常无需持久恢复；持久业务计数器也可合理暴露。rate/increase 能修正样本中可观察到的下降，但不能补回所有停机期间事件或未观察到的重置：
rate(http_requests_total[5m]) # 修正可观察到的重置，不保证重启期间精确计数或曲线连续
运维层面的管理
- 保留期：未配置时间/大小保留限制等情况下本地 TSDB 通常默认 15 天，实际以启动参数为准，长期数据用
--storage.tsdb.retention.time调整或配置对应长期存储架构（例如 Thanos sidecar 上传块，或向支持 remote_write 的后端写入，并非同一种接入）； - 指标清理：废弃的 Counter 先在代码中下线，历史数据等其超过保留期自动淘汰；
- 成本监控：关注
prometheus_tsdb_head_series（活跃序列数），各类指标的标签失控都可能造成高基数，不能认定 Counter 必然居首。
常见问题（FAQ）
Q：Counter 能减少吗？ 不能。可增可减的场景请用 Gauge。
Q：rate 结果出现尖刺？ 窗口太小或抓取间隔抖动，把窗口调到抓取间隔 4 倍以上。
Q：info 类指标算 Counter 吗？ 不算——xxx_info 是值为 1 的 Gauge，靠 group_left 提供标签。
