后缀和冒号不是惯例，是契约

一句话总结

Prometheus 的指标命名规则不是个人偏好，而是工具赖以工作的契约。_total 声明它是计数器，_bucket、_sum、_count 是直方图的三个组成部分，冒号只允许用于记录规则。只有从名称就能看出指标是什么，仪表板和告警才能相互信任。

为什么需要它

类型选错后，未来想做的计算可能在原理上就无法完成。最常见的事故，是把延迟记录成仪表。

last_latency = Gauge("http_request_duration_seconds", "요청 처리 시간")
last_latency.set(elapsed)   # 앞선 값들은 전부 사라진다

如果抓取间隔为 15 秒、每秒有 500 个请求，7,500 个请求中只保存 1 个值，其余值仿佛从未存在。无法用这条时间序列计算 p99，事后重新处理数据也无法恢复。

工作原理

暴露格式是人类可读的文本。每行包含指标名称、花括号内的标签和值，并附有 # HELP 和 # TYPE 注释。标准路径是 /metrics；若使用其他路径，必须在抓取配置中指定 metrics_path。OpenMetrics 对这一格式进行了标准化，并加入 exemplar 和 created timestamp。

四种类型

类型	暴露的时间序列	回答的问题
Counter	x_total	每秒增加多少（需要 rate）
Gauge	x	当前值是多少
Histogram	x_bucket{le}, x_sum, x_count	分布如何（在服务器端估算分位数）
Summary	x{quantile}, x_sum, x_count	此进程内部的分位数

Summary 在服务层面无用，原因就是前一模块讲过的性质：分位数不能合并。 Summary 输出客户端已经算好的分位数，因此无法把 40 个 Pod 的 p99 合成一个。Histogram 以牺牲桶分辨率范围内的精度为代价，换取了可聚合性。在分布式系统中，后者几乎总是更合适的交换。

指标来自哪里也是考试常见题。

• node_cpu_seconds_total — Node Exporter（主机硬件、操作系统）
• container_cpu_usage_seconds_total — cAdvisor（内置于 kubelet，容器资源）
• kube_deployment_spec_replicas — kube-state-metrics（API 对象状态）
• process_cpu_seconds_total — 客户端库自动附加的进程指标
• probe_success — Blackbox Exporter（HTTP、TCP、DNS 探测）

记录规则把计算从查询时刻移到求值时刻。创建规则有四个判断标准：同一表达式在三处以上重复；查询超过 2 秒；告警每次求值都要运行繁重表达式；希望聚合高基数原始数据后长期保存。

名称遵循 수준:메트릭:연산 约定。从 route:http_requests:rate5m 这个名字，就能读出它是按路由聚合的请求数 5 分钟 rate。原始指标名称绝不使用冒号，因此只看名称便知道“这是派生时间序列”。

层级结构是关键。第 1 层只扫描一次原始数据，第 2 层只引用其结果，原始扫描因此只做一次。但组内规则从上到下求值，所以第 1 层必须位于第 2 层上方。

现场会遇到的情况

曾经一次加入 2,000 条记录规则，结果产生约 100 万条时间序列，WAL 急剧增长。部署前的计算很简单：120 条路由分别为 5 种窗口创建规则就是 600 条；若有 50 条规则，就是 3 万条。规则文件像代码一样接受审查，但成本等同于新增指标。

CI 会协助验证。使用 promtool check rules 检查语法，用 promtool test rules 检查期望值。尤其是在单元测试中亲自算出并写明期望值后，未来有人“优化”规则却改变语义时，CI 就能发现。也有 promtool 无法发现的内容——规则之间的循环引用必须由人在审查中识别。

下一实验要做什么

在 /root/pca-rules/ 下编写记录规则文件和告警规则文件，使用 level:metric:operations 命名创建两层结构。随后，在 promtool 单元测试文件中亲自计算并填入输入时间序列和期望值，最后把相同内容转换为 Prometheus Operator 可读取的 PrometheusRule CR。