Glances, Guider, Neoss , MTR are four tools that provides operator-side, per-machine diagnostics — not fleet-wide observability platforms. They occupy the space between top/ss/traceroute and full enterprise stacks like Prometheus+Grafana or Datadog. You reach for them when you SSH into a misbehaving EC2 instance, debug your Linux workstation, or need quick evidence for an ISP support ticket.
Glances is the one that stretches furthest toward enterprise use: its client-server mode, web UI, and native export to InfluxDB/Prometheus/Elasticsearch mean you can wire it into an existing monitoring stack for a small fleet. But it has no concept of service meshes, pod autoscaling, or distributed traces — it remains a per-host tool. For Kubernetes, you would still need kubectl top, Prometheus with node-exporter, or a managed solution.
Guider, Neoss, and MTR are purely ad-hoc diagnostic tools. Guider is what you pull out when perf feels too raw and you need flame graphs, leak detection, or function profiling without stitching together five different tools. Neoss replaces the muscle memory of ss -tulnp with something interactive. MTR is the universal network path debugger, equally useful from your Mac, a jump box, or a production instance.
On macOS
Glances and MTR work on macOS via Homebrew. Guider and Neoss are Linux-only (Guider relies on
/proc,/sys, and ftrace; Neoss reads from/proc/net).
Glances
Glances is a Python-based, real-time system monitor with 50+ built-in plugins covering CPU, memory, disk I/O, filesystem, network interfaces, processes, sensors, GPU (NVIDIA/AMD), Docker containers, Wi-Fi signal, RAID arrays, and port availability. It auto-adapts its layout to terminal size and color-codes every metric against configurable thresholds (careful → warning → critical).
Modes of Operation
The tool runs in four distinct modes depending on the use case:
- Terminal mode (
glances) — the default interactive TUI - Web mode (
glances -w) — serves a dashboard athttp://<host>:61208 - Client-server mode — run
glances -son the target, connect withglances -c <IP>from your machine - Headless export mode — no UI, just streams metrics to a backend
Web mode is particularly useful on cloud instances where you can SSH-tunnel port 61208 and get a full dashboard in your browser without installing anything on your local machine.
Interactive Controls
While running in terminal or web mode, single-key commands reshape the view:
1 Toggle per-CPU core stats
2 Toggle left sidebar (network, disk, sensors)
3 Toggle quick-look bar (graphical CPU/MEM gauges)
5 Toggle the entire top bar
a Auto-sort processes (by CPU or MEM, whichever is hotter)
c / m / i Sort processes by CPU% / MEM% / I/O rate
p Sort processes by name
T Tree view (process hierarchy, like pstree)
Enter Filter process list with regex
e Extended info for selected process (open files, threads)
z Show/hide idle processes
d / f / n Toggle disk I/O / filesystem / network panels
b Switch network units between bytes and bits
The regex filter (Enter) is especially powerful on busy machines — type java|python to isolate only those processes.
Export and Integration
Glances can push metrics to external systems, which is where it bridges into lightweight enterprise use:
# Stream to InfluxDB v2 (for Grafana dashboards)
glances --export influxdb2
# Expose a Prometheus /metrics endpoint
glances --export prometheus
# Dump to CSV for post-hoc analysis
glances --export csv --export-csv-file /tmp/metrics.csv
# Push to Elasticsearch, Kafka, RabbitMQ, etc.
glances --export elasticsearchYou can also selectively disable expensive plugins on resource-constrained hosts:
glances --disable-plugin gpu,docker,wifiConfiguration
Thresholds and plugin behavior are controlled via ~/.config/glances/glances.conf:
[cpu]
careful=50
warning=70
critical=90
[memory]
careful=50
warning=70
critical=90
[ports]
# Monitor specific ports; shows UP/DOWN in the UI
port_1_host=mydb.internal
port_1_port=5432
port_1_description=PostgreSQLThe port monitoring feature turns Glances into a rudimentary uptime checker for the services a host depends on.
Guider
Where Glances answers “what is happening right now?”, Guider answers “why is it happening?” It is a single-binary performance analysis framework that consolidates the functionality of top, perf, strace, valgrind --tool=massif, taskset, chrt, and several visualization tools. It requires Linux (it reads from /proc, /sys, and the ftrace infrastructure in /sys/kernel/debug/tracing).
Monitoring
The top family of subcommands provides live dashboards scoped to different resource dimensions:
# System-wide: CPU, memory, I/O, network, all processes
guider top -a
# Single process, all threads visible
guider top -eT -g <PID>
# File I/O activity per process
guider ftop
# Network socket activity per process
guider ntop
# Container-level resource usage
guider ctop
# Working set size analysis (actual resident pages, not just RSS)
guider wtopThe -g flag accepts PIDs, process names, or comma-separated lists. Add -o report.out to any command to persist the data for later visualization.
Profiling and Tracing
Profiling aggregates statistics over a sampling window; tracing captures every event with timestamps. Tracing requires root and adequate ftrace buffer:
# Increase trace buffer (default is often too small)
echo 40960 | sudo tee /sys/kernel/debug/tracing/buffer_size_kb# Profile: which functions consume the most CPU in a process?
guider funcprofile -g <PID>
# Profile: which files does a process access, how often, how much I/O?
guider fileprofile -g <PID>
# Trace: every memory allocation, flagging leaks
sudo guider leaktrace -g <PID>
# Trace: all function calls and returns (kernel-level)
sudo guider functrace -g <PID>
# Trace: signal delivery (useful for debugging SIGPIPE, SIGSEGV, etc.)
sudo guider sigtrace -g <PID>
# Trace: system calls (like strace but integrated with the rest of Guider)
sudo guider sytrace -g <PID>Tracing overhead
functraceandleaktraceinstrument the kernel tracing subsystem and can impose significant overhead on hot paths. Use them during dedicated debugging sessions, not on production traffic under load.
Visualization
Any data collected with -o can be turned into graphs. Guider generates these as image files without needing a browser or notebook:
guider draw -t flame -i trace_data.out # Flame graph from function trace
guider draw -t line -i top_data.out # Time-series line graph
guider draw -t stack -i top_data.out # Stacked area (CPU per process over time)
guider draw -t bar -i top_data.out # Bar chart comparison
guider draw -t histogram -i top_data.out # Distribution histogram
guider draw -t violin -i top_data.out # Violin plot for latency distributionsThe flame graph generation is particularly valuable — you get perf record + FlameGraph/stackcollapse + flamegraph.pl in a single command.
Process Control
Guider can actively change process behavior, not just observe it:
# Pin a process to specific CPU cores
guider cpuset -g <PID> -c 0,2
# Set real-time FIFO scheduling with priority 50
guider sched -g <PID> -p fifo -v 50
# Set I/O scheduling priority
guider ioprio -g <PID>
# Cap memory usage
guider memset -g <PID> -l 512MThis is useful on shared machines where a noisy neighbor is degrading your workload and you need immediate relief before a proper fix.
Stress Testing
Built-in benchmarks let you stress individual subsystems to establish baselines or reproduce issues:
guider cputest # CPU-bound stress
guider memtest # Memory bandwidth and integrity
guider storagetest # Disk I/O throughput
guider nettest # Network throughputNeoss
Neoss is a Node.js-based TUI that replaces ss and netstat with an interactive, navigable view of all TCP and UDP sockets on a Linux host. It reads from /proc/net and enriches raw socket data with process information, DNS resolution, and contextual explanations.
Interactive Exploration
Launch with neoss (or npx neoss for one-off use). The TUI displays a table with columns for protocol, state, local/remote address and port, PID, process name, and user. Navigation:
↑/↓/←/→ Navigate cells
s Sort by the currently selected column
r Refresh socket data
Enter Open contextual detail for the selected cell
q / Esc Quit
The contextual detail on Enter is the distinguishing feature. Selecting a cell and pressing Enter produces different information depending on what you selected:
- State cell (e.g.,
CLOSE_WAIT) → explains what the TCP state means and common causes - Port cell (e.g.,
443) → maps to the well-known service (HTTPS) with a description - Remote address cell → performs reverse DNS lookup
- Process cell → shows full command line, UID, owning user
This makes Neoss a learning tool as much as a diagnostic one. Instead of memorizing TCP state diagrams, you can explore them in context.
When to Use Neoss vs ss
ss remains superior for scripting, filtering expressions (ss -tnp state established '( dport = :443 )'), and environments where you cannot install npm packages. Neoss is better when you are interactively exploring connections on a machine — hunting for which process holds a port, understanding why sockets are stuck in CLOSE_WAIT, or quickly sorting by remote address to spot unexpected connections.
MTR
MTR sends continuous probes to a destination and displays per-hop latency and packet loss in real time. Unlike traceroute (which runs once and exits) or ping (which tests only the endpoint), MTR gives you a sustained, hop-by-hop view of the entire network path.
Core Usage
# Interactive real-time view
mtr google.com
# Static report (non-interactive, great for sharing)
mtr -rw -c 100 google.com
# Show both hostnames and IPs simultaneously
mtr -b google.com
# Numeric only, skip DNS (faster startup)
mtr -n google.comProtocol and Probe Options
By default MTR uses ICMP echo, which is frequently rate-limited or blocked by intermediate routers. Switching protocols often reveals a clearer picture:
# TCP SYN probes (bypasses ICMP filtering)
mtr -T google.com
# TCP to a specific port (test the actual path your traffic takes)
mtr -T -P 443 google.com
# UDP probes
mtr -u google.com
# Custom packet size (detect MTU/fragmentation issues)
mtr -s 1400 google.comTCP mode requires root
mtr -Tneeds raw socket access. Run withsudoor grantCAP_NET_RAW.
Timing and scope controls:
mtr -c 200 google.com # Run exactly 200 cycles then stop
mtr -i 0.5 google.com # 500ms between probes (default is 1s)
mtr -m 20 google.com # Max 20 hops (default is 30)Output formats for automation:
mtr -j -c 50 google.com > report.json # JSON
mtr -C -c 50 google.com > report.csv # CSVReading Results
A typical MTR output looks like:
Host Loss% Snt Last Avg Best Wrst StDev
1. gateway.local 0.0% 100 1.2 1.1 0.8 3.2 0.4
2. isp-router.net 0.0% 100 8.5 9.2 7.1 15.3 1.8
3. core-router.isp.net 4.0% 100 12.3 13.1 11.2 25.6 3.1
4. peer-exchange.net 4.0% 100 18.7 19.5 17.2 35.8 4.2
5. google-edge.net 4.0% 100 20.1 21.3 18.5 40.1 5.3
Loss% is the percentage of probes that received no reply. Avg is mean round-trip latency in milliseconds. StDev measures jitter — high StDev means inconsistent latency, which degrades real-time protocols (VoIP, WebRTC) more than raw throughput.
Three patterns matter when interpreting results:
Pattern 1: Loss at one hop, no loss at subsequent hops. This is almost always ICMP rate-limiting by that router, not real packet loss. The router deprioritizes responding to probes while still forwarding your actual traffic. Ignore it.
Pattern 2: Loss appears at hop N and persists through all subsequent hops. This indicates real packet loss originating at hop N. The problem is either that device or the link immediately before it.
Pattern 3: A sudden latency jump between two consecutive hops (50-150ms). This typically means the packets are crossing a geographic boundary — a transoceanic cable, a satellite link, or a long-haul backbone segment. This is expected and not a problem unless the jump is larger than the geography warrants.
Filing network tickets
When contacting an ISP or cloud provider about connectivity issues, attach the output of
mtr -rw -c 500 <target>from both directions if possible (run it on the remote end back to you as well). The-wflag prevents hostname truncation. 500 cycles provides a statistically meaningful sample.
Quick Reference
| Situation | Tool |
|---|---|
| What’s eating CPU/RAM right now? | glances |
| Dashboard for a remote host via browser | glances -w |
| Stream host metrics to Prometheus/Grafana | glances --export prometheus |
| Find which functions are slow in my process | guider funcprofile -g <PID> |
| Detect a memory leak | sudo guider leaktrace -g <PID> |
| Generate a flame graph | guider draw -t flame -i data.out |
| Pin a process to specific CPU cores | guider cpuset -g <PID> -c 0,2 |
| Explore active network connections interactively | neoss |
| Find which process holds a port | neoss → sort by port |
| Diagnose where packets are dropping on a path | mtr <host> |
| Prove to ISP/cloud provider the problem is theirs | mtr -rw -c 500 <host> |
| Test network path when ICMP is blocked | mtr -T -P 443 <host> |