Application Log in rConfig V8 Core

After reading this page, you can read and filter the application log in rConfig V8 Core, search log descriptions for specific events, expand entries for full detail, and configure archival so the log table stays performant as it grows.

When to use this

Use the application log when you need to understand what rConfig did and when. It is the first place to look when a device backup fails, a scheduled task did not run, an authentication attempt was rejected, or the application threw an exception. The log captures every significant event with a timestamp, severity, and description so you can trace a problem to its root cause.

What gets logged

rConfig V8 Core records several categories of event 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
• 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 is an integrated part of the rConfig architecture:

1. System components, device connection modules, and task processors generate log entries when significant events occur.
2. Entries are written to the database with timestamps, severity levels, descriptions, and contextual detail.
3. Logs appear in the interface immediately after generation, so you can troubleshoot live.
4. Log descriptions are indexed for fast keyword search.
5. Scheduled tasks can move aging logs to an archive table to keep query performance high.

Because the log is database-driven rather than file-based, entries survive restarts and support filtering and search that flat log files cannot match.

Log severity levels

rConfig categorises each entry by severity so you can prioritise investigation:

Severity	When to investigate	Typical examples
Emergency	Immediately	Database unavailable, system crash
Alert	Within 15 minutes	Service failure, critical resource exhausted
Critical	Within 1 hour	Connection pool exhausted, major feature broken
Error	Within 4 hours	Device connection failed, command execution error
Warning	Daily review	Deprecated feature use, approaching thresholds
Notice	Weekly review	Normal config changes, scheduled task runs
Info	As needed	Routine operations, successful tasks
Debug	Troubleshooting only	Detailed operational flow

Focus on Critical and Error events during incident response, and watch Warning and Notice levels for trending issues.

Prerequisites

• An administrator account that can access the Application Log section.
• For archival, the ability to create entries under Scheduled Tasks.

View the application log

1. Select Application Log from the main navigation menu.
2. Review the entries, which display in reverse chronological order (newest first). Each row shows the timestamp, a color-coded severity indicator, the log description, and an expand control.

Filter logs by severity

1. Open the severity filter dropdown at the top of the log interface.
2. Select one or more severity levels to display. Choose Error and Critical for failures needing attention, Warning to catch issues early, or Info and Debug for detailed operational insight.
3. Review the updated list, which now shows only matching entries.
4. Clear the filters to return to the full log view.

Search log descriptions

1. Locate the search field at the top of the log interface.
2. Enter a keyword related to the event you are investigating. Search runs against the Log Description field and supports partial matching.
3. Review the results. Useful keyword groups:
   • Connection: conn, auth, timeout, refused
   • Device: hostname or IP address
   • Command: snippet, command, execute
   • Errors: failed, error, exception, denied

Partial matching means a search for conn returns “connection”, “connected”, “connect”, and “disconnect”, so broad patterns surface with minimal typing.

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, command	Config retrieval events
Task execution	task, scheduled, queue, job	Task starts, completions, failures
System errors	error, exception, critical, failed	Application errors, exceptions

View full log details

1. Find the entry of interest in the main log view.
2. Click the expand control on the right of the row to reveal the complete message, any stack trace for exceptions, additional context fields (user, device, or task), and the precise timestamp.
3. Click the copy control to copy the raw log data to the clipboard.
4. Paste the copied data into a support request, incident ticket, or internal note.

Archive and manage logs

As rConfig runs, log volume grows continuously. Large log tables slow searches and degrade the application. Archival moves aging entries to a separate archive table, keeping the active log fast while preserving history for compliance or forensic needs. Archived entries are moved, not deleted, and remain accessible through database queries.

Configure log archival

1. Select Scheduled Tasks from the main navigation menu.
2. Create a new scheduled task to archive application logs.
3. Set the schedule (daily or weekly is typical) and the retention threshold (the number of days of logs to keep in the active table, for example 30).
4. Enable and save the task. It then moves logs older than the retention threshold to the archive table on each run.

Recommended archival strategies

Standard deployments (100 to 500 devices):

• Retain 30 days of active logs
• Archive weekly
• Keep 12 months total (active plus archived)

Large deployments (1,000+ devices):

• Retain 14 days of active logs
• Archive daily
• Keep 6 months for performance logs, 12+ months for security events
• Consider exporting archived logs to an external SIEM for long-term storage

Compliance-driven environments:

• Retain 30 days of active logs
• Archive weekly
• Align total retention with regulatory requirements (often 3 to 7 years)
• Include the archive table in your database backup strategy

Enable archival early

Any deployment managing more than 100 devices should turn on archival before the active table grows large. The performance impact of an oversized log table affects the whole application, not just the log view.

Troubleshooting

Logs not appearing for recent events

Likely causes: database connection issues, disk space exhaustion, application permissions, or logging disabled in configuration.

1. Verify database connectivity:

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

2. Check disk space on the database partition:

   df -h

3. Review Laravel logs for database errors:

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

4. Confirm the application can reach the database:

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

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

Log search returns no results

Likely causes: an over-specific or misspelled term, archived logs no longer in the active table, or an active severity filter excluding matches.

1. Try broader partial-match terms (use auth instead of authentication failure, or 192.168 instead of a full IP).
2. Confirm the events fall within the active log retention window.
3. Check whether the logs were archived by reviewing scheduled task execution history.
4. Clear any severity filters that might be hiding matches.

Application log page loads slowly

Likely causes: excessive log volume without archival, missing or fragmented indexes, or insufficient database resources.

1. Check the log table row count:

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

2. If the count exceeds 100,000 rows, enable archival.
3. Optimize the table:

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

4. Consider increasing database resources for large deployments.

Archived logs cannot be found

Likely causes: the archival task did not run successfully, the archive table is missing, or archived logs are being confused with purged logs.

1. Verify the archive table exists:

   php /var/www/html/rconfig/artisan tinker
   DB::select("SHOW TABLES LIKE 'activity_log_archive'");

2. Check the archived row count:

   DB::table('activity_log_archive')->count();

3. Review scheduled task execution history for archival failures.
4. Query archived logs directly when needed for compliance or forensic work:

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

Common gotchas

Common gotchas

• Partial matching is broad. A short term like auth matches many unrelated descriptions, so add context (a device IP or failed) when results are noisy.
• An active severity filter can hide the entry you expect. Clear filters before concluding an event was never logged.
• Archived entries are not in the active log view. If a search comes up empty for an older event, it may have moved to activity_log_archive already.
• Without archival enabled, the log table grows unbounded and slows the whole application, not just the log page. Turn it on before the table reaches six figures of rows.
• Authentication entries reveal access patterns and failed logins. Restrict the Application Log to administrators and keep security-relevant logs longer than routine operational logs.

What’s next

• Configure scheduled tasks to automate log archival and other recurring jobs.
• Manage users and roles to control who can view the application log.
• Troubleshoot device connectivity using log entries to diagnose connection failures.