Release notes

Red Hat OpenShift Logging 6.6

Highlights of what is new and what has changed with this OpenShift logging release.

Red Hat OpenShift Documentation Team

Abstract

The release notes for OpenShift logging summarize all new features and enhancements, notable technical changes, major corrections from the previous version, and any known bugs upon general availability.

Chapter 1. Logging 6.6 release notes

This release of OpenShift Logging is supported on OpenShift Container Platform 4.19 and later.

1.1. Logging 6.6.0

This release of OpenShift Logging is supported on OpenShift Container Platform 4.20 and later. This release includes new features, enhancements, and bug fixes.

This release includes RHBA-2026:39344.

1.1.1. New features and enhancements

This release of OpenShift Logging includes the following new features and enhancements.

Azure Monitor Logs Ingestion API support
With this release, you can forward logs to Azure Monitor by using the new Logs Ingestion API with Data Collection Rules (DCR). This replaces the deprecated Data Collector API, which Microsoft will disable on September 14, 2026. The new azureLogsIngestion output type offers enhanced security through support for Microsoft Entra ID Workload Identity. This enables pod-based authentication without managing shared secrets. Service principal authentication with client secrets remains available for environments that require it. Data Collection Rules provide schema flexibility. You can define custom log schemas that match your organization’s requirements. You can specify which field receives the timestamp. This supports standard schemas such as TimeGenerated or specialized schemas such as ASIM that use EventStartTime. Both the new azureLogsIngestion output and the deprecated azureMonitor output can coexist in the same ClusterLogForwarder custom resource during the migration period. (Content from redhat.atlassian.net is not included.LOG-7259)
Google Cloud Platform Workload Identity Federation authentication
With this release, you can forward logs to Google Cloud Logging by using Workload Identity Federation (WIF) for authentication. WIF provides short-lived credentials instead of long-lived service account keys. This improves security by eliminating the need to manage and rotate service account key files. This feature is only supported on Red Hat OpenShift Logging clusters installed on GCP in manual credentials mode with WIF enabled. To configure WIF authentication, use the Cloud Credential Operator utility (ccoctl). This utility creates GCP service accounts, IAM policy bindings, and workload identity bindings between Red Hat OpenShift Logging service accounts and GCP service accounts. The collector uses pod-injected service account tokens as subject tokens for WIF token exchange with GCP. Service account key authentication remains available for environments that do not use WIF. (Content from redhat.atlassian.net is not included.LOG-3577)
Metrics collection profiles to reduce collector cardinality
With this release, you can configure the cluster monitoring operator to use metrics collection profiles. These profiles control how many metrics Prometheus collects from the log collector. The minimal profile reduces metrics cardinality by collecting only the metrics needed for platform alerts, dashboards, telemetry, and Horizontal and Vertical Pod Autoscaling. This profile excludes high-cardinality histogram metrics, such as vector_component_received_events_count_bucket and vector_buffer_send_duration_seconds_bucket. These metrics create thousands of time series in multitenant environments but are not required for platform functionality. Testing shows the minimal profile reduces Prometheus CPU consumption by approximately 21% and memory consumption by approximately 33% while maintaining all functionality needed for cluster operations. To configure the profile, set the collectionProfile field to minimal in the cluster-monitoring-config ConfigMap in the openshift-monitoring namespace. The available profiles are full (default, collects all metrics), minimal (collects only metrics needed for platform functionality), and telemetry (collects only metrics required for Red Hat telemetry). (Content from redhat.atlassian.net is not included.LOG-9355)
Improved high availability for LokiStack ingestion
With this release, the 1x.extra-small and 1x.small LokiStack deployment sizes now deploy 3 ingester replicas instead of 2. This provides high availability for log ingestion. Previously, these sizes deployed only 2 ingesters with a replication factor of 2. Log ingestion could be interrupted during pod restarts or node failures because at least replication factor plus one (RF+1) ingester replicas are needed to maintain availability. The operator previously generated a warning condition for these sizes indicating non-HA configuration. With this release, ingester resources are redistributed within the existing resource envelope to support 3 ingester replicas. This ensures that log ingestion continues uninterrupted during routine maintenance operations. This change aligns 1x.extra-small and 1x.small with the HA configuration already used by 1x.pico and 1x.medium sizes. (This content is not included.LOG-9352)

1.1.1.1. Additional enhancements

The following enhancements were also introduced in this release:

  • The log collector now exposes a metric that tracks when logs are discarded at the source because they exceed the MaxRecordSize tuning parameter. This enables you to create alerts when logs are being dropped. You can then investigate which log stream is affected and take corrective action. (Content from redhat.atlassian.net is not included.LOG-6384)
  • A runbook for the CollectorNodeDown critical alert is now available in the OpenShift runbooks repository. The runbook provides troubleshooting steps and remediation guidance when this alert fires. (Content from redhat.atlassian.net is not included.LOG-7256)
  • The LokiStack configuration now uses the new object storage backend based on thanos-io/objstore, which was introduced in Loki 3.4.0. The new backend uses named stores to avoid duplication of object storage configuration across components. (Content from redhat.atlassian.net is not included.LOG-7392)
  • The Red Hat OpenShift Logging Operator now reacts to changes in the cluster TLS profile and updates its own TLS configuration to match. The operator’s metrics endpoint uses the cluster TLS profile for cipher suites and minimum TLS version. When you modify the cluster TLS profile, the Red Hat OpenShift Logging Operator pod restarts to apply the new configuration. The collector also respects the cluster TLS profile unless you specify an output-specific TLS security profile in the ClusterLogForwarder custom resource. An output-specific profile takes precedence over the cluster-level profile. (Content from redhat.atlassian.net is not included.LOG-8972)
  • The Red Hat OpenShift Logging Operator metrics endpoint now uses authentication and TLS encryption. Prometheus must provide a valid bearer token to scrape metrics from the operator. This ensures that only authorized clients can retrieve operator metrics and that the configuration respects the cluster TLS profile. (Content from redhat.atlassian.net is not included.LOG-8977)
  • The log file metrics exporter metrics endpoint now uses authentication and TLS encryption. Prometheus must provide a valid bearer token to scrape metrics from the exporter. This ensures that only authorized clients can retrieve exporter metrics and that the configuration respects the cluster TLS profile. (Content from redhat.atlassian.net is not included.LOG-8978)
  • The Vector collector metrics endpoint now uses authentication and TLS encryption. Prometheus must provide a valid bearer token to scrape metrics from the collector. This ensures that only authorized clients can retrieve collector metrics and that the configuration respects the cluster TLS profile. (Content from redhat.atlassian.net is not included.LOG-9358)
  • LokiStack ingesters now persist ring tokens to disk by using the ingester.tokens-file-path configuration option. When an ingester pod restarts, it reuses its previous tokens instead of generating new ones. This avoids unnecessary resharding of data across the ring. (Content from redhat.atlassian.net is not included.LOG-9401)
  • LokiStack PodDisruptionBudgets now set maxUnavailable: 1 instead of minAvailable. This ensures that during voluntary disruptions such as node drains or upgrades, at most one pod is unavailable at a time. This preserves availability guarantees. (Content from redhat.atlassian.net is not included.LOG-9402)

1.1.2. Bug fixes

The following issues were resolved in this release of OpenShift Logging.

  • Previously, the description of the LokiIngesterFlushFailureRateCritical alert did not match its actual definition. This caused confusion when investigating alert conditions. With this release, the alert description accurately reflects its definition. (This content is not included.LOG-8509)
  • Previously, when the CA certificate in the spec.outputs.tls.ca.configMapName field was updated, the collector pods did not restart to use the new certificate. With this release, the Red Hat OpenShift Logging Operator watches the CA ConfigMap and restarts collector pods when the certificate changes. (This content is not included.LOG-8631)
  • Previously, the RulerConfig custom resource definition validation incorrectly listed header as a valid value for RemoteWriteAuthType instead of the correct value bearer. With this release, the validation accepts bearer as the valid authentication type. (This content is not included.LOG-9002)
  • Previously, the LokiRequestLatency alert threshold was set to 1 second. This was lower than the actual distributor timeout of 5 seconds. This caused the alert to fire even when no timeouts occurred. With this release, the alert threshold matches the distributor timeout. (This content is not included.LOG-9196)
  • Previously, the default ignore_older_secs value of 3600 seconds for the input_audit_host input type was too short. This caused audit logs older than one hour to be ignored. With this release, the default value is increased to allow collection of older audit logs. (This content is not included.LOG-9359)
  • Previously, when noProxy: example.com was set and logs were forwarded to x.example.com, the noProxy setting was not honored and the proxy was used incorrectly. With this release, subdomain matching for noProxy settings works correctly. (This content is not included.LOG-9383)
  • Previously, the API description for spec.outputs.lokiStack.tuning.deliveryMode did not list the possible options. This made it difficult to configure this field correctly. With this release, the API description lists all valid options for the deliveryMode field. (This content is not included.LOG-9400)
  • Previously, the kubernetes field was null for all non-container logs such as node logs and audit logs. With this release, the kubernetes field contains appropriate values for non-container logs or is properly omitted where not applicable. (This content is not included.LOG-9423)
  • Previously, the DiskBufferUsage alert had a broken template variable in the summary annotation and used inconsistent severity casing. With this release, the alert summary displays the actual node hostname and uses lowercase severity labels consistent with other alerts. (This content is not included.LOG-9461)

1.1.3. Deprecations and removals

The following section lists features and functionality that are deprecated or removed in this release of OpenShift Logging.

Azure Monitor Data Collector API deprecated
The azureMonitor output type is deprecated in this release. This output type uses the Azure HTTP Data Collector API. Microsoft will disable the Data Collector API on September 14, 2026. If you currently use the azureMonitor output type, you must migrate to the new azureLogsIngestion output type before this date to avoid service disruption. The azureLogsIngestion output type uses the Azure Monitor Logs Ingestion API with Data Collection Rules (DCR). This new API provides enhanced security, schema flexibility, and improved reliability compared to the deprecated API. Both output types can coexist in the same ClusterLogForwarder custom resource during the migration period. This allows you to validate the new configuration before you remove the deprecated output. (Content from redhat.atlassian.net is not included.OBSDA-804)

Legal Notice

Copyright © Red Hat.
Except as otherwise noted below, the text of and illustrations in this documentation are licensed by Red Hat under the Creative Commons Attribution–Share Alike 3.0 Unported license . If you distribute this document or an adaptation of it, you must provide the URL for the original version.
Red Hat, as the licensor of this document, waives the right to enforce, and agrees not to assert, Section 4d of CC-BY-SA to the fullest extent permitted by applicable law.
Red Hat, the Red Hat logo, JBoss, Hibernate, and RHCE are trademarks or registered trademarks of Red Hat, LLC. or its subsidiaries in the United States and other countries.
Linux® is the registered trademark of Linus Torvalds in the United States and other countries.
XFS is a trademark or registered trademark of Hewlett Packard Enterprise Development LP or its subsidiaries in the United States and other countries.
The OpenStack® Word Mark and OpenStack logo are trademarks or registered trademarks of the Linux Foundation, used under license.
All other trademarks are the property of their respective owners.