rConfig V8 System Logs & Application Logging - Troubleshooting Guide

rConfig V8 System Logs & Application Logging - Troubleshooting Guide

rConfig V8 implements a dual-logging architecture that separates operational business events from technical framework diagnostics. This design addresses the distinct needs of operations teams investigating device connectivity and configuration management workflows versus system administrators diagnosing application-level technical failures.

Understanding the purpose, scope, and appropriate use of each logging system enables effective troubleshooting, security monitoring, and system maintenance. Organizations can leverage this architecture to maintain comprehensive audit trails while keeping log data organized and performant at scale.

The Dual-Logging Architecture

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

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

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

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

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

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

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

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

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

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

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

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.

Integration with System Monitoring

Centralized Logging

Organizations with enterprise monitoring infrastructure can integrate rConfig logs into centralized systems:

Application Log integration:

• Export log data from database to SIEM platforms
• Configure scheduled exports to external log aggregators
• Maintain correlation IDs for cross-system event tracking
• Implement log forwarding for real-time monitoring

System Log integration:

• Configure Laravel to write to syslog in addition to files
• Forward log files to centralized log management platforms
• Use log shippers (Filebeat, Fluentd) to stream log data
• Retain local logs as backup during network outages

Alerting and Notification

Proactive monitoring reduces incident impact:

Application Log alerts:

• Configure alerts for sustained error rates exceeding thresholds
• Notify on critical security events (repeated failed authentication)
• Alert when scheduled tasks fail multiple consecutive executions
• Monitor for device connectivity patterns indicating infrastructure issues

System Log alerts:

• Alert on emergency or critical severity log entries
• Notify when log file sizes indicate repeated errors
• Monitor disk space on log partition
• Alert on framework exceptions indicating application instability

Best Practices Summary

Choose the right log for the task: Application Log for operations, System Logs for technical diagnostics. Understanding the distinction accelerates troubleshooting.

Implement appropriate retention: Archive Application Logs for compliance, delete System Logs more aggressively to manage disk space.

Set proper log levels: Use debug only when actively troubleshooting. Production systems should use info or warning to reduce noise.

Review logs proactively: Don’t wait for incidents. Regular log review identifies emerging issues before they impact operations.

Protect sensitive data: Both log systems contain information requiring access controls and careful handling during external sharing.

Coordinate with other tools: Integrate logs with monitoring platforms, ticketing systems, and backup strategies for comprehensive observability.

Related Documentation

• Application Log - Detailed guide to operational event logging
• System Logs - Framework and technical diagnostic logging
• Scheduled Tasks - Configuring automated log archival
• Horizon Queue Manager - Understanding background job processing and queue logs
• Troubleshooting Guide - Common issues and diagnostic procedures

Summary

rConfig V8’s dual-logging architecture separates operational concerns from technical diagnostics, enabling both operations teams and system administrators to access the information relevant to their roles. The Application Log captures business events in structured database tables, while System Logs preserve detailed framework diagnostics in daily rotated files.

Effective log management requires understanding when to use each system, implementing appropriate retention policies, and coordinating log analysis with broader monitoring strategies. Organizations that master this architecture gain comprehensive visibility into both what their network configuration management system is doing (Application Log) and how the underlying software is executing (System Logs), enabling rapid troubleshooting and maintaining system reliability.