Logging 5.9.0 Release Notes

_topic_maps/_topic_map.yml

@@ -2696,6 +2696,8 @@ Topics:
 - Name: Release notes
   Dir: logging_release_notes
   Topics:
+  - Name: Logging 5.9
+    File: logging-5-9-release-notes
   - Name: Logging 5.8
     File: logging-5-8-release-notes
   - Name: Logging 5.7

_topic_maps/_topic_map_osd.yml

@@ -1129,6 +1129,8 @@ Topics:
 - Name: Release notes
   Dir: logging_release_notes
   Topics:
+  - Name: Logging 5.9
+    File: logging-5-9-release-notes
   - Name: Logging 5.8
     File: logging-5-8-release-notes
   - Name: Logging 5.7

_topic_maps/_topic_map_rosa.yml

@@ -1369,6 +1369,8 @@ Topics:
 - Name: Release notes
   Dir: logging_release_notes
   Topics:
+  - Name: Logging 5.9
+    File: logging-5-9-release-notes
   - Name: Logging 5.8
     File: logging-5-8-release-notes
   - Name: Logging 5.7

logging/logging_release_notes/logging-5-9-release-notes.adoc

@@ -0,0 +1,13 @@
+:_mod-docs-content-type: ASSEMBLY
+[id="logging-5-9-release-notes"]
+include::_attributes/common-attributes.adoc[]
+= Logging 5.9
+:context: logging-5-9-release-notes
+
+toc::[]
+
+include::snippets/logging-compatibility-snip.adoc[]
+
+include::snippets/logging-stable-updates-snip.adoc[]
+
+include::modules/logging-release-notes-5-9-0.adoc[leveloffset=+1]

modules/logging-release-notes-5-9-0.adoc

@@ -0,0 +1,77 @@
+//module included in logging-5-9-release-notes.adoc
+:content-type: REFERENCE
+[id="logging-release-notes-5-9-0_{context}"]
+= Logging 5.9.0
+This release includes link:https://access.redhat.com/errata/RHBA-2024:1591[OpenShift Logging Bug Fix Release 5.9.0]
+
+[id="logging-release-notes-5-9-0-removal-notice"]
+== Removal notice
+
+The {logging-uc} 5.9 release does not contain an updated version of the {es-op}. Instances of {es-op} from prior {logging} releases, remain supported until the EOL of the {logging} release. As an alternative to using the {es-op} to manage the default log storage, you can use the {loki-op}. For more information on the {logging-uc} lifecycle dates, see link:https://access.redhat.com/support/policy/updates/openshift_operators#platform-agnostic[Platform Agnostic Operators].
+
+[id="logging-release-notes-5-9-0-deprecation-notice"]
+== Deprecation notice
+
+* In {logging-uc} 5.9, Fluentd, and Kibana are deprecated and are planned to be removed in {logging-uc} 6.0, which is expected to be shipped alongside a future release of {product-title}. Red Hat will provide critical and above CVE bug fixes and support for these components during the current release lifecycle, but these components will no longer receive feature enhancements. The Vector-based collector provided by the {clo} and LokiStack provided by the {loki-op} are the preferred Operators for log collection and storage. We encourage all users to adopt the Vector and Loki log stack, as this will be the stack that will be enhanced going forward.
+
+* In {logging-uc} 5.9, *Fields* option in output type Splunk is deprecated and is planned to be removed in a future release. Red Hat will provide bug fixes and support for this feature during the current release lifecycle, but this feature will no longer receive enhancements and will be removed.
+
+[id="logging-release-notes-5-9-0-enhancements"]
+== Enhancements
+
+[id="logging-release-notes-5-9-0-log-collection"]
+=== Log Collection
+* This enhancement adds the ability to refine the process of log collection by using a workload's metadata and to `drop` or `prune` logs based on their content. Additionally, it allows the collection of infrastructure like journal or container logs and audit logs like `kube api` or `ovn` to only collect individual sources. (link:https://issues.redhat.com/browse/LOG-2155[LOG-2155])
+
+* This enhancement introduces a new type of remote log receiver, the Syslog Receiver. You can configure it to expose a port over a network, allowing external systems to send Syslog logs using compatible tools such as Rsyslog. (link:https://issues.redhat.com/browse/LOG-3527[LOG-3527])
+
+* With this update, the `ClusterLogForwarder` API now supports log forwarding to Azure Monitor Logs, giving users better monitoring abilities. This feature helps users to maintain optimal system performance and streamline log analysis processes in Azure Monitor, which speeds up issue resolution and improves operational efficiency. (link:https://issues.redhat.com/browse/LOG-4605[LOG-4605])
+
+* This enhancement improves collector resource utilization by deploying collectors as a deployment with two replicas. It happens when the only input source defined in the `ClusterLogForwarder` is a receiver input instead of using a daemonset on all nodes. Additionally, collectors deployed like this do not mount the host file system. To use this enhancement, you need to annotate the `ClusterLogForwarder` with `logging.openshift.io/dev-preview-enable-collector-as-deployment`. (link:https://issues.redhat.com/browse/LOG-4779[LOG-4779])
+
+* This enhancement introduces the capability for custom tenant configuration across all supported outputs, facilitating the organization of log records in a logical manner. However, it does not permit custom tenant configuration for {logging} managed storage. (link:https://issues.redhat.com/browse/LOG-4843[LOG-4843])
+
+* With this update, the `ClusterLogForwarder` that specifies an application input with one or more infrastructure namespaces like `default`, `openshift*`, or `kube*`, now requires a service account with the `collect-infrastructure-logs` role. (link:https://issues.redhat.com/browse/LOG-4943[LOG-4943])
+
+* This enhancement introduces the capability for tuning some output settings like compression, retry duration, and max payloads, to match characteristics of the receiver. Additionally, this feature includes a delivery mode to allow administrators to choose between throughput and log durability. For example, `AtLeastOnce` configures minimal disk buffering of collected logs so that the collector can deliver those logs after a restart. (link:https://issues.redhat.com/browse/LOG-5026[LOG-5026])
+
+* This enhancement adds three new Prometheus alerts, warning users about the deprecation of Elasticsearch, Fluentd, and Kibana. (link:https://issues.redhat.com/browse/LOG-5055[LOG-5055])
+
+[id="logging-release-notes-5-9-0-log-storage"]
+=== Log Storage
+
+* This enhancement in LokiStack improves support for OTEL by using the new V13 object storage format and enabling automatic stream sharding by default. This also prepares the collector for future enhancements and configurations. (link:https://issues.redhat.com/browse/LOG-4538[LOG-4538])
+
+* This enhancement introduces support for short-lived token workload identity federation with Azure and AWS log stores for STS enabled {product-title} 4.14 and later clusters. Local storage requires the addition of a `CredentialMode: static` annotation under `spec.storage.secret` in the LokiStack CR. (link:https://issues.redhat.com/browse/LOG-4540[LOG-4540])
+
+* With this update, the validation of the Azure storage secret is now extended to give early warning for certain error conditions. (link:https://issues.redhat.com/browse/LOG-4571[LOG-4571])
+
+* With this update, Loki now adds upstream and downstream support for GCP workload identity federation mechanism. This allows authenticated and authorized access to the corresponding object storage services. (link:https://issues.redhat.com/browse/LOG-4754[LOG-4754])
+
+[id="logging-release-notes-5-9-0-bug-fixes"]
+== Bug Fixes
+* Before this update, the {logging} must-gather could not collect any logs on the FIPS enabled cluster. With this update, a new `oc` client is available in `cluster-logging-rhel9-operator`, and must-gather works properly on FIPS clusters. (link:https://issues.redhat.com/browse/LOG-4403[LOG-4403])
+
+* Before this update, the LokiStack ruler pods could not format the IPv6 pod IP in HTTP URLs used for cross-pod communication. This issue caused querying rules and alerts through the Prometheus-compatible API to fail. With this update, the LokiStack ruler pods encapsulate the IPv6 pod IP in square brackets, resolving the problem. Now, querying rules and alerts through the Prometheus-compatible API works just like in IPv4 environments. (link:https://issues.redhat.com/browse/LOG-4709[LOG-4709])
+
+* Before this fix, the YAML content from the {logging} must-gather was exported in a single line, making it unreadable. With this update, the YAML white spaces are preserved, ensuring that the file is properly formatted. (link:https://issues.redhat.com/browse/LOG-4792[LOG-4792])
+
+* Before this update, when the `ClusterLogForwarder` was enabled, the {clo} could run into a nil pointer exception when `ClusterLogging.Spec.Collection` was nil. With this update, the issue is now resolved in the {clo}. (link:https://issues.redhat.com/browse/LOG-5006[LOG-5006])
+
+* Before this update, in specific corner cases, replacing the `ClusterLogForwarder` status field caused the `resourceVersion` to constantly update due to changing timestamps in `Status` conditions. As a result, it led to an infinite reconciliation loop. With this update, all status conditions synchronize, so that timestamps remain unchanged if conditions stay the same. (link:https://issues.redhat.com/browse/LOG-5007[LOG-5007])
+
+* Before this update, there was an internal buffering behavior to `drop_newest` to address high memory consumption by the collector resulting in significant log loss. With this update, the behavior reverts to using the collector defaults. (link:https://issues.redhat.com/browse/LOG-5123[LOG-5123])
+
+* Before this update, the configuration of the {loki-op}'s `ServiceMonitor` could match many Kubernetes services, resulting in the {loki-op}'s metrics being collected multiple times. With this update, the configuration of `ServiceMonitor` now only matches the dedicated metrics service. (link:https://issues.redhat.com/browse/LOG-5212[LOG-5212])
+
+[id="logging-release-notes-5-9-0-known-issues"]
+== Known Issues
+None.
+
+[id="logging-release-notes-5-9-0-CVEs"]
+== CVEs
+* link:https://access.redhat.com/security/cve/CVE-2023-5363[CVE-2023-5363]
+* link:https://access.redhat.com/security/cve/CVE-2023-5981[CVE-2023-5981]
+* link:https://access.redhat.com/security/cve/CVE-2023-46218[CVE-2023-46218]
+* link:https://access.redhat.com/security/cve/CVE-2024-0553[CVE-2024-0553]
+* link:https://access.redhat.com/security/cve/CVE-2024-0567[CVE-2023-0567]