超越利用率监控：基于硬件性能计数器的ML系统异常检测实践

1. 项目概述：为什么我们需要超越“利用率”的系统监控？

在任何一个运行着大规模机器学习训练任务的数据中心或云平台上，运维工程师和算法研究员最常挂在嘴边的词可能就是“利用率”了。CPU利用率90%，GPU利用率95%，内存占用80%——这些数字看起来很美，似乎意味着我们的昂贵硬件正在满负荷运转，物尽其用。但作为一名在HPC和AI基础设施领域摸爬滚打了十多年的老兵，我必须告诉你一个残酷的事实：高利用率往往是最具欺骗性的性能假象。

我见过太多这样的场景：一个分布式训练任务，GPU利用率持续在95%以上，但训练速度却异常缓慢，一个epoch的时间比预期长了三倍。团队一开始怀疑是模型结构或数据流水线的问题，排查了几天几夜，最后才发现罪魁祸首是某个计算节点上持续发生的DRAM ECC纠错，导致内存访问延迟激增，而GPU因为等待数据，计算单元看似繁忙实则“空转”。传统的监控仪表盘一片绿色，但真实的业务效率早已跌入谷底。

这就是我们启动这个“基于低层系统指标与硬件性能计数器的ML基础设施异常检测”项目的初衷。我们厌倦了在问题发生后像无头苍蝇一样进行事后排查，我们希望构建一套“透视眼”系统，能够穿透利用率这层表象，直接看到硬件子系统在最微观层面的真实行为。这套系统的核心，不是替换现有的监控（如Prometheus + Grafana），而是对其进行深度增强。我们采集那些通常被运维工具忽略的“底层噪音”——CPU的每周期指令数（IPC）、各级缓存的未命中率、内存控制器的活跃周期、GPU的显存纠错计数、网络栈的重传报文数等等。这些指标就像系统的“心电图”和“脑电图”，能提前揭示出资源争用、硬件降级、驱动兼容性等深层问题。

这项工作对于保障动辄消耗数十万GPU卡时的大型模型训练任务至关重要。一次非计划中的中断，其成本不仅是机器闲置的费用，更是整个研究团队进度的延误。我们的目标，是让基础设施的“可观测性”从“知道机器是否活着”，进化到“理解计算任务为何跑得不够快”，最终实现“预测并预防性能衰退”。接下来，我将详细拆解我们是如何设计并实现这套系统的，包括指标采集的“脏活累活”、特征工程的“炼金术”，以及如何让异常检测结果变得可解释、可行动。

2. 核心思路：从“粗放监控”到“精细画像”的范式转变

传统的集群监控体系，其设计哲学源于保障服务的可用性（Availability）。它关注的是“是否可达”、“是否存活”、“资源是否耗尽”。因此，其指标集多是面向资源的、聚合的、高层的。例如，node_cpu_seconds_total告诉你CPU时间花在了哪里，node_memory_MemFree_bytes告诉你还剩多少内存。这些指标对容量规划和服务调度至关重要，但对理解一个计算密集型任务的性能瓶颈，却显得力不从心。

我们的框架实现了一次根本性的范式转变：从面向资源的监控，转向面向工作负载（Workload）的性能剖析（Profiling）。这意味着，我们监控的焦点不再是“机器”，而是“机器上正在运行的特定计算任务”。我们试图为每一次训练任务绘制一张多维度的“系统行为指纹”。

2.1 设计哲学：关注“如何运行”，而非“是否运行”

这个转变背后有三个核心设计原则：

1. 关联性（Correlation）：所有采集的指标都必须能与特定的工作负载（例如，一个Kubernetes Pod，一个SLURM作业ID）强关联。我们通过在采集代理中注入作业上下文信息来实现这一点，确保每一行指标数据都知道自己“属于谁”。
2. 低层性（Low-level）：我们必须获取硬件和操作系统内核暴露的最原始性能事件。CPU的硬件性能计数器（Performance Monitoring Counters, PMCs）是这里的宝藏，它能告诉你L1缓存命中了多少次、分支预测失败了几回、执行端口是否拥堵。这些信息是利用率指标永远无法提供的。
3. 高频与同步（High-frequency & Synchronization）：许多性能异常是瞬态的，比如由内存带宽瞬时饱和引起的短时卡顿。我们采用了毫秒级（100Hz）的采样频率。更重要的是，我们确保了跨节点、跨子系统（CPU、GPU、网络）的指标时间戳是严格同步的（使用PTP或高精度NTP），只有这样，才能在后端分析中准确地构建跨硬件的因果关系链。

2.2 技术选型：轻量级代理与原生工具的组合拳

在技术选型上，我们摒弃了部署一套全新的、重量级的监控Agent的方案。我们的经验是，在已经布满各种Agent的生产环境中，增加一个“巨无霸”是运维团队的噩梦，也容易引入新的不稳定因素。

因此，我们选择了“轻量级Bash脚本胶水 + 原生性能工具”的路线。在每个计算节点上，我们部署的是一个用Bash编写的“采集协调器”。它本身几乎不消耗资源，它的核心工作是：

• 定时调度：以精确的间隔（如10毫秒）触发各个专业工具进行数据采集。
• 上下文注入：将当前运行的主要工作负载标识符（容器ID、进程组ID）写入环境变量或命令行参数。
• 数据规整：将不同工具输出的、格式各异的文本流，统一加上时间戳和上下文标签，写入结构化的临时日志文件（如每10秒滚动一个文件）。

这个设计的好处显而易见：稳定性高、开销极低、依赖清晰。我们依赖的工具全是Linux发行版或硬件厂商官方提供的最稳定组件：

• perf stat：采集CPU PMCs的绝对权威。它通过Linux内核的perf_event_open系统调用直接与CPU的PMU（性能监控单元）交互。
• turbostat：Intel/AMD CPU功耗和频率状态的“透视镜”。它能读出每个核心的C-state（休眠状态）、P-state（性能状态）、实际运行频率（Bzy_MHz）和封装功耗（PkgWatt）。
• nvidia-smi：NVIDIA GPU监控的事实标准。我们不仅查询utilization.gpu和memory.used，更关注ecc_error.corrected.volatile.total（易失性ECC纠错）和power.draw（实时功耗）。
• /proc文件系统：内核统计信息的宝库。我们定期读取/proc/stat（CPU时间）、/proc/meminfo（内存）、/proc/net/dev（网络接口）、/proc/diskstats（磁盘I/O）。
• nstat和ss：网络栈深度诊断工具。nstat查看TCP层的关键计数器，如TcpRetransSegs（重传报文数）；ss则能提供socket级别的状态和缓冲区信息。

这个“组合拳”方案，确保了我们在获得最深度的系统洞察的同时，最大程度地保持了与现有环境的兼容性和可维护性。

注意：使用perf采集硬件性能计数器通常需要CAP_SYS_ADMIN权限或直接以root身份运行。在生产环境中，这需要通过安全的特权容器或与节点管理员协作来部署。我们通常将采集脚本打包为一个带有必要权限的DaemonSet（K8s）或systemd服务。

3. 指标采集实战：如何高效、准确地抓取底层数据

理论说完了，我们来点干货。下面我将分子系统拆解我们的采集脚本关键片段，并分享其中踩过的坑和优化技巧。

3.1 CPU子系统：超越“%usr”和“%sys”

CPU利用率（%usr + %sys）是一个极其粗糙的指标。一个处于spin-lock（自旋锁）忙等待的线程，其用户态利用率是100%，但实际有效工作量为零。我们需要更精细的指标。

核心工具：perf stat与turbostat

我们的采集脚本会并发启动两个监控进程：

# 采集硬件性能计数器 (每100毫秒采样一次，持续1秒后输出) perf stat -e cycles,instructions,\ cpu/event=0xa3,umask=0x6,name=stalls_l3_miss/,\ # Intel L3未命中停顿周期 cpu/event=0xd0,umask=0x81,name=mem_loads/,\ # 内存读取次数 cpu/event=0xd0,umask=0x82,name=mem_stores/,\ # 内存写入次数 branch-instructions,branch-misses \ -a -I 100 --interval-count 10 -o /tmp/perf_metrics.$$.log & PERF_PID=$! # 采集CPU功耗与频率状态 (每1秒采样一次) turbostat --quiet --show Bzy_MHz,PkgWatt,Pkg%pc6,CoreTmp -i 1 > /tmp/turbo_metrics.$$.log & TURBO_PID=$! # 等待一个采集周期 sleep 1.1 # 发送中断信号，等待工具完成输出 kill -SIGINT $PERF_PID $TURBO_PID 2>/dev/null wait $PERF_PID $TURBO_PID 2>/dev/null

关键指标解读与避坑指南：

• IPC (Instructions Per Cycle)：通过cycles和instructions计数器计算得出。这是衡量CPU效率的黄金指标。IPC接近或大于1通常表示代码友好，流水线顺畅；IPC持续低于0.5则可能意味着内存访问瓶颈（频繁等待数据）或指令依赖严重。
  • 踩坑记录：虚拟化环境（如云虚拟机）下，perf采集的cycles可能受宿主调度影响而不准，计算出的IPC会有波动。此时需要结合turbostat的Bzy_MHz（实际频率）来综合判断。
• stalls_l3_miss：当数据不在L3缓存中，需要从内存读取时，CPU核心流水线停顿的周期数。这是诊断“内存墙”问题的直接证据。即使CPU利用率不高，但此值持续高位，也意味着应用是内存密集型，CPU在“空等”。
• Pkg%pc6：CPU封装处于深度节能状态（C6）的时间百分比。在服务器上，如果此值经常很高，而Bzy_MHz很低，可能触发了功耗或温度墙（Thermal Throttling），导致CPU无法睿频到最高频率，悄无声息地降低了算力。
• CoreTmp：核心温度。与PkgWatt（封装功耗）结合看，可以判断散热是否良好。温度过高会导致降频（Bzy_MHz下降），形成“发热 -> 降频 -> 算力降 -> 任务时间变长 -> 持续发热”的恶性循环。

3.2 GPU子系统：警惕“高利用率”陷阱

nvidia-smi显示的utilization.gpu是一个SM（流多处理器）活动性的估计值。但SM活动不等于有效计算。例如，当GPU在等待PCIe总线传输数据时，SM可能处于某种忙碌状态，但并未执行核心计算。

我们的采集命令更关注以下“健康指标”：

# 关键指标采集 nvidia-smi --query-gpu=timestamp,name,utilization.gpu,utilization.memory,\ memory.used,memory.total,power.draw,power.limit,\ temperature.gpu,clocks.current.graphics,clocks.current.memory,\ ecc_error.corrected.volatile.device_memory,\ ecc_error.corrected.volatile.l1_cache,\ ecc_error.corrected.volatile.l2_cache \ --format=csv -lms 100 -f /tmp/gpu_metrics.$$.log

关键指标解读与避坑指南：

• power.draw与power.limit：实时功耗与功耗上限。如果power.draw持续接近power.limit，GPU可能因功耗限制而无法运行在最高Boost频率上，性能受损。这是我们发现多卡训练时单卡性能不达标的常见原因——机柜电源或主板供电不足。
• ecc_error.corrected.volatile.*：易失性ECC纠错计数。这是GPU显存健康的“晴雨表”。偶尔的纠错是正常的，但如果纠错计数在短时间内持续、快速增长，这预示着显存硬件可能存在问题，或处于不稳定超频状态。高ECC纠错率会显著增加内存访问延迟，是“高GPU利用率，低训练吞吐”的隐形杀手之一。
• clocks.current.graphics：GPU的当前图形时钟（可近似看作计算核心频率）。与temperature.gpu结合，可以判断是否因温度过高发生了降频（Throttling）。

3.3 内存、网络与存储：寻找隐藏的瓶颈

• 内存：我们从/proc/meminfo获取MemAvailable（真正可用的内存），这比MemFree更有意义。同时，perf采集的mem_loads/mem_stores速率和stalls_l3_miss共同刻画了内存访问压力。
• 网络：/proc/net/dev提供接口级别的字节数、包数、错包/丢包数。但我们更看重nstat -s输出的TCP层指标，尤其是TcpRetransSegs。重传率的轻微上升（例如从0.01%到0.1%），在分布式训练的All-Reduce通信中就会被放大，导致整个迭代步的同步时间拉长。
• 存储：/proc/diskstats的time_spent_reading和time_spent_writing字段（单位毫秒）直接反映了I/O延迟。当检查点（Checkpoint）保存或数据集加载变慢时，这两个值是首要怀疑对象。

实操心得：时间戳同步跨工具采集的最大挑战是时间同步。我们采用的方法是：在每个采集循环开始时，由Bash协调器通过date +%s.%N获取一个高精度时间戳（MASTER_TS），然后将这个时间戳作为环境变量传递给所有子进程（perf,turbostat等），并要求每个工具在输出的每一行数据前都加上这个MASTER_TS。这样，尽管各工具采集有微小的时间差，但所有数据都关联到同一个逻辑时间点，保证了后续跨子系统关联分析的准确性。

4. 从原始指标到异常特征：特征工程的“炼金术”

采集到的原始时间序列数据是海量且高噪声的。直接把这些数据扔给异常检测算法，效果通常很差，且无法解释。因此，我们必须进行特征工程，将原始的“信号”提炼成有意义的“特征”。

我们的特征构建流程分为两步：派生指标计算和时间窗口特征提取。

4.1 构建派生指标：揭示系统内部状态

原始计数器很多是累积值（Cumulative Counter），如“自系统启动以来的总CPU周期数”。我们更关心其变化率。因此，第一步是计算各种派生指标：

1. 速率（Rate）：对任何累积计数器，计算其单位时间内的增量。例如，instructions的导数就是指令吞吐率（IPS）。
2. 比率（Ratio）：计算有意义的比率指标，这是性能分析的核心。
   • IPC (Instructions Per Cycle)=instructions/cycles
   • 缓存未命中率 (Cache Miss Ratio)=cache-misses/cache-references
   • 分支误预测率 (Branch Miss Prediction Ratio)=branch-misses/branch-instructions
   • 内存停滞周期占比=stalls_l3_miss/cycles
3. 利用率（Utilization）：虽然我们批评传统利用率，但计算更精细的利用率仍有价值。例如，内存带宽利用率可以通过(mem_loads + mem_stores) * 64 bytes / time_window / theoretical_bandwidth来估算。

这些派生指标将原始的硬件事件，转化为了反映系统“健康度”和“效率”的工程指标。

4.2 时间窗口特征提取：捕捉动态模式

单一时间点的指标值意义有限。异常往往表现为模式的变化。因此，我们对每个指标在滑动时间窗口（例如60秒）内提取一系列统计特征。我们使用了tsfresh这个强大的时间序列特征提取库。

对于一个指标在窗口内的序列，我们提取的特征包括但不限��：

• 基本统计量：均值、中位数、标准差、最大值、最小值、峰度、偏度。
• 时序特征：
  • autocorrelation__lag_1：一阶自相关系数。用于检测周期性的打破或趋势的突变。例如，CPU频率通常有波动，但其自相关性是稳定的。如果自相关性突然下降，可能表示调度器行为异常或负载突变。
  • value_count__value_0：序列中等于基线均值的次数占比。用于检测指标是否“卡”在某个异常值上。
  • c3__lag_1：一种非线性时序依赖度量，对发现复杂交互引发的异常更敏感。
• 变化特征：
  • mean_abs_change：绝对变化量的均值，反映波动剧烈程度。
  • variance_larger_than_standard_deviation：一个布尔特征，用于识别方差突增的情况。

例如，对于CPU_Busy%这个指标，我们不仅看它的平均值是否过高，更关注它在窗口内的__value__variance（方差）是否与历史基线有显著差异。一个方差突然变小的CPU_Busy%，可能意味着某个进程死锁或调度异常，导致CPU使用模式僵化。

特征筛选提取的特征维度会爆炸式增长（指标数 × 特征类型数）。我们必须进行筛选，只保留对区分“正常”与“异常”行为有用的特征。我们采用了组合策略：

1. 方差过滤：剔除在所有时间窗口上方差接近零的特征（常量特征无意义）。
2. 相关性过滤：剔除高度线性相关的特征，减少冗余。
3. 基于模型的重要性筛选：使用简单的随机森林或XGBoost模型，以窗口标签（正常/异常）为目标，计算特征重要性，保留Top-K个特征。

经过这个流程，我们将每秒数百个原始指标，转化为了一个维度在100-200左右的、富含信息的特征向量，供下游的异常检测模型使用。

5. 异常检测引擎：多模型融合与可解释性输出

我们并不追求一个“终极”的异常检测算法。在复杂的系统行为面前，任何单一模型都有其局限性。因此，我们采用了**多模型融合（Ensemble）**的策略，结合无监督与有监督方法的优点，并最终将结果转化为人类可读的“异常报告”。

5.1 三大无监督检测器及其分工

我们对每个时间窗口的特征向量，并行运行三种经典的无监督异常检测算法：

1. Z-Score 检测器：

   • 原理：假设特征服从正态分布，计算每个特征值距离其历史均值的标准差倍数。|Z| > 3通常被视为异常。
   • 擅长：检测单维度上极端偏离的点。例如，GPU_ecc_errors突然出现一个尖峰，CPU_PkgWatt异常低（可能掉电）。
   • 局限：无法处理特征间的相关性，且对数据分布假设较强。

2. 马氏距离（Mahalanobis Distance）检测器：

   • 原理：考虑特征间的协方差结构，计算特征向量到整个数据分布中心的“距离”。这个距离考虑了特征的相关性。
   • 擅长：检测多维度联合异常。例如，CPU_IPC轻微下降的同时mem_stalls轻微上升，单独看都没超阈值，但它们的组合模式偏离了历史正常模式，马氏距离就能捕捉到。
   • 局限：计算协方差矩阵的逆，在高维特征下可能不稳定，且对异常点本身敏感（需要用稳健的协方差估计，如最小协方差行列式MCD）。

3. 孤立森林（Isolation Forest）检测器：

   • 原理：随机选择特征和分割点来“隔离”数据点。异常点因为与主流群体不同，通常能被更少的步骤隔离出来。
   • 擅长：检测局部异常和新颖性（Novelty）。对于训练集中未出现过的、新的异常模式，孤立森林往往比基于距离的方法更敏感。
   • 局限：在高维稀疏数据上效果可能下降，且解释性较差。

实操心得：模型参数与在线更新

• Z-Score：我们使用滚动窗口（如过去6小时）的均值和标准差作为动态基线，以适应工作负载的阶段变化（如从数据预处理阶段进入训练阶段）。
• 马氏距离：我们每小时用过去一段时间的“正常”数据重新计算一次协方差矩阵，实现模型的在线更新。
• 孤立森林：我们定期（如每天）用过去24小时的“正常”数据重新训练一次森林，以吸收系统正常行为的缓慢漂移。

5.2 融合策略与可解释性报告

三个检测器会各自输出一个异常分数（或二值标签）。我们的融合策略很简单但有效：“多数投票”或“加权投票”。如果一个时间窗口被至少两个检测器标记为异常，则最终判定为异常。

但光说“异常”没用，运维人员需要知道“哪里异常”和“为什么异常”。这就是可解释性（Interpretability）的关键。我们的系统会自动生成类似下表的报告：

这份报告的价值在于：

1. 定位：直接指出是CPU、内存、网络还是存储的问题。
2. 定性：通过“方差”、“自相关”、“最大值”等特征类型，描述了异常的模式（是波动变了？还是出现尖峰？）。
3. 关联：引导运维人员去查看相关的原始指标（如报告中的“推断”部分），进行根因分析。

6. 实战部署与效果：在真实ML工作负载上的验证

为了验证我们框架的有效性，我们将其部署到了一个混合的CPU/GPU集群上，并监控了多种典型的机器学习工作负载，包括自然语言处理（NLP）和计算机视觉（CV）任务。软件环境基于容器化（Apptainer/Singularity），堆栈包括PyTorch、CUDA以及各种常见的优化库（如bitsandbytes、FlashAttention）。

6.1 监控配置与工作负载

我们统一了监控配置：所有节点以100Hz频率采集约700个原始指标。工作负载涵盖了从7B参数的大语言模型（如LLaMA-3-8B, Mistral-7B）到经典的CV模型（ResNet, VGG, ViT），任务包括文本分类、图像分类和分割。所有LLM均采用4-bit量化与LoRA进行高效微调，使用FSDP进行分布式训练。

我们故意注入了几类常见的“软故障”来测试系统：

1. 内存带宽竞争：在同一个NUMA节点上，同时运行一个内存带宽密集型测试程序（如stress-ng --vm-bytes）和BERT训练任务。
2. GPU ECC错误模拟：通过调整GPU显存时钟频率（轻微超频/降频），诱发可纠正的ECC错误。
3. 网络拥塞：使用tc（流量控制）工具在训练节点间引入微小的随机延迟和丢包。
4. CPU热节流：用cpulimit和stress工具让部分CPU核心持续高负载，观察散热不足时的降频行为。

6.2 检测结果与案例分��

我们的框架成功地在这些故障对训练任务产生显著性能下降（如迭代时间增加10%以上）之前，就发出了预警。以下是一个典型案例：

案例：隐蔽的GPU显存故障在一次持续的ViT模型训练中，GPU利用率仪表盘显示一切正常（持续在92%-96%）。然而，我们的系统在运行约2小时后，连续多个窗口触发了马氏距离和孤立森林异常警报。

• 主要异常特征：GPU_ecc_corrected_volatile_total的__value__maximum和__value__sum特征显著偏离基线。
• 关联指标：GPU_power_draw出现微小但持续的下降趋势，GPU_utilization_memory的波动性增加。
• 根因分析：检查物理节点日志，发现该GPU卡在近期确实记录过显存ECC警告。持续的训练负载和较高的显存温度，加剧了显存单元的不稳定性，导致纠错事件频率从每小时几次上升到每分钟几次。虽然训练没有崩溃，但频繁的ECC纠错引入了额外的延迟，导致训练吞吐量（samples/sec）下降了约5%。
• 行动：系统自动标记该GPU为“可疑”，并在任务调度器中降低其优先级。运维团队在训练间隙更换了该GPU卡，避免了后续更严重任务失败的风险。

这个案例凸显了低层指标的价值：在业务指标（训练速度）出现明显下滑之前，硬件健康指标已经发出了早期预警。

6.3 性能开销评估

这是所有监控系统必须回答的问题：你本身消耗了多少资源？我们的评估结果显示，在100Hz的采样频率下：

• CPU开销：每个节点上所有采集代理（perf,turbostat,nvidia-smi等）的总和，平均额外占用不到一个物理核心的3%。这主要得益于perf在系统级（-a）采样的高效性。
• 内存开销：Bash协调器和日志缓冲占用内存极少（<50MB）。主要的后处理（特征提取、异常检测）是在中心服务器进行的。
• 网络开销：原始指标数据量约为每个节点每秒100KB。经过压缩和选择性上传（如只上传特征或异常窗口的原始数据），对集群网络的冲击可忽略不计。
• 存储开销：原始日志按节点和时间分片，保留7天，总容量可控。特征和检测结果数据库是主要存储消耗点。

总体而言，低于0.5%的系统资源开销，换来了对潜在性能瓶颈和硬件故障的深度洞察能力，这笔交易在生产和研究环境中都是非常划算的。

7. 开源与复现：数据集与工具包

我们认为，系统性能研究需要可复现的基准。因此，我们将本项目的核心产出——监控数据集和全链路工具包——完全开源。

7.1 RevealTelemetry 数据集

我们将从多次受控实验中收集的时序数据整理成了一个开源数据集，发布在Hugging Face上。

数据集包含：

• 原始指标：超过10次不同ML工作负载运行中，以100Hz采集的、涵盖所有子系统的700+维时间序列。
• 精炼指标：通过我们特征选择管道筛选出的150个最具判别力和稳定性的指标子集。
• 标注窗口：滑动窗口（如60秒）提取的特征，以及Z-Score、马氏距离、孤立森林三种方法计算的异常分数和标签。
• 元数据：工作负载类型（如“LLaMA-3-8B fine-tuning”）、任务、硬件环境、模型架构等。

这个数据集可用于：

• 验证和比较不同的时间序列异常检测算法在系统监控场景下的效果。
• 研究不同ML工作负载（如Transformer vs CNN）对硬件资源的使用模式差异。
• 作为系统领域研究的标准基准。

7.2 RevealProfiling 工具包

我们同时开源了完整的采集与处理工具包。它被设计为模块化、可扩展和低侵入的。

工具包主要模块：

1. collectors/：包含所有Bash采集脚本，以及部署说明（如K8s DaemonSet YAML， systemd service文件）。
2. processor/：Python数据处理管道。包括原始日志解析器、派生指标计算器、基于tsfresh的特征提取模块，以及特征筛选代码。
3. detector/：异常检测引擎。实现了我们使用的三种无监督算法，以及简单的融合逻辑。
4. visualizer/：可视化工具。可以绘制子系统指标联动图、异常时间线、以及特征空间的UMAP/t-SNE降维投影图，帮助直观理解异常。

快速上手示例：

# 1. 部署采集器 (以单节点测试为例) cd collectors sudo ./deploy_standalone.sh --interval 100ms --output-dir /path/to/logs # 2. 在另一个终端运行你的工作负载，例如： # python train.py ... # 3. 工作负载结束后，停止采集器并处理数据 sudo ./stop_standalone.sh cd ../processor python process_logs.py --input /path/to/logs --output features.csv # 4. 运行异常检测 cd ../detector python detect.py --feature-file features.csv --model zscore,mahalanobis,iforest --output report.json # 5. 生成可视化报告 cd ../visualizer python plot_anomaly_timeline.py --report report.json --features features.csv

我们希望这个工具包能帮助更多的团队和研究者，以极低的成本为其ML基础设施或高性能计算环境增加一层深度可观测性，共同推动系统稳定性和计算效率的边界。