Memory Logging Infrastructure for Timing Processes

Benefits of Memory Logging Infrastructure for Timing Processes

• Enhance debugging efficiency by providing detailed logging of critical and operational events for quicker identification and resolution of system issues.

• Improve system resilience through effective log management, capturing significant issues and documenting operational details for future analysis.

• Support seamless integration with timing processes, such as clock synchronize processes, clksyncd and clksyncm, enabling consistent performance monitoring and troubleshooting across platforms.

• Ensure operational continuity by enabling log handling features like dump-on-wrap, maintaining log records even during system restarts or configuration changes.

Overview

The Memory Logging Infrastructure for timing processes provides a sophisticated mechanism for capturing and managing log data that are crucial for troubleshooting and enhancing system resilience. Critical logs highlight significant issues needing immediate attention and primary logs document operational details essential for ongoing system analysis.

By storing these logs in heap memory, you gain access to crucial debugging information even during high-demand operations. Efficiently categorized logs facilitate troubleshooting and ensure that critical events are not overlooked during system evaluations.

To effectively manage the in-memory logs, several CLI commands are available:

• Memory logging is enabled by default on MX240, MX480, MX960, MX10004, MX10008, MX9608, MX2010, MX2020, MX10016, MX10001, and MX10002 platforms. You can disable memory logging for specific processes using the set protocols clock-synchronization memory-logging clksyncd memory-log-disable (for clksyncd) or set protocols clock-synchronization memory-logging lc-clocking memory-log-disable (for clksyncm) commands.

• Viewing logs is possible through the show chassis synchronization memory-logging messages command and the show chassis synchronization memory-logging summary command provides a summary of the memory logging.

• For targeted troubleshooting, filter logs by specific tags using the show chassis synchronization memory-logging messages <tags> command.

• When logs are no longer needed or require resetting, use the clear chassis synchronization memory-logging all-logs or clear chassis synchronization memory-logging priority-logs command to clear the entries, optimizing your log buffer for capturing new events.

• The infrastructure supports advanced features like dumping logs to files with the set protocols clock-synchronization memory-logging clksyncd file-dump-on-wrap command for clksyncd when buffers are full, preventing data loss and managing system resources efficiently. This dump-on-wrap capability allows continued log operation even when the system approaches maximum buffer capacity, preserving data integrity during high-activity periods or unexpected system restarts. This feature is not enabled by default, and must be enabled if it is required.

By understanding and configuring these features, you can leverage the full potential of the memory logging infrastructure to enhance your network's operational visibility and performance management.

Considerations

• Critical logs and priority logs are enabled by default. However, when memory logging is disabled, both critical and priority logs are disabled.

• If the critical log buffer is full and additional critical logs come in, those will be logged in the priority log section. Note that the priority log buffer can be rolled over.

• Dump-on-wrap is not enabled by default. When priority logs are full, then both the existing priority and critical logs will be written on to a file (in /var/log/) when dump-on-wrap is enabled for the process. However, when dump-on-wrap is not enabled, the priority logs are overwritten starting from the first one when the buffer is full. No. of buffer wraps shown in the output of the command show chassis synchronizaton memory-logging summary indicates the number of times the buffer has gotten full.

• A maximum of 256 critical logs and 768 priority logs can be stored by each process.

• Logs might be lost during process or system restarts.