Enhanced observability in OpenShift 4.15

In the Red Hat OpenShift 4.15 release, our focus remains on simplifying integration of the Observability stack for new OpenShift users. And there are some particularly exciting and useful Observability features this time around, including OpenShift Monitoring 4.15, Logging 5.9, and Distributed Tracing 3.1. These tools enhance data collection, storage, delivery, visualization, and analytics capabilities, which transforms your data into actionable insights, empowering you to troubleshoot efficiently.

The Cluster Observability Operator enables the more seamless installation of a default set of monitoring components and features for cluster monitoring. We've also expanded the logging components and integrated log metrics into both the administrative and developer consoles of the Observability UI. We've launched a tech preview of the Power Monitoring component, providing you with the capability to monitor the energy consumption of your applications on the OpenShift cluster.

Improved monitoring on your OpenShift cluster

A great new feature is that we now ‘tolerate scrape timestamp jitter’. Ideally, scrapes should happen precisely on the defined scrape interval (every 30 seconds, for example). However, due to factors like network delays or system load, small timing variations (jitter) can occur.  This jitter, even when minor, can significantly disrupt the effectiveness of delta-of-delta compression, leading to large storage requirements in a TSDB. Prometheus can be configured to tolerate a certain degree of jitter in scrape timestamps so that it adjusts recorded timestamps of metrics, within a small range, to align them with expected scrape intervals. In the best cases, we've observed a 50% difference in on-disk TSDB storage for a replicated HA pair.

User Workload Monitoring (UWM) allows you to use exemplar-storage, references to data outside of your MetricSet (for example, IDs of program traces). Exemplar storage is implemented as a fixed-size circular buffer that stores exemplars in memory for all series.

For data visualization, OpenShift 4.15 brings visibility enhancements by displaying  externalLabels defined in cluster-monitoring-config as alerts triggered within the OpenShift web console.

Better troubleshooting with improved logging

In Logging 5.9, you can benefit from Log Metrics presented through the Logs UI within the web console. Specifically, you have access to a line chart for log-based metrics to help with comprehensive troubleshooting. You can also search across multiple namespaces in the Logs UI.

Developers can select various namespaces from a drop-down menu, enhancing troubleshooting efficiency across namespaces.

Red Hat build of OpenTelemetry for seamless data collection

A few months ago, we announced the General Availability of the Red Hat build of OpenTelemetry, offering support for all OpenTelemetry Protocol (OTLP) signals: metrics, logs, and traces. This marks a significant milestone in modern and open observability, emphasizing seamless data collection and delivery. This release extends support to Arm environments, too. For developers, we've made observability and instrumentation easier with the introduction of the Automatic Instrumentation CR, and new components available in Tech Preview.

Additionally, you can generate metrics from spans and create alerts based on those metrics. The latest update also facilitates the integration of a Kafka receiver and exporter, along with more seamless incorporation into the Prometheus stack. This enhancement enables you to scrape Prometheus endpoints more effortlessly and efficiently manage and scale with the Target Allocator. We've also introduced Filelog and journald receivers as a developer preview to gather early feedback, and we're eager to hear your thoughts and experiences with OpenTelemetry.

Distributed tracing with the Tempo Operator

The Tempo Operator is now Generally Available as our preferred backend to store traces, and it comes with support for Arm architectures. Tempo is a scalable, distributed tracing storage solution that can be used to store and query traces from large-scale microservices architectures.

To emphasize our commitment to this new stack, we've made the decision to deprecate Jaeger. Rest assured, Red Hat continues to offer essential CVE and bug fixes and provide support for these components for at least two releases. It's worth noting that Tempo still includes the Jaeger User Interface, which helps to provide a smoother visualization of traces.

In the latest release, we've enabled support for span request count, duration, and error count (RED) metrics. This marks a significant advancement for you to seamlessly visualize service and application performance monitoring directly in the monitor tab, eliminating the need for additional investment in third-party platforms.

There's now a developer preview of Tempo monolithic deployment. Serving as a drop-in replacement for a Jaeger all-in-one deployment, this enables effortless local deployments.

Monitor tab in the Jaeger user interface, installed by the Tempo operator

Power monitoring

Last October, we announced the developer preview of power monitoring for Red Hat OpenShift, unveiling Kepler as an integral component of the sustainable-computing upstream community initiative. This initiative enables early adopters to experiment with this promising technology. Since that announcement, our team has been working hard to build pipelines and tooling that meet Red Hat's product security and testing standards.

Recently, we introduced power monitoring as a Technology Preview for Red Hat OpenShift. This makes the operator available in the Red Hat Marketplace. This integration with the Observability UI allows you to easily assess the most power-consuming workloads on your cluster and gain insights into the overall energy consumption of your cluster.

To learn more about power monitoring for Red Hat OpenShift, see our announcement.

What’s next for Red Hat OpenShift Observability?

Our aim is to provide you with a comprehensive set of observability components, facilitating seamless integration of data into various workflows while also enabling us to develop additional features atop them. A primary focus of our efforts is directed towards detecting, investigating, and remediating problems.

We're working to deliver a Tech Preview of Observability Signal Correlation for Red Hat OpenShift. In the future, this will support additional observability signals, such as traces and network flow data. This will enable faster problem resolution, and a better understanding of complex system behaviors.

Additionally, we are dedicated to enhancing the user interface experience across all Observability components by closely integrating them with the OpenShift console and, eventually, with the Red Hat Advanced Cluster Management console. In late December 2023, the Red Hat Observability team began collaborating within the upstream community Perses. The Perses project aims to establish a standard dashboarding tool for all our observability components, enabling us to deliver dashboards as code to enhance UI dashboards easily with available components. Powered by Perses, a ScatterPlot and associated table will empower users to explore traces. In pursuit of unifying the OpenShift Observability experience, we've been diligently working on providing an Observe>Distributed Tracing UI. Starting in Q2 2024, users will have the opportunity to experience a Dev Preview of the Distributed Tracing UI within the Admin Perspective of the OCP Web Console.

In the realm of OpenTelemetry, we're actively heeding your feedback and incorporating support for numerous components from the extensive and vibrant community of contributors to the opentelemetry-collector-contrib repository. Keep an eye out, because the upcoming release will introduce numerous additions in Technology Preview!

Discover more about our Observability components and upcoming developments at https://redhat.com/observability

We value your feedback, which is crucial for enhancing our products. Share your questions and recommendations with us using the Red Hat OpenShift feedback form.