Release notes
Highlights of what is new and what has changed with this OpenShift logging release.
Abstract
Chapter 1. Logging 6.5 release notes
1.1. Logging 6.5.0 release notes
This release of OpenShift Logging is supported on OpenShift Container Platform 4.19 and later.
This release includes RHBA-2026:6393.
1.1.1. New features and enhancements
- Automatic trace context enrichment for OTLP log forwarding
With this release, log entries forwarded to OpenTelemetry Protocol (OTLP) or LokiStack outputs with
dataModel: Otelare automatically enriched with trace context attributes, including trace ID, span ID, and trace flags. This enables you to correlate logs with distributed traces in your observability platform, making it easier to troubleshoot issues across services. Trace context is automatically extracted from log messages without requiring any additional configuration.- Dynamic Pod Disruption Budget for LokiStack ingesters
With this release, the Pod Disruption Budget for LokiStack ingester pods dynamically adjusts based on the configured replication factor and number of ingester replicas, rather than using a hard-coded value determined by the LokiStack size. This helps ensure high availability is maintained when you customize the replication factor beyond the default value for your selected LokiStack size.
- OpenTelemetry log forwarding is now generally available
With this release, OpenShift Logging support for OpenTelemetry (OTel) is promoted to General Availability (GA). You can now forward logs over OTLP outputs using OTel semantic conventions as specified in the Content from github.com is not included.Red Hat Observability Model. This includes configuring log forwarding to a LokiStack deployment using the OTel data model for log storage and retrieving logs using the log observability UI plugin distributed by the Cluster Observability Operator.
Content from redhat.atlassian.net is not included.LOG-7623
ImportantThis release reduces the default set of stream labels for OTLP log forwarding to LokiStack to help improve LokiStack performance. The new default configuration uses only the following labels as stream labels:
-
k8s.namespace.name -
kubernetes.namespace_name -
log_source -
log_type -
openshift.cluster.uid -
openshift.log.source -
openshift.log.type
If you have existing queries that used other labels in label matchers (inside
{}), you must rewrite them to use those labels as filters (after|) instead. Alternatively, you can configure your LokiStack to use the previous set of stream labels.-
- NDJSON support for HTTP output
With this release, you can configure an HTTP output to forward logs as new line delimited JSON (NDJSON) instead of as a JSON array by setting the
formatfield tondjson. This format reduces memory footprint for some receivers.# ... spec: outputs: - http: format: ndjson method: POST url: http://echo-service.test.svc:8080 name: http-echo type: http # ...- Port validation for Kafka and Syslog outputs
With this release, the
ClusterLogForwarderAPI requires port numbers in destination URLs for Kafka and Syslog outputs. URLs without port numbers are rejected at admission time, which provides immediate feedback to administrators. This validation enhances security when evaluating NetworkPolicy configurations for socket-level transports.- HTTP proxy configuration for Loki output
With this release, you can configure a proxy URL when forwarding logs to a Loki output in the
ClusterLogForwardercustom resource by setting theproxyURLfield. This follows the same syntax and semantics as the HTTP output proxy configuration.# ... spec: outputs: - loki: proxyURL: http://proxy.example.com:8080 url: https://loki-endpoint.example.com:3100 name: loki-output type: loki # ...- Ability to disable the LokiStack Gateway Route
With this release, you can disable the Gateway Route created automatically by the Loki Operator by setting the
disableIngressfield totruein theLokiStackcustom resource. This provides more control over external access to your LokiStack deployment.# ... spec: tenants: disableIngress: true mode: openshift-logging # ...- Improved leader election resilience for Loki Operator
With this release, the Loki Operator uses recommended leader election parameters to better tolerate API server disruptions. The lease duration, renew deadline, and retry period values are configured according to OpenShift best practices, which helps improve operator resilience during cluster maintenance or temporary API server unavailability.
- Fine-grained authorization for the openshift-network tenant
With this release, the LokiStack
openshift-networktenant correctly enforces fine-grained authorization. The gateway selector extractor is configured to extract selectors from queries, which allows Open Policy Agent (OPA) to enforce fine-grained authorization. As a result, network observability data access is properly restricted based on authorization policies.
1.1.2. Fixed issues
- LokiStack components alert fires when pods are in Pending state
Before this update, the
LokistackComponentsNotReadyWarningalert did not fire when LokiStack components were inPendingstate during initial deployment, such as when provisioned with an incorrect storage class. As a consequence, administrators were not alerted to configuration issues that prevented components from becoming ready. With this update, the alert rule is triggered when a LokiStack is deployed with components that are not ready, even during first-time deployment. As a result, the alert now properly fires when components fail to reach a ready state.- NetworkPolicy uses correct port for ODF NooBaa S3 backend egress
Before this update, the NetworkPolicy generated by the Loki Operator used the Service port instead of the Pod port for the egress port configuration. As a consequence, when a Kubernetes service was configured for the object storage endpoint with OpenShift Data Foundation (ODF), ingestion and flush failures occurred with timeout errors. With this update, the Loki Operator fetches the Service and EndpointSlices and correctly uses the Pod port rather than the Service port in the NetworkPolicy. As a result, the LokiStack can successfully forward logs to the NooBaa S3 backend.
- NetworkPolicy uses correct ports for OpenStack Swift backend egress
Before this update, the NetworkPolicy generated by the Loki Operator exposed only the OpenStack authentication port for egress. As a consequence, when using OpenStack Swift as a storage backend, ingestion and flush failures occurred with timeout errors, and compactor and ingester pods entered a crash loop. With this update, the Loki Operator exposes either the default SSL port 443 for services or, for OpenShift installations, Red Hat’s OpenStack default SSL port 13808. As a result, the LokiStack can successfully forward logs to the OpenStack Swift storage backend.
- NetworkPolicy uses correct ports for cluster-wide proxy egress
Before this update, the NetworkPolicy generated by the Loki Operator exposed the incorrect port when NetworkPolicies and cluster-wide proxy were enabled. As a consequence, egress to storage backends timed out with proxy connection errors. With this update, the Loki Operator exposes the proxy port to allow communication between the ingester and object storage through the proxy. As a result, the LokiStack can successfully forward logs through the cluster-wide proxy.
- Deprecated replicationFactor field is handled correctly
Before this update, the handling of the deprecated
replicationFactorfield was in the wrong part of the code. As a consequence, the field was ignored by the Loki Operator and not applied toreplication.factorin the generated Loki configuration. With this update, the handling is moved to the correct location where it is visible by the operator. As a result, the deprecatedreplicationFactorfield is correctly processed and applied.