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 Copy linkLink copied to clipboard!
You must grant explicit permissions to the collector service account before the ClusterLogForwarder can collect logs. Each log type requires a separate ClusterRoleBinding.
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-adminpermissions.
Procedure
Create a service account for the collector. This example creates the service account in the
openshift-loggingnamespace, but you can deploy the collector in any namespace by running the following command:$ oc create sa collector -n openshift-loggingGrant 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:collectorGrant 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:collectorOptional: 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:collectorNoteYou can add audit log collection later. If you do, grant this
ClusterRoleBindingbefore you addauditto theinputRefslist in yourClusterLogForwarderCR.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
prunefilters to remove specific fields before the logs are forwarded to their destination.
Verification
Verify that the
ClusterRoleBindingsexist for your service account by running the following command:$ oc get clusterrolebinding -o wide | grep collectThe 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 Copy linkLink copied to clipboard!
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-adminpermissions. -
You have installed the Red Hat OpenShift Logging Operator in the
openshift-loggingnamespace. -
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
LokiStackinstance namedlogging-lokiexists in theopenshift-loggingnamespace if you are forwarding logs to LokiStack.
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
Define the
ClusterLogForwarderCR. Use the following example to forward application and infrastructure logs to an in-clusterLokiStack.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-lokistackmetadata.name-
The
namemust beinstance. It is a singleton. spec.serviceAccount.name-
The service account that the collector uses to authenticate. This service account must have
ClusterRoleBindingsfor each log type listed ininputRefs. spec.outputs[].type-
Set to
lokiStackfor the in-clusterLokiStack. This type uses theLokiStackgateway for authentication and multi-tenancy. spec.outputs[].lokiStack.target.name-
The name of your
LokiStackCR. This value must strictly match the name of theLokiStackyou want to forward logs to, and is not bound to a specific default. spec.outputs[].tls.ca.configMapName-
The
ConfigMapthat has the certificate authority (CA) bundle for theLokiStackgateway. Uselogging-loki-gateway-ca-bundle. spec.outputs[].tls.ca.keyThe key in the
ConfigMapthat has the CA certificate. For the service-signed certificate, useservice-ca.crt.NoteYou must include the
tls.cablock in the output configuration when forwarding to LokiStack. Without it, the collector cannot verify theLokiStackgateway certificate. TheClusterLogForwarderreportsReady, but the collector fails silently and no logs reachLokiStack.spec.pipelines[].inputRefs-
The log types to collect. Add only log types for which the service account has
ClusterRoleBindings.
Apply the
ClusterLogForwarderCR by running the following command:$ oc apply -f <filename>.yamlVerify that the
ClusterLogForwarderstatus showsReadyby 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 showsFalse, check thestatus.conditionsfor 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 Copy linkLink copied to clipboard!
After you grant collector permissions, create a ClusterLogForwarder custom resource (CR) to forward logs to the in-cluster LokiStack.
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-loggingnamespace. -
You have installed the Loki Operator and a
LokiStackinstance namedlogging-lokiexists in theopenshift-loggingnamespace. -
You have created a collector service account and granted the required
ClusterRoleBindings. See "Granting collector permissions for log collection." -
You have
cluster-adminpermissions.
Procedure
Create a
ClusterLogForwarderCR 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-lokistackspec.serviceAccount.name-
The service account that the collector uses to authenticate. This service account must have
ClusterRoleBindingsfor each log type listed ininputRefs. spec.outputs[].type-
Set to
lokiStackfor the in-clusterLokiStack. This type uses theLokiStackgateway for authentication and multi-tenancy. spec.outputs[].lokiStack.target.name-
The name of your
LokiStackCR. This value must match the name of theLokiStackyou want to forward logs to exactly. There is no default value. spec.outputs[].tls.ca.configMapName-
The
ConfigMapthat has the certificate authority (CA) bundle for theLokiStackgateway. Uselogging-loki-gateway-ca-bundle. spec.outputs[].tls.ca.key-
The key in the
ConfigMapthat has the CA certificate. For the service-signed certificate, useservice-ca.crt. spec.pipelines[].inputRefs-
The log types to collect. Add only log types for which the service account has
ClusterRoleBindings.
Apply the
ClusterLogForwarderCR by running the following command:$ oc apply -f <filename>.yamlVerify that the
ClusterLogForwarderstatus showsReadyby 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 showsFalse, check thestatus.conditionsfor error messages:$ oc get clusterlogforwarder instance -n openshift-logging \ -o jsonpath='{.status.conditions}' | python3 -m json.tool
6.2.2. Check status conditions Copy linkLink copied to clipboard!
You can view the ClusterLogForwarder status conditions to verify that the CR is valid and the collector is running.
Procedure
View the
ClusterLogForwarderstatus by running the following command:$ oc get clusterlogforwarder instance -n openshift-logging \ -o jsonpath='{.status.conditions}' | python3 -m json.toolExample 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 Copy linkLink copied to clipboard!
The ClusterLogForwarder reports its state through status.conditions. Use these conditions to verify that the CR is valid and the collector is running:
| Condition | Expected | Description |
|---|---|---|
|
|
|
The collector service account has |
|
|
| The CR passes schema and semantic validation. |
|
|
| 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 Copy linkLink copied to clipboard!
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
ClusterLogForwarderCR. - You have access to the OpenShift Container Platform web console.
Procedure
Verify that the
ClusterLogForwarderstatus conditions all showTrueby running the following command:$ oc get clusterlogforwarder instance -n openshift-logging \ -o jsonpath='{.status.conditions}' | python3 -m json.toolConfirm the following conditions:
-
observability.openshift.io/AuthorizedisTrueand the message lists the log types that the collector can collect. -
observability.openshift.io/ValidisTrue. -
ReadyisTrue.
If
AuthorizedshowsFalse, the collector service account lacks a requiredClusterRoleBinding. See "Granting collector permissions for log collection."-
Verify that a collector pod is running by running the following command:
$ oc get pods -n openshift-logging -l app.kubernetes.io/component=collectorExample output
NAME READY STATUS RESTARTS AGE instance-jlhjw 1/1 Running 0 5m- In the OpenShift Container Platform web console, go to Observe > Logs.
- Select a log type from the drop-down menu, such as infrastructure, and verify that log entries appear.
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 chainThe
tls.cablock is missing or incorrect in theClusterLogForwarderoutput configuration. TheClusterLogForwarderstill reportsReady, but the collector cannot deliver logs. See "Creating aClusterLogForwarderforLokiStack`" for the required `tls.caconfiguration.-
Collector pod not found: If no collector pod exists, check the
ClusterLogForwarderstatus conditions. A common cause is a missingClusterRoleBindingfor one of the log types ininputRefs. See "Granting collector permissions for log collection."