词元星图TokenAtlas
返回案例库

精选案例 · Agent / 实践案例

Lab Fault Ops

这个案例围绕「Lab Fault Ops」记录了一条真实 AI 实践线索，正文重点集中在「快速部署」「报告输出」，适合先按任务意图阅读再判断复用。

案例速读

README 标题「Lab Fault Ops」下已经出现运行/配置路径、脚本或接口线索、结果证据，正文重点集中在「快速部署」「报告输出」，比纯概念介绍更适合进入精选阅读流。 这篇案例的阅读价值在于，它把真实任务、模型辅助过程和可迁移做法放在同一个上下文里，读者可以从 「Lab Fault Ops」、「快速部署」、「报告输出」、「目录结构」 进入正文。

  • 建议重点看 可参考其中的运行与配置路径、包含可迁移的命令、脚本或接口线索、已有结果或观测证据可用于判断复用价值。结合 Agent / 实践案例 和「任务驱动用户、AI 实践者」这一受众定位，它更适合作为任务检索后的精读材料，而不是只看一句短摘要后快速跳过。
  • 正文目录和原始材料仍然是判断依据；导读只帮助你更快定位阅读重点。
看点
Lab Fault Ops
读者
任务驱动用户、AI 实践者
复用
可参考其中的运行与配置路径
结构
9 个目录入口

原文内容

Lab Fault Ops

Linux/GPU 服务器故障监控 Agent，基于 fault-agent（https://git.ustc.edu.cn/ustcnic/fault-agent）扩展了 GPU 状态、掉卡、ECC、硬件温度、网卡错误、登录失败统计和硬件 RAID 等服务器巡检项。脚本以只读检查为主，定期采集系统故障状态，并把完整报告和摘要保存到本地指定目录。

快速部署

cd /usr/src
git clone <repo-url> lab-fault-ops
cd /usr/src/lab-fault-ops
cp config.json.sample config.json
vi config.json
python3 fault-agent.py --config config.json

脚本会运行检查并把完整报告和摘要保存到 agent.report_dir。部署到固定路径后也可以这样运行：

python3 /usr/src/lab-fault-ops/fault-agent.py --config /usr/src/lab-fault-ops/config.json

crontab 示例：

0 * * * * python3 /usr/src/lab-fault-ops/fault-agent.py --config /usr/src/lab-fault-ops/config.json 2> /dev/null

报告输出

每次运行都会把两份文件写入 agent.report_dir，默认目录为 /var/log/lab-fault-ops：

  • report_<hostname>_<timestamp>.json：完整结构化 JSON 报告。
  • summary_<hostname>_<timestamp>.txt：人类可读摘要，只列出 warning/critical/error；无异常时说明无异常。

时间戳来自报告的 reported_at，使用 UTC 时间并放在文件名中。agent.report_dir 是唯一报告输出位置。

目录结构

lab-fault-ops/
├── fault-agent.py              # CLI 入口，仅负责调用 utils.runtime.main()
├── utils/
│   ├── core.py                 # 常量、通用工具、检查结果 helper
│   ├── checks.py               # 检查项聚合、CHECK_MAP、run_checks()
│   ├── checks_gpu.py           # NVIDIA GPU、掉卡、ECC、GPU 进程
│   ├── checks_resources.py     # CPU、内存、swap、systemd、时间同步、内核消息
│   ├── checks_storage.py       # 磁盘、inode、只读文件系统、NFS、RAID/LVM、storcli
│   ├── checks_network.py       # 网络连通性、DNS、端口、conntrack、登录失败、安全文件
│   ├── checks_temperature.py   # CPU/主板/磁盘温度
│   └── runtime.py              # 配置加载、报告构建、本地保存、CLI 主流程
├── config.json.sample
├── crontab.txt
├── SKILL.md
└── references/                 # 分析指南、操作手册、高危命令黑名单

配置

配置文件当前采用 JSON 格式，示例见 config.json.sample。

agent.tags 支持 Web 页面显示和筛选：

  • GID：访问控制，填写工号或学号；多个 ID 用逗号分隔。
  • group：分组标签，如 "GPU服务器"、"Web服务器"、"KVM"。

GPU 服务器建议配置物理 GPU 数量，避免 PCI 设备计数导致 gpu_missing 误报：

{
  "checks": {
    "gpu_missing": {
      "enabled": true,
      "expected_gpu_count": 10
    }
  }
}

检查项

在 fault-agent 通用系统故障检查基础上，面向课题组服务器补充了 GPU 和硬件巡检项。

GPU/硬件项：

检查项 说明
gpu_status GPU 利用率/显存采集、温度告警、功率、风扇
gpu_processes GPU 计算进程 PID、进程名、显存
gpu_missing nvidia-smi GPU 数与期望值或 PCI 计数对比
gpu_ecc_errors nvidia-smi -q ECC 检查，SBE warning、DBE critical
temperature_status sensors、sysfs、smartctl 温度，含 CPU/主板/磁盘
network_interface_errors /proc/net/dev 网卡 drops/errors
login_failures lastb -i 失败登录统计
storcli_raid storcli 硬件 RAID 物理盘状态

通用系统故障检查包括磁盘使用率、inode、磁盘 I/O 错误、内存、OOM、Swap、CPU 负载、僵尸进程、systemd、网络连通性、DNS、端口耗尽、conntrack、文件描述符、时间同步、证书过期、只读文件系统、NFS、firewall、内核错误、RAID/LVM、可疑文件。

报告 JSON

输出仍保持 fault-agent 的顶层结构：

{
  "agent_version": "1.0.2",
  "schema_version": "1.0",
  "hostname": "gpu-01",
  "machine_id": "...",
  "sysinfo": "192.168.8.21",
  "tags": {"GID": "XXXXX,YYYYY", "group": "GPU服务器"},
  "reported_at": "2026-05-08T14:30:00.000+00:00",
  "uptime_seconds": 6134400,
  "checks": [],
  "summary": {"total": 28, "ok": 26, "warning": 2, "critical": 0, "error": 0}
}

状态含义：ok、warning、critical、error。

运维约束

  • 智能体只读分析，不直接执行删除、清理、重启、kill、配置修改等操作。
  • 涉及删除或清理前，必须先查 references/blacklist.md。
  • 修改配置前必须先备份。
  • 用户个人 docker-rootless 任务默认不主动关注，除非长时间高占用并影响服务器稳定性。
  • 配置 SSH IP 白名单的服务器上，外部 lastb 失败登录通常无需重点关注。

依赖

  • Python 3.7+
  • 标准库即可运行
  • 可选：nvidia-smi、lspci、sensors、smartctl、storcli、lastb
返回顶部