平台拿什么来量自己

一句话总结

平台团队要衡量的不是节点的 CPU，而是平台对用户做出的承诺。自助服务请求的成功比例、部署完成所需的时间、不得不回滚的部署的比例，就是这些承诺。

为什么只有资源指标不够

只看节点指标的仪表板，即使出了事故也是绿灯。因为即使自助发放全部失败，节点的 CPU 反而是空闲的。反过来，即使节点很忙，从用户的角度来看也可能毫无问题。

所以要把平台也当作一个服务来看。用户是开发团队，请求是创建账单或部署，有成功与失败，也有耗时。这样一来，要衡量什么就清楚了。

衡量什么	为什么是它
发放请求的成功比例	自助服务是否真的是自助服务
从请求到可以使用的时间	黄金路径是否真的快
部署频率与回滚的比例	部署是不是一件令人畏惧的事
故障恢复所花的时间	发现问题所花的时间与修复问题所花的时间

工作原理

先有记录规则，再有告警

如果在告警条件里每次都计算比例，同一个表达式就会分散在多个告警中。修改了一处而忘了另一处的事故，就出在这里。所以比例通过记录规则定义一次，告警引用它的名称。

groups:
  - name: platform-slo
    rules:
      - record: platform:provision_success:ratio5m
        expr: |
          sum(rate(platform_provision_total{result="success"}[5m]))
          /
          sum(rate(platform_provision_total[5m]))

如果名称中含有 5m，表达式的区间也必须是 5 分钟。如果名称与内容不一致，所有使用这个指标的人，都会基于错误的前提做出判断。

触发延迟要按目的来确定

for 要求条件保持一段时间。本实验使用 10 分钟，但对于需要立即响应的事件，也可以省略。这个时间与 Alertmanager 的发送和重复间隔不同。当告警表达式为假时，必须移除序列。vector(0) 或 비율 < bool 0.95（韩文，意为“比例”）是一个陷阱：即使值为 0，序列仍会保留，导致告警被激活。请在官方告警规则说明中区分阅读 pending 和 firing。

没有 runbook_url 的告警也是同样的。凌晨三点收到的告警，如果没有写明下一步的行动，那它就不是信息，而是噪音。severity 标签是路由分流的依据，如果没有它，所有告警都会走同一条路径。

验证过的内容与部署的内容必须相同

规则文件可以用 promtool check rules 验证。靠人眼阅读，抓不出表达式中少了的一个括号。不过，如果验证的文件与上传到集群的 PrometheusRule 是不同的东西，那么这种验证就什么也保证不了。要从文件生成 CR，上传之后，对照整个 spec.groups。如果名称相同而表达式变了，那就是另一条规则。不要断定 API 存储了，Operator 就选中了，或者 Prometheus 就加载了。这次的环境没有运行 Operator，所以只验证到存储一致为止，不声称测试过告警的送达。

在现场相遇的样子

来想一个虚构的案例。如果做了一个失败路径不留下指标的发放服务，仪表板上可能只会显示成功率 100%。如果分母只统计成功，比例就永远是 1。

仅凭一个比例，很难分辨这种埋点遗漏。只有直接阅读表达式，看它在统计什么，才能发现。所以在创建新指标时，必须故意制造一次失败，并确认这个值是否会变化。告警也是一样。

语法之后要放入事件

上面的简单比例，是两个结果序列都存在时的起点。如果只有失败序列，分子就为空，如果没有流量，分母就是 0。在接下来的实验中，只有失败时用 0 补充分子，但只有在总 rate 为正数时才保留比例。观测空白不应当被当作成功 100%，而要作为另外的埋点异常去调查。如果对各实例的成功率做简单平均，就会把只有 1 次请求的服务器和有 1 万次请求的服务器看得一样重，从而产生错误。

按照 rate 官方说明，要先按各个计数器计算 rate，再求和。如果先求和再计算 rate，一个序列的重启就会与另一个序列的增加混在一起，对重置的解读就会不同。本实验还会在重置区间内检查只有成功计数器重启的事件。

在这个过程中使用的 13 个事件是：正常 99%、持续失败 80%、边界 95% 及其两侧、3 分钟故障、故障后恢复、无流量、没有观测、只有成功、只有失败、计数器重置，以及请求量不同的两个实例。还会确认恢复后第 17 分钟的成功率和第 19 分钟的解除，以区分把 5 分钟区间改成 10 分钟的错误。这是使用学习用固定数据的测试，并不是对所有生产流量的证明。

promtool check rules 检查语法，promtool test rules 检查虚拟时间序列上的值。请阅读官方测试格式中的 input_series 和 eval_time，并把它们与真实的等待时间区分开。镜像中的 3.0.1 不支持最新文档中的 fuzzy_compare，所以辅助工具会直接检查比例误差是否小于 1e-9。

接下来阅读什么

在指标告知异常之后，接下来看应该先统计什么来对这个异常分类。