Configuring Agent Metrics

Server Scout's monitoring agent is designed to be lightweight and efficient, which means not every available metric is enabled by default. This guide will show you how to customise which metrics your agent collects and how often it gathers them.

Understanding Default Behaviour

By default, Server Scout enables only the most essential metrics to minimise system overhead whilst providing meaningful insights. The agent focuses on core performance indicators like CPU usage, memory consumption, and disk space—metrics that matter for virtually every server.

However, different server roles have different monitoring requirements. A database server might need detailed I/O metrics, whilst a web server might benefit from TCP connection monitoring. Understanding how to configure these options ensures you get the data you need without unnecessary overhead.

Using the Interactive Configuration Menu

The simplest way to configure metrics is through the built-in interactive menu:

sudo scout --configure

This launches a user-friendly interface that displays all available metrics organised by collection frequency. You can toggle metrics on or off using simple keystrokes, and the interface shows you exactly what each metric monitors.

The interactive menu is particularly useful when you're first setting up monitoring or experimenting with different configurations, as it provides descriptions and lets you see the impact of your choices immediately.

Manual Configuration via scout.conf

For automated deployments or precise control, you can edit the configuration file directly:

sudo nano /etc/scout/scout.conf

The configuration uses simple key=value pairs. Each metric can be set to true or false:

cpu_iowait=true
cpu_steal=false
net_errors=true
services=true

This approach is ideal for configuration management systems like Ansible or when deploying identical configurations across multiple servers.

Available Metrics and Collection Schedules

Server Scout organises metrics into five collection tiers based on how frequently the data changes and its importance for immediate alerting:

Fast (5 seconds): Core performance metrics like CPU usage, memory, and basic disk statistics that can change rapidly and require immediate attention.

Medium (30 seconds): Network statistics (neterrors), system load averages (load5m, load15m), process counts (procsrunning, procsblocked), and resource-intensive metrics like topprocesses.

Slow (5 minutes): File system checks (multimount, fsreadonly), service monitoring (services), system health indicators (zombiecount, oomkills), and detailed I/O metrics (ioread, iowrite).

Glacial (1 hour): Hardware monitoring (cputemp), security metrics (entropy), detailed connection statistics (tcpconnections), and system internals (context_switches).

Daily (24 hours): Long-term maintenance indicators like packageupdates, rebootrequired, and uptime_seconds that change infrequently but are important for system administration.

Choosing Metrics for Different Server Roles

Web Servers typically benefit from enabling tcpconnections, neterrors, and context_switches to monitor traffic patterns and connection handling.

Database Servers should enable ioread, iowrite, cpuiowait, and procsblocked to track storage performance and query processing.

Virtualised Environments running on shared infrastructure should enable cpu_steal to monitor hypervisor resource contention.

Critical Production Systems might want services, rebootrequired, and packageupdates for comprehensive health monitoring.

Resource-Constrained Servers should be selective, focusing only on metrics directly relevant to their primary function to minimise monitoring overhead.

Performance Considerations

Each enabled metric consumes small amounts of CPU, memory, and network bandwidth. The cumulative effect can be significant on resource-constrained systems or when monitoring hundreds of servers.

Metrics like topprocesses and tcpconnections are more resource-intensive than basic counters. Enable them only when their data provides actionable insights for your specific environment.

Applying Configuration Changes

After modifying your configuration, restart the agent to apply changes:

sudo systemctl restart scout-agent

The new configuration takes effect immediately, and you'll see the updated metrics in your Server Scout dashboard within the next collection cycle.