exit状态指纹是通过结构化容器退出码（如137、143）并关联日志、指标、事件与拓扑上下文，形成可归因、可聚合、可回溯的轻量级载荷健康信号，补全资源监控缺失的语义层。
用 exit 状态指纹实时规范评估容器集群载荷，关键不是只看 exit code 数字本身，而是把它作为触发点，串联起日志、指标、事件和拓扑上下文，形成可归因、可聚合、可回溯的轻量级载荷健康信号。它不替代传统资源监控（如 CPU、内存），而是补全“为什么负载突变”的语义层。
提取标准化 exit 指纹
容器退出时的原始 exit code（如 137、143、255）需结合运行时上下文升维为结构化指纹：
- 统一捕获
exitCode、signal（如 SIGKILL）、oomkilled: true/false、reason（CrashLoopBackOff / OOMKilled / Error / Completed） - Promtail pipeline 中增加 stage：解析
docker inspect $CONTAINER_ID --format='{{.State.ExitCode}} {{.State.OOMKilled}}'或监听/sys/fs/cgroup/memory/kubepods/.../memory.oom_control - 为每个崩溃 Pod 打上固定标签组合：
pod_name、container_name、image_digest、node、namespace、deployment（若存在）
构建实时载荷关联视图
单个 exit 指纹价值有限；真正用于载荷评估的是其在时间与空间维度上的聚合模式：
- 按分钟/5 分钟窗口统计各命名空间下
exitCode=137的 Pod 数量 —— 这是 OOM 压力最直接的实时载荷代理指标 - 将
exitCode=143（SIGTERM）与同一 Pod 的kube_pod_container_status_restarts_total和container_cpu_usage_seconds_total关联，识别“高频重启+高 CPU”组合，指向调度过载或资源争抢 - 对
exitCode=255或非标准码，叠加 Prometheus 中kube_pod_status_phase{phase="Failed"}和kube_pod_container_status_waiting_reason{reason="ImagePullBackOff"}，区分是镜像拉取失败（基础设施层）还是启动脚本异常（应用层）
嵌入 SLO 与自动响应链
把 exit 指纹纳入服务等级目标（SLO）体系，让载荷评估结果驱动真实动作：
- 定义关键服务的“崩溃率 SLO”：例如
rate(kube_pod_container_status_terminated_reason{reason=~"OOMKilled|CrashLoopBackOff"}[30m]) / rate(kube_pod_container_status_started_total[30m]) - 当某 deployment 在 5 分钟内出现 ≥3 次 exitCode=137，自动触发告警并附带 Prometheus 查询链接 + Loki 日志上下文片段 + 节点内存压力快照（
node_memory_MemAvailable_bytes / node_memory_MemTotal_bytes） - 在 Grafana 面板中，将 exit 指纹热力图（X: 时间，Y: deployment，颜色深浅=崩溃次数）与 CPU/Memory 使用率曲线同屏叠加，直观定位载荷拐点
避免常见误用
exit 指纹不是万能诊断器，需警惕几个典型偏差：
-
忽略正常退出：exitCode=0 未必代表健康，比如健康检查失败后主动退出的 sidecar 容器，需结合
container_state_terminated_reason标签过滤 - 混用不同生命周期：Job 类工作负载天然会以非零码退出（如 exitCode=1 表示任务失败），不应与 Deployment 的崩溃率混算
-
未对齐时间窗口：Prometheus 指标采样间隔（如 15s）与容器实际退出时刻可能存在偏移，建议用
increase()函数替代瞬时值做趋势判断
