1. Plan and prepare (complete BEFORE installing operators):

   • Verify cluster prerequisites (StorageClass availability)
   • Configure object storage backend with TLS certificates
   • Choose initial deployment size based on cluster size (cannot calculate actual log volume until after installation)
   • Verify cluster has sufficient CPU, memory, and storage capacity for the initial size

2. Install operators:

   • Install the Loki Operator
   • Install the Red Hat OpenShift Logging Operator

3. Configure and deploy:

   • Create LokiStack custom resource with initial size
   • Create ClusterLogForwarder custom resource for log collection
   • Verify log collection and storage

4. Optimize after deployment (24+ hours after installation):

   • Measure actual log ingestion rate using metrics
   • Adjust LokiStack size if needed based on observed log volume
   • Monitor resource utilization

Procedure

1. List available StorageClass resources:

   $ oc get storageclass

   Copy code to clipboard

2. Identify the StorageClass you will use for LokiStack. It can be the default StorageClass (marked with (default)) or any other available StorageClass:

   $ oc get storageclass -o=jsonpath='{.items[?(@.metadata.annotations.storageclass\.kubernetes\.io/is-default-class=="true")].metadata.name}'

   Copy code to clipboard

3. Verify the StorageClass supports block storage (strongly recommended for Loki performance):

   Look for a provisioner such as ebs.csi.aws.com, csi.vsphere.vmware.com, openshift-storage.ceph.rbd, or similar.

   Important

   Loki supports both block and filesystem storage, but filesystem storage introduces significant performance issues and is not recommended for production deployments. Always use block storage (volumeMode: Block) when available.

4. Verify the StorageClass has sufficient available capacity:

   Check the disk space requirements from the Loki sizing table. For example, 1x.medium with ruler requires 910 GiB of total disk capacity across all PVCs.

Procedure

1. Create the project, if it does not exist, by running the following command:

   $ oc adm new-project openshift-local-storage

   Copy code to clipboard
2. Install the Local Storage Operator from OperatorHub (Web Console) or via Subscription YAML. Use the stable channel.

3. Create a LocalVolume CR for block devices (recommended for Loki):

   Example: localvolume-block.yaml

   apiVersion: local.storage.openshift.io/v1
   kind: LocalVolume
   metadata:
     name: local-block
     namespace: openshift-local-storage
   spec:
     nodeSelector:
       nodeSelectorTerms:
       - matchExpressions:
         - key: kubernetes.io/hostname
           operator: In
           values:
           - <your_node_name>
     storageClassDevices:
     - storageClassName: local-block
       volumeMode: Block
       devicePaths:
       - /dev/disk/by-id/<device_id>
       fsType: ""

   Copy code to clipboard

   <your_node_name>

   Replace with your node name or use node labels for selection.

   storageClassName: local-block

   This value becomes your new StorageClass name.

   <device_id>

   Use stable by-id paths for device identification.

4. Apply it by running the following command:

   $ oc apply -f localvolume-block.yaml

   Copy code to clipboard

5. Verify the new StorageClass by running the following command:

   $ oc get storageclass local-block

   Copy code to clipboard
6. Optional: Make it the default StorageClass.

Procedure

1. Extract the CA certificate from your storage provider by running the following command. For example, if using S3 Compatible storage, you can use openssl:

   $ openssl s_client -connect <storage_endpoint>:<port> -showcerts </dev/null 2>/dev/null | openssl x509 -out storage-ca.crt

   Copy code to clipboard
   Note

   If you are using OpenShift Data Foundation Ceph RGW (provided by the NooBaa service in Rook deployments), you might need to use the openshift-service-ca.crt from the openshift-service-ca config map.

2. Create a ConfigMap in the openshift-logging namespace containing the CA certificate by running the following command:

   $ oc create configmap loki-s3-ca-bundle \
       -n openshift-logging \
       --from-file=ca-bundle.crt=./storage-ca.crt

   Copy code to clipboard

3. Reference the CA bundle ConfigMap in your LokiStack custom resource (CR) under spec.storage.tls:

   apiVersion: loki.storage.openshift.io/v1
   kind: LokiStack
   metadata:
     name: logging-loki
     namespace: openshift-logging
   spec:
     storage:
       schemas:
       - version: v13
         effectiveDate: "2024-10-01"
       secret:
         name: logging-loki-s3
         type: s3
       tls:
         caName: loki-s3-ca-bundle
     storageClassName: <storage_class_name>
     tenants:
       mode: openshift-logging

   Copy code to clipboard

   The caName field references the ConfigMap created in step 2.

Procedure

1. Create an object storage secret with the name logging-loki-s3:

   For standard AWS authentication:

   $ oc create secret generic logging-loki-s3 \
     -n openshift-logging \
     --from-literal=bucketnames="<bucket_name>" \
     --from-literal=endpoint="https://s3.<region>.amazonaws.com" \
     --from-literal=access_key_id="<aws_access_key_id>" \
     --from-literal=access_key_secret="<aws_access_key_secret>" \
     --from-literal=region="<aws_region>"

   Copy code to clipboard

   For clusters with Security Token Service (STS) enabled:

   $ oc -n openshift-logging create secret generic "logging-loki-s3" \
     --from-literal=bucketnames="<s3_bucket_name>" \
     --from-literal=region="<bucket_region>" \
     --from-literal=audience="<oidc_audience>"

   Copy code to clipboard

Procedure

1. Obtain the service account credentials from Google Cloud and save them as key.json.

2. Create an object storage secret with the name logging-loki-s3:

   $ oc create secret generic logging-loki-s3 \
     -n openshift-logging \
     --from-literal=bucketname="<bucket_name>" \
     --from-file=key.json="./key.json"

   Copy code to clipboard

Procedure

1. Create an object storage secret with the name logging-loki-s3:

   For standard Azure authentication:

   $ oc create secret generic logging-loki-s3 \
     -n openshift-logging \
     --from-literal=container="<azure_container_name>" \
     --from-literal=environment="<azure_environment>" \
     --from-literal=account_name="<azure_account_name>" \
     --from-literal=account_key="<azure_account_key>"

   Copy code to clipboard

   Supported environment values are AzureGlobal, AzureChinaCloud, AzureGermanCloud, or AzureUSGovernment.

   For clusters with Microsoft Entra Workload ID enabled:

   $ oc -n openshift-logging create secret generic logging-loki-s3 \
     --from-literal=environment="<azure_environment>" \
     --from-literal=account_name="<storage_account_name>" \
     --from-literal=container="<container_name>"

   Copy code to clipboard

Procedure

1. Create an object storage secret with the name logging-loki-s3:

   $ oc create secret generic logging-loki-s3 \
     -n openshift-logging \
     --from-literal=bucketnames="<bucket_name>" \
     --from-literal=endpoint="<s3_endpoint_url>" \  1
     --from-literal=access_key_id="<access_key>" \
     --from-literal=access_key_secret="<secret_key>" \
     --from-literal=forcepathstyle="true"  2

   Copy code to clipboard

   1

   The full endpoint URL, including protocol and port (for example, https://s3.example.com:9000). Do NOT include the bucket name in the endpoint.

   2

   The forcepathstyle="true" parameter is required for S3 Compatible storage. This is NOT used for AWS S3.

2. If your S3 Compatible storage uses self-signed certificates or an internal CA, configure the TLS CA bundle. Follow Configuring a TLS CA bundle for object storage.

   Important

   Skipping the CA bundle configuration when using self-signed certificates causes logs to be silently dropped. The LokiStack shows Ready but logs are not stored.

Procedure

1. Create an ObjectBucketClaim custom resource in the openshift-logging namespace:

   apiVersion: objectbucket.io/v1alpha1
   kind: ObjectBucketClaim
   metadata:
     name: loki-bucket-odf
     namespace: openshift-logging
   spec:
     generateBucketName: loki-bucket-odf
     storageClassName: openshift-storage.ceph.rbd  1

   Copy code to clipboard

   1

   For OpenShift Data Foundation deployments, use openshift-storage.ceph.rbd for block storage. The object storage endpoint is provided via Ceph RGW (RADOS Gateway), also known as NooBaa in Rook implementations.

2. Get the bucket properties and credentials from the associated ConfigMap and Secret objects.

3. Create an object storage secret with the name logging-loki-s3:

   $ oc create -n openshift-logging secret generic logging-loki-s3 \
     --from-literal=access_key_id="<access_key_id>" \
     --from-literal=access_key_secret="<secret_access_key>" \
     --from-literal=bucketnames="<bucket_name>" \
     --from-literal=endpoint="https://<bucket_host>:<bucket_port>" \
     --from-literal=forcepathstyle="true"

   Copy code to clipboard

4. Optional: If your Ceph RGW installation uses self-signed certificates, follow Configuring a TLS CA bundle for object storage.

   Note

   If using the default Red Hat OpenShift Data Foundation Ceph RGW endpoint (NooBaa service in Rook deployments), you might need to use the service CA certificate.

Procedure

1. Create a Namespace object for the Loki Operator:

   apiVersion: v1
   kind: Namespace
   metadata:
     name: openshift-operators-redhat
     labels:
       openshift.io/cluster-monitoring: "true"

   Copy code to clipboard

   metadata.name

   You must specify openshift-operators-redhat as the namespace for the Loki Operator. The openshift-operators namespace might contain community Operators, which are untrusted and could publish metrics with the same name as OpenShift Container Platform metrics, causing conflicts.

   metadata.labels."openshift.io/cluster-monitoring"

   A string value that enables cluster monitoring to scrape this namespace.

2. Apply the Namespace object by running the following command:

   $ oc apply -f <filename>.yaml

   Copy code to clipboard

3. Create an OperatorGroup object:

   apiVersion: operators.coreos.com/v1
   kind: OperatorGroup
   metadata:
     name: loki-operator
     namespace: openshift-operators-redhat
   spec:
     upgradeStrategy: Default

   Copy code to clipboard

4. Apply the OperatorGroup object by running the following command:

   $ oc apply -f <filename>.yaml

   Copy code to clipboard

5. Create a Subscription object for the Loki Operator:

   apiVersion: operators.coreos.com/v1alpha1
   kind: Subscription
   metadata:
     name: loki-operator
     namespace: openshift-operators-redhat
   spec:
     channel: stable-6.4
     installPlanApproval: Automatic
     name: loki-operator
     source: redhat-operators
     sourceNamespace: openshift-marketplace

   Copy code to clipboard

   spec.channel

   Specify stable-6.4 as the channel.

   spec.installPlanApproval

   If the approval strategy in the subscription is set to Automatic, the update process initiates as soon as a new Operator version is available in the selected channel. If the approval strategy is set to Manual, you must manually approve pending updates.

   spec.source

   Specify redhat-operators as the value. If your OpenShift Container Platform cluster is installed on a restricted network, also known as a disconnected cluster, specify the name of the CatalogSource object that you created when you configured Operator Lifecycle Manager (OLM).

   Warning

   A community loki-operator package also exists in the community-operators catalog source. You must specify redhat-operators to install the supported Red Hat version. Using the wrong source installs the upstream community version with different channel names.

6. Apply the Subscription object by running the following command:

   $ oc apply -f <filename>.yaml

   Copy code to clipboard

7. Verify that the operator installed successfully by running the following command:

   $ oc get csv -n openshift-operators-redhat

   Copy code to clipboard

   You get an output similar to the following example:

   NAME                                     DISPLAY         VERSION                PHASE
   loki-operator.v6.4.0   Loki Operator   6.4.0     Succeeded

   Copy code to clipboard

Procedure

1. In the OpenShift Container Platform web console Administrator perspective:

   • For OpenShift Container Platform 4.19 or earlier, click Operators → OperatorHub.
   • For OpenShift Container Platform 4.20 or later, click Ecosystem → Software Catalog.

2. Type Loki Operator in the Filter by keyword field. Click Loki Operator in the list of available Operators, and then click Install.

   Important

   The Community Loki Operator is not supported by Red Hat. Select the operator provided by Red Hat.

3. Select stable-6.4 as the Update channel.

   The Loki Operator must be deployed to the global Operator group namespace openshift-operators-redhat, so the Installation mode and Installed Namespace are already selected. If this namespace does not already exist, it is created for you.

4. Select Enable Operator-recommended cluster monitoring on this namespace.

   This option sets the openshift.io/cluster-monitoring: "true" label in the Namespace object. You must select this option to ensure that cluster monitoring scrapes the openshift-operators-redhat namespace.

5. For Update approval select Automatic, then click Install.

   Note

   An Operator might display a Failed status before the installation completes. If the Operator installation completes with an InstallSucceeded message, refresh the page.

Verification

1. Navigate to the Installed Operators page.
2. Verify that the Loki Operator displays with a Status of Succeeded.

Procedure

1. Create a Namespace object:

   apiVersion: v1
   kind: Namespace
   metadata:
     name: openshift-logging
     labels:
       openshift.io/cluster-monitoring: "true"

   Copy code to clipboard

   metadata.name

   The openshift-logging namespace is dedicated for all logging workloads.

   metadata.labels."openshift.io/cluster-monitoring"

   A string value that enables cluster monitoring to scrape this namespace.

2. Apply the Namespace object by running the following command:

   $ oc apply -f <filename>.yaml

   Copy code to clipboard

Procedure

1. Create a Secret object with your object storage credentials. For provider-specific parameters, see the storage configuration documentation.

   Example Secret object for AWS S3

   apiVersion: v1
   kind: Secret
   metadata:
     name: logging-loki-s3
     namespace: openshift-logging
   stringData:
     access_key_id: <your_access_key_id>
     access_key_secret: <your_secret_access_key>
     bucketnames: <your_bucket_name>
     endpoint: <your_s3_endpoint>
     region: <your_region>

   Copy code to clipboard

   metadata.name

   Use the name logging-loki-s3 to match the reference in the LokiStack CR.

   metadata.namespace

   You must create this secret in the openshift-logging namespace.

   access_key_id

   Your S3 access key ID.

   access_key_secret

   Your S3 secret access key.

   bucketnames

   The name of a pre-created S3 bucket, for example loki.

   endpoint

   The full endpoint URL. For AWS: https://s3.<region>.amazonaws.com. For S3 Compatible storage: https://s3.example.com:9000.

   region

   The S3 region, for example us-east-1.

   Note

   The field names access_key_id, access_key_secret, bucketnames, and endpoint are specific to the Loki Operator. They do not match the standard AWS SDK environment variable names.

2. Apply the Secret object by running the following command:

   $ oc apply -f <filename>.yaml

   Copy code to clipboard

Procedure

1. Create an OperatorGroup object:

   apiVersion: operators.coreos.com/v1
   kind: OperatorGroup
   metadata:
     name: cluster-logging
     namespace: openshift-logging
   spec:
     upgradeStrategy: Default

   Copy code to clipboard

2. Apply the OperatorGroup object by running the following command:

   $ oc apply -f <filename>.yaml

   Copy code to clipboard

3. Create a Subscription object for the Red Hat OpenShift Logging Operator:

   apiVersion: operators.coreos.com/v1alpha1
   kind: Subscription
   metadata:
     name: cluster-logging
     namespace: openshift-logging
   spec:
     channel: stable-6.4
     installPlanApproval: Automatic
     name: cluster-logging
     source: redhat-operators
     sourceNamespace: openshift-marketplace

   Copy code to clipboard

   spec.channel

   Specify stable-6.4 as the channel. This must match the channel used for the Loki Operator.

   spec.source

   Specify redhat-operators as the value. If your OpenShift Container Platform cluster is installed on a restricted network, specify the name of the CatalogSource object you created when you configured OLM.

4. Apply the Subscription object by running the following command:

   $ oc apply -f <filename>.yaml

   Copy code to clipboard

5. Verify that the operator installed successfully by running the following command:

   $ oc get csv -n openshift-logging

   Copy code to clipboard

   You get an output similar to the following example:

   NAME                                            DISPLAY                      VERSION                       PHASE
   cluster-logging.v6.4.0   Red Hat OpenShift Logging   6.4.0     Succeeded

   Copy code to clipboard

Procedure

1. Create a service account for the log collector:

   $ oc create sa logging-collector -n openshift-logging

   Copy code to clipboard

2. Assign the required cluster roles to the service account:

   $ oc adm policy add-cluster-role-to-user logging-collector-logs-writer \
       -z logging-collector -n openshift-logging

   Copy code to clipboard

   $ oc adm policy add-cluster-role-to-user collect-application-logs \
       -z logging-collector -n openshift-logging

   Copy code to clipboard

   $ oc adm policy add-cluster-role-to-user collect-infrastructure-logs \
       -z logging-collector -n openshift-logging

   Copy code to clipboard
   Note

   These three cluster roles are created by the Red Hat OpenShift Logging Operator:

   • logging-collector-logs-writer: Allows writing logs to the LokiStack.
   • collect-application-logs: Allows reading application container logs.
   • collect-infrastructure-logs: Allows reading infrastructure container logs.

   If you also want to collect audit logs, add the collect-audit-logs cluster role.

Procedure

1. Create a ClusterLogForwarder CR:

   apiVersion: observability.openshift.io/v1
   kind: ClusterLogForwarder
   metadata:
     name: instance
     namespace: openshift-logging
   spec:
     serviceAccount:
       name: collector
     outputs:
     - name: lokistack-out
       type: lokiStack
       lokiStack:
         target:
           name: logging-loki
           namespace: openshift-logging
         authentication:
           token:
             from: serviceAccount
       tls:
         ca:
           key: service-ca.crt
           configMapName: logging-loki-gateway-ca-bundle
     pipelines:
     - name: infra-app-logs
       inputRefs:
       - application
       - infrastructure
       outputRefs:
       - lokistack-out

   Copy code to clipboard

   spec.serviceAccount.name

   Specify the service account created in the previous step.

   outputs[0].type

   Select the lokiStack output type to send logs to the LokiStack instance.

   outputs[0].lokiStack.target.name

   Must match the name of the LokiStack instance you created.

   outputs[0].tls.ca

   Required. The LokiStack gateway uses the OpenShift service-serving CA for TLS. Without this block, the collector fails with certificate verify failed: self-signed certificate in certificate chain.

   pipelines[0].inputRefs

   Select the log types to forward. Options: application, infrastructure, and audit.

   Important

   The tls.ca block is required when forwarding logs to a LokiStack in the same cluster. The LokiStack gateway endpoint uses a TLS certificate signed by the cluster’s service-serving CA, which is not in the system truststore. If you omit this block, the ClusterLogForwarder status might show Ready: True, but the collector pods fail to connect at runtime.

2. Apply the ClusterLogForwarder CR by running the following command:

   $ oc apply -f <filename>.yaml

   Copy code to clipboard

Procedure

1. In the OpenShift Container Platform web console Administrator perspective, go to Operators → OperatorHub.
2. Type Red Hat OpenShift Logging in the Filter by keyword field. Click Red Hat OpenShift Logging Operator in the list of available Operators, and then click Install.

3. Select stable-6.4 as the Update channel.

   The Red Hat OpenShift Logging Operator must be deployed to the openshift-logging namespace, so the Installation mode and Installed Namespace are already selected. If this namespace does not already exist, it is created for you.

4. Select Enable Operator-recommended cluster monitoring on this namespace.

   This option sets the openshift.io/cluster-monitoring: "true" label in the Namespace object. You must select this option to ensure that cluster monitoring scrapes the openshift-logging namespace.

5. For Update approval select Automatic, then click Install.

   Note

   An Operator might display a Failed status before the installation completes. If the Operator installation completes with an InstallSucceeded message, refresh the page.

6. While the Operator installs, create the service account for the log collector:

   1. Click the + button in the top right of the screen to access the Import YAML page.

   2. Enter the following YAML to create the service account:

      apiVersion: v1
      kind: ServiceAccount
      metadata:
        name: logging-collector
        namespace: openshift-logging

      Copy code to clipboard
   3. Click Create.

7. Create the required cluster role bindings for the log collector. Click the + button again and enter the following YAML:

   apiVersion: rbac.authorization.k8s.io/v1
   kind: ClusterRoleBinding
   metadata:
     name: logging-collector:write-logs
   roleRef:
     apiGroup: rbac.authorization.k8s.io
     kind: ClusterRole
     name: logging-collector-logs-writer
   subjects:
   - kind: ServiceAccount
     name: logging-collector
     namespace: openshift-logging
   ---
   apiVersion: rbac.authorization.k8s.io/v1
   kind: ClusterRoleBinding
   metadata:
     name: logging-collector:collect-application
   roleRef:
     apiGroup: rbac.authorization.k8s.io
     kind: ClusterRole
     name: collect-application-logs
   subjects:
   - kind: ServiceAccount
     name: logging-collector
     namespace: openshift-logging
   ---
   apiVersion: rbac.authorization.k8s.io/v1
   kind: ClusterRoleBinding
   metadata:
     name: logging-collector:collect-infrastructure
   roleRef:
     apiGroup: rbac.authorization.k8s.io
     kind: ClusterRole
     name: collect-infrastructure-logs
   subjects:
   - kind: ServiceAccount
     name: logging-collector
     namespace: openshift-logging

   Copy code to clipboard
   Note

   If you also want to collect audit logs, add an additional ClusterRoleBinding with the cluster role collect-audit-logs.

   1. Click Create.
8. Navigate to Operators → Installed Operators. Select the Red Hat OpenShift Logging Operator, and under Provided APIs, find the ClusterLogForwarder resource and click Create Instance.

9. Select YAML view, and then use the following template to create a ClusterLogForwarder CR:

   apiVersion: observability.openshift.io/v1
   kind: ClusterLogForwarder
   metadata:
     name: instance
     namespace: openshift-logging
   spec:
     serviceAccount:
       name: logging-collector
     outputs:
     - name: lokistack-out
       type: lokiStack
       lokiStack:
         target:
           name: logging-loki
           namespace: openshift-logging
         authentication:
           token:
             from: serviceAccount
       tls:
         ca:
           key: service-ca.crt
           configMapName: openshift-service-ca.crt
     pipelines:
     - name: infra-app-logs
       inputRefs:
       - application
       - infrastructure
       outputRefs:
       - lokistack-out

   Copy code to clipboard
   Important

   The tls.ca block is required. Without it, the collector pods fail to connect to the LokiStack gateway with a certificate verify failed error. The ClusterLogForwarder status might show Ready: True even when this block is missing.

10. Click Create.

Verification

1. In the ClusterLogForwarder tab, verify that you see your ClusterLogForwarder instance.

2. In the Status column, verify that you see the following conditions:

   • observability.openshift.io/Authorized
   • observability.openshift.io/Valid, Ready

Procedure

1. Create a LogFileMetricExporter CR as a YAML file:

   apiVersion: logging.openshift.io/v1alpha1
   kind: LogFileMetricExporter
   metadata:
     name: instance
     namespace: openshift-logging
   spec:
     nodeSelector: {}
     resources:
       limits:
         cpu: 500m
         memory: 256Mi
       requests:
         cpu: 200m
         memory: 128Mi
     tolerations: []

   Copy code to clipboard

   spec.nodeSelector

   Optional: Define the nodes that the exporter pods run on.

   spec.resources

   Optional: Define CPU and memory resource limits and requests for the exporter.

   spec.tolerations

   Optional: Define tolerations that the exporter pods accept.

   Note

   The LogFileMetricExporter is a singleton. The Operator only honors openshift-logging/instance for the namespace and name.

2. Run the following command to apply the LogFileMetricExporter CR:

   $ oc apply -f <filename>.yaml

   Copy code to clipboard

Procedure

1. Install the Cluster Observability Operator.

   The COO installs into the openshift-operators namespace, which already has a pre-existing OperatorGroup. No additional namespace or OperatorGroup configuration is required.

2. Create a UIPlugin CR:

   apiVersion: observability.openshift.io/v1alpha1
   kind: UIPlugin
   metadata:
     name: logging
   spec:
     type: Logging
     logging:
       lokiStack:
         name: logging-loki
       logsLimit: 50
       timeout: 30s
       schema: otel

   Copy code to clipboard

   metadata.name

   Set the name to logging.

   spec.type

   Set the type to Logging.

   spec.logging.lokiStack.name

   Must match the name of your LokiStack instance.

   spec.logging.schema

   Set to otel, viaq, or select. The default is viaq if no value is specified. When you select select, you can select the mode in the UI when you run a query.

   Note

   The following are known issues for the logging UI plugin (OU-587):

   • The schema feature is only supported in OpenShift Container Platform 4.15 and later. In earlier versions, the logging UI plugin uses only the viaq attribute, ignoring any other values that might be set.
   • Non-administrator users cannot query logs by using the otel attribute with logging versions 5.8 to 6.2. (LOG-6589)

3. Apply the UIPlugin CR by running the following command:

   $ oc apply -f <filename>.yaml

   Copy code to clipboard
4. Refresh the OpenShift Container Platform web console. Navigate to Observe → Logs to verify that the Logs tab is available. You can also view aggregated logs for individual pods from the Aggregated Logs tab on a pod’s detail page.

Procedure

1. Check that collector pods are running on each node:

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

   Copy code to clipboard

   You should see one collector pod per node in your cluster.

2. Check the collector logs for errors:

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

   Copy code to clipboard

   Healthy output has only WARN messages about small files. If you see certificate verify failed, verify the tls.ca block in your ClusterLogForwarder.

3. Query logs from the web console:

   Click to Observe → Logs and run the following query:

   {log_type="infrastructure"}

   Copy code to clipboard

   You should see infrastructure log entries from your cluster.

Procedure

1. Create a Subscription object for the COO:

   apiVersion: operators.coreos.com/v1alpha1
   kind: Subscription
   metadata:
     name: cluster-observability-operator
     namespace: openshift-operators
   spec:
     channel: development
     installPlanApproval: Automatic
     name: cluster-observability-operator
     source: redhat-operators
     sourceNamespace: openshift-marketplace

   Copy code to clipboard

   spec.channel

   Specify development as the channel.

   spec.namespace

   The COO installs into the openshift-operators namespace, which already has a pre-existing OperatorGroup. No additional namespace or OperatorGroup configuration is required.

   spec.source

   Specify redhat-operators as the value. If your OpenShift Container Platform cluster is installed on a restricted network, specify the name of the CatalogSource object you created when you configured OLM.

2. Apply the Subscription object by running the following command:

   $ oc apply -f <filename>.yaml

   Copy code to clipboard

3. Verify that the operator installed successfully by running the following command:

   $ oc get csv -n openshift-operators | grep cluster-observability

   Copy code to clipboard

   You get an output similar to the following example:

   cluster-observability-operator.v0.4.2   Cluster Observability Operator   0.4.2   Succeeded

   Copy code to clipboard

Procedure

1. In the OpenShift Container Platform web console, navigate to Operators → OperatorHub.
2. Type Cluster Observability Operator in the Filter by keyword box.
3. Select the Cluster Observability Operator tile and click Install.

4. On the Install Operator page:

   1. Select development from the Update channel list.

   2. Select openshift-operators from the Installed Namespace list.

      Note

      The COO must be installed in the openshift-operators namespace.

   3. Select an Update approval strategy:

      • Automatic updates the Operator automatically when a new version is available.
      • Manual requires manual approval before updates are applied.
5. Click Install.

Verification

1. Navigate to Operators → Installed Operators.
2. Verify that the Cluster Observability Operator is listed with a status of Succeeded in the openshift-operators namespace.

Procedure

1. Go to the Operators → Installed Operators page. Click the All instances tab.
2. From the Create new drop-down list, select LokiStack.

3. Select YAML view, and then use the following template to create a LokiStack CR:

   apiVersion: loki.grafana.com/v1
   kind: LokiStack
   metadata:
     name: logging-loki 1
     namespace: openshift-logging
   spec:
     size: 1x.small 2
     storage:
       schemas:
         - effectiveDate: '2023-10-15'
           version: v13
       secret:
         name: logging-loki-s3 3
         type: s3 4
         credentialMode: 5
     storageClassName: <storage_class_name> 6
     tenants:
       mode: openshift-logging

   Copy code to clipboard

   1

   Use the name logging-loki.

   2

   Specify the deployment size. In the logging 5.8 and later versions, the supported size options for production instances of Loki are 1x.extra-small, 1x.small, or 1x.medium.

   3

   Specify the secret used for your log storage.

   4

   Specify the corresponding storage type.

   5

   Optional field, logging 5.9 and later. Supported user configured values are as follows: static is the default authentication mode available for all supported object storage types using credentials stored in a Secret. token for short-lived tokens retrieved from a credential source. In this mode the static configuration does not contain credentials needed for the object storage. Instead, they are generated during runtime using a service, which allows for shorter-lived credentials and much more granular control. This authentication mode is not supported for all object storage types. token-cco is the default value when Loki is running on managed STS mode and using CCO on STS/WIF clusters.

   6

   Enter the name of a storage class for temporary storage. For best performance, specify a storage class that allocates block storage. Available storage classes for your cluster can be listed by using the oc get storageclasses command.

Procedure

1. Enter the following command to create a new group:

   $ oc adm groups new cluster-admin

   Copy code to clipboard

2. Enter the following command to add the desired user to the cluster-admin group:

   $ oc adm groups add-users cluster-admin <username>

   Copy code to clipboard

3. Enter the following command to add cluster-admin user role to the group:

   $ oc adm policy add-cluster-role-to-group cluster-admin cluster-admin

   Copy code to clipboard