4. MTTR 数据采集方法：Prometheus 指标采集、Event 事件采集、kubectl get events、日志聚合（Loki/ELK）

MTTR 复盘的核心前提是 可观测数据 的完整性与准确性。节点异常从发生到恢复的每一个时间节点，都需要被精确记录。本章详细阐述四种数据采集方法，覆盖指标、事件、命令行快照与日志聚合四个维度，构建 MTTR 计算的完整数据基座。

4.1 数据采集方法对比总览

四种方法在数据源、时效性、存储周期与复盘用途上各有侧重。下表为 MTTR 复盘场景下的选型参考：

4.2 Prometheus 指标采集：时间轴定界

Prometheus 是 MTTR 时间线计算的 主力数据源。通过节点相关指标的时序变化，可以精确判定异常开始时间（T1）与恢复时间（T4）。

4.2.1 核心指标与 MTTR 映射

4.2.2 PromQL 查询示例：计算节点不可用时长

# 查询节点 node-01 在最近 24h 内 NotReady 的总时长（秒）
avg_over_time(
  (time() - (kube_node_status_condition{node="node-01", condition="Ready", status="true"} 
  * time()))[24h:15s]
)

4.3 Event 事件采集：状态变迁标记

Kubernetes Event 记录了节点、Pod 等资源的状态变迁，是 MTTR 时间线中 T2（响应时间） 和 T3（修复时间） 的关键证据。

4.3.1 关键 Event 类型与 MTTR 关联

4.3.2 事件采集架构

原生 Event 存储在 etcd 中，默认 TTL 仅 1 小时，无法满足 MTTR 复盘需求。推荐使用 event-exporter 或 kube-eventer 将事件持久化到外部存储。

# event-exporter 配置示例：将事件发送到 Loki
apiVersion: v1
kind: ConfigMap
metadata:
  name: event-exporter-config
  namespace: monitoring
data:
  config.yaml: |
    logLevel: info
    route:
      routes:
        - match:
            - receiver: "loki"
    receivers:
      - name: "loki"
        loki:
          url: "http://loki.monitoring:3100/loki/api/v1/push"
          tenant: "kubernetes-events"

4.4 kubectl get events：现场快照与人工校准

在复盘过程中，kubectl get events 是 最直接 的现场数据获取方式。虽然数据不持久化，但在故障发生时立即执行，可以捕获最原始的时间戳信息。

4.4.1 常用命令组合

# 查看节点相关事件（按时间排序）
kubectl get events --field-selector involvedObject.kind=Node \
  --sort-by='.lastTimestamp' -n default

# 查看特定节点事件
kubectl get events --field-selector involvedObject.name=node-01 \
  --sort-by='.lastTimestamp' --all-namespaces

# 查看 Warning 级别事件（重点关注）
kubectl get events --field-selector type=Warning \
  --sort-by='.lastTimestamp' --all-namespaces

# 输出为自定义列格式（便于导入复盘表格）
kubectl get events --all-namespaces \
  -o custom-columns=TIME:.lastTimestamp,TYPE:.type,REASON:.reason,OBJECT:.involvedObject.name,MESSAGE:.message \
  --sort-by='.lastTimestamp'

4.5 日志聚合（Loki/ELK）：根因证据链

指标和事件标记了 “什么时候” 发生了异常，而日志回答了 “为什么” 发生异常。日志聚合系统是 MTTR 复盘中根因分析（RCA）的核心数据源。

4.5.1 节点关键日志源

4.5.2 Loki 与 ELK 选型对比

4.5.3 LogQL 查询示例：定位 OOM 事件

# 在 Loki 中查询节点 node-01 最近 1 小时的 OOM 相关日志
{job="systemd-journal", hostname="node-01"} 
|~ "oom_killer|Out of memory|Killed process" 
| logfmt 
| line_format "{{.timestamp}} {{.message}}"

4.6 数据采集架构总览

下图展示了四种数据采集方法在 Kubernetes 节点 MTTR 复盘中的协同架构：

4.7 数据采集最佳实践

1. 时间同步： 所有节点必须配置 NTP 服务，确保 Prometheus、Event、日志的时间戳一致。时间偏差超过 5 秒将导致 MTTR 计算失真。
2. 标签统一： 在 Prometheus、Loki、Event 中统一使用 node、cluster、region 等标签，便于跨系统关联查询。
3. 数据保留策略： MTTR 复盘通常需要回溯 30~90 天数据。Prometheus TSDB 建议保留 30 天，日志存储建议保留 90 天。
4. 自动化采集： 将 kubectl get events 命令封装为故障自愈流程的 第一步，在触发告警时自动执行并保存结果到对象存储。
5. 冗余采集： 至少使用两种独立的数据源验证同一个时间点。例如，节点 NotReady 时间同时从 Prometheus 指标和 Event 事件中获取，取交集作为最终时间戳。