Chapter 1. OpenShift Logging overview


OpenShift Logging is Red Hat’s Kubernetes-native solution for collecting, storing, and forwarding log data from your OpenShift Container Platform cluster. It provides the logging capabilities within the broader observability ecosystem, working alongside metrics and distributed tracing to give you complete visibility into your cluster’s behavior.

1.1. What is observability?

Observability is the practice of collecting and analyzing telemetry data from your systems to understand their internal state and behavior. Modern observability relies on three complementary signals:

Logs
Discrete timestamped events with structured or unstructured context that record what happened in your applications and infrastructure. Logs are the focus of this documentation. The rest of this guide explains how OpenShift Logging collects, stores, and forwards log data, and how logs fit into the larger observability picture.
Metrics
Numerical measurements aggregated over time that show system condition, performance trends, and resource usage.
Traces
Request flows across distributed services that show how components interact and where time is spent processing requests.

These three signals work together to provide complete visibility. Metrics and logs help you understand what happened and where, while traces help you correlate those events to identify when and in what order they occurred.

OpenTelemetry (OTel) is a vendor-neutral, open source observability framework and Cloud Native Computing Foundation (CNCF) standard. It provides a unified approach to collecting traces, metrics, and logs under one API, SDK, and wire protocol.

Key characteristics of OpenTelemetry:

  • Vendor neutrality: 100% open source with no vendor lock-in. Deploy on-premises, in hybrid environments, or across multiple clouds.
  • Unified standard: One framework to instrument applications and collect all three observability signals.
  • Signal correlation: Distributed context flows through your entire request path, connecting logs, metrics, and traces using trace IDs and span IDs.
  • Automatic instrumentation: SDKs for all major programming languages with automatic instrumentation for popular frameworks.
  • OpenTelemetry Collector: Central component that receives telemetry from services, enriches it with context, and routes it to one or more backends.

OpenShift Logging fits into this larger observability ecosystem. While OpenShift Logging focuses specifically on log collection and storage, it can integrate with OpenTelemetry-instrumented applications and forward log data to OpenTelemetry-compatible backends.

1.3. What is OpenShift Logging?

OpenShift Logging is Red Hat’s solution for log management in Kubernetes environments. It is a subset of the complete observability picture, focused specifically on collecting, storing, and forwarding log data from your OpenShift Container Platform cluster.

OpenShift Logging provides:

  • Kubernetes-native log collection: Automatically collects logs from all pods, containers, and cluster infrastructure using the DaemonSet deployment pattern.
  • Flexible log storage: Optional local log storage with Loki for short-term troubleshooting, or forward-only mode for external log platforms.
  • Multiple destination support: Forward logs to external systems like Amazon CloudWatch, Splunk, Kafka, or Azure Monitor while optionally storing locally.
  • Structured log processing: Transform, filter, and enrich log data using the Vector data pipeline before storage or forwarding.
  • Console integration: Query and visualize logs directly in the OpenShift web console when using the Cluster Observability Operator.
  • Enterprise support: Backed by Red Hat with predictable release cycles and long-term support.

1.4. Modular architecture

OpenShift Logging uses a modular architecture where you deploy only the components you need for your use case. The three main components are:

Vector collector (required)
The log collection engine that runs on every node. Vector collects logs from all pods and containers, transforms the data, and forwards it to configured destinations. Vector is always required in any OpenShift Logging deployment.
Loki log store (optional)
A horizontally scalable log aggregation system that provides local log storage for short-term troubleshooting. Loki indexes only metadata labels (not full log content) and stores compressed logs in object storage. Loki is optional. You can forward logs to external systems without deploying Loki.
Cluster Observability Operator (optional)
Provides UI visualization capabilities in the OpenShift web console, including a "Logs" tab for querying logs with LogQL. The COO also enables signal correlation between logs, metrics, and traces. The COO is optional and only needed if you want console-based log visualization.

You choose which components to deploy based on your requirements. See the deployment scenarios overview for common configurations.

1.5. Component management

OpenShift Logging components are managed by Kubernetes Operators:

  • Red Hat OpenShift Logging Operator: Manages the Vector log collector and the ClusterLogForwarder custom resource that configures log collection and forwarding.
  • Loki Operator: Manages Loki log store deployments and the LokiStack custom resource.
  • Cluster Observability Operator: Manages monitoring stacks and UI plugins for observability visualization.

Each operator is installed separately, giving you flexibility to deploy only the components you need.

You can use Logging to collect, normalize, and forward application, infrastructure, and audit logs to supported storage and forwarding destinations.

Note

Logging provides log collection and forwarding. For long-term log retention and storage, configure external storage backends. For Security Information and Event Monitoring (SIEM), forward logs to SIEM-compatible systems. Audit logs are not stored locally by default and require explicit forwarding configuration.

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