Configuring SNMP Alarms for Log Files

Log File Monitoring shows the properties you can set to determine which log files in the configuration are monitored.

The following shows a sample alarm log file in the YAML configuration file.

snmp-adapter:
  alarms:
    logFiles:
      - fileName: /var/log/mtx/mylog.log
        pollingFrequency: 5s

Notice that the properties include an array style index. This allows multiple file monitoring configurations to be added.

Matching Rules

The matching rules define regular expressions that are compared against each line of the monitored files. If a match is found, then an SNMP notification is sent to the SNMP NMS. The matching rules determine which parameters are sent and how they are formed. Matching Rules shows the properties you can set.

The following shows sample matching rules in the YAML configuration file.

snmp-adapter:
  alarms:
    matchingRules:
 
 
      # Specific Error Trap
      - pattern: '^\[ERROR\s*\]\s+([0-9]{4}-[0-9]{2}-[0-9]{2}\s[0-9]{2}:[0-9]{2}:[0-9]{2}.[0-9]{0,6})\s+\[.*\]\s+.*\s-\sA very specific situation has arisen because (.*)'
        trapOid: '1.3.6.1.4.1.35838.1.999.1.1'
        variables:
 
 
          # Extract the timestamp out of the log message which is captured as the first group of the regular expression
          - oid: '1.3.6.1.4.1.35838.1.999.2.1'
            type: 'string'
            template: '$1'
 
 
          # Extract the description out of the log message which is captured as the second group of the regular expression
          - oid: '1.3.6.1.4.1.35838.1.999.2.2'
            type: 'string'
            template: 'Error Message was: $2'
 
 
      # Generic Catch All Error Trap (ordered to be last)
      - pattern: '^\[ERROR\s*\]\s+([0-9]{4}-[0-9]{2}-[0-9]{2}\s[0-9]{2}:[0-9]{2}:[0-9]{2}.[0-9]{0,6})\s+\[.*\]\s+.*\s-\s(.*)'
        trapOid: '1.3.6.1.4.1.35838.1.999.1.1'
        order: 999
        variables:
 
 
          # Extract the timestamp out of the log message which is captured as the first group of the regular expression
          - oid: '1.3.6.1.4.1.35838.1.999.2.1'
            type: 'string'
            template: '$1'
 
 
          # Extract the description out of the log message which is captured as the second group of the regular expression
          - oid: '1.3.6.1.4.1.35838.1.999.2.2'
            type: 'string'
            template: '$2'

Notice that the properties include an array style index at two points. This allows multiple file matching rules to be added, with each matching rule defining multiple variables.

Configuring SNMP Alarms for Queues and Buffers

You can configure alarm thresholds on all key buffers and queues including MtxBuf, write buffers, the CAMEL Gateway input queue and the queue from the CAMEL Gateway. Threshold breaches shall be reported using SNMP and to Prometheus. This feature can be enabled by configuration. Specifically, an event monitoring system such as Prometheus can be configured to raise alarms based on the value of SNMP statistics.

In Queues, see the queues and their descriptions.

MATRIXX-COMMON-MIB::sysQueueStatsQueueName.charging.7 = blade_1_1_1_chrg.1.5.input

This means that the queue with service ID, charging and queue ID 7 has the name blade_1_1_1_chrg.1.5.input the queue from the CAMEL Gateway to the Charging Server.

MATRIXX-COMMON-MIB::sysQueueStatsFullCount.charging.7 = 57

MATRIXX-MIB::sysBufferPoolStatsPoolName.6 = blade_1_1_1_shared_buffer_pool_large_6_freequeueSo pool ID

The number of buffers in the pool is given by MATRIXX-MIB::sysBufferPoolStatsCurrentCount.<pool ID> For example, MATRIXX-MIB::sysBufferPoolStatsCurrentCount.6 = 32683 means that there are 32683 free, large buffers. You can configure the system monitoring tool to log an alarm for the number of available large buffers being nearly exhausted when the value of the above statistic drops below, as an example, 5000.