Understanding the Plugin Architecture

Server Scout's plugin architecture provides a flexible and extensible way to monitor various services and applications on your Linux servers. By understanding how this system works, you can better configure your monitoring setup and troubleshoot any issues that may arise.

Core Plugin Framework

Every Server Scout plugin follows a standardised structure built around three essential functions that work together to provide seamless monitoring capabilities.

The Three Required Functions

detect() This function determines whether the monitored software or service is present on the system. It performs quick checks such as verifying if processes are running, configuration files exist, or binaries are available. The function returns 0 if the software is detected and available for monitoring, or a non-zero value if it's not present.

collect() Once a plugin detects that its target software is available, the collect function gathers the relevant metrics and performance data. This might include parsing log files, querying service APIs, reading system files, or executing commands to retrieve status information.

json() The final function structures all collected data into a standardised JSON format that Server Scout can process and transmit to the monitoring dashboard. This ensures consistent data formatting across all plugins.

Here's a basic example of how these functions work together:

# Plugin checks if nginx is running
detect() {
    pgrep nginx >/dev/null 2>&1
    return $?
}

# Collects nginx statistics
collect() {
    curl -s http://localhost/nginx_status
}

# Formats output as JSON
json() {
    echo '{"active_connections": 42, "requests_per_second": 15.3}'
}

Plugin Tiers and Collection Frequency

The PLUGIN_TIER declaration within each plugin controls how frequently data collection occurs. This system aligns with Server Scout's five-tier scheduling system:

• Tier 1: Critical metrics collected every 30 seconds
• Tier 2: Important metrics collected every 2 minutes
• Tier 3: Standard metrics collected every 5 minutes
• Tier 4: Detailed metrics collected every 15 minutes
• Tier 5: Historical metrics collected every 30 minutes

You can specify the tier by adding this declaration to your plugin:

PLUGIN_TIER=3

Choose your tier based on how critical the monitored service is and how quickly you need to detect issues. Database plugins might use Tier 1 or 2, whilst backup job monitoring might use Tier 4 or 5.

Auto-Discovery and Plugin Management

Server Scout automatically discovers and loads plugins from the plugins.d/ directory within your agent installation. When the agent starts, it scans this directory for executable files and attempts to run their detect functions. Successfully detected plugins are then scheduled according to their tier settings.

This auto-discovery mechanism means you can simply drop new plugins into the directory and restart the agent to begin monitoring additional services.

Disabling Specific Plugins

Sometimes you may want to prevent certain plugins from running, even if their target software is present. You can disable specific plugins through the agent configuration file by adding them to the disabled plugins list:

[plugins]
disabled = mysql,redis,custom_app

This approach is particularly useful when you want to monitor a service through external tools or when a plugin conflicts with your specific setup.

Plugin Auto-Updates

Server Scout plugins update automatically alongside the main agent. When you update the agent software, any bundled plugins are refreshed to their latest versions. This ensures you receive bug fixes, performance improvements, and support for newer software versions without manual intervention.

Custom plugins you've written or installed separately won't be affected by this auto-update process, allowing you to maintain your bespoke monitoring solutions.

Extending Monitoring Capabilities

The plugin architecture transforms Server Scout from a basic system monitor into a comprehensive infrastructure monitoring solution. Plugins can monitor virtually any service or application by:

• Parsing application-specific log formats
• Querying service APIs and databases
• Monitoring custom business metrics
• Checking external dependencies and integrations

Understanding this architecture helps you make informed decisions about which plugins to enable, how to configure collection frequencies, and when you might need to develop custom monitoring solutions for your unique infrastructure requirements.