OpenShift Logging, read on the cluster.
OpenShift Logging in 2026 is the Loki log store, the Vector collector, and the OpenShift console plugin that surfaces logs in the cluster console. The stack installs through the Logging operator on Red Hat OpenShift Container Platform and is included as a value added operator inside the platform entitlement on the clusters where the stack runs. The audit posture turns on where the log store lives and which storage entitlement line carries the underlying object store. The buyer side discipline reads OpenShift Logging as two entitlements at once: the logging operator on the cluster, and the storage line for the bucket the Loki store reads and writes.
The Loki and Vector stack, as the 2026 reference.
OpenShift Logging in 2026 ships the Loki log store and the Vector log collector as the reference stack on Red Hat OpenShift Container Platform. The Logging operator manages the lifecycle of both components, and the OpenShift console plugin surfaces query and tail capability inside the cluster console. The earlier ElasticSearch and Fluentd stack is in deprecation across recent OpenShift releases and is no longer the recommended deployment target1.
The reading on the renewal line is that OpenShift Logging is included as a value added operator inside the OpenShift platform entitlement on the clusters where the stack runs2. The Logging operator does not carry a separate per cluster or per log volume charge in the 2026 reference. The platform line on the clusters that host the stack absorbs the logging attribution.
What the platform line does not absorb is the storage backend that the Loki store reads and writes against. Loki is a log aggregation system that stores its index and chunks in an object store. The object store backend carries its own entitlement reading and its own commercial agreement, and the logging product is incomplete without reconciling both lines together.
The storage backend reading, often missed.
The Loki backend can be Red Hat OpenShift Data Foundation, Red Hat Ceph Storage, AWS S3, Azure Blob Storage, GCP Cloud Storage, or any S3 compatible object store on premises3. Each backend carries its own entitlement question and its own audit reading. The buyer who reads only the logging operator line signs a renewal that misses half of the logging cost story.
The Red Hat backed paths concentrate two of the readings in one Red Hat reading. OpenShift Data Foundation on the same cluster as the Logging operator carries the ODF entitlement on the cluster cores. The ODF bucket sized for log retention can grow rapidly because logs are time series data with retention periods often measured in months. The ODF line scales with the bucket sizing, and the logging retention policy quietly governs the ODF storage line.
The hyperscaler backed paths split the reading. The cluster cores carry the OpenShift platform line. The object store carries an AWS, Azure, or GCP line outside the Red Hat reading. The hyperscaler line is operational cost rather than entitlement cost, but the contract review at renewal should reconcile both lines to understand the full annual logging spend.
Multi tenant log storage, and the bundle reading.
OpenShift Logging on the OpenShift Plus bundle reads through the bundle line on the bundle clusters. The bundle includes the Logging operator on the bundle clusters at no incremental charge. Where the bundle is the contract vehicle, the logging operator question is contained inside the bundle line and the buyer focus shifts to the storage backend reading on those clusters.
Multi tenant log storage on Loki uses Loki tenant identifiers to separate logs from multiple workload tenants into separate index and chunk paths in the object store. The tenant scaling does not add a logging operator charge in 2026 but it does scale the object store bucket linearly with tenant count and log retention. A buyer who scoped the storage backend at signature against a single tenant deployment carries the storage line at a multiple of the original sizing when the tenant count grows.
A subscription assessment in the ninety days before renewal produces a tenant by retention sizing for the storage backend and reconciles the storage line against the bucket sizing. The reconciliation tends to surface either a Loki retention period that exceeds operational need or a storage backend that is materially under sized for the realistic log volume.
Three counting traps across the logging stack.
Three counting traps produce most of the exposure observed across OpenShift Logging engagements in the trailing twelve months.
The first trap is the ODF backend that scaled without the ODF line scaling with it4. The Loki retention policy quietly increased the ODF bucket size across the contract term, and the ODF line on the cluster did not absorb the growth. The audit reads the ODF bucket at its current size and the ODF line at its signature scope. The mitigation is a quarterly bucket sizing reconciliation aligned to a documented retention policy.
The second trap is the ElasticSearch deployment that was not migrated. Clusters that still run the legacy ElasticSearch and Fluentd stack carry the entitlement question for those operators, and Red Hat support for the legacy stack is winding down on a published schedule. A migration plan to the Loki and Vector reference closes the entitlement question and removes the support cliff.
The third trap is the logging operator left enabled on a cluster after the cluster moved to a centralised log aggregation pattern. The operator state on the source cluster is the audit signal that logging was in use, and a cluster that was reconfigured to ship logs to a central Loki store but kept the local Logging operator installed continues to carry the local attribution. A formal operator removal on the centralisation date closes the attribution at the migration date rather than at the next renewal.
| Pattern | Frequency | Reading |
|---|---|---|
| Loki on ODF with retention reconciled | 3 of 10 | Pays |
| Loki on hyperscaler bucket, line documented | 3 of 10 | Pays |
| ODF bucket grew, ODF line did not | 2 of 10 | Traps |
| Legacy ElasticSearch still in service | 1 of 10 | Traps |
| Logging operator left on centralised cluster | 1 of 10 | Traps |
Reading the logging line and the storage line together.
OpenShift Logging in 2026 is two readings, not one. The logging operator attribution sits on the platform line for the clusters where the stack runs. The storage backend attribution sits on the ODF line, the Ceph line, or the hyperscaler bucket cost depending on the chosen backend. The buyer who reads one without the other reads half the cost.
The discipline at signature sets four protections that hold across the term. The cluster footprint that runs the Logging operator is named in the contract record. The storage backend choice is documented and the storage line is reconciled against the realistic log retention policy. The legacy ElasticSearch migration plan is named with a target completion date so the deprecation timeline does not become an audit event. A quarterly log volume and bucket sizing review aligns the operational reality with the contract scope.
For the broader cross product reading, see the OpenShift practice hub, the GitOps read, the Service Mesh entitlement, the Pipelines line, and the Insights Policies read when log driven drift detection sits alongside the logging stack. For the engagement protocol, see contact.
Notes & references
- 1. Red Hat OpenShift Logging product page and operator catalog notes, accessed across 2025 and 2026. The 2026 reference stack is Loki for log storage and Vector for log collection. The previous ElasticSearch and Fluentd stack is in deprecation across recent OpenShift releases.
- 2. OpenShift Logging installs as a value added operator inside Red Hat OpenShift Container Platform entitlement on the clusters where the stack runs. The platform line on those clusters carries the operator attribution.
- 3. Loki requires an object store backend. The object store can be Red Hat OpenShift Data Foundation, Red Hat Ceph Storage, AWS S3, Azure Blob, GCP Cloud Storage, or an on premises S3 compatible store. Each backend carries its own entitlement question.
- 4. Practice observation across ten OpenShift Logging engagements settled in the trailing twelve months. The most common exposure pattern is the Loki backend running on ODF without the ODF entitlement reconciled against the bucket sizing.
- 5. Concession bands and trailing twelve month figures refer to the practice observation across signed contracts. The eighty two percent audit exposure reduction in marginalia is the trailing twelve month average across defenses settled.
Preparing a response? The practice keeps a one-page Red Hat audit response checklist — what to acknowledge, what to preserve, and what not to volunteer in the first fourteen days after the letter arrives.