Chapter 6. Set up log forwarding


Create and verify a ClusterLogForwarder to route logs from your cluster to external destinations.

6.1. Grant collector permissions

You must grant explicit permissions to the collector service account before the ClusterLogForwarder can collect logs. Each log type requires a separate ClusterRoleBinding.

Warning

Avoid a service outage: Always create the required ClusterRoleBinding before you add a new log type to the ClusterLogForwarder custom resource (CR).

If you add a log type to your pipeline without the corresponding permissions, the Operator removes the entire collector DaemonSet. This stops all log collection for the entire cluster.

Prerequisites

  • You have installed the Red Hat OpenShift Logging Operator.
  • You have cluster-admin permissions.

Procedure

  1. Create a service account for the collector. This example creates the service account in the openshift-logging namespace, but you can deploy the collector in any namespace by running the following command:

    $ oc create sa collector -n openshift-logging
  2. Grant the service account permission to collect application logs by running the following command:

    $ oc adm policy add-cluster-role-to-user collect-application-logs \
      system:serviceaccount:openshift-logging:collector
  3. Grant the service account permission to collect infrastructure logs by running the following command:

    $ oc adm policy add-cluster-role-to-user collect-infrastructure-logs \
      system:serviceaccount:openshift-logging:collector
  4. Optional: Grant the service account permission to collect audit logs by running the following command:

    $ oc adm policy add-cluster-role-to-user collect-audit-logs \
      system:serviceaccount:openshift-logging:collector
    Note

    You can add audit log collection later. If you do, grant this ClusterRoleBinding before you add audit to the inputRefs list in your ClusterLogForwarder CR.

    Considerations for audit logs:

    • Volume and Cost: Audit logs are significantly more voluminous than application or infrastructure logs. In cloud environments, this can lead to unexpected storage and data transfer costs.
    • Sensitivity: Audit logs contain a detailed record of API activity. To protect sensitive metadata and manage data volume, consider implementing prune filters to remove specific fields before the logs are forwarded to their destination.

Verification

  • Verify that the ClusterRoleBindings exist for your service account by running the following command:

    $ oc get clusterrolebinding -o wide | grep collect

    The output shows a binding for each log type that you granted:

    Example output

    collect-application-logs     ClusterRole/collect-application-logs     11m   system:serviceaccount:openshift-logging:collector
    collect-infrastructure-logs  ClusterRole/collect-infrastructure-logs  11m   system:serviceaccount:openshift-logging:collector

6.2. Create the log forwarder

Create a ClusterLogForwarder custom resource (CR) to define your log forwarding pipeline. This CR links the collector’s service account to specific log sources, optional filters, and your chosen destination.

Prerequisites

  • You have cluster-admin permissions.
  • You have installed the Red Hat OpenShift Logging Operator in the openshift-logging namespace.
  • You have created a collector service account and granted the required ClusterRoleBindings. See "Granting collector permissions for log collection."
  • You have installed the Loki Operator and a LokiStack instance named logging-loki exists in the openshift-logging namespace if you are forwarding logs to LokiStack.
Warning

Prerequisite Check: You must have already created the collector service account and granted it the required permissions. If you reference a service account or log source without the proper ClusterRoleBinding, the Operator will shut down all log collection for the cluster.

Procedure

  1. Define the ClusterLogForwarder CR. Use the following example to forward application and infrastructure logs to an in-cluster LokiStack.

    apiVersion: observability.openshift.io/v1
    kind: ClusterLogForwarder
    metadata:
      name: instance
      namespace: openshift-logging
    spec:
      serviceAccount:
        name: collector
      outputs:
      - name: default-lokistack
        type: lokiStack
        lokiStack:
          authentication:
            token:
              from: serviceAccount
          target:
            name: logging-loki
            namespace: openshift-logging
        tls:
          ca:
            configMapName: logging-loki-gateway-ca-bundle
            key: service-ca.crt
      pipelines:
      - name: default-logstore
        inputRefs:
        - application
        - infrastructure
        outputRefs:
        - default-lokistack
    metadata.name
    The name must be instance. It is a singleton.
    spec.serviceAccount.name
    The service account that the collector uses to authenticate. This service account must have ClusterRoleBindings for each log type listed in inputRefs.
    spec.outputs[].type
    Set to lokiStack for the in-cluster LokiStack. This type uses the LokiStack gateway for authentication and multi-tenancy.
    spec.outputs[].lokiStack.target.name
    The name of your LokiStack CR. This value must strictly match the name of the LokiStack you want to forward logs to, and is not bound to a specific default.
    spec.outputs[].tls.ca.configMapName
    The ConfigMap that has the certificate authority (CA) bundle for the LokiStack gateway. Use logging-loki-gateway-ca-bundle.
    spec.outputs[].tls.ca.key

    The key in the ConfigMap that has the CA certificate. For the service-signed certificate, use service-ca.crt.

    Note

    You must include the tls.ca block in the output configuration when forwarding to LokiStack. Without it, the collector cannot verify the LokiStack gateway certificate. The ClusterLogForwarder reports Ready, but the collector fails silently and no logs reach LokiStack.

    spec.pipelines[].inputRefs
    The log types to collect. Add only log types for which the service account has ClusterRoleBindings.
  2. Apply the ClusterLogForwarder CR by running the following command:

    $ oc apply -f <filename>.yaml
  3. Verify that the ClusterLogForwarder status shows Ready by running the following command:

    $ oc get clusterlogforwarder instance -n openshift-logging \
      -o jsonpath='{.status.conditions[?(@.type=="Ready")].status}'

    The output should show True. If the output shows False, check the status.conditions for error messages:

    $ oc get clusterlogforwarder instance -n openshift-logging \
      -o jsonpath='{.status.conditions}' | python3 -m json.tool

6.2.1. Create a ClusterLogForwarder for LokiStack

After you grant collector permissions, create a ClusterLogForwarder custom resource (CR) to forward logs to the in-cluster LokiStack.

Important

You must include the tls.ca block in the output configuration. Without it, the collector cannot verify the LokiStack gateway certificate. The ClusterLogForwarder reports Ready, but the collector fails silently and no logs reach the LokiStack.

Prerequisites

  • You have installed the Red Hat OpenShift Logging Operator in the openshift-logging namespace.
  • You have installed the Loki Operator and a LokiStack instance named logging-loki exists in the openshift-logging namespace.
  • You have created a collector service account and granted the required ClusterRoleBindings. See "Granting collector permissions for log collection."
  • You have cluster-admin permissions.

Procedure

  1. Create a ClusterLogForwarder CR as a YAML file:

    apiVersion: observability.openshift.io/v1
    kind: ClusterLogForwarder
    metadata:
      name: instance
      namespace: openshift-logging
    spec:
      serviceAccount:
        name: collector
      outputs:
      - name: default-lokistack
        type: lokiStack
        lokiStack:
          authentication:
            token:
              from: serviceAccount
          target:
            name: logging-loki
            namespace: openshift-logging
        tls:
          ca:
            configMapName: logging-loki-gateway-ca-bundle
            key: service-ca.crt
      pipelines:
      - name: default-logstore
        inputRefs:
        - application
        - infrastructure
        outputRefs:
        - default-lokistack
    spec.serviceAccount.name
    The service account that the collector uses to authenticate. This service account must have ClusterRoleBindings for each log type listed in inputRefs.
    spec.outputs[].type
    Set to lokiStack for the in-cluster LokiStack. This type uses the LokiStack gateway for authentication and multi-tenancy.
    spec.outputs[].lokiStack.target.name
    The name of your LokiStack CR. This value must match the name of the LokiStack you want to forward logs to exactly. There is no default value.
    spec.outputs[].tls.ca.configMapName
    The ConfigMap that has the certificate authority (CA) bundle for the LokiStack gateway. Use logging-loki-gateway-ca-bundle.
    spec.outputs[].tls.ca.key
    The key in the ConfigMap that has the CA certificate. For the service-signed certificate, use service-ca.crt.
    spec.pipelines[].inputRefs
    The log types to collect. Add only log types for which the service account has ClusterRoleBindings.
  2. Apply the ClusterLogForwarder CR by running the following command:

    $ oc apply -f <filename>.yaml
  3. Verify that the ClusterLogForwarder status shows Ready by running the following command:

    $ oc get clusterlogforwarder instance -n openshift-logging \
      -o jsonpath='{.status.conditions[?(@.type=="Ready")].status}'

    The output should show True. If the output shows False, check the status.conditions for error messages:

    $ oc get clusterlogforwarder instance -n openshift-logging \
      -o jsonpath='{.status.conditions}' | python3 -m json.tool

6.2.2. Check status conditions

You can view the ClusterLogForwarder status conditions to verify that the CR is valid and the collector is running.

Procedure

  • View the ClusterLogForwarder status by running the following command:

    $ oc get clusterlogforwarder instance -n openshift-logging \
      -o jsonpath='{.status.conditions}' | python3 -m json.tool

    Example output

    [
        {
            "type": "observability.openshift.io/Authorized",
            "status": "True",
            "message": "permitted to collect log types: [application infrastructure]"
        },
        {
            "type": "observability.openshift.io/Valid",
            "status": "True",
            "message": ""
        },
        {
            "type": "Ready",
            "status": "True",
            "message": ""
        }
    ]

6.2.3. Status conditions

The ClusterLogForwarder reports its state through status.conditions. Use these conditions to verify that the CR is valid and the collector is running:

Table 6.1. ClusterLogForwarder status conditions
ConditionExpectedDescription

observability.openshift.io/Authorized

True

The collector service account has ClusterRoleBindings for all log types in inputRefs. The message lists the authorized log types.

observability.openshift.io/Valid

True

The CR passes schema and semantic validation.

Ready

True

The Operator reconciled the CR without error or validation failures, and can create resources to support a collector deployment.

If Authorized shows False, the collector service account lacks a required ClusterRoleBinding. The Operator removes the collector DaemonSet until you grant the missing binding.

If Valid shows False, the CR has a structural or semantic error. Check the message field for details.

6.2.4. Verify that log collection is working

After you create the ClusterLogForwarder custom resource (CR), verify that the collector is running and that logs are flowing to your destination. This verification step is critical for all stakeholders: developers need to confirm that their application logs are accessible, site reliability engineers need operational visibility, and security officers must ensure that audit logs are being captured for compliance.

Prerequisites

  • You have created a ClusterLogForwarder CR.
  • You have access to the OpenShift Container Platform web console.

Procedure

  1. Verify that the ClusterLogForwarder status conditions all show True by running the following command:

    $ oc get clusterlogforwarder instance -n openshift-logging \
      -o jsonpath='{.status.conditions}' | python3 -m json.tool

    Confirm the following conditions:

    • observability.openshift.io/Authorized is True and the message lists the log types that the collector can collect.
    • observability.openshift.io/Valid is True.
    • Ready is True.

    If Authorized shows False, the collector service account lacks a required ClusterRoleBinding. See "Granting collector permissions for log collection."

  2. Verify that a collector pod is running by running the following command:

    $ oc get pods -n openshift-logging -l app.kubernetes.io/component=collector

    Example output

    NAME               READY   STATUS    RESTARTS   AGE
    instance-jlhjw     1/1     Running   0          5m

  3. In the OpenShift Container Platform web console, go to Observe > Logs.
  4. Select a log type from the drop-down menu, such as infrastructure, and verify that log entries appear.
  5. Optional: Check the collector logs for errors by running the following command:

    $ oc logs -n openshift-logging -l app.kubernetes.io/component=collector --tail=20

Troubleshooting

  • 429 Too Many Requests: This status code can occur during initial log collection. The collector flushes a backlog of accumulated logs to the LokiStack. The error typically resolves within several minutes.
  • Certificate verification error: If you see the following error in the collector logs:

    certificate verify failed: self-signed certificate in certificate chain

    The tls.ca block is missing or incorrect in the ClusterLogForwarder output configuration. The ClusterLogForwarder still reports Ready, but the collector cannot deliver logs. See "Creating a ClusterLogForwarder for LokiStack`" for the required `tls.ca configuration.

  • Collector pod not found: If no collector pod exists, check the ClusterLogForwarder status conditions. A common cause is a missing ClusterRoleBinding for one of the log types in inputRefs. See "Granting collector permissions for log collection."
Red Hat logoGithubRedditYoutubeTwitter

Learn

Try, buy, & sell

Communities

About Red Hat

We deliver hardened solutions that make it easier for enterprises to work across platforms and environments, from the core datacenter to the network edge.

Making open source more inclusive

Red Hat is committed to replacing problematic language in our code, documentation, and web properties. For more details, see the Red Hat Blog.

About Red Hat Documentation

Legal Notice

Theme

© 2026 Red Hat
Back to top