Chapter 3. Plan your logging installation
Plan your logging deployment by understanding the available operators, deployment scenarios, and how to choose the right combination for your use case.
3.1. Logging operator overview Copy linkLink copied to clipboard!
Red Hat OpenShift Logging provides three Operators to deploy and manage logging. Each Operator manages a distinct layer of the logging stack:
- Loki Operator
-
Installs into the
openshift-operators-redhatnamespace. Manages the log store: receives, indices, and stores logs in S3-compatible object storage by using aLokiStackinstance. - Red Hat OpenShift Logging Operator
-
Installs into the
openshift-loggingnamespace. Manages log collection and forwarding: tails container logs and ships them to the log store by using aClusterLogForwarderinstance. - Cluster Observability Operator (COO)
-
Installs into the
openshift-cluster-observability-operatornamespace. Manages visualization: adds the Logs tab to the web console under ObserveLogs by using a UIPlugininstance.
3.2. Choose which operators to install Copy linkLink copied to clipboard!
The Operators you need depend on your use case:
- Collect and forward logs to a third-party log store: Install only the Red Hat OpenShift Logging Operator.
- Store logs in-cluster with LokiStack: Install the Loki Operator first, then the Red Hat OpenShift Logging Operator.
Store logs in-cluster and visualize them in the web console: Install all three operators in this order:
- Loki Operator
- Red Hat OpenShift Logging Operator
- Cluster Observability Operator (COO)
- You must install and configure the Loki Operator before configuring the Red Hat OpenShift Logging Operator.
-
The Loki Operator and the Red Hat OpenShift Logging Operator must use the same major and minor version. For example, both operators must be on
stable-6.6.
3.3. Deployment scenarios Copy linkLink copied to clipboard!
Select your deployment scenario to determine the required storage backend and sizing.
- Cloud deployment (AWS, GCP, Azure)
- Storage backend: Use cloud-managed object storage (S3, GCS, Azure Blob Storage)
- TLS CA bundle: Typically not required when using standard public endpoints. Required when using custom endpoints, VPC endpoints, or private link configurations with custom certificates.
- Authentication: Configure IAM roles (AWS STS recommended) or service accounts
-
Sizing: Start with
1x.picoor1x.extra-smallfor development,1x.smallor1x.mediumfor production
- On-premise deployment (bare metal, VMware)
- Storage backend: Deploy S3 Compatible storage (NetApp StorageGRID and others), Ceph RGW, or use enterprise S3-compatible storage
- TLS CA bundle: Required when using self-signed certificates or internal certificate authorities. Not required when using publicly trusted certificates.
- Authentication: Create Kubernetes secret with storage credentials
-
Sizing: Start with
1x.extra-smallfor development,1x.smallor1x.mediumfor production
- Edge deployment (single-node clusters, remote sites)
-
Storage backend: Forward logs to central cluster with
LokiStack, or use local S3 Compatible storage with limited retention - StorageClass: Must configure Local Storage Operator or Logical Volume Manager Storage for persistent volumes
-
Sizing: Use
1x.picoor1x.extra-smallwith short retention (7-14 days) - Consider: Log forwarding to central hub instead of local storage for capacity-constrained nodes
-
Storage backend: Forward logs to central cluster with
- Multi-cluster or enterprise deployment
- Storage backend: Centralized object storage with multi-region replication
-
Sizing:
1x.mediumor larger, with ruler enabled for alerting and retention policies -
Consider: Separate
LokiStackinstances per environment (dev/staging/prod) or centralized aggregation