OpenStack: Monitoring vs. Observability

Das Dashboard eines OpenStack-Betreibers sagt, alles sei in Ordnung. nova-api läuft, neutron läuft, die RabbitMQ-Queues sind flach, Galera hat Quorum, jeder Compute-Node meldet sich. Und ein Tenant sagt Ihnen, dass das Starten einer Instanz vier Minuten dauert, wo es früher vierzig Sekunden waren.

Diese Lücke ist die ganze Unterscheidung zwischen Monitoring und Observability auf OpenStack. Monitoring sagt Ihnen, dass die Dienste laufen. Es kann Ihnen nicht sagen, wohin vier Minuten verschwunden sind, denn ein einzelner Instanz-Start durchquert sechs Dienste, zwei Message Queues und eine Datenbank — und kein Health-Check pro Dienst sieht den Request als eine Sache.

Was OpenStack-Monitoring gut abdeckt

Konventionelles Monitoring auf OpenStack ist ausgereift und behaltenswert. Es beantwortet Komponentenfragen:

• Liveness der Control Plane. API-Endpunkte antworten, Worker registriert, Scheduler läuft.
• Infrastruktur-Health. CPU, Arbeitsspeicher und Disk der Compute-Nodes; Zustand der Ceph-OSDs; Galera-Clustergrösse und Replikationsverzögerung; RabbitMQ-Queue-Tiefe und Consumer-Zahlen.
• Kapazität. Die Sicht von Placement auf zugeteilte gegenüber verfügbaren Ressourcen pro Cell — was tatsächlich bestimmt, ob eine Scheduling-Anfrage erfolgreich sein kann.

Diese Schicht bedienen Exporter gut: der Community-openstack-exporter für Dienst- und Ressourcenzustand, Cephs Manager-Modul, RabbitMQs eigenes Prometheus-Plugin, dazu hostmetrics auf jedem Node. Der prometheus-Receiver eines OpenTelemetry Collectors scrapet sie alle in eine Pipeline — eine echte Vereinfachung gegenüber vier getrennten Scrape-Konfigurationen.

Was nichts davon leistet: einen langsamen Request erklären.

Warum Fragen auf Request-Ebene hier schwierig sind

Ein Instanz-Start ist eine verteilte Transaktion in der Form, die OpenStack schon immer hatte:

nova-api → placement (Kandidaten-Hosts) → nova-scheduler → nova-conductor → nova-compute → neutron (Port-Binding) → cinder (Volume-Attach) → glance (Image-Abruf)

Jeder Hop ist ein eigener Prozess, oft auf einem eigenen Host, und kommuniziert über oslo.messaging auf RabbitMQ. Die vier Minuten könnten der Image-Download sein, ein langsames Cinder-Backend, ein Neutron-Agent, der das Port-Binding wiederholt, oder Scheduler-Retries gegen einen Host, der den Claim immer wieder ablehnt. Jeder dieser Dienste kann einzeln „gesund” sein, während die Transaktion kriecht.

Monitoring gibt Ihnen sechs grüne Lämpchen. Observability gibt Ihnen den Zeitstrahl.

Die Korrelations-ID, die OpenStack bereits hat

Das Nützliche — und der Teil, den die meisten OpenStack-Betreiber zu wenig nutzen — ist, dass OpenStack Requests bereits mit einer Korrelations-Kennung stempelt. Jeder API-Aufruf trägt eine X-Openstack-Request-Id, und oslo.log schreibt eine Request-ID in die Log-Zeilen, während sie die Dienste durchlaufen.

Das ist kein Trace, verhält sich aber für die Rekonstruktion eines Requests wie einer. Wenn Sie die Request-ID zur Erfassungszeit aus der Log-Zeile in ein strukturiertes Attribut parsen, können Sie jeden Log-Datensatz jedes Dienstes auswählen, der zu einem einzelnen Start gehört — der Reihe nach, ohne Anwendungscode anzufassen.

Praktisch heisst das: eine filelog- oder journald-Quelle pro Dienst mit einem Parse-Schritt, der Request-ID, Severity und Dienstnamen in Attribute hebt — dasselbe Onboarding-Problem wie in unordentliche Logs parsen. Es ist der günstigste Schritt von „wir haben Logs” zu „wir können einem Request folgen”, und er verlangt keine Änderung an OpenStack.

Wo echtes Tracing steht — ehrlich

Zwei Dinge, bei denen man klar sein sollte:

• OpenStack-Dienste sind nicht ab Werk OpenTelemetry-instrumentiert. Es gibt kein Flag, das Nova in einen OTLP-Trace-Produzenten verwandelt. OSProfiler existiert und erzeugt durchaus Request-Traces für OpenStack, ist aber ein eigenes Subsystem mit eigenen Backends, wird wegen des Overheads typischerweise selektiv aktiviert und ist keine OTLP-Pipeline, die Sie auf ein beliebiges Backend richten können.
• Die realistische Leiter lautet also Metriken → korrelierte Logs → selektives Tracing. Die meisten Betreiber holen den Grossteil des Nutzens auf Sprosse zwei. Vollständiges Distributed Tracing über die Control Plane ist ein Projekt, keine Konfigurationsänderung — und es lohnt sich, das ehrlich zu bemessen, statt es in einem Designdokument zu versprechen.

Wo OpenTelemetry sofort hilft, ist als Erfassungs- und Routing-Schicht: ein Agent pro Node, der Host-Metriken erfasst, die Exporter scrapet, die oslo-Logs tailt, Request-IDs parst und alles dorthin schickt, wo Sie es aufbewahren — statt vier Agents, von denen jeder einem anderen Subsystem gehört.

Was zuerst instrumentieren

Wenn Sie von Monitoring in Richtung Observability auf OpenStack gehen, zahlt sich diese Reihenfolge am schnellsten aus:

1. Ein Collector pro Node, der hostmetrics und die Prometheus-Scrapes macht, die Sie ohnehin haben. Betrieblich ändert das nichts und konsolidiert den Agent-Bestand.
2. Die Dienst-Logs mit Request-ID-Parsing ergänzen. Das ist der Schritt, der aus „grüne Dashboards, verärgerter Tenant” eine beantwortbare Frage macht.
3. RabbitMQ- und Galera-Detail ergänzen. Queue-Tiefe pro Queue und Replikationsverzögerung sind die zwei Signale, die Langsamkeit der Control Plane am häufigsten erklären.
4. Den Startpfad Ende zu Ende messen, als synthetischen Test: eine Instanz nach Zeitplan starten und festhalten, wie lange jede Phase dauerte. Eine synthetische Transaktion ist ein schlechter Ersatz für Tracing und ein ausgezeichneter Ersatz für nichts.
5. Dann OSProfiler erwägen für die konkreten Abläufe, die Sie weiterhin nicht erklären können.

Der Haken bei der Mandantenfähigkeit

OpenStack ist konstruktionsbedingt mandantenfähig, und die Observability-Schicht erbt das. Die Projekt-(Tenant-)Identität gehört als Resource-Attribut an die Telemetrie — und sobald sie dort ist, gelten dieselben Routing- und Quota-Fragen wie für jede geteilte Pipeline: Wessen Daten gehen wohin, wer darf sie sehen, und wie hindert man ein lautes Projekt daran, das Erfassungsbudget aller zu verbrauchen. Das ist das Thema von Multi-Tenant-Collector-Architektur, und auf OpenStack ist es nicht optional.

Die ehrliche Zusammenfassung

OpenStack zu monitoren ist ein gelöstes Problem mit guten Exportern. Observability auf OpenStack ist ein teilweise gelöstes Problem: Sie bekommen korrelierte, abfragbare, auf den Request bezogene Nachweise, ohne die Dienste zu instrumentieren — und echte Traces nur mit mehr Aufwand, als die meisten Deployments aufwenden werden.

Die Schicht, die beides erschwinglich macht, ist dieselbe: eine Erfassungsebene, die Sie kontrollieren, die Exporter und Logs konsolidiert, genug Struktur parst, um die Daten beantwortbar zu machen, und sie an Backends routet, die Sie gewählt haben — das Telemetrie-Pipeline-Argument, angewandt auf eine Private Cloud. Ist auch Proxmox im Bestand, stellt OpenStack vs. Proxmox: Observability im Vergleich die beiden nebeneinander.