- MATRIXX Engine Log Files
Each MATRIXX Engine server has a Log Manager that uses the rsyslog utility to collect, filter, and store messages generated during runtime for each server running in the pod. The logs can be analyzed to determine the root cause of issues that occur with the MATRIXX processes and transaction processing.
- Collect Log Files
If a server is no longer available or a critical issue occurred during processing, run the gather_logs.py script to collect MATRIXX files that can contain information relevant to the issue.
- Filter Out Entries From the Debug Log
During system runtime, you can query the debug log for a particular string of text, including words, characters, and patterns of characters, and have all logical log entries containing that expression written to a specified output file. This is useful when the debug log is large and you must isolate a specific area of functionality to understand and resolve issues.
- Turn on Trace Logging for a Subscriber
You can turn on trace logging for a subscriber during runtime by specifying a trace option such as a device IMSI or NAI (network access identifier). Turning on a trace sets the logging level for the specified gateway (Diameter Gateway, CAMEL Application Part (CAP), or both) and the Charging Server dynamically during runtime. This allows these MATRIXX processes to log trace messages to the mtx_debug.log file.
- Merge Messages from Multiple Debug Logs
You can merge the messages from multiple system logs into one log file. The result is the combined log messages ordered according to the time stamp on the LM_ line.
- Configure MTX Log Rotation
MATRIXX uses the logrotate utility to rotate the MATRIXX Engine log files, including the mtx_debug.log, mtx_diameter_error.log, and mtx_mdc_gateway_error.log. The rotation involves compressing the files for archiving purposes and then removing them. The log volume and current date are used to determine if the log files need to be rotated.