- Configuring MATRIXX Engine Logging
The topics in this section provide information about maintaining, monitoring, and resolving problems with a MATRIXX Engine installation.
- Network Enabler Logging in Kubernetes
Network Enabler (NE) logs in a MATRIXX installation for Docker and Kubernetes must be written to a persistent volume so that they are retained if a NE container is re-created.
- Changing System Logging Behavior
Follow the procedures in this section to change the default rsyslog behavior and the log level for a MATRIXX business application or component.
- Logging and Alerts
Cloud native MATRIXX installations can replace or remove containers in the process of scaling or failure recovery. This presents challenges such as insuring log data persists after a container has been removed or replaced, and requiring to be able to view and search logs without having to log in to many individual containers.
- Using Logs to Troubleshoot Problems
This section contains information to help identify and resolve system problems.
- Java-Based Container Logging
Log output from applications running in containers must be written to persistent storage outside of the container to be preserved when the container is recreated after a failure or at application start.
- Topology Operator Logging
Topology Operator and related components can be configured to log to STDOUT or a persistent volume (PV), similar to other MATRIXX components.