Plugins Overview
StatusRadar Agent supports 16 monitoring plugins to track databases, web servers, caches, message queues, load balancers, RAID arrays, and other infrastructure services.
What are Plugins?
Plugins extend the base agent functionality to monitor specific services running on your server. Each plugin:
- Collects service-specific metrics (connections, queries, cache hits, etc.)
- Runs independently — one plugin failure doesn't affect others
- Is optional — enable only what you need
- Auto-discovers services — detects whether the service is available
- Reports to the dashboard — metrics appear automatically in the UI
Available Plugins
Databases & Search
| Plugin | Service | Metrics | Use Case |
|---|---|---|---|
| Redis | Redis 4.0+ | Memory, commands, connections, keyspace, replication | Cache & session store monitoring |
| MySQL | MySQL 5.7+, MariaDB 10.3+ | Queries, connections, locks, InnoDB, replication | Database performance monitoring |
| PostgreSQL | PostgreSQL 10+ | Transactions, locks, cache hits, replication lag | Database performance monitoring |
| MongoDB | MongoDB 4.0+ | Operations, connections, WiredTiger cache, locks | NoSQL database monitoring |
| Elasticsearch | Elasticsearch 7.0+ | Cluster health, nodes, indices, JVM, queries | Search engine monitoring |
| Meilisearch | Meilisearch 1.0+ | HTTP requests, database size, indices, searches | Search engine monitoring |
| VictoriaMetrics | VictoriaMetrics 1.80+ | Active series, ingestion rate, storage, queries | Time-series database monitoring |
Web Servers & Proxies
| Plugin | Service | Metrics | Use Case |
|---|---|---|---|
| Nginx | Nginx (any version) | Active connections, requests/sec, worker states | Web server monitoring |
| Apache | Apache 2.4+ | Workers, requests, bytes transferred, CPU load | Web server monitoring |
| PHP-FPM | PHP-FPM 7.4+ | Active/idle processes, slow requests, queue | PHP application monitoring |
| Varnish | Varnish 6.0+ | Cache hits/misses, backend connections, objects | HTTP cache monitoring |
| HAProxy | HAProxy 2.0+ | Frontend/backend stats, sessions, queue, health | Load balancer monitoring |
Caching & Messaging
| Plugin | Service | Metrics | Use Case |
|---|---|---|---|
| Memcached | Memcached 1.4+ | Hits/misses, memory, connections, evictions | Cache monitoring |
| RabbitMQ | RabbitMQ 3.8+ | Queues, messages, consumers, memory, disk | Message broker monitoring |
Containers & Storage
| Plugin | Service | Metrics | Use Case |
|---|---|---|---|
| Docker | Docker 20.10+ | Container count, CPU/memory per container, I/O | Container monitoring |
| mdadm | Linux Software RAID | Array count, degraded/failed arrays, device counts, sync/rebuild progress | RAID health monitoring |
How Plugins Work
Architecture
┌─────────────────────────────────────────┐
│ StatusRadar Agent │
│ │
│ ┌─────────────────────────────────┐ │
│ │ Base Agent (System Metrics) │ │
│ │ - CPU, Memory, Disk, Network │ │
│ └─────────────────────────────────┘ │
│ │
│ ┌─────────────────────────────────┐ │
│ │ Plugin Manager │ │
│ │ - Loads enabled plugins │ │
│ │ - Runs collection cycle │ │
│ │ - Handles errors gracefully │ │
│ └─────────────────────────────────┘ │
│ │
│ ┌──────┐ ┌──────┐ ┌──────┐ ┌──────┐ │
│ │Redis │ │MySQL │ │Nginx │ │Docker│ │
│ │Plugin│ │Plugin│ │Plugin│ │Plugin│ │
│ └──────┘ └──────┘ └──────┘ └──────┘ │
│ │ │ │ │ │
└──────┼────────┼────────┼────────┼──────┘
│ │ │ │
▼ ▼ ▼ ▼
┌──────┐┌──────┐┌──────┐┌──────────┐
│Redis ││MySQL ││Nginx ││Docker │
│6379 ││3306 ││80 ││/var/run/ │
└──────┘└──────┘└──────┘└──────────┘
Collection Cycle
- Agent starts → Loads configuration from
/opt/statusradar/config.env - Plugin discovery → Reads the
PLUGINSlist to see which plugins are enabled - Service detection → Tests whether each service is reachable
- Metric collection → Each plugin collects its metrics
- Aggregation → Combines all metrics into a single payload
- API submission → Sends to the StatusRadar API
- Wait → Sleeps until the next collection interval (default: 300 seconds, minimum 60)
- Repeat → Returns to step 3
Error Handling
Plugins are isolated from each other:
- One plugin fails → Others continue working
- Service unavailable → Plugin reports status but doesn't crash the agent
- Network error → Agent retries API submission
- Configuration error → Plugin is disabled, others continue
Configuration
The agent is configured through a single shell environment file at /opt/statusradar/config.env. There is no YAML config file. systemd loads it via EnvironmentFile=, so every key is a plain KEY=value line.
The installer writes a base set of keys. Plugins are turned on by listing them in the comma-separated PLUGINS variable, and each plugin reads its own environment variables from the same file.
# /opt/statusradar/config.env
API_TOKEN=your-token-here
API_URL=https://statusradar.dev
INTERVAL=300
# Enabled plugins (comma-separated)
PLUGINS=redis,mysql,nginx,docker,mdadm
# Per-plugin settings
REDIS_HOST=localhost
REDIS_PORT=6379
MYSQL_HOST=localhost
MYSQL_PORT=3306
MYSQL_USER=monitor
MYSQL_PASSWORD=secret
NGINX_STATUS_URL=http://127.0.0.1/nginx_status
After editing the file, restart the agent:
sudo systemctl restart statusradar-agent
Enabling Plugins
Method 1: During Installation (Recommended)
Set PLUGINS and any plugin variables as a prefix to the install one-liner. The token is passed via the TOKEN environment variable:
PLUGINS='redis,mysql,nginx,docker' \
REDIS_HOST='localhost' REDIS_PORT='6379' \
TOKEN='your-token-here' \
bash -c "$(curl -sL https://statusradar.dev/install-agent.sh)"
The installer writes these values into /opt/statusradar/config.env.
Method 2: Manual Configuration
Edit /opt/statusradar/config.env, add the plugin name to PLUGINS, add its environment variables, and restart:
# /opt/statusradar/config.env
PLUGINS=redis,mysql,nginx
REDIS_HOST=localhost
REDIS_PORT=6379
sudo systemctl restart statusradar-agent
The installer auto-populates a few plugin sections (REDIS_*, DOCKER_SOCKET, VM_*, RABBITMQ_*). All other plugin variables must be added to config.env manually, then the agent restarted.
Plugin Environment Variables
Each plugin reads its settings from config.env. The full set of recognized variables:
| Plugin | Environment Variables |
|---|---|
| Redis | REDIS_HOST, REDIS_PORT, REDIS_PASSWORD, REDIS_DB |
| MySQL | MYSQL_HOST, MYSQL_PORT, MYSQL_USER, MYSQL_PASSWORD, MYSQL_DATABASE |
| PostgreSQL | POSTGRESQL_HOST, POSTGRESQL_PORT, POSTGRESQL_USER, POSTGRESQL_PASSWORD, POSTGRESQL_DATABASE |
| MongoDB | MONGODB_HOST, MONGODB_PORT, MONGODB_USER, MONGODB_PASSWORD, MONGODB_DATABASE |
| Elasticsearch | ELASTICSEARCH_HOST, ELASTICSEARCH_PORT, ELASTICSEARCH_PROTOCOL, ELASTICSEARCH_USER, ELASTICSEARCH_PASSWORD |
| Meilisearch | MEILISEARCH_HOST, MEILISEARCH_PORT, MEILISEARCH_PROTOCOL, MEILISEARCH_API_KEY |
| VictoriaMetrics | VM_URL, VM_AUTH_TOKEN |
| Nginx | NGINX_STATUS_URL |
| Apache | APACHE_STATUS_URL |
| PHP-FPM | PHP_FPM_STATUS_URL |
| Varnish | VARNISH_NAME, VARNISH_INSTANCE |
| HAProxy | HAPROXY_STATS_URL, HAPROXY_USERNAME, HAPROXY_PASSWORD, HAPROXY_TIMEOUT |
| Memcached | MEMCACHED_HOST, MEMCACHED_PORT |
| RabbitMQ | RABBITMQ_HOST, RABBITMQ_PORT, RABBITMQ_USERNAME, RABBITMQ_PASSWORD, RABBITMQ_VHOST, RABBITMQ_USE_SSL |
| Docker | DOCKER_SOCKET |
| mdadm | None — reads /proc/mdstat directly (just add mdadm to PLUGINS) |
Configuration Patterns
Local Service Monitoring
The most common setup — monitor services on localhost:
PLUGINS=redis,mysql
REDIS_HOST=localhost
REDIS_PORT=6379
MYSQL_HOST=localhost
MYSQL_PORT=3306
MYSQL_USER=monitor
MYSQL_PASSWORD=secret
Remote Service Monitoring
Monitor services on other servers:
PLUGINS=redis,postgresql
REDIS_HOST=cache-server.example.com
REDIS_PORT=6379
REDIS_PASSWORD=secret
POSTGRESQL_HOST=db-server.example.com
POSTGRESQL_PORT=5432
POSTGRESQL_USER=monitor
POSTGRESQL_PASSWORD=secret
POSTGRESQL_DATABASE=postgres
Multiple Instances
Note: The agent monitors one instance per plugin type. To monitor multiple Redis instances, deploy separate agents.
Workaround for multiple databases:
- The MySQL plugin reports server-wide stats via
SHOW GLOBAL STATUS. - The PostgreSQL plugin aggregates all databases via
pg_stat_database. - The MongoDB plugin reports server-wide stats via
db.serverStatus().
Plugin Categories
Connection-Based Plugins
Require a network connection to the service:
- Redis (TCP 6379)
- MySQL (TCP 3306)
- PostgreSQL (TCP 5432)
- MongoDB (TCP 27017)
- Memcached (TCP 11211)
- Elasticsearch (HTTP 9200)
- Meilisearch (HTTP 7700)
- RabbitMQ (HTTP 15672 — management API)
- VictoriaMetrics (HTTP 8428)
HTTP Endpoint Plugins
Require an HTTP status endpoint:
- Nginx (
/nginx_status) - Apache (
/server-status?auto) - PHP-FPM (
/status) - HAProxy (
/stats;csv)
Command-Based Plugins
Execute system commands:
- Varnish (
varnishstat)
Socket-Based Plugins
Access Unix sockets or APIs:
- Docker (
/var/run/docker.sock)
File-Based Plugins
Read kernel/proc state directly:
- mdadm (
/proc/mdstat)
Plugin Dependencies
Python Packages
Some plugins require an extra Python package:
# Redis plugin
pip install redis
# MySQL plugin
pip install pymysql
# PostgreSQL plugin
pip install psycopg2-binary
# MongoDB plugin
pip install pymongo
# Docker plugin
pip install docker
# Elasticsearch plugin
pip install elasticsearch
The Nginx, Apache, PHP-FPM, HAProxy, Memcached, Meilisearch, VictoriaMetrics, Varnish, and mdadm plugins use only the Python standard library (or local system tools), so they need no extra packages.
Auto-installation: The installer automatically installs required packages for enabled plugins.
Service Requirements
Each plugin requires the target service to be:
-
Installed and running
sudo systemctl status redis sudo systemctl status mysql -
Accessible from the agent (network, firewall)
telnet localhost 6379 # Redis telnet localhost 3306 # MySQL -
Configured for monitoring (see plugin-specific docs)
Best Practices
1. Enable Only Needed Plugins
Each plugin adds roughly 10-20 MB RAM and ~2% CPU during collection. Only list plugins for services that are actually running.
2. Use Read-Only Users
MySQL example:
CREATE USER 'monitor'@'localhost' IDENTIFIED BY 'secret';
GRANT PROCESS, REPLICATION CLIENT ON *.* TO 'monitor'@'localhost';
FLUSH PRIVILEGES;
PostgreSQL example:
CREATE USER monitor WITH PASSWORD 'secret';
GRANT pg_monitor TO monitor;
Benefits:
- Security — the monitoring user can't modify data
- Safety — prevents accidental writes
- Compliance — audit-friendly
3. Secure the Configuration File
config.env holds credentials, so lock it down:
sudo chmod 600 /opt/statusradar/config.env
sudo chown root:root /opt/statusradar/config.env
4. Monitor Plugin Health
Plugin activity is written to the agent log:
sudo tail -f /var/log/statusradar/agent.log
On systemd 240+ the same output is also available via journald:
sudo journalctl -u statusradar-agent -f
5. Test a Plugin Before Deploying
Each plugin can be run directly for a quick check:
cd /opt/statusradar
PLUGINS=redis python3 plugins/redis_plugin.py
PLUGINS=mdadm python3 plugins/mdadm_plugin.py
Expected output:
Plugin name: redis
Enabled: True
Available: True
Metrics collected:
...
6. Adjust the Collection Interval
For high-traffic services, consider a longer interval. Set INTERVAL (seconds, minimum 60) in config.env:
INTERVAL=600
Benefits:
- Reduced load on monitored services
- Lower agent resource usage
- Sufficient for most monitoring needs
Performance Impact
Resource Usage by Plugin Count
| Plugins Enabled | Memory Usage | CPU (avg) | CPU (peak) |
|---|---|---|---|
| 0 (base only) | 50 MB | 0.5% | 5% |
| 1-3 plugins | 80 MB | 1% | 10% |
| 4-7 plugins | 120 MB | 2% | 15% |
| 8-12 plugins | 180 MB | 3% | 20% |
| 13-16 plugins (all) | 250 MB | 5% | 30% |
Collection Duration
Time to collect metrics (typical):
| Plugin | Collection Time |
|---|---|
| Redis | 0.1-0.3 seconds |
| MySQL | 0.2-0.5 seconds |
| PostgreSQL | 0.2-0.5 seconds |
| MongoDB | 0.3-0.6 seconds |
| Nginx | 0.1-0.2 seconds |
| Apache | 0.1-0.2 seconds |
| mdadm | 0.1 seconds |
| Docker | 0.5-2.0 seconds (depends on container count) |
| Elasticsearch | 0.3-0.8 seconds |
Total collection time: 2-10 seconds (depending on enabled plugins)
Troubleshooting Plugins
Plugin Not Collecting Metrics
Check 1: Is the plugin listed in PLUGINS?
grep '^PLUGINS=' /opt/statusradar/config.env
Check 2: Is the service running?
sudo systemctl status redis
sudo systemctl status mysql
Check 3: Can the agent connect?
telnet localhost 6379 # Redis
curl http://localhost/nginx_status # Nginx
Check 4: Are the credentials correct?
mysql -u monitor -p -h localhost -e "SHOW STATUS"
psql -U monitor -h localhost -d postgres -c "SELECT version()"
Check 5: Review the agent log
sudo tail -n 100 /var/log/statusradar/agent.log
Common Errors
"Connection refused"
- Service not running:
sudo systemctl start redis - Wrong host/port in
config.env - Firewall blocking the connection
"Authentication failed"
- Wrong username/password in
config.env - User doesn't exist: create the monitoring user
- User lacks permissions: grant the required privileges
"Permission denied"
- Agent can't access the socket: check file permissions
- SELinux blocking access: check audit logs
"Module not found"
- Python package not installed:
pip install <package-name>
"Plugin not found"
- Plugin not listed in
PLUGINS, or a typo in the name - Plugin file missing: reinstall the agent
Plugin Updates
Plugins are updated automatically when you update the agent:
curl -s https://statusradar.dev/install-agent.sh | sudo bash -s update
Update process:
- Downloads the latest agent code
- Updates all plugin files
- Restarts the agent service
- Preserves the existing
config.env
Next Steps
Plugin Documentation
Detailed guides for each plugin:
Databases & Search:
- Redis Plugin
- MySQL Plugin
- PostgreSQL Plugin
- MongoDB Plugin
- Elasticsearch Plugin
- Meilisearch Plugin
- VictoriaMetrics Plugin
Web Servers & Proxies:
Caching & Messaging:
Containers & Storage:
General Documentation
- What are Plugins?
- Available Plugins
- Databases & Search
- Web Servers & Proxies
- Caching & Messaging
- Containers & Storage
- How Plugins Work
- Architecture
- Collection Cycle
- Error Handling
- Configuration
- Enabling Plugins
- Method 1: During Installation (Recommended)
- Method 2: Manual Configuration
- Plugin Environment Variables
- Configuration Patterns
- Local Service Monitoring
- Remote Service Monitoring
- Multiple Instances
- Plugin Categories
- Connection-Based Plugins
- HTTP Endpoint Plugins
- Command-Based Plugins
- Socket-Based Plugins
- File-Based Plugins
- Plugin Dependencies
- Python Packages
- Service Requirements
- Best Practices
- 1. Enable Only Needed Plugins
- 2. Use Read-Only Users
- 3. Secure the Configuration File
- 4. Monitor Plugin Health
- 5. Test a Plugin Before Deploying
- 6. Adjust the Collection Interval
- Performance Impact
- Resource Usage by Plugin Count
- Collection Duration
- Troubleshooting Plugins
- Plugin Not Collecting Metrics
- Common Errors
- Plugin Updates
- Next Steps
- Plugin Documentation
- General Documentation