Chapter 1. Logging 6.3 release notes
1.1. Logging 6.3.3 release notes Copy linkLink copied to clipboard!
This release includes RHBA-2026:2489.
1.1.1. New features and enhancements Copy linkLink copied to clipboard!
- With this update, the log collector is updated to Vector 0.47.0-rh. (LOG-8138)
1.1.2. Bug fixes Copy linkLink copied to clipboard!
-
Before this update, the collector merged large application log messages without enforcing a size limit, which could cause internal output buffers to overflow. With this update, the
MaxMessageSizetuning parameter is introduced for application logs. The collector now discards messages that exceed the configured threshold, preventing buffer exhaustion. (LOG-8304) - Before this update, a short timeout between the distributor and ingester components caused intermittent HTTP 503 errors when ingesting logs into LokiStack under high load. With this update, the timeout is increased, improving ingestion reliability during peak workloads. (LOG-8586)
-
Before this update, enabling the
rateLimitPerContainersetting resulted in error events reportingMissing fields on event: ["file"]due to incorrect throttle configuration generation. With this update, the throttle configuration is generated correctly, and all expected event fields are preserved when you enable rate limiting. (LOG-8614)
1.2. Logging 6.3.2 release notes Copy linkLink copied to clipboard!
This release includes RHSA-2025:23057.
1.2.1. New features and enhancements Copy linkLink copied to clipboard!
This release adds an alert to notify administrators of deprecated features that will be removed in future releases. As a result, you can make adjustments as needed.
Additionally, this release provides changes to log collector deployments to promote Technology Preview configuration options introduced in LOG-7196 to General Availability. The change enables caching of kube API server calls and introduces a
ClusterLogForwarderfield to tune collector rollout strategy. Administrators managing clusters with large numbers of nodes can now modify the collector upgrade behavior so that the collector requests do not overwhelm the Kubernetes API server. You can control the behavior by setting theMaxUnavailablefield for collectors during upgrade. (LOG-7774)
1.2.2. Bug fixes Copy linkLink copied to clipboard!
-
Before this update, the
clusterLogForwarderAPI did not validate the URL scheme for Kafka outputs. This could cause users to configure a Kafka output with an invalid URL that was missing the requiredtcp://ortls://prefix, leading to a silent failure that prevented log forwarding. With this update, the API includes new validation rules. The clusterLogForwarder now rejects configurations with a Kafka URL that does not have a tcp or tls scheme, preventing the misconfiguration and ensuring logs can be forwarded successfully. (LOG-7386) -
Before this fix, Vector could not recover from silently closed TCP connections. With this update, Vector uses
keepaliveprobes to detect and automatically re-establish unresponsive TCP connections. (LOG-7751) -
Before this update, the OpenShift Container Platform web console incorrectly highlighted info-level log messages containing the
errorkeyword as errors. With this update, the web console no longer highlights info-level logs containing theerrorkeyword as errors. (LOG-7777) -
Before this update, the prune filter failed to remove the
.openshift.sequencefield from the log record. With this update, the field is correctly pruned from the log record. (LOG-7805) -
Before this update, the prune filter failed to remove the
.kubernetes.container_iostreamfield from the log record. With this update, the field is now correctly pruned from the log record. (LOG-7806) -
Before this update, any request that exceeded a Kafka broker’s
message.max.sizevalue would be rejected because the collector’s tuning did not correctly set an allowable producer configuration. With this update, you can set the collector’s kafka client configuration to allow message sizes that are equal to or smaller than theMaxSizevalue. (LOG-7811) - Before this update, buffer corruption following an Out-Of-Memory (OOM) event caused deserialization errors that blocked log forwarding and reduced OpenShift Logging resilience. This update improves the recovery logic for corrupted buffer files and prevents log forwarding issues after OOM events. The collector now successfully recovers from OOM events and subsequent buffer corruption, ensuring continuous log forwarding. (LOG-7996)
1.2.3. CVEs Copy linkLink copied to clipboard!
1.3. Logging 6.3.1 release notes Copy linkLink copied to clipboard!
This release includes RHBA-2025:16105.
1.3.1. Bug fixes Copy linkLink copied to clipboard!
-
Before this update, the log collector was configured to find the event timestamp at the root of the log record. When forwarding logs to Splunk with a
payloadKeyvalue specified, thetimestampfield was omitted causing timestamp-related warnings. As a consequence, timestamp warnings flooded collector pods, disrupting log forwarding to Splunk. With this update, the log collector uses an internal timestamp field when forwarding logs. This ensures that the correct timestamp is used when forwarding logs to Splunk, resolving the issue. (LOG-7311) -
Before this update, using the prune filter to remove Kubernetes metadata fields such as
.kubernetes.namespace_namecaused a remapping error during Syslog output generation. This prevented theappnameandtagfields from being correctly initialized and could prevent forwarding of logs. With this update, this issue is fixed. Improved error handling initializes these fields with an empty string if the source metadata is missing, ensuring successful log processing. (LOG-7355) - Before this update, a log record with a malformed timestamp could cause the Vector agent to panic when attempting to forward logs to Loki. With this update, error handling for out-of-range timestamp values has been improved resolving the issue. (LOG-7417)
-
Before this update, the loki-gateway did not apply the
ORexpression foropenshift-networktenants in LokiStack. With this update, the loki-gateway correctly applies theORexpression for theopenshift-networktenants in LokiStack. (LOG-7421) -
Before this update, the
vector_buffer_byte_sizeandvector_buffer_eventsmetrics incorrectly reported negative values under certain system load and timing conditions. This led to unreliable monitoring, potentially masking buffer issues. With this update, a concurrent, centralized state tracker ensures that these metrics are always reported as non-negative values. This ensures that the metrics correctly report buffer sizes helping with accurate monitoring.(LOG-7592) - Before this update, a change to the container image format caused issues when mirroring the images to image registries that do not support the new format. With this update, the container images are published using the older format again resolving the issue. (LOG-7699)
1.4. Logging 6.3.0 release notes Copy linkLink copied to clipboard!
This release of OpenShift Logging is supported on OpenShift Container Platform 4.17 and later. This release includes RHBA-2025:11336.
1.4.1. New features and enhancements Copy linkLink copied to clipboard!
1.4.1.1. Log collection Copy linkLink copied to clipboard!
-
With this release, you can configure multiple Amazon Web Services (AWS) outputs with distinct identity and access management (IAM) roles in the
clusterLogForwarderresource. (LOG-6790) - With this release, you can configure affinity rules to control collector scheduling. (LOG-6858)
- With this release, the default values of Splunk metadata keys (that is, index, indexed fields, source, and message payload) are predefined for log forwarders. The values are based on the log type. As a user, you can override these values. (LOG-6859)
1.4.1.2. Log storage Copy linkLink copied to clipboard!
-
With this release, you can use the
forcepathstylefield in the S3 secret. Use this field to configure Loki to use either path style or virtual host style for the S3 access. By default, only AWS endpoints use the virtual host style URL, while others use path-style. (LOG-7024)
1.4.2. Technology preview features Copy linkLink copied to clipboard!
The OpenTelemetry Protocol (OTLP) output log forwarder is a Technology Preview feature only. Technology Preview features are not supported with Red Hat production service level agreements (SLAs) and might not be functionally complete. Red Hat does not recommend using them in production. These features provide early access to upcoming product features, enabling customers to test functionality and provide feedback during the development process.
For more information about the support scope of Red Hat Technology Preview features, see Technology Preview Features Support Scope.
1.4.3. Bug fixes Copy linkLink copied to clipboard!
- Before this update, collector pods would enter a crash loop due to a configuration error when attempting token-based authentication with an Elasticsearch output. With this update, token authentication with an Elasticsearch output generates a valid configuration. (LOG-5991)
- Before this update, because of a lack of filtering based on the namespace in the Prometheus rules endpoint, user alerts were visible in unrelated namespaces. With this update, rule label filters have been added to the handler configuration. As a result, alert visibility is now restricted to the original namespace. (LOG-6148)
-
Before this update, the Loki API documentation did not specify the required attributes for the
lokistack.spec.tenants.openshift.otlpresource. With this update, the Loki API documentation has been updated to include the missing information. (LOG-6810) -
Before this update, the loki-gateway did not enforce fine-grained authorization on the
/seriesendpoint for theapplicationtenant. As a consequence, users could get unauthorized access to the stream metadata information from different log streams. With this update, the/seriesendpoint uses thematchparameter instead of thequeryparameter to filter the series metadata that is returned for a request. As a result, the loki-gateway correctly enforces fine-grained authorization for the/seriesendpoint for theapplicationtenant. (LOG-6892)
Before this update, restarting Vector collector pods in OpenShift Container Platform clusters created a high volume of requests to the
KubeAPI. As a result, the control plane could become unavailable. With this update, when restarting the collector pods, users can enable kube caching with theuse-apiserver-cacheattribute and configure the DaemonSet rollout strategy with themax-unavailable-rolloutattribute . As a result, the control plane remains stable during collector pod restarts, which reduces API request timeouts. (LOG-7196)ImportantUsing the
use-apiserver-cacheandmax-unavailable-rolloutattributes is a Technology Preview feature only. Technology Preview features are not supported with Red Hat production service level agreements (SLAs) and might not be functionally complete. Red Hat does not recommend using them in production. These features provide early access to upcoming product features, enabling customers to test functionality and provide feedback during the development process.For more information about the support scope of Red Hat Technology Preview features, see Technology Preview Features Support Scope.
-
Before this update, a
ClusterLogForwarderCR that was configured for aLokiStackoutput with the OTEL data model incorrectly passed validation without thetech previewannotation. With this update, aClusterLogForwarderCR that is configured for aLokiStackoutput with the OTEL data model correctly fails validation unless thetech previewannotation is included. (LOG-7279)
1.4.4. Known issues Copy linkLink copied to clipboard!
- When you forward logs to a syslog output, the produced message format is inconsistent between Fluentd and Vector log collectors. Vector messages are within quotation marks; Fluentd messages are not. As a consequence, users might experience issues with their tool integrations when they migrate from Fluentd to Vector. (LOG-7007)