Chapter 1. Logging 6.5 release notes

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 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 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 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.

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 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.

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