Application Log: System Events and Audit Trail Management in rConfig V8

The Application Log provides comprehensive visibility into all system events, device interactions, and operational activities within rConfig V8. This centralized logging system addresses the critical challenge of troubleshooting complex network automation workflows, audit trail requirements, and security monitoring across distributed device management operations.

Organizations can leverage the Application Log to diagnose connection failures, track configuration changes, monitor authentication events, and maintain compliance audit trails. The logging system captures granular detail about every significant operation, enabling rapid root cause analysis and forensic investigation when issues arise.

When to Use This Page

Use this page to diagnose a specific failure (device connection, task, or authentication), search for events tied to a device or user, or plan retention for the underlying activity_log table.

Prerequisites

• setting.view permission (or equivalent RBAC access) to view the Application Log.
• No other setup is required: logging is on by default and requires no configuration to start capturing events.

Understanding Application Logging

What Gets Logged

rConfig V8 captures multiple categories of events in the Application Log:

System Events:

• Authentication attempts (successful and failed logins)
• Application exceptions and error conditions
• Email notification delivery status
• System configuration changes
• Database operations and maintenance events

Device Connection Events:

• Connection attempts to network devices
• Authentication successes and failures
• Protocol negotiation details (SSH, Telnet, SNMP)
• Connection timeout or refusal events
• Session establishment and termination

Device Configuration Events:

• Configuration download successes and failures
• Command execution results
• Configuration snippet deployment outcomes
• Prompt detection and matching details

Scheduled Task Events:

• Task execution start and completion
• Task scheduling and queue assignment
• Task failures with error details
• Manual task invocation records

How Logging Works

The logging system operates as an integrated component of the rConfig architecture:

1. Event generation: System components, device connection modules, and task processors generate log entries when significant events occur
2. Structured storage: Log entries are written to the database with timestamps, severity levels, descriptions, and contextual details
3. Real-time availability: Logs appear in the interface immediately after generation, enabling live troubleshooting
4. Search indexing: Log descriptions are indexed for rapid keyword-based searching
5. Archival mechanism: Scheduled tasks can transfer aging logs to archive tables to maintain performance

This database-driven approach ensures logs survive system restarts and provides powerful filtering and search capabilities that file-based logging cannot match.

Log Severity Levels

rConfig categorizes log entries into five severity levels to help prioritize investigation efforts:

• Critical: Conditions affecting core functionality that need immediate attention
• Error: Error conditions preventing specific operations from completing
• Warn: Warning conditions that may lead to errors if unaddressed
• Info: Informational messages about routine operations
• Debug: Detailed debugging information for development and deep troubleshooting

Understanding severity levels helps operations teams triage issues effectively, focusing on critical and error-level events during incident response while monitoring warn-level entries for trending issues.

Viewing and Searching Logs

Accessing the Application Log

To view system logs:

1. Navigate to Application Log from the main navigation menu
2. The log interface displays recent entries in reverse chronological order (newest first)
3. Each log entry shows:
   • Timestamp: When the event occurred
   • Severity level: Color-coded indicator of event importance
   • Log description: Brief summary of the event
   • Expand icon: Access full log details

Filtering Logs by Severity

To focus on specific severity levels:

1. Locate the Severity filter at the top of the log interface
2. Select one or more severity levels to display:
   • Select Error and Critical to focus on failures requiring immediate attention
   • Select Warn to identify potential issues before they become critical
   • Select Info and Debug for detailed operational insight during troubleshooting
   • Select All to toggle every level on or off at once
3. The log view updates immediately to show only matching entries
4. Clear filters to return to the full log view

Filtering by severity significantly reduces noise when investigating specific problem categories, allowing rapid identification of relevant events among thousands of log entries.

Searching Log Descriptions

The search functionality enables keyword-based log discovery:

1. Locate the search field at the top of the log interface
2. Enter search keywords related to the event you’re investigating
3. The search operates on the Log Description field and supports partial matching
4. Use targeted keywords for effective searches:
   • Connection-related: conn, auth, timeout, refused
   • Device-specific: Device hostname or IP address
   • Command-related: snippet, command, execute
   • Error patterns: failed, error, exception, denied

Search Examples:

• Search auth to find all authentication events
• Search 192.168.1.1 to find all events related to a specific device
• Search timeout to identify connection timing issues
• Search snippet to find configuration snippet deployment events

The partial matching capability means searching conn returns entries containing “connection”, “connected”, “connect”, and “disconnect”, enabling broad pattern discovery with minimal typing.

Viewing Full Log Details

To examine complete log information:

1. Locate the log entry of interest in the main log view
2. Click the expand icon on the right side of the log entry
3. The entry expands to reveal:
   • Complete log message with full detail
   • Stack traces for exceptions (when applicable)
   • Additional context fields like user, device, or task information
   • Precise timestamp with microsecond resolution
4. Click the copy button to copy raw log data to the clipboard
5. Paste copied log data into support requests, incident tickets, or documentation

Expanded log details provide the granular information needed for effective troubleshooting, especially when working with rConfig support to diagnose complex issues.

Log Retention and Purging

Log archival was replaced by Data Purge in 8.1

Earlier rConfig releases archived aging logs to a separate table via a dedicated rconfig:archive-logs command. That command is deprecated and removed as of rConfig 8.1: running it now just prints an error pointing you to the current approach described below.

How Log Retention Works Today

As rConfig operates over time, the volume of log entries in the activity_log table grows continuously. Large log tables can impact database performance and make log searches slower. Retention for the Application Log is managed the same way as every other purgeable table: through Data Purge.

Two tables are relevant:

• activity_log: the active table this page reads from. Defaults to 90 days retention, purged daily.
• activity_log_archives: a legacy archive table from earlier releases. Defaults to 365 days retention, purged weekly. New installs generally accumulate little to nothing here going forward.

Configuring Log Retention

To change how long Application Log entries are kept:

1. Navigate to System Settings → Data Management → Data Purge.
2. Locate the activity_log row (and activity_log_archives if relevant to your deployment).
3. Adjust Retention (Days) to the number of days you want to keep entries.
4. Adjust Frequency (daily, weekly, monthly) and Batch Size if needed.
5. Save. The new threshold applies from the next scheduled or manual purge; it does not retroactively delete existing data.

Recommended Retention Periods

Consider these retention approaches based on your environment:

Standard deployments managing 100-500 devices:

• Retain 90 days of activity_log (the default)
• Review quarterly and shorten if storage becomes a concern

Large deployments managing 1,000+ devices:

• Consider shortening activity_log retention (for example, 30 days) and increasing purge frequency
• Export logs to an external SIEM before they age out if long-term retention is required, since rConfig purges rather than archives them elsewhere

Compliance-driven environments:

• Align retention with your regulatory requirements
• Since purge permanently deletes rather than moves data, export logs to compliant long-term storage before the retention window closes
• Coordinate retention changes with backup schedules so recent backups exist before shortening any window

Troubleshooting

Symptom: Logs Not Appearing for Recent Events

Diagnosis: Check that logging is enabled and the database is accessible.

Possible Causes:

• Database connection issues preventing log writes
• Disk space exhaustion preventing database writes
• Application permissions preventing database access
• Logging disabled in configuration

Resolution Steps:

1. Verify database connectivity:

   php /var/www/html/rconfig8/current/artisan tinker
   DB::connection()->getPdo();

2. Check disk space on database partition:

   df -h

3. Review Laravel logs for database errors:

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

4. Verify application can write to database:

   php /var/www/html/rconfig8/current/artisan migrate:status

5. If disk space is exhausted, archive or purge old logs, then restart services

Symptom: Log Search Returns No Results

Diagnosis: Verify search syntax and database indexing.

Possible Causes:

• Search term too specific or contains typos
• Database search indexes missing or corrupted
• Logs archived and no longer in active table
• Case sensitivity issues in search implementation

Resolution Steps:

1. Try broader search terms with partial matching:

   • Instead of authentication failure, try auth
   • Instead of specific IP address, try partial IP like 192.168

2. Verify the events you’re searching for occurred within the active log retention window

3. Check if logs were archived by reviewing scheduled task execution history

4. Clear any severity filters that might exclude matching logs

5. Contact rConfig support if search functionality appears broken across all searches

Symptom: Application Log Page Loads Slowly

Diagnosis: Check log table size and database performance.

Possible Causes:

• Excessive log volume without archival enabled
• Database indexes missing or fragmented
• Insufficient database resources (CPU, memory, disk I/O)
• Database server under load from other operations

Resolution Steps:

1. Check log table row count:

   php /var/www/html/rconfig8/current/artisan tinker
   DB::table('activity_log')->count();

2. If count exceeds 100,000 rows, enable log archival immediately

3. Optimize database tables:

   mysql -u root -p -e "OPTIMIZE TABLE rconfig.activity_log;"

4. Enable log archival scheduled task to prevent future accumulation

5. Consider increasing database resources for large deployments

Symptom: Logs Missing After a Retention Change

Diagnosis: Confirm whether the missing entries fall outside the current activity_log retention window.

Possible Causes:

• Retention Days on the activity_log Data Purge setting was recently shortened
• The entries are older than 90 days (the default retention) and have already been purged
• Confusion with the legacy activity_log_archives table from pre-8.1 installs, which is no longer actively written to

Resolution Steps:

1. Check the current retention setting for activity_log under Data Purge.

2. Check the legacy archive table for older entries, if your installation predates 8.1:

   php /var/www/html/rconfig8/current/artisan tinker
   DB::table('activity_log_archives')->count();

3. If the data genuinely falls outside your configured retention window, it has been permanently deleted by Data Purge; restore from a database backup if you need it back.

4. Going forward, lengthen the activity_log retention period if this window is too short for your operational needs.

5. Access archived logs directly via database queries if needed for compliance or forensic investigation

Best Practices

Security

Protect authentication logs: Authentication logs contain sensitive information about user access patterns and failed login attempts. Restrict access to the Application Log to administrators and security personnel only. Configure role-based access controls to prevent unauthorized log viewing.

Monitor for suspicious patterns: Regularly review logs for security indicators such as repeated failed authentication attempts, unusual connection sources, or unexpected configuration changes. Consider integrating rConfig logs with security information and event management (SIEM) systems for centralized security monitoring.

Retain security-relevant logs longer: While performance logs may be archived or purged after months, authentication and configuration change logs often require multi-year retention for compliance and forensic purposes. Implement different retention policies for security events versus operational logs.

Archive logs to immutable storage: For environments requiring forensic-grade logging, consider exporting archived logs to write-once-read-many (WORM) storage systems that prevent log tampering.

Performance

Enable log archival for active deployments: Any rConfig deployment managing more than 100 devices should implement automated log archival. The performance impact of large log tables degrades the entire application over time, not just the log viewing interface.

Archive frequently in high-volume environments: Deployments polling thousands of devices generate thousands of log entries daily. Archive logs weekly or even daily to maintain optimal database performance.

Balance retention with performance: While longer retention provides better historical visibility, it increases database size and backup duration. Align retention policies with actual investigation patterns, since most troubleshooting requires only recent logs.

Monitor database growth: Track database size growth over time to identify when log tables consume excessive storage. Set up alerting when database size approaches 80% of available disk space.

Organization

Establish log review procedures: Define regular log review schedules for operations teams. Daily review of error and critical logs identifies emerging issues before they impact production. Weekly review of warning logs reveals trending problems requiring proactive attention.

Document common log patterns: Create internal documentation mapping common log messages to known issues and resolutions. This accelerates troubleshooting by providing teams with immediate context for recurring events.

Integrate with ticketing systems: When log entries indicate issues requiring intervention, create tickets with log details attached. This ensures issues are tracked to resolution and provides accountability.

Export logs for compliance reporting: Organizations with regulatory requirements often need to demonstrate system activity for audits. Develop procedures to export log data in formats acceptable to auditors.

Maintenance

Test log archival procedures: After configuring log archival, monitor the first few execution cycles to ensure logs are correctly transferred to archive tables and active tables remain performant.

Verify archived log accessibility: Periodically query archived log tables to confirm archived data remains accessible. Archived logs are useless if they cannot be retrieved when needed.

Coordinate archival with backup schedules: Ensure database backups include archived log tables. Archived logs outside backup scope are at risk of permanent loss during disaster recovery.

Review log retention policies annually: As deployments grow and requirements change, retention policies should evolve. Annual review ensures policies remain aligned with operational needs and compliance obligations.

Common Gotchas

Common gotchas

• Severity is stored as log_name on each row, using the values critical, error, warn, info, and debug. There is no separate emergency, alert, or notice level, so don’t build a filter or alert rule expecting them.
• Application Log entries are purged, not archived, from 8.1 onward. If you shorten activity_log retention on the Data Purge page, older entries are permanently deleted, not moved somewhere else.
• The activity_log_archives table only holds data from pre-8.1 archival runs. On a fresh 8.1+ install it stays empty; don’t expect it to keep receiving new entries.
• Search only matches the Description field. If you can’t find an event by device name or IP, check whether that value actually appears in the log’s description text rather than only in its raw properties.

Related Documentation

• Data Purge - configure retention for the activity_log table
• Users - role-based access control for log viewing
• rConfig V8 Pro Installation Guide - database setup and optimization for log performance

Quick Reference

Common Log Search Keywords

Issue Category	Search Keywords	Example Logs Found
Authentication	auth, login, failed, denied	Login failures, session events
Device Connectivity	conn, timeout, refused, unreachable	Connection attempts, failures
Configuration Downloads	download, config, snippet, command	Config retrieval events
Task Execution	task, scheduled, queue, job	Task starts, completions, failures
System Errors	error, exception, critical, failed	Application errors, exceptions

Log Severity Quick Reference

Severity	When to Investigate	Typical Examples
Critical	Within 1 hour	Connection pool exhausted, major feature broken
Error	Within 4 hours	Device connection failed, command execution error
Warn	Daily review	Deprecated feature use, approaching thresholds
Info	As needed	Routine operations, successful tasks
Debug	Troubleshooting only	Detailed operational flow

Useful Database Queries

php /var/www/html/rconfig8/current/artisan tinker

DB::table('activity_log')
  ->where('log_name', 'error')
  ->where('created_at', '>', '2026-01-01')
  ->orderBy('created_at', 'desc')
  ->limit(100)
  ->get();

DB::table('activity_log')
  ->where('description', 'like', '%192.168.1.1%')
  ->orderBy('created_at', 'desc')
  ->get();

Summary

The Application Log provides comprehensive visibility into all rConfig V8 operations, enabling effective troubleshooting, security monitoring, and compliance audit trails. Organizations can leverage severity-based filtering, keyword searching, and detailed log expansion to rapidly diagnose issues and track system activity.

Key takeaways for effective log management:

• Filter by severity to focus investigation efforts on critical and error-level events during incident response
• Use keyword search with partial matching to quickly locate relevant events among thousands of log entries
• Enable log archival on any active deployment to maintain database performance as log volume grows
• Copy full log details to support requests to accelerate issue resolution with rConfig engineering
• Implement retention policies that balance operational needs with compliance requirements and database performance

Regular log review identifies emerging issues before they impact operations, while proper archival strategies ensure historical data remains accessible without degrading system performance. The Application Log transforms raw system events into actionable intelligence for network operations teams.