How to monitor rConfig V8 Core health

System monitoring keeps rConfig V8 Core reliable by giving you visibility into infrastructure health, application performance, and resource use. After reading this page, you can identify which components to watch, set sensible alert thresholds, and choose external tools to detect problems before they degrade service.

rConfig V8 Core runs on a standard stack: Laravel (PHP), a web server (Apache or Nginx), PHP-FPM, a database (PostgreSQL or MariaDB), and Laravel Horizon for queue processing. Monitoring each of these layers keeps the application stable, performant, and secure.

Note

All thresholds and metrics on this page are recommendations. Tune them to your environment, service level agreements, and workload. A value that warrants a warning in one deployment can be normal in another.

Key monitoring components

Disk usage and I/O performance

Disk capacity and I/O performance directly affect rConfig’s ability to store configurations, write logs, and run database operations.

Metrics to monitor:

• Disk space utilisation: percentage of used space on partitions holding rConfig data
• Available disk space: absolute free space in gigabytes
• Disk I/O wait: percentage of CPU time waiting for disk operations
• Read/write throughput: MB/s for sequential and random operations
• IOPS: input/output operations per second

Critical directories:

• /var/www/html/rconfigstorage: configuration files, logs, backups, uploaded files
• Database partition: PostgreSQL or MariaDB data directory
• /tmp: temporary files during operations

Why it matters: insufficient disk space prevents configuration downloads, breaks backups, causes database failures, and fills log partitions, which can crash the application. High I/O wait points to storage bottlenecks degrading performance.

Recommended thresholds:

• Warning: 80% disk utilisation
• Critical: 90% disk utilisation
• Alert: I/O wait sustained above 25%
• Alert: available space below 10GB on the rConfig partition

Monitoring approaches:

df -h /var/www/html/rconfigstorage
iostat -x 1 10

Use Nagios, Zabbix, or custom scripts built on df, iostat, and iotop for continuous monitoring.

Web server performance

The web server (Apache or Nginx) handles all user interface requests, API calls, and configuration downloads.

Metrics to monitor:

• Request rate: requests per second
• Response time: average and 95th percentile latency
• Error rate: 4xx and 5xx HTTP status codes
• Active connections: current open connections
• Queue depth: pending requests waiting for processing

Why it matters: slow response times frustrate users and signal capacity issues. High error rates suggest application problems. Connection exhaustion blocks new users from reaching rConfig.

Recommended thresholds:

• Warning: average response time above 2 seconds
• Critical: average response time above 5 seconds
• Alert: 5xx error rate above 1% of requests
• Alert: active connections above 80% of the configured maximum

Apache monitoring. Enable mod_status in the Apache configuration:

<Location "/server-status">
    SetHandler server-status
    Require local
</Location>

Access the status at http://localhost/server-status or integrate it with monitoring tools.

Nginx monitoring. Enable the stub_status module:

location /nginx_status {
    stub_status on;
    access_log off;
    allow 127.0.0.1;
    deny all;
}

Tools: Apache mod_status, Nginx stub_status, Prometheus exporters, the ELK Stack for log analysis, or Grafana dashboards.

PHP-FPM process management

PHP-FPM manages the PHP worker processes that execute rConfig application code.

Metrics to monitor:

• Active processes: currently executing requests
• Idle processes: workers ready for new requests
• Total processes: current worker pool size
• Request duration: time spent processing requests
• Memory per process: memory used by individual workers
• Slow requests: requests exceeding the configured slow threshold

Why it matters: worker pool exhaustion causes request queuing and timeouts. Memory bloat indicates leaks that warrant process recycling. Slow requests pinpoint performance bottlenecks.

Recommended thresholds:

• Warning: fewer than 5 idle processes available
• Critical: 0 idle processes (pool exhausted)
• Alert: average process memory above 256MB
• Alert: slow request count increasing

Enable the status page in the PHP-FPM pool configuration:

pm.status_path = /php-fpm-status

Expose it via the web server:

location ~ ^/php-fpm-status$ {
    access_log off;
    allow 127.0.0.1;
    deny all;
    include fastcgi_params;
    fastcgi_pass unix:/var/run/php/php8.2-fpm.sock;
}

Tools: the PHP-FPM status page, New Relic APM, Datadog, or the Prometheus php-fpm-exporter.

Tip

PHP-FPM monitoring is optional for small deployments but becomes important for environments with 500 or more devices or high user concurrency. Start once you observe performance degradation or timeout errors.

Memory and CPU utilisation

System resource limits cap how many operations rConfig can process at once.

Metrics to monitor:

• Total memory utilisation: percentage of RAM in use
• Available memory: free RAM for new processes
• Swap usage: memory paged to disk, which signals RAM exhaustion
• CPU utilisation: percentage across all cores
• Load average: system load over 1, 5, and 15-minute intervals
• Process-specific metrics: memory and CPU per rConfig component

Why it matters: memory exhaustion triggers swapping, which sharply degrades performance. High CPU points to capacity limits or inefficient work. Sustained high load suggests undersized infrastructure.

Recommended thresholds:

• Warning: memory utilisation above 85%
• Critical: memory utilisation above 95%
• Alert: swap usage above 100MB (swap should rarely be used)
• Warning: CPU utilisation above 80% sustained for 5 or more minutes
• Critical: load average above the number of CPU cores

Monitoring commands:

top
htop
free -h
vmstat 1

PHP memory configuration: raise the PHP memory_limit from the default 128MB toward roughly 50% of server RAM on a dedicated rConfig server. See PHP settings for rConfig V8 Core for detailed guidance.

Tools: top, htop, Nagios, Zabbix, Prometheus node_exporter, or cloud provider metrics (CloudWatch, Azure Monitor).

Database performance

Database health is critical, because all rConfig operational data lives in PostgreSQL or MariaDB.

Metrics to monitor:

• Query performance: average query execution time
• Slow queries: queries exceeding a threshold (typically 1 to 5 seconds)
• Connection count: active and total database connections
• Connection pool utilisation: percentage of max_connections in use
• Database size: total storage consumed
• Replication lag: for replicated databases, delay between primary and replica
• Lock waits: queries waiting for table locks
• Buffer cache hit ratio: percentage of queries served from memory rather than disk

Why it matters: slow queries degrade responsiveness. Connection exhaustion blocks new operations. Unmonitored growth leads to capacity exhaustion. Replication lag risks data loss during failover.

Recommended thresholds:

• Warning: average query time above 100ms
• Critical: slow queries (above 1 second) increasing
• Warning: connections above 70% of max_connections
• Critical: connections above 90% of max_connections
• Alert: replication lag above 60 seconds
• Alert: buffer cache hit ratio below 90%

PostgreSQL monitoring:

SELECT * FROM pg_stat_activity;
SELECT * FROM pg_stat_database;
SELECT query, calls, total_time, mean_time FROM pg_stat_statements ORDER BY mean_time DESC LIMIT 10;

MariaDB monitoring:

SHOW PROCESSLIST;
SHOW STATUS;
SHOW GLOBAL STATUS LIKE 'Slow_queries';
SELECT * FROM information_schema.innodb_trx;

Tools: Percona Monitoring and Management (PMM), pgBadger, MySQLTuner, pg_stat_statements, Grafana with PostgreSQL or MySQL data sources, or Datadog database monitoring.

Laravel Horizon queue management

Laravel Horizon manages background job processing for configuration downloads and scheduled tasks.

Metrics to monitor:

• Queue depth: number of pending jobs in each queue
• Processing rate: jobs processed per minute
• Failed jobs: jobs that encountered errors
• Worker status: health of queue worker processes
• Job wait time: time jobs spend queued before processing
• Job processing time: duration to complete jobs

Why it matters: growing queue depth indicates too few workers or stuck jobs. Failed jobs represent unsuccessful operations. Worker failures stop all background processing.

Note

Supervisord must always run Laravel Horizon. Horizon manages the Laravel queue workers as a long-running process. If Supervisord or Horizon stops, all background operations cease, including configuration downloads and scheduled tasks.

Recommended thresholds:

• Warning: queue depth above 100 jobs
• Critical: queue depth growing continuously
• Alert: failed jobs increasing
• Critical: Horizon process not running
• Alert: jobs waiting more than 5 minutes before processing

Check Horizon status:

php /var/www/html/rconfig/artisan horizon:status

Access the Horizon dashboard at https://your-rconfig-server/horizon.

Monitor Supervisord:

sudo supervisorctl status

Tools: the built-in Horizon dashboard, the Supervisord web interface, custom scripts checking process status, or a Prometheus exporter for Horizon.

For full queue management detail, see the Horizon queue manager guide and the queue manager reference.

Backup operations

Backup monitoring protects configuration data and underpins disaster recovery.

Metrics to monitor:

• Backup success or failure: whether backups complete without errors
• Backup duration: time required to complete backups
• Backup size: size of generated backup archives
• Backup frequency: confirming scheduled backups run as configured
• Backup integrity: verifying that backup archives are valid

Why it matters: a failed backup discovered during recovery is discovered too late. Duration increases can indicate capacity issues. Size growth helps with capacity planning.

Caution

The rConfig V8 Core built-in backup provides basic protection. For production, add an enterprise-grade backup solution with offsite storage, encryption, and automated testing, and include it in your monitoring strategy.

Recommended thresholds:

• Critical: any backup failure
• Warning: backup duration above twice the typical duration
• Alert: backup size growth above 50% month over month
• Alert: last successful backup more than 48 hours ago

Review backup logs:

tail -f /var/www/html/rconfig/storage/logs/laravel.log | grep -i backup

Check backup file timestamps:

ls -lth /var/www/html/rconfig/storage/app/backups/ | head -10

Tools: custom scripts parsing backup logs, integration with backup solutions (Bacula, Veeam), monitoring of scheduled task execution, or alerting on backup file age.

For backup configuration detail, see Backups in rConfig V8 Core.

File integrity monitoring

Security monitoring of critical configuration files detects unauthorised modifications.

Files to monitor:

• .env file: encryption keys, database credentials, and sensitive configuration
• Application code: unauthorised changes can indicate compromise
• Configuration files: web server, PHP, and database configurations
• SSL certificates: expiry and replacement detection

Why it matters: unauthorised .env changes expose encryption keys and credentials. Code changes can introduce vulnerabilities or backdoors. Configuration tampering causes application failures or security weaknesses.

Caution

The .env file holds the application encryption key (APP_KEY) that protects all device credentials. Any unauthorised access or modification is a critical security incident. Monitor this file continuously and alert on any change.

Recommended monitoring:

• Alert: any .env file modification
• Alert: application code changes outside maintenance windows
• Alert: SSL certificate expiry within 30 days
• Alert: configuration file modifications by unauthorised users

File integrity check:

sudo tripwire --check

Watch .env with inotify:

inotifywait -m /var/www/html/rconfig/.env

Tools: Tripwire, AIDE (Advanced Intrusion Detection Environment), OSSEC, or custom scripts using file checksums.

For the encryption key itself, see Application encryption key.

Application logs

Log monitoring gives early warning of application errors, exceptions, and security events.

Log locations:

• Laravel application logs: /var/www/html/rconfig/storage/logs/laravel.log
• Web server logs: /var/log/apache2/ or /var/log/nginx/
• PHP-FPM logs: /var/log/php-fpm/
• Database logs: PostgreSQL or MariaDB log directories
• System logs: /var/log/syslog or /var/log/messages

Why it matters: repeated errors indicate application bugs or configuration issues. Exception patterns reveal performance problems. Security events enable threat detection.

Recommended monitoring:

• Alert: PHP fatal errors or exceptions
• Alert: database connection failures
• Alert: authentication failures (potential brute force)
• Warning: deprecation warnings in logs
• Alert: disk space errors writing logs

Watch logs in real time:

tail -f /var/www/html/rconfig/storage/logs/laravel.log

Search for errors:

grep -i "error\|exception\|fatal" /var/www/html/rconfig/storage/logs/laravel.log

Tools: the ELK Stack (Elasticsearch, Logstash, Kibana), Splunk, Graylog, Prometheus Loki, or custom scripts with alerting.

For log management detail, see Application log and System logs.

Additional metrics

Uptime monitoring: confirm the rConfig web interface and API endpoints stay reachable. Use external services (Pingdom, UptimeRobot, StatusCake) to detect outages from the user’s perspective.

SSL certificate expiry: track certificate validity and alert 30 days before expiry to allow renewal time. Use openssl commands or monitoring tools with SSL checks.

Network connectivity: monitor connectivity to managed devices. Device unreachability can indicate a network problem rather than an rConfig one. Track success rates for device connections.

API performance: if you use the rConfig API, monitor response times, error rates, and rate limit consumption. Degraded API performance affects integrations and automation.

Recommended monitoring tools

Tool	Purpose	Suitable for
Nagios	General infrastructure monitoring with alerting	Organisations with existing Nagios infrastructure
Zabbix	Comprehensive system and application monitoring	Teams needing detailed metrics and trending
Prometheus + Grafana	Time-series metrics collection with visualisation	Modern containerised or cloud-native deployments
ELK Stack	Log aggregation, analysis, and searching	High log volume requiring centralised logging
Datadog	Cloud-based monitoring and APM	Teams preferring a SaaS monitoring solution
New Relic	Application performance monitoring with deep visibility	Environments needing code-level performance insight
Tripwire / AIDE	File integrity monitoring for security	Security-conscious or compliance-driven environments
Percona PMM	MySQL/MariaDB and PostgreSQL monitoring	Database-heavy deployments needing query optimisation

Best practices

Implementation

Centralise monitoring: aggregate metrics from all rConfig components in one platform. Spreading monitoring across many tools complicates correlation and alerting. Pick one primary platform (for example Zabbix or Prometheus) and integrate all metrics into it.

Use gradual alerting: set warning thresholds before critical ones so you can respond proactively. For example, alert at 80% disk usage (warning) and 90% (critical) to intervene before exhaustion.

Set up alert escalation: route alerts to the right people based on severity and duration. Critical alerts can page on-call engineers, while warnings email during business hours.

Build dashboards: provide at-a-glance status of critical metrics. Leaders benefit from high-level availability views, while operations teams need detailed component metrics.

Monitor external dependencies: track external services rConfig uses (LDAP, SSO, external APIs). Their failures affect rConfig but may not show up in rConfig’s own metrics.

Operations

Test alerting: periodically trigger test alerts to confirm the mechanisms work. Alerts no one receives serve no purpose.

Document response procedures: create runbooks mapping each alert type to investigation and remediation steps. This speeds incident response and helps junior staff handle common issues.

Review monitoring regularly: evaluate whether thresholds remain appropriate as infrastructure scales, usage changes, or new features ship.

Tune thresholds: adjust based on operational experience. Thresholds that fire frequent false positives cause alert fatigue, while thresholds set too high miss real issues.

Correlate across layers: when investigating, examine metrics across infrastructure, database, application, and queue. A problem in one layer often surfaces as a symptom in another.

Security

Secure monitoring credentials: monitoring systems access sensitive metrics and logs. Protect their credentials as rigorously as production system access.

Encrypt monitoring data: ensure data transmits over TLS between agents and collectors, since it can reveal infrastructure topology and weaknesses.

Restrict monitoring access: limit dashboard access to authorised personnel. Full infrastructure visibility aids attacker reconnaissance.

Monitor the monitors: add meta-monitoring so you know the monitoring platform itself is up. Monitoring failures during incidents compound problems.

Audit monitoring changes: track who changes monitoring configuration, thresholds, or alert recipients. Unauthorised changes can indicate compromise or insider threat.

Compliance

Retain monitoring data: align retention with regulatory requirements. Some frameworks require 90 days to several years of monitoring data and alerts.

Generate compliance reports: produce reports showing monitoring coverage, alert response times, and availability for auditors.

Document monitoring strategy: describe the architecture, covered components, alert definitions, and response procedures. Auditors often require documented practices.

Track changes: log all system changes (configuration, software updates, user changes) for audit trails and forensic investigation.

Integration with rConfig features

Monitoring queue operations

Integrate monitoring with Horizon queue metrics:

• Track queue depth trends to spot capacity issues
• Alert on failed job patterns that indicate systemic problems
• Monitor job processing times to detect performance degradation
• Correlate queue depth with scheduled task execution

Monitoring configuration downloads

Monitor device connection operations:

• Success and failure rates per vendor or device type
• Configuration download duration trends
• Authentication failure patterns
• Network timeout patterns by region

Note

Policy compliance evaluation and reporting are features of the Pro, Enterprise, and Vector editions rather than V8 Core. To monitor compliance operations, see the Pro edition documentation.

Troubleshooting

Why can’t my monitoring agent connect to rConfig?

Verify firewall rules and authentication.

Possible causes:

• Firewall blocking monitoring agent connections
• Incorrect monitoring credentials
• Monitoring endpoint disabled in rConfig
• Network connectivity issues

Resolution steps:

1. Verify the monitoring endpoint is reachable from the monitoring server
2. Check firewall rules permit monitoring agent connections
3. Validate the monitoring credentials
4. Review rConfig logs for authentication failures
5. Test network connectivity between the monitoring server and rConfig

Why is memory usage so high?

Identify which processes consume memory.

Possible causes:

• PHP memory_limit set too high, letting individual processes consume excessive RAM
• Memory leak in application code or a PHP extension
• Database queries loading large result sets into memory
• Insufficient RAM for the workload

Resolution steps:

1. Identify the top memory consumers: ps aux --sort=-%mem | head -20
2. Review the PHP memory_limit setting in php.ini
3. Check for leaks by tracking individual process memory over time
4. Optimise database queries returning large result sets
5. Increase server RAM if the workload legitimately needs more

Why am I getting too many warnings?

Review alert thresholds and frequencies.

Possible causes:

• Thresholds set too aggressively
• Normal operational patterns triggering warnings
• No alert de-duplication
• Missing alert priority classification

Resolution steps:

1. Analyse alert history to find the most frequent alerts
2. Adjust thresholds for alerts that fire often without requiring action
3. Implement alert de-duplication to group related alerts
4. Re-classify alerts based on the urgency you observe operationally
5. Consider suppressing alerts during maintenance windows

What’s next

• Tune PHP settings for rConfig V8 Core for performance and memory configuration
• Manage the Horizon queue to keep background processing healthy
• Review system requirements for infrastructure sizing and capacity planning