Automated Linux Server Diagnostics: From Manual Checks to eBPF Analysis in Minutes
Developers and sysadmins with Linux experience know the drill: a "server is sluggish" complaint means running the usual suspects — top, vmstat, iostat, ss. That's Tier 1 diagnostics, taking 20–40 minutes. Next comes diving into eBPF tools like runqlat, biolatency, tcpretrans from Brendan Gregg. The catch: rare incidents erode your memory, so you're constantly Googling /proc files, sysctl params, and BCC-tools syntax.
AI (ChatGPT, Claude) simplifies log analysis but doesn't handle data collection. Neural networks won't run tools on their own or connect the dots between metrics like PruneCalled and TCP memory. You need a structured data collector to feed into AI.
Melisai: Data Collection into a Single JSON
Melisai is a static Go binary with no dependencies. Launch it with:
sudo melisai collect --profile quick -o report.json
Quick mode takes 10 seconds, deep mode 60 seconds. Output: JSON with CPU, memory, disk, network, processes, containers, and GPU metrics.
What it collects:
- Tier 1: procfs, sysfs,
ss,ethtool,nvidia-smi(no root needed). - Tier 2: 67 BCC/eBPF tools (
runqlat,biolatency,tcpretrans, etc., requires root + bcc-tools). - Tier 3: native eBPF via cilium/ebpf (root + kernel ≥5.8 with BTF).
Fallback: If Tier 2/3 unavailable, it runs Tier 1.
Two-Phase Collection and Rate Metrics
To avoid the observer effect, collection is split:
- Baseline: Tier 1 metrics (CPU, memory, I/O, network).
- eBPF: BCC-tools run after baseline.
Rate-based calculations: deltas between measurements. Not cumulative counters (200-day uptime = softnet_dropped=5000 is normal), but rates (softnet_drop_rate=50/sec flags an anomaly).
37 anomaly rules based on Gregg and production practices:
| Category | Example Thresholds |
|----------|--------------------|
| CPU | util>95%, PSI>5%, runqlat p99>50ms |
| Memory | direct reclaim>10/s, THP splits>1/s, NUMA miss>5% |
| Disk | util>90%, latency>50ms |
| Network | retransmits>50/s, conntrack>90% |
| GPU | NUMA mismatch GPU-NIC |
Case Study: Cascade Failure on a Docker Host
Production setup: 8 cores, 32GB RAM, HDD RAID. Symptoms: overall slowdown.
sudo melisai collect --profile deep --ai-prompt -o report.json
Results (60 sec):
Health Score: 46/100
Anomalies:
[CRITICAL] tcp_retransmits 134/sec
[WARNING] disk_util 80.5%
[WARNING] cpu_psi 17.6%
[WARNING] io_psi 12.8%
[WARNING] disk_latency 12.1ms
[WARNING] tcp_close_wait 1 socket
Cascade:
- HDD p99=49ms → Block I/O latency (
biolatency). - PruneCalled=105 → TCP buffers trimmed (memory pressure).
- TCP retransmits=31/s → Packet loss inside the server.
- WireGuard tx_dropped=226k → VPN tunnel suffers.
Root cause: HDD bottleneck. Recommendation: sysctl -w net.ipv4.tcp_mem='1048576 2097152 4194304'.
AI Integration via MCP
Built-in MCP server for Claude Desktop/Cursor:
{
"mcpServers": {
"melisai": {
"command": "ssh",
"args": ["root@server", "/usr/local/bin/melisai", "mcp"]
}
}
}
AI calls:
get_health— score + anomalies.explain_anomaly— root cause + fix commands.collect_metrics— full report with histograms.
JSON includes ai_context.prompt with 27 anti-patterns.
Recommendations and Limits
Recommendations are ready-to-run commands:
{
"type": "fix",
"title": "TCP memory pressure (PruneCalled)",
"commands": ["sysctl -w net.ipv4.tcp_mem='1048576 2097152 4194304'"],
"evidence": "PruneCalled=105"
}
Limits:
- Not monitoring (snapshots, not Prometheus).
- Not alerting (on-demand/cron only).
- Not app profiling (
pproffor that). - NVIDIA GPU only (ROCm on roadmap).
Installation and Building
curl -sSL https://melisai.dev/install | sh
Build:
GOOS=linux GOARCH=amd64 CGO_ENABLED=0 go build -o melisai ./cmd/melisai/
Apache 2.0.
Key Takeaways
- Collects 67 eBPF tools + Tier 1 in 10–60 sec into structured JSON.
- Rate metrics eliminate false positives on long-uptime servers.
- 37 anomaly rules + ready sysctl commands.
- MCP integration: AI analyzes directly, no copy-paste.
- Two-phase collection minimizes observer effect.
— Editorial Team
No comments yet.