⚡

GASP诊断助手Skill gasp-diagnostics

GASP诊断助手是一个基于AI的Linux系统性能监控与诊断工具，能够主动获取主机指标数据，提供智能化的系统健康分析、性能瓶颈识别和问题解决方案。适用于系统管理员、DevOps工程师和IT运维人员，帮助快速定位CPU、内存、磁盘、网络等系统资源问题，并提供可操作的建议。关键词：Linux系统监控，性能诊断，AI运维，GASP工具，系统健康检查，服务器管理，自动化运维，指标分析。

Docker/K8s 0 次安装 0 次浏览 更新于 3/1/2026

name: gasp-diagnostics description: 使用GASP（通用AI专用进程监控器）进行系统诊断。当用户询问Linux系统性能、请求系统检查、提及GASP、要求诊断主机或说类似“检查我的系统”或“[主机名]有什么问题”时使用。可以通过HTTP主动从主机获取GASP指标或解释提供的JSON输出。

GASP诊断

使用GASP的AI优化监控输出实现全面的Linux系统诊断。主动从主机获取指标并提供具有上下文感知的智能分析。

获取GASP指标

当用户提及主机或请求系统检查时：

  1. 获取指标端点

    web_fetch("http://{主机名}:8080/metrics")

  2. 支持的主机名格式

    • mDNS/本地：accelerated.local、hyperion.local
    • DNS名称：proxmox1、dev-server、workstation
    • IP地址：192.168.1.100

  3. 默认端口：8080（除非用户另行指定）

  4. 错误处理

    • 主机无法访问：通知用户，建议检查GASP是否正在运行
    • 端口关闭/拒绝：尝试建议在主机上运行systemctl status gasp
    • JSON解析错误：GASP可能未安装或端点错误
    • 超时：网络问题或主机宕机

  5. 多主机查询：如果用户提及多个主机，按顺序获取每个主机并进行比较

快速诊断工作流

对于任何系统检查请求：

  1. 获取指定主机（们）的指标
  2. 先检查摘要：查看summary.health和summary.concerns[]
  3. 使用以下指标关联识别问题
  4. 报告发现的问题，包括严重程度和具体建议

触发示例

以下用户消息应触发此技能并主动获取：

  • “帮我检查hyperion”
  • “accelerated.local怎么了？”
  • “proxmox1有问题吗？”
  • “比较hyperion和proxmox1”
  • “为什么我的系统很慢？”（获取localhost）
  • “诊断192.168.1.50”
  • “检查我所有的proxmox节点”

指标解释

健康摘要

  • summary.health：快速评估
    • “healthy”：无需操作
    • “degraded”：存在问题但不严重
    • “critical”：需要立即关注
  • summary.concerns[]：预先分析的问题，应首先调查
  • summary.recent_changes[]：当前状态的上下文

CPU分析

负载率 = load_avg_1m / 核心数：

  • < 0.7：正常使用
  • 0.7-1.0：繁忙但健康
  • 1.0-2.0：饱和（可能导致变慢）

  • 2.0：严重过载

关键指标：

  • trend：“increasing”即使当前负载可接受也值得关注
  • baseline_load：与基线的差异比绝对值更重要
  • top_processes[]：检查意外的CPU消耗大户

内存分析

红色标志（优先级顺序）：

  1. oom_kills_recent > 0：严重 - 系统杀死了进程，立即查找内存消耗大户
  2. swap_used_mb > 0：性能正在下降
  3. pressure_pct > 5%：系统正在处理内存争用
  4. usage_percent > 90%：接近限制

重要：Linux使用内存作为缓存，因此仅usage_percent高是正常的。关注压力和交换。

磁盘I/O

饱和指标：

  • io_wait_ms > 10：显著的磁盘瓶颈
  • queue_depth持续高：磁盘跟不上
  • 高read_iops或write_iops且响应慢：磁盘性能问题

存储容量：

  • usage_percent > 90%：空间不足
  • usage_percent > 95%：严重 - 很快会导致故障

网络

  • rx_bytes_per_sec / tx_bytes_per_sec：检查意外的流量峰值
  • errors > 0或drops > 0：网络硬件/配置问题
  • 大量time_wait连接：可能表示连接泄漏

进程智能

  • zombie > 0：进程管理错误（通常无害但表明问题）
  • 处于D状态的进程：卡在不可中断睡眠（磁盘或内核问题）
  • new_since_last[]：检查意外的进程生成

Systemd服务

  • units_failed > 0：检查failed_units[]数组
  • recent_restarts[]：可能表示不稳定

日志摘要

  • errors_last_interval：错误率升高表明问题
  • message_rate_per_min：峰值表明日志风暴或严重问题
  • 查看recent_errors[]了解具体问题

桌面指标（存在时）

  • gpu.utilization_pct vs CPU：识别GPU绑定与CPU绑定的工作负载
  • gpu.temperature_c > 85：可能发生热节流
  • active_window：提供资源使用的上下文

常见系统模式

开发工作站（预期）

  • IDE、浏览器导致高内存使用
  • Firefox/Chrome通常是内存消耗大户
  • Docker守护进程使用CPU/内存
  • VSCode、JetBrains IDE在顶级进程中
  • 基线负载：核心的10-30%

容器主机（预期）

  • 基线负载升高（许多进程）
  • dockerd/containerd在顶级进程中
  • 50-70%内存使用正常
  • 顶级列表中有许多进程

Proxmox/虚拟化主机（预期）

  • 基线负载与VM数量成比例
  • 一致的低级资源使用
  • Proxmox本身约2GB开销
  • 多个QEMU/KVM进程

GPU工作负载（预期）

  • GPU利用率高，CPU利用率低
  • 显著的GPU内存使用
  • 常见于：渲染、ML推理、游戏

多主机分析

检查多个主机时：

  1. 首先获取所有主机（并行思考）
  2. 比较基线：识别异常值
  3. 寻找关联：网络事件与单个主机问题
  4. 检查recent_changes：迁移、部署、包更新
  5. 识别异常值：哪个主机与模式不同？

示例分析模式：

主机1：负载2.1/8核心（26%），正常
主机2：负载7.8/8核心（97%），需要关注 ← 异常值
主机3：负载1.9/8核心（24%），正常

关注主机2 - 调查top_processes

诊断策略

“系统很慢”

  1. 检查负载率（CPU饱和？）
  2. 检查io_wait（磁盘瓶颈？）
  3. 检查内存压力（交换？）
  4. 识别相关类别的顶级消费者
  5. 评估该进程的消耗是否预期

“高内存使用”

  1. 首先：检查pressure_pct（真实问题还是只是缓存？）
  2. 检查swap_used_mb（实际问题？）
  3. 查找顶级内存消费者
  4. 检查进程运行时间（泄漏还是正常？）
  5. 与基线比较（差异比绝对值更重要）

“意外行为”

  1. 检查recent_changes寻找线索
  2. 查看systemd失败单元
  3. 检查日志中的recent_errors
  4. 查找自上次快照以来的新进程
  5. 将当前指标与基线比较

报告指南

报告发现时：

  1. 从结论开始：“健康”、“发现问题”、“严重问题”
  2. 具体说明：命名导致问题的进程/服务
  3. 提供上下文：这对于此主机类型是否预期？
  4. 给出可操作建议：用户应该做什么？
  5. 包含相关指标：用数据支持发现

良好示例：

“在accelerated.local上发现问题：内存压力为8.2%。postgres容器2小时前开始交换，现在使用12GB RAM（基线为4GB）。这可能表示查询泄漏。建议检查最近的查询并重启容器。”

不良示例：

“内存使用很高。你可能想看看。”

高级诊断

对于复杂问题或初始分析不明确时，请参考：

使用提供的JSON

如果用户粘贴GASP JSON而不是请求获取：

  1. 使用上述所有指南分析提供的JSON
  2. 不要尝试获取（数据已提供）
  3. 应用相同的解释和报告指南