Uploaded image for project: 'OpenShift Logging'
  1. OpenShift Logging
  2. LOG-4805

The log severity should be sorted from most priority to less

XMLWordPrintable

    • False
    • None
    • False
    • NEW
    • NEW
    • Hide
      Before this update, the log level was determined by a mix of structured and unstructured keywords in an unclear order. With this update, the log level is now determined in a clearly documented sequence, starting with structured keywords and, if no match is found, followed by unstructured ones.
      Show
      Before this update, the log level was determined by a mix of structured and unstructured keywords in an unclear order. With this update, the log level is now determined in a clearly documented sequence, starting with structured keywords and, if no match is found, followed by unstructured ones.
    • Bug Fix
    • Log Collection - Sprint 257, Log Collection - Sprint 258
    • Moderate

      Description of problem:

      It is observed in the collector pods the rules for matching the log level and they are not sorted from higher priority to lower priority as it should be expected to match.

      The current configuration is:

        if !exists(.level) {
          .level = "default"
          if match!(.message, r'Info|INFO|^I[0-9]+|level=info|Value:info|"level":"info"|<info>') {
            .level = "info"
          } else if match!(.message, r'Warning|WARN|^W[0-9]+|level=warn|Value:warn|"level":"warn"|<warn>') {
            .level = "warn"
          } else if match!(.message, r'Error|ERROR|^E[0-9]+|level=error|Value:error|"level":"error"|<error>') {
            .level = "error"
          } else if match!(.message, r'Critical|CRITICAL|^C[0-9]+|level=critical|Value:critical|"level":"critical"|<critical>') {
            .level = "critical"
          } else if match!(.message, r'Debug|DEBUG|^D[0-9]+|level=debug|Value:debug|"level":"debug"|<debug>') {
            .level = "debug"
          } else if match!(.message, r'Notice|NOTICE|^N[0-9]+|level=notice|Value:notice|"level":"notice"|<notice>') {
            .level = "notice"
          } else if match!(.message, r'Alert|ALERT|^A[0-9]+|level=alert|Value:alert|"level":"alert"|<alert>') {
            .level = "alert"
          } else if match!(.message, r'Emergency|EMERGENCY|^EM[0-9]+|level=emergency|Value:emergency|"level":"emergency"|<emergency>') {
            .level = "emergency"
          }
      

      Then, for example, as ` Warning` is before `Critical` or `Notice` before Alert, then, they would be matching `Warning` or `Notice` instead of `Critical` or `Alert` in case that containing in the same log line both.

      The same would happen with `Debug` that goes before of `Alert` or `Emergency`, then, a log containing `Debug` and `Alert` in the same log, it should be matching `Debug` instead of `Alert`.

      As said before, the log level priorities should be defined from the highest to the lowest priority and a good guideline is the stablished in the manual of [syslog.cong](https://linux.die.net/man/5/syslog.conf) where it indicates:

      "The priority is one of the following keywords, in ascending order: debug, info, notice, warning, warn (same as warning), err, error (same as err), crit, alert, emerg, panic (same as emerg). The keywords error, warn and panic are deprecated and should not be used anymore. The priority defines the severity of the message".

      Then, if this was followed, it should be in the collectors from top to down: emergency, alert, critical, error, warn, notice, info, debug (it's not included default here)

      Version-Release number of selected component (if applicable):

      Logging 5.8 and 5.7

      How reproducible:

      Always

      Steps to Reproduce:

      1. Deploy Logging stack and generate a single log line where the contain could match `Debug` instead of `Alert`.

      Actual results:

      Observe as the log level asigned is `Debug` instead of the expected `Alert`

      Expected results:

      The matched log level is `Alert` since it has the highest priority

            rh-ee-calee Calvin Lee
            rhn-support-ocasalsa Oscar Casal Sanchez
            Votes:
            0 Vote for this issue
            Watchers:
            5 Start watching this issue

              Created:
              Updated:
              Resolved: