设计一套算力集群监控与告警系统，用于实时监控GPU/TPU等加速器的资源使用情况、训练任务状态及容器运行状态，并说明告警规则的设计。

1) 【一句话结论】

设计一套基于Prometheus生态的算力集群监控与告警系统，通过多维度指标（资源使用、任务进度、容器健康）实时采集与关联分析，结合动态调整的智能告警规则，确保GPU/TPU资源高效利用与训练任务稳定运行。

2) 【原理/概念讲解】

系统分层架构讲解：

• 数据采集层：使用Telegraf作为采集器，结合GPU exporter（如nvidia-smi）抓取显存、计算核使用率、温度、功耗；TPU自定义exporter采集算子执行时间、模型吞吐量等指标；通过K8s自定义Exporter或Docker stats获取容器CPU/内存、网络I/O。任务状态指标（训练步骤完成率、模型损失）通过训练框架（如TensorFlow、PyTorch）的日志或自定义指标导出器采集。
• 数据处理与关联层：Prometheus作为时间序列数据库（TSDB）存储所有指标，用PromQL关联资源指标与任务状态（如计算GPU显存使用率与训练步骤完成率的关系）；Grafana构建监控大屏，展示资源使用趋势、任务进度曲线。
• 告警处理层：Alertmanager接收Prometheus的告警，规则结合资源阈值（如GPU显存>80%）与任务进度（如训练步骤完成率<80%），并支持动态阈值调整（如基于历史数据用record函数更新阈值）。

3) 【对比与适用场景】

对比Prometheus与Zabbix（针对AI算力集群）：

特性	Prometheus	Zabbix
数据模型	时间序列数据库（TSDB）	RRDTool（圆环图数据库）
采集方式	Agent + Pull（适合K8s容器化环境）	Agent + Push（配置复杂，适合传统IT）
适合场景	云原生、大规模容器化AI算力集群	中小规模传统IT基础设施，混合云环境
注意点	需合理配置查询，避免性能问题	适合中小规模，配置复杂度较高

4) 【示例】

• 动态阈值调整示例（Prometheus record函数）：
  记录过去5分钟的平均GPU显存使用率，乘以系数（如1.2）作为新阈值：

  # 计算过去5分钟平均GPU显存使用率
  avg_gpu_mem_usage = avg by (instance) (rate(gpu_memory_used_bytes{job="gpu-exporter"}[5m])) / avg by (instance) (rate(gpu_memory_total_bytes{job="gpu-exporter"}[5m])) * 100
  # 动态更新告警阈值
  dynamic_gpu_threshold = record("gpu_mem_dynamic_threshold", avg_gpu_mem_usage * 1.2)
  

• 任务进度波动处理（阈值分级+时间窗口）：
  当训练步骤完成率低于目标值（如80%）且GPU显存使用率超过动态阈值时，触发告警：

  # 计算训练步骤完成率（假设指标为training_step_completed）
  training_progress = sum by (job) (training_step_completed) / sum by (job) (training_steps_total)
  # 告警规则（分级阈值：70%为警告，80%为临界）
  alert: GPU Task Stuck
    expr: (gpu_memory_usage > dynamic_gpu_threshold) and (training_progress < 0.8)
    for: 2m
    labels:
      severity: critical
    annotations:
      summary: "GPU {{ $labels.instance }} resource overload with training task stuck"
  

• TPU指标采集示例：
  自定义TPU exporter导出算子执行时间（如tpu_op_exec_time）、模型吞吐量（tpu_model_throughput），通过Telegraf采集后存储到Prometheus。

5) 【面试口播版答案】

（约90秒）
“面试官您好，我设计的算力集群监控与告警系统，核心是通过多维度指标关联分析，确保资源与任务状态协同。具体来说，数据采集层用Telegraf抓取GPU/TPU资源（显存、计算核、温度、功耗）和容器状态（CPU/内存、网络），同时通过训练框架导出训练步骤完成率、模型损失等任务指标。处理层用Prometheus存储并关联这些指标，Grafana展示资源与任务进度趋势。告警层结合资源阈值（如GPU显存超80%）和任务进度（如训练步骤完成率低于80%），当两者同时满足时触发告警。系统还支持动态调整告警阈值，比如用Prometheus的record函数基于历史负载数据计算新阈值，避免误报。这样既能保证资源高效利用，又能及时处理任务异常，确保集群稳定运行。”

6) 【追问清单】

• 问：如何动态调整告警规则中的阈值？
  回答要点：通过Prometheus的record函数动态计算阈值，例如基于过去5分钟的平均负载乘以系数（如1.2）作为新阈值，或结合机器学习模型（如时间序列预测）预测未来负载并调整。
• 问：如何处理任务进度的正常波动（如训练步骤完成率因训练波动而变化）？
  回答要点：设置阈值时考虑训练波动，增加时间窗口（如2分钟）过滤短时间波动，或采用分级阈值（70%为警告，80%为临界），避免因训练波动触发误报。
• 问：如何保证大规模集群数据采集的实时性？
  回答要点：对关键指标（如GPU显存使用率）启用Pushgateway模式，减少拉取延迟；采用Prometheus联邦架构（如Thanos）聚合多集群数据，分担查询压力。
• 问：如何处理TPU的特定指标（如算子执行时间）？
  回答要点：通过自定义TPU exporter采集算子执行时间、模型吞吐量等指标，用Telegraf采集后存储到Prometheus，确保全面覆盖加速器状态。

7) 【常见坑/雷区】

• 坑1：忽略TPU的特定指标（如算子执行时间）。雷区：仅采集GPU指标，遗漏TPU核心性能指标，导致无法全面评估TPU资源使用情况。
• 坑2：告警规则仅基于资源阈值，导致误报（如资源波动触发告警）。雷区：未考虑任务进度的正常波动，需增加时间窗口和阈值分级，过滤短时间资源波动。
• 坑3：动态阈值实现不具体，缺乏可验证的算法。雷区：未给出Prometheus record函数的具体配置或动态阈值计算逻辑，导致可落地性不足。
• 坑4：系统扩展性不足，无法应对大规模集群。雷区：未提及Pushgateway或Prometheus联邦架构，导致数据采集延迟高，影响监控实时性。
• 坑5：告警绝对化表述（如“确保”资源高效利用）。雷区：应改为“有助于”或“旨在”，避免过度承诺，同时考虑误报、漏报等风险。