Uploaded image for project: 'Docs for Red Hat Developers'
  1. Docs for Red Hat Developers
  2. RHDEVDOCS-3828

Loki's tenantKey and labelKeys in ClusterLogForwarder CR is put in wrong place

    XMLWordPrintable

Details

    • Bug
    • Resolution: Done
    • Major
    • Logging 5.5
    • Logging 5.2, Logging 5.3
    • Logging
    • devex docs #222 Jul 21-Aug 11
    • 3
    • Documentation (Ref Guide, User Guide, etc.)

    Description

      What is the problem that your customer is facing?

      The example Cluster Log forwarder CR to forward logs to loki is having the parameter `loki:` in wrong place.

      Ref: https://docs.openshift.com/container-platform/4.9/logging/cluster-logging-external.html#cluster-logging-collector-log-forward-loki_cluster-logging-external

      o Current behavior for Cluster Log forwarder CR:

      Parameter `loki:` is put inside pipelines

      apiVersion: "logging.openshift.io/v1"
      kind: ClusterLogForwarder
      metadata:
        name: instance 
        namespace: openshift-logging 
      spec:
        outputs:
         - name: loki-insecure 
           type: "loki" 
           url: http://loki.insecure.com:9200 
         - name: loki-secure
           type: "loki"
           url: https://loki.secure.com:9200 
           secret:
              name: loki-secret 
        pipelines:
         - name: application-logs 
           inputRefs: 
           - application
           - audit
           outputRefs:
           - loki-secure 
           loki:
             tenantKey: kubernetes.namespace_name 
             labelKeys: kubernetes.labels.foo 

      o Expected behavior for Cluster Log forwarder CR:

      Parameter `loki:` should be inside outputs

      apiVersion: "logging.openshift.io/v1"
      kind: ClusterLogForwarder
      metadata:
        name: instance 
        namespace: openshift-logging 
      spec:
        outputs:
         - name: loki-insecure 
           type: "loki" 
           url: http://loki.insecure.com:9200
           loki:
              tenantKey: kubernetes.namespace_name
              labelKeys: kubernetes.labels.foo
         - name: loki-secure
           type: "loki"
           url: https://loki.secure.com:9200 
           secret:
              name: loki-secret
           loki:
              tenantKey: kubernetes.namespace_name
              labelKeys: kubernetes.labels.foo
        pipelines:
         - name: application-logs 
           inputRefs: 
           - application
           - audit
           outputRefs:
           - loki-secure 

      What is the business impact, if any, if this request will not be made available?

      The tenantKey and labelKeys are an important parameter in case multi-tenancy.
      Currently, the customers must be setting this in wrong place following the doc and the multi-tenancy is not working as expected.

      What are your expectations for this feature

      The document should have the ClusterLogForwarder CR as follow:

      apiVersion: "logging.openshift.io/v1"
      kind: ClusterLogForwarder
      metadata:
        name: instance 
        namespace: openshift-logging 
      spec:
        outputs:
         - name: loki-insecure 
           type: "loki" 
           url: http://loki.insecure.com:9200
           loki:
              tenantKey: kubernetes.namespace_name
              labelKeys: kubernetes.labels.foo
         - name: loki-secure
           type: "loki"
           url: https://loki.secure.com:9200 
           secret:
              name: loki-secret 
           loki:
              tenantKey: kubernetes.namespace_name
              labelKeys: kubernetes.labels.foo
        pipelines:
         - name: application-logs 
           inputRefs: 
           - application
           - audit
           outputRefs:
           - loki-secure

       

      Attachments

        Activity

          People

            landerso@redhat.com Libby Anderson
            sasagarw@redhat.com Sashank Agarwal (Inactive)
            Votes:
            0 Vote for this issue
            Watchers:
            2 Start watching this issue

            Dates

              Created:
              Updated:
              Resolved: