OpenShift 5 reshapes the observability stack beyond AI incident response

Red Hat’s OpenShift 5 observability guide describes a broader platform change than the release’s headline AI troubleshooting features. Alongside supervised diagnosis and generated dashboards, the stack changes how teams configure metrics, operate logging pipelines, deploy OpenTelemetry components and expose traces to AI tooling.

What changed

Cluster Observability Operator 1.6 makes the Red Hat build of Perses easier to put into production. It supplies a default Thanos data source, lets application teams create Perses projects in the console and bundles plug-ins for disconnected environments. Lightspeed can generate Perses panels from natural-language requests, while an AI-Assisted badge lets operators inspect the PromQL, time range and metrics before pinning a panel.

OpenShift 5 also changes the underlying monitoring surface. Prometheus remote-write endpoints can select message version 1.0 or 2.0; node exporter enables the nvmesubsystem collector by default so OpenShift can alert on degraded or lost NVMe paths; and the first phase of a validated ClusterMonitoring custom resource appears behind no-upgrade preview feature sets. Red Hat says the existing ConfigMap remains authoritative when both mechanisms define the same field.

Logging for OpenShift 6.7 moves Loki to the 4.0 engine with schema v13 and TSDB indexing. The release adds age-based backlog filtering, multi-endpoint Elasticsearch forwarding with failover, AWS PrivateLink support for Loki object storage and disk buffering for at-least-once delivery. Red Hat explicitly tells users to migrate LokiStack configurations to schema v13 or later to use the updated capabilities.

Who should care

Platform teams running shared OpenShift observability services have the clearest action. Remote-write receivers must support the message version selected by each endpoint, and logging operators need to plan the Loki schema migration rather than treating 6.7 as a drop-in engine update.

OpenTelemetry operators gain high availability for the operator webhook and Tempo, including zone-aware replication. A technology preview of eBPF-based auto-instrumentation can collect web spans and request, error and duration metrics without code changes. New collector components add a Prometheus remote-write receiver, attribute redaction, outbound header manipulation and Kubernetes leader election.

What to try

Teams evaluating the release should separate production-ready paths from previews. Perses setup improvements, remote-write controls and the logging changes are operational features to validate against current receivers and storage. The ClusterMonitoring custom resource and eBPF auto-instrumentation remain previews with different risk boundaries.

The MCP integration is also worth testing in a controlled environment. OpenShift’s MCP server can list Tempo instances and search traces, tags and values, while OpenShift Lightspeed records agentic-run audit traces in Tempo. That creates a bridge between AI-assisted operations and the telemetry evidence needed to review what the agent proposed and what a human approved.