GASP Diagnostics

Enables comprehensive Linux system diagnostics using GASP's AI-optimized monitoring output. Actively fetches metrics from hosts and provides intelligent analysis with context-aware interpretation.

Fetching GASP Metrics

When user mentions a host or requests a system check:

1. •

   Fetch the metrics endpoint

   code

   web_fetch("http://{hostname}:8080/metrics")
   

2. •

   Hostname formats supported

   • •mDNS/local: accelerated.local, hyperion.local
   • •DNS names: proxmox1, dev-server, workstation
   • •IP addresses: 192.168.1.100
3. •

   Default port: 8080 (unless user specifies otherwise)

4. •

   Error handling

   • •Host unreachable: Inform user, suggest checking if GASP is running
   • •Port closed/refused: Try suggesting systemctl status gasp on the host
   • •JSON parse error: GASP may not be installed or wrong endpoint
   • •Timeout: Network issue or host down
5. •

   Multi-host queries: If user mentions multiple hosts, fetch each in sequence and compare

Quick Diagnosis Workflow

For any system check request:

1. •Fetch metrics from specified host(s)
2. •Check summary first: Look at summary.health and summary.concerns[]
3. •Identify issues using metric correlations below
4. •Report findings with severity and specific recommendations

Trigger Examples

These user messages should trigger this skill and active fetching:

• •"Check hyperion for me"
• •"What's going on with accelerated.local?"
• •"Is proxmox1 having issues?"
• •"Compare hyperion and proxmox1"
• •"Why is my system slow?" (fetch localhost)
• •"Diagnose 192.168.1.50"
• •"Check all my proxmox nodes"

Metric Interpretation

Health Summary

• •summary.health: Quick assessment
  • •"healthy": No action needed
  • •"degraded": Issues present but not critical
  • •"critical": Immediate attention required
• •summary.concerns[]: Pre-analyzed issues to investigate first
• •summary.recent_changes[]: Context for current state

CPU Analysis

Load ratio = load_avg_1m / cores:

• •< 0.7: Normal usage
• •0.7-1.0: Busy but healthy
• •1.0-2.0: Saturated (may cause slowness)
• •> 2.0: Severe overload

Key indicators:

• •trend: "increasing" is concerning even if current load is acceptable
• •baseline_load: Delta from baseline is more important than absolute value
• •top_processes[]: Check for unexpected CPU hogs

Memory Analysis

Red flags (priority order):

1. •oom_kills_recent > 0: CRITICAL - system killed processes, find memory hog immediately
2. •swap_used_mb > 0: Performance degradation in progress
3. •pressure_pct > 5%: System struggling with memory contention
4. •usage_percent > 90%: Getting close to limits

Important: Linux uses memory for cache, so high usage_percent alone is normal. Focus on pressure and swap.

Disk I/O

Saturation indicators:

• •io_wait_ms > 10: Significant disk bottleneck
• •queue_depth consistently high: Disk can't keep up
• •High read_iops or write_iops with slow response: Disk performance issue

Storage capacity:

• •usage_percent > 90%: Running out of space
• •usage_percent > 95%: Critical - will cause failures soon

Network

• •rx_bytes_per_sec / tx_bytes_per_sec: Check for unexpected traffic spikes
• •errors > 0 or drops > 0: Network hardware/configuration issue
• •Large number of time_wait connections: May indicate connection leak

Process Intelligence

• •zombie > 0: Process management bug (usually benign but indicates issue)
• •Processes in D state: Stuck in uninterruptible sleep (disk or kernel issue)
• •new_since_last[]: Check for unexpected process spawning

Systemd Services

• •units_failed > 0: Check failed_units[] array
• •recent_restarts[]: May indicate instability

Log Summary

• •errors_last_interval: Elevated error rate indicates problems
• •message_rate_per_min: Spikes suggest logging storm or serious issue
• •Review recent_errors[] for specific problems

Desktop Metrics (when present)

• •gpu.utilization_pct vs CPU: Identify GPU-bound vs CPU-bound workloads
• •gpu.temperature_c > 85: Thermal throttling likely
• •active_window: Provides context for resource usage

Common System Patterns

Development Workstation (Expected)

• •High memory usage from IDEs, browsers
• •Firefox/Chrome often in top memory consumers
• •Docker daemon using CPU/memory
• •VSCode, JetBrains IDEs in top processes
• •Baseline load: 10-30% of cores

Container Host (Expected)

• •Elevated baseline load (many processes)
• •dockerd/containerd in top processes
• •50-70% memory usage normal
• •Many processes in top list

Proxmox/Virtualization Host (Expected)

• •Baseline load proportional to VM count
• •Consistent low-level resource usage
• •~2GB overhead for Proxmox itself
• •Multiple QEMU/KVM processes

GPU Workload (Expected)

• •High GPU utilization with lower CPU
• •Significant GPU memory usage
• •Common for: rendering, ML inference, gaming

Multi-Host Analysis

When checking multiple hosts:

1. •Fetch all hosts first (parallel thinking)
2. •Compare baselines: Identify outliers
3. •Look for correlations: Network event vs individual host issue
4. •Check recent_changes: Migrations, deployments, package updates
5. •Identify the odd one out: Which host differs from the pattern?

Example analysis pattern:

Host 1: Load 2.1/8 cores (26%), normal
Host 2: Load 7.8/8 cores (97%), ATTENTION NEEDED  ← outlier
Host 3: Load 1.9/8 cores (24%), normal

Focus on Host 2 - investigate top_processes

Diagnosis Strategies

"System is slow"

1. •Check load ratio (CPU saturation?)
2. •Check io_wait (disk bottleneck?)
3. •Check memory pressure (swapping?)
4. •Identify top consumer in relevant category
5. •Assess if consumption is expected for that process

"High memory usage"

1. •First: Check pressure_pct (real issue or just cache?)
2. •Check swap_used_mb (actual problem?)
3. •Find top memory consumers
4. •Check process uptime (leak or normal?)
5. •Compare to baseline (delta more important than absolute)

"Unexpected behavior"

1. •Check recent_changes for clues
2. •Review systemd failed units
3. •Check recent_errors in logs
4. •Look for new processes since last snapshot
5. •Compare current metrics to baseline

Reporting Guidelines

When reporting findings:

1. •Start with verdict: "Healthy", "Issue found", "Critical problem"
2. •Be specific: Name the process/service causing issues
3. •Provide context: Is this expected for this host type?
4. •Give actionable recommendations: What should user do?
5. •Include relevant metrics: Back up findings with data

Good example:

"Issue found on accelerated.local: Memory pressure at 8.2%. The postgres container started swapping 2 hours ago and is now using 12GB RAM (up from 4GB baseline). This likely indicates a query leak. Recommend checking recent queries and restarting the container."

Bad example:

"Memory usage is high. You might want to look into it."

Advanced Diagnostics

For complex issues or when initial analysis is unclear, consult:

• •references/diagnostic-workflows.md - Detailed diagnostic procedures
• •references/common-patterns.md - Infrastructure-specific patterns

Using with Provided JSON

If user pastes GASP JSON instead of requesting a fetch:

1. •Analyze the provided JSON using all guidance above
2. •Don't attempt to fetch (data already provided)
3. •Apply same interpretation and reporting guidelines