Home
MATRIXX Monitoring and Logging
Logging
The following describes logging information for MATRIXX.
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.
Generating Alerts From Log Data
After Fluent Bit is configured to scrape the logs from persistent storage as explained in the log aggregation section, the User can define Alert rules using the Kibana web interface to generate Alerts for specific log types such as Alerts for Log Level "ERROR" or "FATAL" or "CRITICAL." These Alerts can be configured to be triggered upon meeting a certain threshold as required for monitoring the system. For more details, see the Kibana Guide and the ElasticSearch Official Guide.

Welcome
MATRIXX Release Notes
MATRIXX Architecture
MATRIXX Installation and Upgrade
MATRIXX Configuration
MATRIXX Security
MATRIXX Integration
MATRIXX Diameter Integration
MATRIXX Call Control Framework Integration
MATRIXX TM Forum Integration
MATRIXX 5G Integration
MATRIXX 5G Event Streaming
MATRIXX Event Streaming
MATRIXX Administration
MATRIXX Web App Administration
MATRIXX Monitoring and Logging
- About MATRIXX Monitoring and Logging
  MATRIXX Monitoring and Logging describes monitoring and logging for MATRIXX components in a MATRIXX environment.
- Metrics and Alerts
  The following information describes monitoring metrics and alerts information for MATRIXX. MATRIXX Support recommends using the Prometheus and Grafana third-party products to monitor a MATRIXX environment, along with aggregated logging.
- Logging
  The following describes logging information for MATRIXX.
  - 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.
    - View System Logs
      You can view several MATRIXX log files to gather information about runtime processing, including mtx_debug.log, diameter_error_mdc.log, mdc_gateway_error_mdc.log, mtx_cmd.log, and storage_commands.log.
    - Configuring Logging Levels with JVM Properties
      In cloud native environments, change logging levels for MATRIXX applications and components with JVM properties.
    - Aggregating Logs
      All MATRIXX components produce log output used for debugging any issues that may arise in the system. In a Kubernetes environment, you can view and search logs without having to log in to individual Kubernetes pods. To persist logs in a cloud native environment, use a log aggregator, which collects log output and sends it to persistent storage where it can be queried. This document describes the reference architecture for handling MATRIXX logs in a Kubernetes environment.
    - Generating Alerts From Log Data
      After Fluent Bit is configured to scrape the logs from persistent storage as explained in the log aggregation section, the User can define Alert rules using the Kibana web interface to generate Alerts for specific log types such as Alerts for Log Level "ERROR" or "FATAL" or "CRITICAL." These Alerts can be configured to be triggered upon meeting a certain threshold as required for monitoring the system. For more details, see the Kibana Guide and the ElasticSearch Official Guide.
    - Log Rotation Triggering Policy
      Log rotation rollover in MATRIXX gateways and web apps is triggered based on file size and a maximum number of files.
  - 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.
- Tracing
  The following information describes tracing information for MATRIXX.
- Monitoring Components
  The following information describes monitoring different components for MATRIXX.
- Appendixes
MATRIXX Policy
MATRIXX Kafka CDR Consumer
MATRIXX Pricing and Rating
MATRIXX Pay Now
MATRIXX Subscriber Management
MATRIXX Subscriber Management API
MATRIXX Business API SDK
My MATRIXX Help
MATRIXX Backoffice Customer Tool Help
MATRIXX Third-Party Licenses
Glossary

Generating Alerts From Log Data

After Fluent Bit is configured to scrape the logs from persistent storage as explained in the log aggregation section, the User can define Alert rules using the Kibana web interface to generate Alerts for specific log types such as Alerts for Log Level "ERROR" or "FATAL" or "CRITICAL." These Alerts can be configured to be triggered upon meeting a certain threshold as required for monitoring the system. For more details, see the Kibana Guide and the ElasticSearch Official Guide.

For more information about ElasticSearch and Kibana, see the discussion about cloud native logging and alerts, and also see the discussion about cloud native infrastructure requirements in MATRIXX Installation and Upgrade.