Skip to content
rConfig Documentation

rConfig V8 System Logs & Logging

rConfig System Logs and Application Logging

Section titled “rConfig System Logs and Application Logging”

rConfig uses a dual-logging architecture that separates operational business events from technical framework diagnostics. The Application Log captures device connectivity and configuration management events in a searchable database; System Logs store Laravel framework diagnostics in daily-rotated files. Knowing which log to check gets you to the root cause faster for both operational and technical issues.

The Dual-Logging Architecture

Section titled “The Dual-Logging Architecture”

Application Log: Business Logic and Operations

Section titled “Application Log: Business Logic and Operations”

The Application Log captures events related to rConfig’s core network configuration management functions. This database-driven logging system records structured events that answer operational questions like “Did the device connection succeed?”, “When was this configuration downloaded?”, or “Who modified this policy?”

Primary use cases:

  • Troubleshooting device connectivity issues
  • Tracking configuration change history
  • Security audit trails for user actions
  • Monitoring scheduled task execution
  • Compliance reporting and forensics

Key characteristics:

  • Stored in database tables for powerful filtering and searching
  • Structured data with severity levels, timestamps, and contextual metadata
  • Real-time visibility through web interface
  • Supports archival to separate tables for long-term retention
  • Accessible to operations teams and administrators

System Logs: Framework and Technical Diagnostics

Section titled “System Logs: Framework and Technical Diagnostics”

System Logs contain detailed technical output from the Laravel framework, PHP runtime, and background queue workers. This file-based logging system records stack traces, exception details, and low-level execution information that answer technical questions like “Why did the application crash?”, “Which code path generated this error?”, or “What caused the queue job to fail?”

Primary use cases:

  • Diagnosing application crashes and white screens
  • Investigating framework-level exceptions
  • Analyzing queue worker failures
  • Debugging database query issues
  • Providing detailed error context to rConfig support

Key characteristics:

  • Stored as daily rotated files in the filesystem
  • Unstructured text with full stack traces and variable dumps
  • Viewed through elegant web interface or command-line tools
  • Requires admin-level access due to sensitive technical details
  • Supports download for offline analysis and support requests

When to Use Each Log System

Section titled “When to Use Each Log System”

Decision Framework

Section titled “Decision Framework”

Use this decision tree to determine which logging system addresses your investigation needs:

Start here: What type of issue are you investigating?

Operational/business logic issues → Use Application Log:

  • Device won’t connect or authenticate
  • Configuration download failed
  • Scheduled task didn’t run as expected
  • User performed unauthorized action
  • Need compliance audit trail

Technical/application issues → Use System Logs:

  • Web interface displays white screen or 500 error
  • Background jobs failing silently
  • Database connection errors
  • PHP memory or timeout errors
  • Need detailed stack traces for support

Complex issues → Use both logs together:

  • Application Log provides business context (which device, which task)
  • System Logs provide technical details (exact exception, stack trace)
  • Cross-reference timestamps to correlate events

Common Scenarios

Section titled “Common Scenarios”

Scenario: Device connection repeatedly fails

  1. Start with Application Log: Search for device hostname or IP address
  2. Filter by severity: Error level
  3. Review log descriptions for connection failure patterns
  4. If errors indicate framework exceptions, switch to System Logs
  5. Search System Logs for exception class names found in Application Log

Scenario: Scheduled backup task doesn’t complete

  1. Start with Application Log: Filter for task execution events
  2. Check if task started but failed (error severity)
  3. If task queued but never executed, check System Logs
  4. Search System Logs for queue worker errors or job failures
  5. Review stack traces in System Logs for root cause

Scenario: White screen appears when accessing specific page

  1. Go directly to System Logs: This is a framework-level error
  2. Open today’s log file
  3. Scroll to entries near the time the error occurred
  4. Review the exception type, message, and stack trace
  5. Note the file and line number where the error originated

Log Management Lifecycle

Section titled “Log Management Lifecycle”

Generation and Storage

Section titled “Generation and Storage”

Application Log workflow:

  1. System components generate structured log entries during operations
  2. Entries written to database table with severity, timestamp, description
  3. Immediately visible in web interface for real-time monitoring
  4. Searchable and filterable through database queries
  5. Archived to separate tables based on retention policies

System Log workflow:

  1. Laravel framework and PHP runtime generate log entries
  2. Entries appended to daily log files in /var/www/html/rconfig8/current/storage/logs/
  3. Files rotated automatically at midnight (new file per day)
  4. Viewed through Log Viewer web interface or command-line tools
  5. Deleted manually when no longer needed

Retention and Archival

Section titled “Retention and Archival”

Different retention strategies apply to each log type based on their purpose and compliance requirements:

Application Log retention:

  • Active logs: 14-30 days in primary database tables for fast searching
  • Archived logs: Moved to archive tables for long-term retention (6-12+ months)
  • Security events: Often retained longer for compliance (3-7 years)
  • Automated archival via scheduled tasks prevents performance degradation

System Log retention:

  • Active logs: 30-90 days as daily files in storage directory
  • Large deployments: May reduce to 14-30 days due to file size
  • Critical incidents: Archive important files before cleanup
  • Manual deletion or automated cleanup via scheduled tasks

Performance Considerations

Section titled “Performance Considerations”

Application Log optimization:

  • Archive aging logs regularly to maintain query performance
  • Database indexes on timestamp and severity fields accelerate filtering
  • Large deployments (1,000+ devices) should archive weekly
  • Monitor database size growth to prevent storage exhaustion

System Log optimization:

  • Set appropriate log level (info/warning for production, not debug)
  • Large log files (100MB+) should be downloaded for offline analysis
  • Monitor disk space on log partition to prevent write failures
  • Delete old files regularly to reclaim storage capacity

Troubleshooting Workflow

Section titled “Troubleshooting Workflow”

Initial Assessment

Section titled “Initial Assessment”

When investigating any issue, begin with these questions:

  1. What specifically failed or behaved unexpectedly?

    • Operational function (device connection, config download) → Application Log
    • Technical function (page load, background job) → System Logs

  2. When did the issue occur?

    • Narrow search to specific timeframe in either log system
    • Cross-reference timestamps when using both systems

  3. Is this a recurring pattern or isolated incident?

    • Search for similar events across date ranges
    • Identify frequency and potential triggers

Diagnostic Process

Section titled “Diagnostic Process”

Follow this systematic approach for effective troubleshooting:

Phase 1: Identify the symptom

  • What did the user observe or experience?
  • What was the expected outcome?
  • What actually occurred?

Phase 2: Locate relevant log entries

  • Choose appropriate log system based on symptom type
  • Filter by timeframe when issue occurred
  • Apply severity filters (start with error and critical)
  • Search for keywords related to affected devices, tasks, or features

Phase 3: Analyze log context

  • Read log descriptions and messages carefully
  • Review any associated stack traces or error details
  • Expand collapsed entries for full technical detail
  • Note exception types, error codes, or failure reasons

Phase 4: Determine root cause

  • Correlate multiple log entries if needed
  • Review configuration or system state that may contribute
  • Check related documentation for known issues
  • Consult troubleshooting guides for specific components

Phase 5: Implement resolution

  • Follow resolution steps from documentation
  • Verify fix by reproducing original scenario
  • Monitor logs to confirm issue resolved
  • Document solution for future reference

Escalation to Support

Section titled “Escalation to Support”

When contacting rConfig support, provide comprehensive log information:

From Application Log:

  1. Export or copy relevant log entries showing the issue
  2. Include timestamps, severity levels, and full descriptions
  3. Note any patterns or frequency of occurrence
  4. Describe steps taken to reproduce or resolve

From System Logs:

  1. Download complete log files covering the incident timeframe
  2. Do not excerpt or truncate stack traces
  3. Include multiple days if issue spans time periods
  4. Note any configuration changes preceding the issue

Support teams require complete log context to diagnose complex issues effectively. Partial log snippets often lack critical information needed for resolution.

Security and Access Control

Section titled “Security and Access Control”

Role-Based Log Access

Section titled “Role-Based Log Access”

Application Log access:

  • Available to operations staff and administrators
  • Role-based access controls limit visibility based on user permissions
  • Audit trail of who accessed logs maintained
  • Sensitive authentication events visible only to security personnel

System Log access:

  • Restricted to administrators only
  • Contains sensitive technical details (connection strings, API keys in error contexts)
  • Should not be shared externally without sanitization
  • Access logged for security auditing

Sensitive Data Considerations

Section titled “Sensitive Data Considerations”

Both log systems may contain sensitive information requiring protection:

Application Logs may contain:

  • Device IP addresses and hostnames
  • Username information from authentication events
  • Configuration change details
  • Policy violation specifics

System Logs may contain:

  • Database connection credentials in exception contexts
  • API keys or tokens in request/response dumps
  • Internal architecture and code structure details
  • Stack traces revealing application logic

Organizations with strict data protection requirements should implement additional controls such as log encryption at rest, secure log transfer protocols, and automated sanitization before external sharing.

Best practices

Section titled “Best practices”

Choose the right log for the task. Application Log for operational issues, System Logs for technical and framework issues. The distinction is the fastest way to narrow down a problem.

Set appropriate log levels. Use debug only when actively troubleshooting. Production systems should run at info or warning to reduce noise and log volume.

Implement retention policies. Archive Application Logs regularly for compliance (security events often require 3+ years). System Log files can be pruned more aggressively, typically 30-90 days depending on disk space.

Protect sensitive data. Both logs may contain device IPs, usernames, and in error contexts, credentials or API keys. Restrict access and sanitise before sharing with external parties.

What’s next

Section titled “What’s next”