Chapter 1. Logging 6.5 release notes

Previously, Vector could fail to authenticate to Kafka 4.0.0 when using the SCRAM-SHA-512 SASL mechanism, which could lead to connection issues and stalled producers. With this update, the rdkafka library has been upgraded to 0.38.0, resolving these authentication issues and ensuring stable connectivity to Kafka 4.0.0 clusters.

LOG-7506

Previously, duplicate case-variant headers (such as Accept and accept) in the ClusterLogForwarder could cause a media_type_header_exception when sending logs to the Elasticsearch output. With this update, header names are normalized using CanonicalHeaderKey, which prevents duplicate case-variant headers and resolves the exception.

LOG-8581

Previously, the Eventrouter used metadata.creationTimestamp as the log timestamp for Kubernetes Events, which could be weeks or months old for repeated events, causing Loki to reject the logs with a greater_than_max_sample_age error. With this update, Eventrouter now uses event.lastTimestamp as the primary log timestamp, falling back to firstTimestamp, eventTime, and then creationTimestamp only if necessary, ensuring that events are correctly accepted by Loki.

LOG-8697

Previously, setting compression: none for S3 log forwarding was ignored, and logs were always compressed using GZIP by default. With this update, specifying compression: none is correctly respected, allowing logs to be forwarded to S3 without compression as intended.

LOG-8769

Previously, Log File Metric Exporter (LFME) pods would log "unsupported cipher suite" error messages during startup when encountering certain TLS configurations. This update ensures that all required cipher suites are properly recognized and supported, eliminating these error messages and ensuring consistent TLS behavior.

LOG-8893

Previously, collectors configured to use the detect_exceptions transform would create separate instances of the state machine for each log stream, leading to increased memory consumption. With this update, the behavior has been modified to share a single state machine instance across all log streams, significantly reducing the memory usage of the collector.

LOG-9314

With this release, log entries forwarded to OpenTelemetry Protocol (OTLP) or LokiStack outputs with dataModel: Otel are 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.

LOG-5843

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.

LOG-6715

With this release, OpenShift Logging support for OpenTelemetry (OTel) is promoted to General Availability (GA). You can now forward logs over OTLP outputs by using OTel semantic conventions as specified in the Red Hat Observability Model. This includes configuring log forwarding to a LokiStack deployment using the OTel data model for log storage and retrieving logs by using the log observability UI plugin distributed by the Cluster Observability Operator.

LOG-7623

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 format field to ndjson. 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
# ...

LOG-7892

With this release, the ClusterLogForwarder API 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.

LOG-8241

With this release, you can configure a proxy URL when forwarding logs to a Loki output in the ClusterLogForwarder custom resource by setting the proxyURL field. 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
# ...

LOG-8645

With this release, you can disable the Gateway Route created automatically by the Loki Operator by setting the disableIngress field to true in the LokiStack custom resource. This provides more control over external access to your LokiStack deployment.

# ...
spec:
  tenants:
    disableIngress: true
    mode: openshift-logging
# ...

LOG-7810

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.

LOG-8080

With this release, the LokiStack openshift-network tenant 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.

LOG-8131

Before this update, the LokistackComponentsNotReadyWarning alert did not fire when LokiStack components were in Pending state during initial deployment, such as when provisioned with wrong 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.

LOG-7874

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.

LOG-8075

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.

LOG-8083

Before this update, the NetworkPolicy generated by the Loki Operator exposed the wrong 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.

LOG-8084

Before this update, the handling of the deprecated replicationFactor field was in the wrong part of the code. As a consequence, the field was ignored by the Loki Operator and not applied to replication.factor in 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 deprecated replicationFactor field is correctly processed and applied.

LOG-8795