New observability features in Red Hat OpenShift 4.22

The most recent Red Hat OpenShift release introduces powerful new capabilities for native monitoring, logging, tracing, and dashboarding. Red Hat OpenShift observability has matured into a more seamless ecosystem by merging metrics, logs, traces, and network telemetry into a unified workflow. This integrated approach helps eliminate the common burden of Kubernetes tool sprawl, replacing disconnected dashboards with a hardened, centralized, and fully supported platform.

Cluster observability operator 1.5

The Cluster Observability operator (COO) functions as a "meta-operator", tasked with deploying and overseeing autonomous monitoring stacks that operate independently of core OpenShift metrics. Beyond stack management, it provides advanced analytics tools (such as incident detection and Korrel8r-powered signal correlation) alongside observability UI plug-ins. Our latest release introduces several brand new features that are now generally available.

Customizable dashboards with Red Hat build of Perses (general availability)

The Red Hat build of Perses dashboarding tool is now fully supported as part of Cluster Observability operator 1.5 in Red Hat OpenShift and Red Hat Advanced Cluster Management. Read the previous technology preview article for an interactive tutorial.

With COO 1.5, the dashboarding tool is now fully integrated and supported as a core component of the observability stack.

Key capabilities include:

• Native deployment and lifecycle management of the Red Hat build of Perses with COO
• Multi-cluster dashboard visibility through integration with Red Hat Advanced Cluster Management
• Role-Based Access Control (RBAC) alignment with OpenShift for more secure access control
• GitOps-friendly workflows for dashboard definitions
• Compatibility with existing monitoring data sources, including Prometheus and Thanos

This release marks a significant step forward in how teams build, customize, and scale observability dashboards across clusters. With Perses, you gain a modern and extensible dashboarding experience designed for cloud-native environments.

Why Perses?

As observability needs evolve, so do expectations around flexibility, performance, and integration. Traditional dashboarding approaches often struggle to keep up with dynamic, multi-cluster environments.

The Red Hat build of Perses addresses these challenges by offering:

• A Kubernetes-native dashboarding platform with declarative configuration
• Better integration with Prometheus and other observability backends
• High-performance rendering designed for large-scale environments
• A flexible plugin model for custom panels and data sources

This makes Perses a natural fit for OpenShift users who want tighter control over how dashboards are defined, versioned, and deployed.

Built for multi-cluster observability

Running workloads across multiple clusters introduces complexity, not just in monitoring, but in how data is presented and consumed.

With Perses in Red Hat Advanced Cluster Management environments, you can:

• Create reusable dashboards that span multiple clusters
• Normalize observability views across environments
• Reduce duplication in dashboard configuration
• Enable consistent troubleshooting workflows for systems reliability engineering (SRE) and dev teams

This aligns with a broader shift toward centralized observability with decentralized ownership.

A better developer and SRE experience

Perses is designed with both developers and SREs in mind. Its declarative model enables dashboards to be treated as code, making them easier to version, review, and evolve alongside applications.

For example, a team can define a dashboard in YAML, store it in Git, and deploy it automatically through their existing CI/CD pipelines, providing consistency across environments without manual intervention.

At the same time, the UI remains intuitive and responsive, allowing for rapid exploration and iteration when investigating incidents.

Getting started

The Red Hat build of Perses is available today as part of Cluster Observability operator 1.5. To get started:

• Upgrade to COO 1.5 in your OpenShift environment
• Enable Perses through the operator configuration
• Begin creating dashboards using the OpenShift console
• Integrate with your existing observability data sources

Documentation and examples are available to help you quickly onboard and start building dashboards tailored to your workloads.

This release is just the beginning. Future enhancements will continue to expand Perses capabilities, including richer visualization options, deeper integrations, and enhanced multi-cluster experiences.

OpenShift monitoring

Reliable cluster monitoring is foundational to everything else in observability. If platform metrics are noisy, incomplete, or hard to trust during upgrades, every downstream workflow including alerting, dashboards, capacity planning, and incident response suffers. In OpenShift 4.22, we continue to invest in the in-cluster monitoring stack with a practical focus: make monitoring quieter and more correct day to day, keep the platform aligned with upstream Kubernetes and Prometheus innovation, and give administrators more control when they need deeper visibility.

More trustworthy monitoring health signals

In previous releases, the monitoring ClusterOperator could briefly report degraded or unavailable status during normal upgrades, API rate limiting, or transient etcd leader changes—even when the stack was healthy. OpenShift 4.22 fixes this class of false alarms so ClusterOperator status better reflects real problems. Platform teams get fewer false positives during change windows and a health signal they can trust when deciding whether intervention is required.

Optional network interface metrics with ethtool

Network troubleshooting often needs more than standard node counters. OpenShift 4.22 adds supported Cluster Monitoring operator configuration to enable the node-exporter ethtool collector. It stays off by default, but administrators can opt in for rich NIC diagnostics without custom manifests or unsupported overlays.

EndpointSlice migration and metrics-server hardening

Kubernetes has deprecated the Endpoints API, and OpenShift 4.22 advances the move to EndpointSlices across Cluster Monitoring operator (CMO), kube-prometheus, and platform operators. EndpointSlice metrics are now exposed by kube-state-metrics 2.18.0 by default. This migration continues across the platform, but OpenShift 4.22 materially reduces deprecation noise and keeps monitoring aligned with Kubernetes 1.33+.

We also continue metrics-server hardening: A dedicated client certificate reduces dependency on Prometheus-managed credentials and improves startup reliability.

Monitoring stack component updates

As with every OpenShift release, we've completed another round of downstream component updates to bring in upstream performance improvements, bug fixes, and security patches. Some of the key updates include:

• Prometheus operator 0.90.1 (from 0.87.1 in 4.21)
• Prometheus 3.9.1 (from 3.7.3 in 4.21)
• Kube-state-metrics 2.18.0 (from 2.17.0 in 4.21)
• node-exporter 1.10.2 (unchanged from 4.21)
• Thanos 0.41.0 (from 0.39.2 in 4.21)
• Alertmanager 0.31.1 (from 0.29.0 in 4.21)
• Metrics Server 0.8.1 (from 0.8.0 in 4.21)

Getting started

Most OpenShift 4.22 monitoring improvements are delivered automatically as part of the platform upgrade. For optional capabilities such as the ethtool collector, refer to the Cluster Monitoring operator configuration documentation. For component version details and supported monitoring architecture, see the monitoring documentation and release notes for OpenShift 4.22.

OpenShift logging

Demands on enterprise observability are shifting. It's no longer enough to simply collect logs. Those logs must be secure, the pipelines must be resilient to cloud provider changes, and Day-One setup must be instantaneous.

In OpenShift 4.22, we're delivering major updates to the Red Hat OpenShift logging stack that directly address these needs, focusing on native Microsoft Azure integration and radical simplification of the deployment process.

Log collection: Continued Microsoft Azure Integration

One of the most critical updates in this release is our proactive support for the Microsoft Azure Monitor Logs Ingestion API. With Microsoft retiring its legacy Data Collector API on September 14, 2026, we have modernized the cluster log forwarder (CLF) to keep you ahead of the curve. Key highlights include:

• OTLP-native forwarding: We have updated the CLF to utilize the OpenTelemetry Protocol (OTLP). This provides a vendor-neutral, high-performance bridge to Microsoft Azure, meaning your telemetry streams remain uninterrupted during Microsoft's API transition.
• Zero trust security with WIF: We are moving away from the risks associated with static shared keys. By integrating Workload Identity Federation (WIF), OpenShift can now authenticate to Microsoft Azure using short-lived, cryptographically secure tokens. This automates credential rotation and significantly hardens your security posture.

Log storage: A seamless Day-One experience

Historically, deploying a full logging stack meant managing multiple operators and complex manual configurations. We've changed that. We believe that observability should be a foundational part of the cluster, not a complex add-on. Red Hat OpenShift 4.22 introduces the integration of the logging stack into the Cluster Observability operator installer.

• One-click deployment: Through the ObservabilityInstaller CRD, you can now deploy a production-ready environment—including both the Cluster Logging operator and the Loki operator—as part of your initial cluster setup.
• Immediate visibility: By automating the connection between the collector and the store from the start, application and infrastructure logs are available for troubleshooting the moment your cluster goes live.

All in all, whether you are navigating the move to OpenTelemetry Protocol on Microsoft Azure or looking to stamp out consistent observability across a global fleet of clusters, OpenShift 4.22 provides the tools to make your logging infrastructure invisible, immutable, and incredibly fast.

Take a look at the updated OpenShift logging documentation for sizing guides and the new COO installation workflows.

OpenTelemetry and tracing

Building on the improvements discussed in the OpenShift logging section, we are also releasing Distributed Tracing 3.10, which contains updated versions of the Red Hat build of OpenTelemetry for collecting metrics, logs, events, and traces. We are also releasing the Tempo operator for storing, visualizing, and querying your traces.

The Red Hat build of OpenTelemetry contains four components that have moved to General Availability:

Probabilistic sampler

First, we have the probabilistic sampler. This sampler is very useful when you want to keep accurate samples of your traces while also balancing concerns for storage and costs. You can configure the probabilistic sampler to forward a set percentage of your total traces to storage, and the deterministic decisions made by the collector ensure that the same decisions are made every time on whether to forward or drop the trace. With this sampler, you retain accuracy while only storing a fraction of the traces, saving costs at the compute and the storage level.

Tail-based sampler

With the tail-based sampler, the collector evaluates whether to keep or drop a trace at the end of the request. By waiting until the end of the request to make the decision, the full context of the trace is used for evaluation, which leads to highly accurate decisions. This can also help save storage costs, because you can filter based on very specific criteria, and you have the entire trace context to make that decision.

Kubernetes objects receiver

The Kubernetes objects receiver is an OpenTelemetry component that can collect raw data from the Kubernetes API and export them as OTLP-formatted logs. This is very useful when you need to capture the state of a Kubernetes object, or if you need to collect Kubernetes events and then export them as OTLP logs.

PrometheusRemoteWrite exporter

Finally, the PrometheusRemoteWrite exporter takes metrics that have been collected, compresses them, converts them into a Prometheus time series format, and then pushes them to Prometheus or a Prometheus-compatible database. This is very useful for large architectures that are using a centralized, Prometheus-compatible, database for metrics.

For storage, we have upgraded the version of the Tempo operator to Tempo 2.10.5. One of the important updates here is that the new version of Tempo has enhanced the correctness of the collected metrics, especially the metrics average over time. And finally, for users that utilize their own Grafana instance to access Tempo, we have enhanced the authentication experience by allowing users to authenticate the Tempo route using OpenShift OAuth.

Conclusion

The advancements in Red Hat OpenShift 4.22 signal a shift toward a unified and seamless observability ecosystem. By merging metrics, logs, and traces into a single workflow, this release significantly reduces operational complexity through smarter operators and simplified deployment processes. Tools like the Red Hat build of Perses and modernized telemetry pipelines provide an enhanced experience for developers and SREs, enabling GitOps-friendly workflows and deeper architectural insights.

Ready to explore these new features? Visit the redhat.com/observability and documentation pages to learn more and get started with the latest observability tools in OpenShift. The Red Hat Developers Observability page also contains information to help you learn about and implement observability capabilities.

We value your feedback! Share your thoughts and suggestions using the Red Hat OpenShift feedback form.