Zustandsprüfungen für selbst gehostete Anwendungen: Was bedeutet „gesund“ eigentlich?
Ein praxisnaher Rahmen, um Zustandsprüfungen zu definieren, die echte Nutzerergebnisse abbilden, Start, Liveness und Bereitschaft unterscheiden und Abhängigkeiten berücksichtigen, ohne jeden externen Fehler in einen Anwendungsausfall zu verwandeln.
Warum eine erreichbare URL nicht zwangsläufig eine gesunde Anwendung bedeutet
Wenn ein Browser eine HTTPS-URL erreicht und HTTP 200 erhält, ist das ein nützlicher Hinweis, aber keine vollständige Definition von Gesundheit. Es kann belegen, dass eine Route, ein Proxy oder ein Anwendungshandler eine Anfrage beantwortet hat. Es beweist jedoch nicht unbedingt, dass Nutzer sich anmelden, aktuelle Daten lesen, Änderungen speichern, Dateien hochladen, Arbeit an eine Warteschlange senden oder eine erforderliche Integration nutzen können.
Der umgekehrte Fehler kommt ebenfalls häufig vor: Eine fehlgeschlagene Verbindung zu irgendeiner Abhängigkeit wird als Beweis betrachtet, dass die gesamte Anwendung nicht verfügbar ist. Eine vorübergehend nicht erreichbare optionale API kann eine Funktion beeinträchtigen, während Nutzer ihre wichtigsten Aufgaben weiterhin erledigen können. Ein sinnvolles Design für Zustandsprüfungen unterscheidet diese Fälle, statt jeden Zustand auf eine einzige grüne oder rote Anzeige zu reduzieren.
Docker macht diese Unterscheidung deutlich: Ein Container kann laufen, während ein darin befindlicher Webserver feststeckt und keine neuen Verbindungen verarbeiten kann. Kubernetes trennt ähnlich zwischen Probes, die feststellen sollen, ob eine Anwendung gestartet ist, ob sie neu gestartet werden sollte und ob sie Datenverkehr erhalten sollte. Diese Konzepte bieten ein solides Ausgangsvokabular, doch die passenden Prüfungen hängen weiterhin vom dokumentierten Verhalten jeder Anwendung und von Ihren eigenen getesteten Workflows ab.
- Eine URL-Prüfung kann externe Erreichbarkeit feststellen, aber nicht die vollständige Funktionsfähigkeit des Dienstes.
- Ein laufender Container oder Prozess ist ein operativer Hinweis, kein Beweis für Nutzerbereitschaft.
- Der Ausfall einer Abhängigkeit muss nach seiner Auswirkung auf reale Workflows eingestuft werden.
- Die beste Definition von „gesund“ ist konkret: Die vorgesehene Arbeit kann innerhalb der von Ihnen gewählten Überwachungsgrenzen abgeschlossen werden.
Stellen Sie drei unterschiedliche Fragen: Start, Liveness und Bereitschaft
Lassen Sie nicht eine einzelne Prüfung jede operative Frage beantworten. Kubernetes dokumentiert drei unterschiedliche Probe-Typen. Eine Start-Probe stellt fest, ob die Anwendung in einem Container gestartet ist; wenn sie konfiguriert ist, verhindert sie Liveness- und Bereitschaftsprüfungen, bis sie erfolgreich ist. Das ist wichtig für Anwendungen, die Zeit zur Initialisierung benötigen, bevor ihr Normalbetrieb beurteilt werden kann.
Ein Liveness-Signal beantwortet die Frage, ob die laufende Anwendung noch ausreichend Fortschritt macht, sodass ein Neustart angebracht sein könnte. Kubernetes beschreibt Liveness-Probes als Mittel zur Entscheidung, wann ein Container neu gestartet werden soll, und nennt einen Deadlock als Beispiel: Der Prozess existiert, kann aber keinen Fortschritt erzielen. Da eine fehlerhafte Liveness-Prüfung Container unter Last neu starten und zu kaskadierenden Ausfällen beitragen kann, sollte sie bewusst eng gefasst und konservativ sein.
Ein Bereitschaftssignal beantwortet die Frage, ob die Anwendung den Datenverkehr, den Sie ihr zuführen möchten, derzeit annehmen kann. Kubernetes weist darauf hin, dass Bereitschaft vorübergehende Fehler oder Überlastung abbilden kann und dass eine fehlgeschlagene Bereitschafts-Probe passende Services daran hindert, Datenverkehr an den betroffenen Pod zu senden. In einer selbst gehosteten Umgebung ohne Kubernetes unterscheiden sich die Mechanismen, die Entscheidung bleibt jedoch nützlich: Sollten Nutzer oder vorgeschaltete Systeme jetzt zu dieser Instanz geleitet werden?
- Start: Ist die Initialisierung ausreichend abgeschlossen, damit normale Prüfungen beginnen können?
- Liveness: Macht der Anwendungsprozess Fortschritt, oder ist ein Eingreifen wie ein Neustart gerechtfertigt?
- Bereitschaft: Kann diese Instanz jetzt sicher den vorgesehenen Datenverkehr annehmen?
- Nutzerorientierte Verfügbarkeit: Kann ein externer Nutzer eine repräsentative, erlaubte Aktion ausführen?
- Zustand von Abhängigkeiten: Antworten die für kritische Workflows erforderlichen Dienste wie erwartet?
Beginnen Sie mit Nutzerwegen, nicht mit Endpunkten
Die verlässlichste Methode, Zustandsprüfungen für selbst gehostete Anwendungen zu definieren, besteht darin, bei den Ergebnissen anzusetzen, die Nutzer benötigen, statt bei dem Endpunkt, der sich am einfachsten abfragen lässt. Listen Sie die für die jeweilige Instanz wichtigen Nutzerwege auf. Bei einer Publishing-Website können die öffentliche Auslieferung von Seiten und redaktionelle Aktualisierungen Vorrang haben. Bei einem CRM können Anmeldung, Datensatzsuche, Anlage von Datensätzen und ausgehende Kommunikation Priorität haben. Eine KI-Anwendung benötigt möglicherweise Anmeldung, Abruf- oder Modellanfragen, Dateieinspielung und Hintergrundverarbeitung.
Beschreiben Sie für jeden Nutzerweg den kleinsten sicheren Test, der seine Funktionsfähigkeit nachweist. Ein Test sollte unnötige Änderungen an Produktionsdaten, die Offenlegung von Zugangsdaten und unerwünschte externe Aktionen vermeiden. Wenn die Dokumentation der Anwendung keinen geeigneten Endpunkt, Befehl oder Testkonto-Workflow beschreibt, behandeln Sie dies als Ungewissheit, die durch Herstellerdokumentation und kontrollierte Tests geklärt werden muss – nicht als Erlaubnis anzunehmen, dass eine generische URL Bereitschaft beweist.
Nicht jeder Nutzerweg gehört in dieselbe Warnmeldung. Ein Fehler beim Erstellen von Datensätzen unterscheidet sich von einer nicht verfügbaren optionalen Analyseintegration. Es geht darum, diesen Unterschied sichtbar zu machen, bevor ein Vorfall die Verantwortlichen zwingt, ihn unter Druck zu treffen.
- Anmeldung: Kann ein autorisierter Nutzer über den vorgesehenen Identitätspfad eine Sitzung aufbauen?
- Datenlesen: Können Nutzer die benötigten Datensätze, Seiten oder Ergebnisse abrufen?
- Schreibvorgänge: Kann ein berechtigter Nutzer ein repräsentatives Element erstellen oder aktualisieren?
- Uploads und Speicher: Kann die Anwendung ein Testobjekt akzeptieren und abrufen, sofern dies kritisch ist?
- Hintergrundverarbeitung: Werden Aufgaben in Warteschlangen oder geplante Aufgaben abgeschlossen, wenn der Workflow davon abhängt?
- Integrationen: Kann eine erforderliche Interaktion mit Identitäts-, E-Mail-, Zahlungs-, KI- oder externen API-Diensten abgeschlossen werden?
Ordnen Sie die Komponenten hinter jedem kritischen Nutzerweg zu
Ein Nutzerweg scheitert über eine Kette, nicht über einen einzelnen Anwendungsprozess. Ordnen Sie die direkten Komponenten zu, die an jedem kritischen Workflow beteiligt sind: den Anwendungsprozess, die Datenbank, den Cache, persistenten Speicher, Warteschlange oder Worker, Identitätsdienst, E-Mail-Pfad und externe APIs. Googles SRE Workbook empfiehlt die Überwachung direkter Abhängigkeiten, da sie sich ändern oder Probleme haben können, auch wenn sich die Anwendung selbst nicht verändert hat.
Diese Zuordnung macht Prüfungen aussagekräftiger für die Diagnose. Wenn der öffentliche Zugriff fehlschlägt, aber die interne Betriebsprüfung der Anwendung erfolgreich ist, untersuchen Sie Routing, DNS, TLS oder den Pfad zwischen Nutzer und Anwendung. Wenn die Anwendung erreichbar ist, aber ein Schreibtest fehlschlägt, prüfen Sie Datenbank, Speicher, Berechtigungen, Kapazität oder den für diesen Schreibvorgang relevanten Warteschlangenpfad. Das Zustandssignal sollte den Verantwortlichen helfen, die nächste Frage einzugrenzen, statt nur zu verkünden, dass etwas nicht stimmt.
Berücksichtigen Sie auch Ressourcen mit festen oder praktischen Grenzen. Die SRE-Leitlinien von Google nennen RAM, Speicherplatz, CPU-Quote, Dateideskriptoren, Threads, Wartezeit in Warteschlangen und Logvolumen. Ressourcenüberwachung ersetzt keine Workflow-Prüfungen, kann aber einen bevorstehenden Ausfall aufdecken, bevor ein kritischer Nutzerweg bricht.
- Halten Sie für jeden Workflow die direkten Abhängigkeiten und die Wirkungsrichtung fest.
- Kennzeichnen Sie, ob jede Abhängigkeit intern ist, von einem anderen Team verwaltet wird oder extern ist.
- Dokumentieren Sie die relevanten Ressourcengrenzen und wie Verantwortliche sie prüfen können.
- Bestimmen Sie die kleinste Menge an Signalen, die zur Unterscheidung häufiger Fehlerpfade erforderlich ist.
Wählen Sie flache Liveness-Prüfungen und begrenzte Bereitschaftsprüfungen
Eine Liveness-Prüfung sollte üblicherweise feststellen, dass die Anwendung selbst antworten oder Fortschritt machen kann, ohne sie von jedem nachgelagerten Dienst abhängig zu machen. Ihr Zweck besteht nicht darin, jede Geschäftsfunktion zu zertifizieren, sondern zu vermeiden, dass eine tatsächlich festgefahrene Anwendung unbegrenzt weiterläuft. Wenn eine Anwendung einen dokumentierten Liveness-Endpunkt oder einen Health-Befehl bereitstellt, nutzen Sie die Dokumentation als Ausgangspunkt und testen Sie das tatsächliche Verhalten in Ihrer Umgebung.
Die Bereitschaft darf angemessen tiefgehender sein. Kubernetes dokumentiert ein Muster für Anwendungen mit strikten Backend-Abhängigkeiten: Liveness kann die Anwendung selbst abdecken, während Bereitschaft auch erforderliche Backend-Dienste prüft. So wird verhindert, dass Datenverkehr Instanzen erreicht, die nur Fehler zurückgeben können. Das Wort „erforderlich“ ist entscheidend. Nehmen Sie eine Abhängigkeit in die Bereitschaft auf, wenn ihr Ausfall verhindert, dass der vorgesehene Datenverkehr erfolgreich ist – nicht allein deshalb, weil sie existiert.
Halten Sie tiefgehende Prüfungen begrenzt. Eine Bereitschaftsprüfung, die eine aufwendige Abfrage ausführt, Produktionsdatensätze schreibt oder jede Drittanbieter-API aufruft, kann Last, störende Fehlalarme und mehrdeutige Ergebnisse erzeugen. Bevorzugen Sie eine begrenzte, repräsentative Überprüfung, die zum Zweck der Prüfung passt. Wenn die Anwendung keine dokumentierte Health-Schnittstelle bietet, verwenden Sie eine sorgfältig entworfene externe Workflow-Prüfung und dokumentieren Sie deren Einschränkungen.
- Verwenden Sie dokumentierte Health-Endpunkte oder Befehle der Anwendung erst, nachdem Sie ihre Semantik für die bereitgestellte Anwendung geprüft haben.
- Halten Sie Liveness auf Anwendungsfortschritt und sichere Neustartentscheidungen fokussiert.
- Fügen Sie eine Abhängigkeit nur dann zur Bereitschaft hinzu, wenn sie für den zugelassenen Datenverkehr erforderlich ist.
- Vermeiden Sie bei häufigen Prüfungen aufwendige, destruktive oder breit aufgefächerte Tests.
- Nutzen Sie mehrere fokussierte Signale statt eines überladenen Health-Endpunkts, wenn dies zu klareren Entscheidungen führt.
Definieren Sie eine Richtlinie für Abhängigkeiten, bevor Fehler auftreten
Entscheiden Sie für jede Abhängigkeit im Voraus über ihre operative Klasse. Eine blockierende Abhängigkeit bedeutet, dass Nutzer ohne sie keinen kritischen Workflow abschließen können. Eine beeinträchtigende Abhängigkeit bedeutet, dass eine Funktion eingeschränkt ist, die Anwendung ihren primären Dienst aber weiterhin bereitstellen kann. Eine nur warnende Abhängigkeit verdient Aufmerksamkeit, sollte jedoch für sich genommen den nutzerorientierten Verfügbarkeitsstatus der Anwendung nicht verändern.
Diese Richtlinie verhindert zwei schädliche Extreme. Eine reine Portüberwachung übersieht ein System, das Verbindungen annimmt, aber keine nützliche Arbeit ausführen kann. Umgekehrt kann eine Alles-oder-nichts-Bereitschaftsprüfung eine Anwendung als nicht verfügbar melden, sobald ein optionaler Dienst langsam oder vorübergehend nicht erreichbar ist. Beides führt zu schlechten Entscheidungen bei Vorfällen: Das erste erzeugt falsches Vertrauen, das zweite unnötige Ausfälle und Alarmmüdigkeit.
Die Richtlinie sollte nicht nur die Prüfung, sondern auch die Konsequenz festlegen. Wenn eine Abhängigkeit blockierend ist, entscheiden Sie, ob Datenverkehr zurückgehalten werden sollte, die betroffene Funktion klar als nicht verfügbar angezeigt werden soll oder eine Wiederherstellungsmaßnahme erforderlich ist. Wenn sie beeinträchtigend ist, definieren Sie, wie Nutzer und Verantwortliche den eingeschränkten Modus erkennen. Wenn sie nur warnend ist, bestimmen Sie, wer für die Nachverfolgung zuständig ist und warum sie den kritischen Workflow nicht blockiert.
- Blockierend: Ein Fehler verhindert einen benannten kritischen Workflow; dadurch kann die Instanz für den vorgesehenen Datenverkehr nicht bereit sein.
- Beeinträchtigend: Ein Fehler betrifft eine definierte Funktion; warnen Sie und kommunizieren Sie die Einschränkung, ohne die gesamte Anwendung als ausgefallen zu erklären.
- Nur Warnung: Ein Fehler erfordert Untersuchung, beeinträchtigt aber derzeit nicht das ausgewählte Dienstergebnis.
- Unbekannt: Das Verhalten der Abhängigkeit wurde nicht dokumentiert oder getestet; stufen Sie sie nicht stillschweigend als optional ein.
Trennen Sie öffentliche Prüfungen von internen Betriebsprüfungen
Externe und interne Prüfungen beantworten unterschiedliche Fragen. Google SRE beschreibt Black-Box-Monitoring als Prüfung von extern sichtbarem Verhalten, wie es ein Nutzer wahrnehmen würde, während White-Box-Monitoring Informationen nutzt, die aus dem Inneren des Systems bereitgestellt werden. Beide sind für selbst gehostete Anwendungen wertvoll.
Eine öffentliche Prüfung kann bestätigen, dass die vorgesehene Domain, Route, der TLS-Pfad und eine grundlegende Anwendungsantwort von außen verfügbar sind. Ein authentifizierter synthetischer Workflow kann einen sorgfältig ausgewählten Nutzerweg validieren, sofern Zugangsdaten, Testdaten und Nebenwirkungen sicher verwaltet werden. Interne Prüfungen können den Zustand des Containers, Anwendungsdiagnosen, Verbindungen zu Abhängigkeiten, Warteschlangentiefe oder Worker-Verhalten und Ressourcendruck sichtbar machen.
Stellen Sie operative Endpunkte nicht nur aus Bequemlichkeit öffentlich bereit. Entscheiden Sie, welche Diagnosen Authentifizierung oder privaten Netzwerkzugriff erfordern, und vermeiden Sie Geheimnisse in URLs, Logs oder einfachen Monitoring-Konfigurationen. Ihr Zugriffsmodell, Ihre Datenverarbeitung und Ihre Governance-Anforderungen bleiben in der Verantwortung der Anwendungsverantwortlichen, auch wenn der Infrastrukturbetrieb von einem anderen Anbieter verwaltet wird.
- Öffentlich: Ist der vorgesehene Einstiegspunkt für Nutzer erreichbar und verhält er sich wie erwartet?
- Authentifiziert extern: Kann ein kontrolliertes Konto einen kritischen, sicheren Workflow abschließen?
- Interne Anwendung: Meldet die Anwendung den erwarteten Betriebszustand?
- Abhängigkeiten und Ressourcen: Unterstützen erforderliche Dienste und begrenzte Ressourcen den Workflow?
- Sicherheitsprüfung: Sind Health-Endpunkte, Zugangsdaten, Logs und Testdaten angemessen geschützt?
Machen Sie aus Signalen einen Alarm- und Wiederherstellungsplan
Eine Prüfung ohne Reaktionsentscheidung ist nur eine Messung. Definieren Sie für jedes Signal eine verantwortliche Person, Prüffrequenz, Timeout, die Anzahl fehlgeschlagener Beobachtungen vor einer Alarmierung, den Alarmweg und die Eskalationsentscheidung. Docker-Health-Checks bieten Einstellungen für Intervall, Timeout, Initialisierungszeitraum und aufeinanderfolgende Fehler; diese Einstellungen verdeutlichen, warum eine einzelne fehlgeschlagene Beobachtung nicht automatisch dieselbe Bedeutung wie ein anhaltender Zustand haben sollte. Die passenden Werte sind anwendungsspezifisch und sollten anhand des beobachteten Verhaltens gewählt, nicht als universelle Schwellenwerte übernommen werden.
Machen Sie den Wiederherstellungsweg ebenso explizit. Halten Sie fest, was ein Verantwortlicher zuerst prüfen sollte, welche Maßnahmen sicher sind und welche Belege einen Neustart, eine Wiederherstellung, Konfigurationskorrektur oder ein Rollback rechtfertigen. Kubernetes warnt, dass falsch implementierte Liveness-Probes durch Neustarts unter Last kaskadierende Fehler verursachen können. Dasselbe Betriebsprinzip gilt außerhalb von Kubernetes: Automatisierte Wiederherstellung sollte eng begrenzt, verstanden und getestet sein, statt eine reflexartige Reaktion auf jede fehlgeschlagene Abhängigkeit zu sein.
Nützliche Diagnosen umfassen das extern beobachtete Ergebnis, soweit verfügbar den Zustandsstatus von Anwendung und Container, die jüngste Ausgabe der Zustandsprüfung, Antworten direkter Abhängigkeiten und relevante Ressourcenzustände. Docker dokumentiert, dass der konfigurierte Gesundheitsstatus über den Containerstatus sichtbar ist und die Diagnoseausgabe der Health-Checks zur Untersuchung abgefragt werden kann. Bewahren Sie genügend Kontext auf, damit die Rufbereitschaft handeln kann, ohne raten zu müssen.
- Verantwortung für das Signal: Wer ist für die Prüfungskonfiguration und ihr Runbook zuständig?
- Beobachtungsrichtlinie: Wie häufig läuft die Prüfung, wie lange darf sie dauern und wie viele Fehler ergeben einen aussagekräftigen Zustand?
- Alarmweg: Wer wird benachrichtigt, und bei welchen Bedingungen ist eine sofortige Eskalation erforderlich?
- Erste Prüfung: Welche Logs, Health-Ausgaben, Abhängigkeitsprüfungen und Ressourcenindikatoren sollten überprüft werden?
- Sichere Maßnahmen: Welche Neustart-, Konfigurations-, Wiederherstellungs- oder Rollback-Maßnahmen sind freigegeben?
- Eskalationsgrenze: Wann erfordert das Problem die Beteiligung eines Anwendungsverantwortlichen, Abhängigkeitsverantwortlichen oder Anbieters?
Häufige Fragen
Reicht eine HTTP-200-Antwort für die Zustandsprüfung einer selbst gehosteten Anwendung aus?
In der Regel nicht. Sie kann zeigen, dass eine erreichbare Route eine Antwort zurückgegeben hat, beweist aber möglicherweise nicht, dass Nutzer sich anmelden, auf aktuelle Daten zugreifen, Änderungen speichern, Speicher nutzen, Hintergrundarbeit abschließen oder erforderliche Integrationen erreichen können. Ergänzen Sie eine grundlegende externe Prüfung durch Prüfungen, die die kritischen Workflows dieser Anwendung abbilden.
Was ist der Unterschied zwischen Liveness und Bereitschaft?
Liveness fragt, ob eine laufende Anwendung Fortschritt macht oder möglicherweise neu gestartet werden muss. Bereitschaft fragt, ob sie jetzt den vorgesehenen Datenverkehr sicher annehmen kann. Kubernetes dokumentiert unterschiedliche Folgen: Eine fehlgeschlagene Bereitschaft verhindert, dass passende Services Datenverkehr senden, während eine fehlgeschlagene Liveness unter der konfigurierten Neustartrichtlinie zur Beendigung eines Containers führen kann.
Sollte eine Bereitschaftsprüfung fehlschlagen, wenn eine externe API nicht verfügbar ist?
Nur wenn diese API für den Datenverkehr oder Workflow erforderlich ist, den das Bereitschaftssignal abbildet. Wenn Nutzer ohne sie eine kritische Funktion nicht abschließen können, kann sie eine blockierende Abhängigkeit sein. Wenn sie eine optionale Funktion betrifft, stufen Sie sie stattdessen als beeinträchtigend oder nur warnend ein und definieren Sie die Erfahrung für Nutzer und Verantwortliche ausdrücklich.
Was sollte getestet werden, bevor man sich auf Zustandsprüfungen verlässt?
Testen Sie aussagekräftige Fehlerszenarien kontrolliert: einen gestoppten Anwendungsprozess, eine nicht verfügbare Datenbank, erschöpften Speicher, einen ausgefallenen Warteschlangen-Worker und eine nicht erreichbare externe Abhängigkeit. Bestätigen Sie für jedes Szenario das beobachtete Signal, das Verkehrsverhalten, den Alarmweg, die Diagnosen, die sichere Wiederherstellungsmaßnahme und die Kriterien für die Wiederherstellung.
Wie passt Airbip in die Überwachung selbst gehosteter Anwendungen?
Airbip verwaltet die Bereitstellung von Kataloganwendungen als Docker-Workloads auf seinen Cloud-Servern und bietet Infrastrukturfunktionen wie Routing- und TLS-Automatisierung, DNS-Prüfungen, Verwaltung des Service-Lebenszyklus sowie konfigurierbare tägliche, wöchentliche und monatliche Backups. Anwendungsverantwortliche müssen weiterhin kritische Workflows definieren, Entscheidungen zu Zugriff und Integrationen treffen, anwendungsspezifisches Health-Verhalten verstehen und Wiederherstellungsprioritäten festlegen.
Quellen und weiterführende Literatur
- Liveness, Readiness, and Startup Probes — Kubernetes
- Dockerfile reference: HEALTHCHECK — Docker
- Running containers: Healthchecks — Docker
- Monitoring Distributed Systems — Google SRE
- Monitoring — Google SRE Workbook
- Testing for Reliability — Google SRE