OpenShift Monitoring von der Control Plane bis zur Anwendung
Überwachen Sie Cluster, Nodes, Projekte, Pods und Routes von Red Hat OpenShift mit dem Obseria Agent und OpenTelemetry und verbinden Sie den Plattformzustand mit Ihren Anwendungen.
Warum OpenShift mit Obseria überwachen
Gemacht für OpenShift
Behalten Sie Projekte, Cluster Resource Quotas, Routes und Operators im Blick, nicht nur generische Kubernetes-Objekte.
Ihr Prometheus-Stack bleibt
Leiten Sie Metriken des integrierten OpenShift-Monitorings per Prometheus Remote Write weiter und fragen Sie sie in Obseria mit PromQL ab.
Plattform und App in einer Sicht
Traces und Logs der Workloads werden mit Cluster-, Projekt- und Pod-Metadaten angereichert, sodass Plattform- und Anwendungsteams dasselbe Bild sehen.
OpenShift-Komponenten, die Obseria überwacht
- Control Plane. Latenz und Fehler des API-Servers, etcd-Zustand sowie Signale von Scheduler und Controller Manager.
- Nodes und Machine Pools. CPU, Speicher, Disk und Node Conditions für Control-Plane-, Infrastruktur- und Worker-Nodes.
- Projekte und Quotas. Ressourcennutzung pro Projekt im Verhältnis zu ResourceQuotas und ClusterResourceQuotas.
- Workloads und Pods. Deployments, StatefulSets, DaemonSets und Pods mit Phase, Restarts und Ressourcennutzung.
- Routes und Ingress. Request-Raten, Response-Codes und Backend-Zustand aus dem OpenShift-Router.
- Anwendungen. Traces, Metriken und Logs von Java-, .NET-, Node.js- und Python-Workloads über OpenTelemetry.
Die OpenShift-Kennzahlen, auf die es ankommt
Obseria erfasst diese Werte automatisch und zeigt sie in fertigen Dashboards und Alerts.Verfügbarkeit der Anwendungen
Zeigt, ob alle Teile Ihrer Anwendungen laufen, für Nutzer bereitstehen und nicht ständig neu starten.
Zustand des Clusters
Zeigt, ob die Maschinen hinter Ihrer Plattform gesund sind und wie viel Rechenleistung sie gerade verbrauchen.
Kapazität und Budgets
Behält im Blick, wie viel der reservierten Kapazität und des Speichers jedes Team nutzt, als Basis für faire Planung.
Tempo und Fehler
Zeigt, wie schnell die Plattform und Ihre veröffentlichten Apps reagieren und wie oft Anfragen von Nutzern scheitern.
Alle 9 Metriken im Detail anzeigen
| Metrik | Einheit | Aussage |
|---|---|---|
k8s.pod.phase | {phase} | Aktuelle Pod-Phase; Pods, die in Pending oder Failed hängen, brauchen Aufmerksamkeit. |
k8s.container.restarts | {restart} | Container-Restarts, das erste Anzeichen für Crash Loops und OOM Kills. |
k8s.node.condition_ready | {condition} | Ob ein Node Ready meldet; jeder andere Zustand kostet Kapazität. |
k8s.deployment.available | {pod} | Verfügbare Replicas pro Deployment im Vergleich zur Sollzahl. |
openshift.clusterquota.used | {resource} | Verbrauchte Ressourcen im Verhältnis zu einer ClusterResourceQuota über Projekte hinweg. |
k8s.pod.memory.working_set | By | Aktiv genutzter Speicher eines Pods; im Vergleich zu den Limits lassen sich OOM Kills vorhersehen. |
k8s.node.cpu.usage | {cpu} | Genutzte CPU-Kerne pro Node, die Basis der Kapazitätsplanung. |
apiserver_request_duration_seconds | s | Latenz-Histogramm der Requests an den Kubernetes-API-Server nach Verb und Ressource. |
haproxy_server_http_responses_total | {response} | HTTP-Antworten nach Code-Klasse pro Route-Backend aus dem OpenShift-Router. |
OpenShift-Monitoring in wenigen Minuten einrichten
- Schritt 1
Agent oder Collector ausrollen
Installieren Sie den Obseria Agent per Helm Chart oder den OpenTelemetry Collector als DaemonSet plus eine Instanz auf Cluster-Ebene, jeweils mit den nötigen Security Context Constraints.
- Schritt 2
Plattformmetriken weiterleiten
Ergänzen Sie optional ein Remote-Write-Ziel in der Cluster-Monitoring-Konfiguration von OpenShift, um vorhandene Prometheus-Metriken an Obseria zu senden.
- Schritt 3
Anwendungen instrumentieren
Setzen Sie OTEL_SERVICE_NAME und OTEL_EXPORTER_OTLP_ENDPOINT in Ihren Workloads oder nutzen Sie die OpenTelemetry-Auto-Instrumentierung für Traces.
# k8s_cluster läuft einmal pro Cluster, kubeletstats auf jedem 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]Sofort einsatzbereit
Dashboards, Alerts und SLOs, die bereitstehen, sobald die ersten Daten ankommen.
- OpenShift-Clusterübersicht nach Node-Rolle
- Ressourcennutzung pro Projekt gegenüber Quotas
- Alerts für Pod-Restarts und Crash Loops
- Router-Traffic und 5xx-Rate pro Route
- API-Server-Latenz und etcd-Zustand
OpenShift-Monitoring: Darauf kommt es an
Warum OpenShift Monitoring wichtig ist
Red Hat OpenShift ergänzt Kubernetes um vieles: Projekte mit Quotas, Routes über einen HAProxy-basierten Router, Operators, die die Plattform selbst verwalten, Security Context Constraints und einen integrierten Monitoring-Stack auf Basis von Prometheus. Das macht OpenShift Monitoring zugleich einfacher und schwieriger. Einfacher, weil viele Metriken bereits bereitstehen. Schwieriger, weil die Plattform mehr bewegliche Teile hat und das Team, das den Cluster betreibt, oft nicht das Team ist, das die Anwendungen betreibt.
OpenShift Observability bringt beide Perspektiven zusammen. Plattformteams müssen Node-Druck, Zustand der Control Plane und Quota-Nutzung über viele Projekte hinweg sehen. Anwendungsteams wollen wissen, warum ihr Service langsam ist und ob die Ursache im eigenen Code, in einer Abhängigkeit oder in der Plattform darunter liegt.
Die OpenShift-Signale, auf die es ankommt
Strukturieren Sie Ihr OpenShift Cluster Monitoring in Schichten:
- Control Plane:
apiserver_request_duration_secondsund API-Fehlerraten, Leader-Wechsel in etcd und Disk-Sync-Latenz. Ein langsamer API-Server verzögert Deployments, Skalierung und Operators. - Nodes: Node Conditions wie
k8s.node.condition_ready, CPU- und Speichernutzung sowie Disk Pressure. Trennen Sie Control-Plane-, Infrastruktur- und Worker-Nodes, denn ihre Ausfälle wirken sich unterschiedlich aus. - Projekte und Quotas:
openshift.clusterquota.usedim Verhältnis zu den Limits sowie die ResourceQuota-Nutzung pro Projekt. Erschöpfte Quotas blockieren neue Pods, ohne dass die Anwendung einen offensichtlichen Fehler zeigt. - Workloads:
k8s.pod.phase,k8s.container.restarts,k8s.deployment.availableundk8s.pod.memory.working_setim Vergleich zu den Limits. - Routes: Request-Raten und Response-Codes aus dem Router, etwa
haproxy_server_http_responses_total, liefern die Rate- und Fehlersignale am Edge.
Typische OpenShift-Probleme und wie Sie sie erkennen
Pods hängen in Pending. Meist liegt es an einer Quota, einem fehlenden Node Selector oder zu wenig schedulbarer Kapazität. Pod-Phase, Quota-Nutzung und Scheduler-Events zusammen zeigen, woran genau.
Crash Loops und OOM Kills. Steigende k8s.container.restarts bei Speicher nahe dem Limit deuten auf zu knappe Limits oder ein Speicherleck hin. Continuous Profiling und Traces des Workloads helfen bei der Entscheidung.
Abgelehnte Security Context Constraints. Ein Workload, der Rechte benötigt, die er nicht hat, startet nicht. Kubernetes-Events und Pod-Status zeigen die Ablehnung, und Obseria stellt sie neben das Deployment, das sie ausgelöst hat.
Router-Fehler. 503-Antworten auf einer Route bedeuten oft, dass hinter dem Service keine bereiten Endpunkte stehen. Router-Response-Codes kombiniert mit der Deployment-Verfügbarkeit machen den Zusammenhang in einer Ansicht sichtbar.
Upgrades und Operator-Probleme. Cluster-Upgrades und Operator-Rollouts ändern viele Komponenten gleichzeitig. Erfassen Sie sie als Events auf derselben Zeitachse wie die Metriken, um Regressionen schneller zu finden.
Best Practices für OpenShift Monitoring
- Behalten Sie das integrierte OpenShift-Monitoring für die Plattform und leiten Sie dessen Metriken weiter, statt alles doppelt zu scrapen.
- Labeln Sie Workloads einheitlich mit Service, Team und Version, damit sich Telemetrie nach Verantwortlichen gruppieren lässt.
- Alarmieren Sie auf nutzerrelevante Symptome pro Route und Service und nutzen Sie Node- und Pod-Metriken zur Diagnose.
- Überwachen Sie Quotas proaktiv, denn erschöpfte Quotas fallen Anwendungsteams oft erst spät auf.
- Nutzen Sie OpenTelemetry für Application Traces, damit Sie das Backend wechseln können, ohne neu zu instrumentieren.
So überwacht Obseria OpenShift
Obseria erfasst OpenShift-Telemetrie mit dem Obseria Agent oder dem OpenTelemetry Collector, einschließlich der OpenShift-spezifischen Cluster-Quota-Metriken des Kubernetes Cluster Receivers. Vorhandene Prometheus-Metriken lassen sich per Remote Write senden und mit PromQL abfragen. Traces, Metriken und Logs der Anwendungen kommen per OTLP an und werden mit Projekt-, Pod- und Node-Metadaten angereichert. Obseria TopoGraph bildet Routes, Services, Pods und Nodes automatisch ab, und Obseria Intelligence korreliert Plattform- und Anwendungssignale, um Ursachen zu finden. Dashboards, Alerts und SLOs sind enthalten, und Obseria Pipeline filtert verrauschte Container-Logs vor der Speicherung.
In Multi-Cluster-Umgebungen sendet jeder Cluster seine Telemetrie mit einem Attribut für den Cluster-Namen. So vergleichen Sie Cluster, verfolgen Upgrades über die gesamte Flotte und führen plattformweite SLOs an einem Ort. Die Daten können in der EU-Region oder in Ihrem eigenen Cloud-Konto bleiben.
Verwandte Integrationen
Passende Funktionen
Kubernetes Monitoring
Sehen Sie jeden Cluster, Node, Pod und Workload im Kontext. Obseria verknüpft Metriken, Events, Logs und Traces, damit Sie die Ursache eines fehlerhaften Rollouts in Minuten finden.
Mehr erfahrenDistributed Tracing
Verfolgen Sie jeden Request über Services, Queues und Datenbanken hinweg und finden Sie den langsamen Span oder die fehlerhafte Abhängigkeit in Sekunden.
Mehr erfahrenAnomalie-Erkennung
Obseria Intelligence lernt den normalen Rhythmus jedes Service, meldet echte Abweichungen statt Schwellenwert-Rauschen und fasst zusammenhängende Anomalien zu einem Problem mit wahrscheinlicher Ursache zusammen.
Mehr erfahrenMehr erfahren
Was ist Observability?
Was ist Observability? Wie Metriken, Logs, Traces und Profile Ihre Systeme verständlich machen und was Observability vom Monitoring unterscheidet.
Die vier Golden Signals: Latenz, Traffic, Fehler und Sättigung
Die vier Golden Signals erklärt: Latenz, Traffic, Fehler und Sättigung, der Bezug zu RED- und USE-Methode und die Messung mit OpenTelemetry.
Häufige Fragen zum OpenShift-Monitoring
Ja. Viele Teams behalten den integrierten Monitoring-Stack und ergänzen ein Remote-Write-Ziel, sodass die Metriken zusätzlich in Obseria verfügbar sind, zusammen mit Traces und Logs.
Agent oder Collector benötigen ein Service-Konto mit Lesezugriff auf Cluster-Objekte und den Kubelet-Stats-Endpunkt. Für die Erfassung auf Node-Ebene ist eine Security Context Constraint mit Host-Zugriff erforderlich.
Ja. Cluster Resource Quotas, Projekte und Routes werden neben Standard-Kubernetes-Objekten wie Deployments, Pods und Nodes abgedeckt.
Ja. Nutzen Sie OpenTelemetry SDKs oder Auto-Instrumentierung in Ihren Workloads und senden Sie Traces per OTLP. Die Traces werden mit den Pods und Nodes verknüpft, auf denen sie liefen.
Obseria erfasst Daten über den Agent, den OpenTelemetry Collector und Prometheus Remote Write. All das läuft auf selbst betriebenen und gemanagten OpenShift-Clustern, auf denen Sie Workloads ausrollen können.
Starten Sie heute mit dem OpenShift-Monitoring
Binden Sie OpenShift in Minuten per OpenTelemetry oder Obseria Agent an. 14 Tage kostenlos.