Uploaded image for project: 'Observability Documentation'
  1. Observability Documentation
  2. OBSDOCS-1016

[enterprise-4.14] Issue in file observability/logging/log_collection_forwarding/configuring-log-forwarding.adoc

XMLWordPrintable

    • False
    • Hide

      None

      Show
      None
    • False

      Public docs example: Configuring log forwarding

      Description of problem:

      Description of tuning parameters are incorrect/incomplete

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

      Logging 5.9

      How reproducible:

      Always

      Steps to Reproduce:

      Documentation

      Actual information:
      Document suggests that tuning parameters are in the spec part of ClusterLogForwarder:

      apiVersion: logging.openshift.io/v1
      kind: ClusterLogForwarder
      metadata:
      # ...
      spec:
        tuning:
          delivery: AtLeastOnce
          compression: none
          maxWrite: <integer>
          minRetryDuration: 1s
          maxRetryDuration: 1s
       
      Also, minRetryDuration and maxRetryDuration are claimed to be strings with a s,m etc suffix

      Expected information:

      Required tuning config location in the CR is actually under the output:

      apiVersion: logging.openshift.io/v1
      kind: ClusterLogForwarder
      metadata:
      # ...
      spec:
        outputs:
        - name: example-output
          tuning:
            delivery: AtLeastOnce
            compression: none
            maxWrite: <integer>
            minRetryDuration: 1
            maxRetryDuration: 30
      ...
      Additionally, minRetryDuration and maxRetryDuration are required to be integer number of seconds. They are translated to the `retry_initial_backoff_secs` and `retry_max_duration_secs` parameters in vector.toml and using the example of "1s" results in the CLF being rejected because of a string being where an integer was expected.

      Additional info:

      ALSO, the description of the tuning.delivery parameters is incomplete. The description of AtLeastOnce  and AtMostOnce  talk mostly about how they affect collector restart or crashes. However ... they also affect the behaviour when an output's destination is unavailable or slow. They ultimately effect the buffer `when_full` parameter in vector.toml: more info can be seen in Vector docs, eg: Vector documentation - if AtLeastOnce is selected, `when_full` is set to the default of `block` - this means that a slow or failing log destination can cause ALL logging to halt due to backpressure. It's also possible that the node filesystems will fill up when log rotation is impaired, if AtLeastOnce is selected and the log destination is unreliable.

              bdooley@redhat.com Brian Dooley
              rh-ee-gellner Gareth Ellner
              Votes:
              0 Vote for this issue
              Watchers:
              1 Start watching this issue

                Created:
                Updated: