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

Cluster-Logging Loki Integration


    • CLO Loki Integration
    • False
    • None
    • False
    • Green
    • NEW
    • Done
    • OBSDA-7 - Adopting Loki as an alternative to Elasticsearch to support more lightweight, easier to manage/operate storage scenarios
    • Impediment
    • OBSDA-7Adopting Loki as an alternative to Elasticsearch to support more lightweight, easier to manage/operate storage scenarios
    • 0% To Do, 0% In Progress, 100% Done


      • Provide single-entrypoint log forwarding support for LokiStack as a new default store from cluster-logging collectors.
      • Ensure the log collectors/forwarders have end-to-end access to LokiStack pushing logs based on the current tenancy model (application, infrastructure, audit)


      • Provide single-entrypoint configuration for LokiStack custom resources via the ClusterLogging custom resource.


      The current approach to use LokiStack as the new storage solution for ClusterLogging requires to address manual steps provided by documentation. These steps include (Ref: docs):

      • Create RBAC roles and bindings for the cluster logging log collector serviceaccount to access the LokiStack resource
      • Define a ClusterLogForwarder configuration that ensures one pipeline/output to the LokiStack resource per tenant (application, infrastructure, audit).
      • Ensure that ClusterLogForwarder is using the LokiStack gateway endpoint so that proper authentication/authorization control is applied on collector requests.
      • Ensure that ClusterLogging collector configuration is use the serviceaccount oauth token mounted in the collector pods.

      All the above can and should be automated by the cluster-logging-operator upon using LokiStack as new type of log store. The above bits describe basically steps that require automation for a seamless connectivity between log collectors and LokiStack as a store.


      Continue to provide the above steps only per documentation.

      Acceptance Criteria

      • Verify that log collectors (fluentd, vector) can push logs to LokiStack using the serviceaccount token.
      • Verify that log collectors push logs based on the cuCLO Loki Integrationrent tenancy model.

      Risk and Assumptions

      • We want to keep the configuration bits in ClusterLogging/ClusterLogForwarder limited to connectivity and ensure at the same time that users don't need to figure them out.
      • We want to make it easy to identify the LokiStack instance by name instead of reconciling a LokiStack custom resource from ClusterLogging Operator. On the one hand this ensures users can tune LokiStack independently from ClusterLogging. On the other hand this requires users to properly size and install a LokiStack custom resource upfront.

      Documentation Considerations

      Given that creating a LokiStack resource is a per-requisite for using ClusterLogging with a log store type LokiStack, we need to reverse the order of installation (First LokiStack, Next ClusterLogging). In addition we need to inform the user that ClusterLogForwarder is used by default in this case.

      Open Questions

      Additional Notes

            ptsiraki@redhat.com Periklis Tsirakidis
            ptsiraki@redhat.com Periklis Tsirakidis
            Kabir Bharti Kabir Bharti
            0 Vote for this issue
            10 Start watching this issue