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

   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