OpenShift monitoring from control plane to application
Monitor Red Hat OpenShift clusters, nodes, projects, pods and routes with the Obseria Agent and OpenTelemetry, and connect platform health to the applications running on it.
Why monitor OpenShift with Obseria
Built for OpenShift specifics
Track projects, cluster resource quotas, routes and Operators, not only generic Kubernetes objects.
Keep your Prometheus stack
Forward metrics from OpenShift's built-in monitoring via Prometheus remote write and query them with PromQL in Obseria.
Platform and app in one view
Traces and logs from workloads are enriched with cluster, project and pod metadata, so platform and application teams share one picture.
OpenShift components Obseria monitors
- Control plane. API server latency and errors, etcd health and scheduler and controller manager signals.
- Nodes and machine pools. CPU, memory, disk and node conditions for control plane, infrastructure and worker nodes.
- Projects and quotas. Resource usage per project against ResourceQuotas and ClusterResourceQuotas.
- Workloads and pods. Deployments, StatefulSets, DaemonSets and pods with phase, restarts and resource usage.
- Routes and ingress. Request rates, response codes and backend health from the OpenShift router.
- Applications. Traces, metrics and logs from Java, .NET, Node.js and Python workloads via OpenTelemetry.
The OpenShift signals that matter
Obseria collects these values automatically and shows them in ready-made dashboards and alerts.Application availability
Shows whether all parts of your applications are running, ready to serve users and not restarting over and over.
Cluster health
Tells you whether the machines behind your platform are healthy and how much processing power they are using.
Capacity and budgets
Keeps track of how much of each team's reserved capacity and memory is in use, supporting fair planning.
Speed and errors
Reveals how quickly the platform and your published apps respond and how often users run into failed requests.
Show all 9 metrics in detail
| Metric | Unit | What it tells you |
|---|---|---|
k8s.pod.phase | {phase} | Current pod phase; pods stuck in Pending or Failed need attention. |
k8s.container.restarts | {restart} | Container restarts, the first sign of crash loops and OOM kills. |
k8s.node.condition_ready | {condition} | Whether a node reports Ready; anything else removes capacity. |
k8s.deployment.available | {pod} | Available replicas per deployment compared with the desired count. |
openshift.clusterquota.used | {resource} | Resources consumed against a ClusterResourceQuota across projects. |
k8s.pod.memory.working_set | By | Memory a pod actively uses; compare with limits to predict OOM kills. |
k8s.node.cpu.usage | {cpu} | CPU cores in use per node, the basis for capacity planning. |
apiserver_request_duration_seconds | s | Latency histogram of Kubernetes API server requests by verb and resource. |
haproxy_server_http_responses_total | {response} | HTTP responses by code class per route backend from the OpenShift router. |
Set up OpenShift monitoring in minutes
- Step 1
Deploy agent or Collector
Install the Obseria Agent with the Helm chart, or deploy the OpenTelemetry Collector as a DaemonSet plus one cluster-level instance, with the required security context constraints.
- Step 2
Forward platform metrics
Optionally add a remote write target to OpenShift's cluster monitoring configuration to send existing Prometheus metrics to Obseria.
- Step 3
Instrument applications
Set OTEL_SERVICE_NAME and OTEL_EXPORTER_OTLP_ENDPOINT on your workloads or use OpenTelemetry auto-instrumentation to add traces.
# k8s_cluster runs once per cluster; kubeletstats runs on every node
receivers:
k8s_cluster:
distribution: openshift
collection_interval: 30s
kubeletstats:
auth_type: serviceAccount
endpoint: "https://${env:K8S_NODE_NAME}:10250"
insecure_skip_verify: true
processors:
k8sattributes: {}
batch: {}
exporters:
otlphttp:
endpoint: ${env:OBSERIA_OTLP_ENDPOINT}
headers:
Authorization: "Bearer ${env:OBSERIA_TOKEN}"
service:
pipelines:
metrics:
receivers: [k8s_cluster, kubeletstats]
processors: [k8sattributes, batch]
exporters: [otlphttp]Out of the box
Dashboards, alerts and SLOs that are ready the moment data arrives.
- OpenShift cluster overview by node role
- Project resource usage against quotas
- Pod restarts and crash loop alerts
- Router traffic and 5xx rate per route
- API server latency and etcd health
OpenShift monitoring: what matters
Why OpenShift monitoring matters
Red Hat OpenShift adds a lot on top of Kubernetes: projects with quotas, routes served by an HAProxy-based router, Operators that manage the platform itself, security context constraints and an integrated monitoring stack based on Prometheus. That makes OpenShift monitoring both easier and harder. Easier, because many metrics are already exposed. Harder, because the platform has more moving parts, and the people who run the cluster are often not the people who run the applications.
OpenShift observability brings both perspectives together. Platform teams need to see node pressure, control plane health and quota usage across many projects. Application teams need to see why their service is slow, and whether the cause is their code, a dependency or the platform below.
The OpenShift signals that matter
Structure your OpenShift cluster monitoring in layers:
- Control plane:
apiserver_request_duration_secondsand API error rates, etcd leader changes and disk sync latency. A slow API server delays deployments, scaling and Operators. - Nodes: node conditions such as
k8s.node.condition_ready, CPU and memory usage, and disk pressure. Separate control plane, infrastructure and worker nodes, because their failure impact differs. - Projects and quotas:
openshift.clusterquota.usedagainst limits and ResourceQuota usage per project. Exhausted quotas block new pods without obvious errors in the application. - Workloads:
k8s.pod.phase,k8s.container.restarts,k8s.deployment.availableandk8s.pod.memory.working_setagainst limits. - Routes: request rates and response codes from the router, for example
haproxy_server_http_responses_total, give you the rate and error signals at the edge.
Common OpenShift problems and how to detect them
Pods stuck in Pending. Usually a quota, a missing node selector or not enough schedulable capacity. Pod phase together with quota usage and scheduler events tells you which one.
Crash loops and OOM kills. Rising k8s.container.restarts with memory close to the limit points to undersized limits or a memory leak. Continuous profiling and traces from the workload help decide which.
Security context constraint denials. A workload that needs privileges it does not have will fail to start. Kubernetes events and pod status reveal the denial, and Obseria shows it next to the deployment that triggered it.
Router errors. 503 responses on a route often mean no ready endpoints behind the service. Router response codes combined with deployment availability make the link visible in one view.
Upgrades and Operator issues. Cluster upgrades and Operator rollouts change many components at once. Tracking them as events on the same timeline as metrics shortens the search for regressions.
OpenShift monitoring best practices
- Keep OpenShift's built-in monitoring for the platform and forward its metrics instead of scraping everything twice.
- Label workloads consistently with service, team and version so telemetry can be grouped by owner.
- Alert on user-facing symptoms per route and service, and use node and pod metrics for diagnosis.
- Watch quotas proactively, since quota exhaustion fails silently for application teams.
- Use OpenTelemetry for application traces so you can switch backends without re-instrumenting.
How Obseria monitors OpenShift
Obseria collects OpenShift telemetry with the Obseria Agent or the OpenTelemetry Collector, including the OpenShift-specific cluster quota metrics of the Kubernetes cluster receiver. Existing Prometheus metrics can be sent by remote write and queried with PromQL. Application traces, metrics and logs arrive over OTLP and are enriched with project, pod and node metadata. Obseria TopoGraph maps routes, services, pods and nodes automatically, and Obseria Intelligence correlates platform and application signals to find root causes. Dashboards, alerts and SLOs are included, and Obseria Pipeline can filter noisy container logs before they are stored.
For multi-cluster setups, each cluster sends its telemetry with a cluster name attribute, so you can compare clusters, track upgrades across a fleet and keep platform-wide SLOs in one place. Data can stay in the EU region or in your own cloud account.
Related integrations
Related capabilities
Kubernetes Monitoring
See every cluster, node, pod and workload in context. Obseria connects Kubernetes metrics, events, logs and traces so you find the cause of a failing rollout in minutes.
Learn moreDistributed Tracing
Follow each request across services, queues and databases with OpenTelemetry-native distributed tracing, and find the slow span or failing dependency in seconds.
Learn moreAnomaly Detection
Obseria Intelligence learns the normal rhythm of every service, flags real deviations instead of threshold noise and groups related anomalies into one problem with a probable root cause.
Learn moreLearn more
What is observability?
What is observability? Learn how metrics, logs, traces and profiles let you understand any system state, how it differs from monitoring, and how to start.
The four golden signals: latency, traffic, errors and saturation
The four golden signals explained: latency, traffic, errors and saturation, how they relate to the RED and USE methods, and how to measure them with OTel.
OpenShift monitoring FAQ
Yes. Many teams keep the built-in monitoring stack and add a remote write target so the metrics are also available in Obseria, together with traces and logs.
The agent or Collector needs a service account with read access to cluster objects and the kubelet stats endpoint. Node-level collection requires a security context constraint that allows host access.
Yes. Cluster resource quotas, projects and routes are covered alongside standard Kubernetes objects such as deployments, pods and nodes.
Yes. Use OpenTelemetry SDKs or auto-instrumentation in your workloads and send traces over OTLP. Traces are linked to the pods and nodes they ran on.
Obseria collects data through the agent, the OpenTelemetry Collector and Prometheus remote write, all of which run on self-managed and managed OpenShift clusters where you can deploy workloads.
Start monitoring OpenShift today
Connect OpenShift in minutes with OpenTelemetry or the Obseria Agent. Free for 14 days.