嘿，咱们来聊聊怎么搞定Kubernetes里的MTTR（平均恢复时间）计算吧～你之前用kube-state-metrics效果不理想，大概率是因为MTTR不只是看容器启动时间，得把故障触发、调度、启动到服务就绪的全链路串起来。给你几个实操方向：

1. 先把MTTR的计算边界定义清楚 #

这是第一步，不然算出来的数根本没意义：

• 故障起始点：你得明确啥叫“故障”？是Pod变成Failed/CrashLoopBackOff的时刻？还是服务的健康探测（比如HTTP探针）第一次失败的时间？
• 恢复完成点：是Pod状态显示Running就够了？还是就绪探针连续成功、服务真正能处理请求的时刻？

比如对无状态服务来说，通常用就绪探针成功的时间 - 故障触发的时间作为单实例的恢复时长，再取所有故障实例的平均值。

2. 补全kube-state-metrics缺的关键指标 #

kube-state-metrics确实能给你Pod的状态，但有些核心时间戳它没提供，得搭配其他数据源：

• 容器实际启动时间：用容器运行时的指标，比如containerd或CRI-O暴露的container_start_time_seconds，能拿到容器真正启动的时刻
• K8s事件转指标：Pod重启时，Events里会有Created container、Started container这类时间戳，你可以用Prometheus的event exporter把这些事件转成可查询的指标
• 就绪探针成功时间：盯着kube_pod_container_status_ready这个指标，当它从0变成1的那个时间点，就是服务真正就绪的时刻

3. 用PromQL写出实际的MTTR计算逻辑 #

给你举个实际的例子，如果我们以Pod故障（kube_pod_status_phase{phase="Failed"}触发）到就绪的时长来计算：

• 先抓故障发生的时间戳：用这个PromQL检测Pod从正常变故障的时刻：kube_pod_status_phase{phase="Failed"} offset 1m == 1 and kube_pod_status_phase{phase="Failed"} == 0
• 再抓对应Pod就绪的时间戳：kube_pod_container_status_ready{ready="true"} == 1
• 最后计算差值并取平均：

avg_over_time(
  (timestamp(kube_pod_container_status_ready{ready="true"}) - timestamp(kube_pod_status_phase{phase="Failed"}))[7d:]
)

注意要确保Pod的标签能准确关联，别把不同Pod的时间混在一起了。

4. 别忘了调度延迟的影响 #

有时候容器启动慢不是因为镜像拉取或启动本身，而是调度器花了时间找合适的节点（比如节点资源不够、亲和性限制）。你可以用kube-state-metrics提供的kube_pod_scheduled_time_seconds减去kube_pod_created_time_seconds，得到调度耗时，这部分也是MTTR的组成部分，得算进去。

5. 有状态服务要特殊处理 #

如果是StatefulSet这类有状态服务，恢复时间还包括PVC挂载、数据恢复的时间，这时候得加额外监控：

• PVC绑定时间：看kube_pvc_status_bound从0变1的时间点
• 应用数据初始化完成时间：让应用自己暴露个自定义指标，比如app_data_initialized_seconds，这样能拿到数据准备好的时刻

6. 避开这些常见坑 #

• 别只看容器Running状态：容器跑起来不代表服务能用，必须结合就绪探针的状态
• 排除自愿重启：比如滚动更新、配置变更导致的Pod重启，这不属于故障恢复，要通过标签或事件过滤掉
• 明确多实例的计算逻辑：如果服务有多个副本，MTTR是从第一个实例故障到最后一个恢复的时间？还是单个实例恢复时间的平均？得根据你的业务需求来定

内容的提问来源于stack exchange，提问作者Ayush Dewan