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

    • Icon: Bug Bug
    • Resolution: Done
    • Icon: Major 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.)

      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

       

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

                Created:
                Updated:
                Resolved: