← Zurück zur Kategorie
GeoDienst liefert HTTP 503 Service Unavailable
HTTP 503 bedeutet in der Regel, dass der GeoDienst oder eine vorgeschaltete Komponente vorübergehend nicht verfügbar ist. Prüfe zuerst den betroffenen Endpunkt, dann Upstream, Proxy/Ingress, Logs und letzte Änderungen; nach der Behebung den Status erneut validieren.
Ein GeoDienst-Endpunkt antwortet mit HTTP 503 Service Unavailable und wird vom Monitoring als nicht erreichbar oder down markiert. Das betrifft typischerweise den Dienst selbst, einen Upstream oder eine vorgelagerte Komponente wie Proxy, Ingress oder Load Balancer.
- HTTP 503 Service Unavailable beim Aufruf des GeoDienst-Endpunkts
- Monitoring markiert den Dienst als Down
- Der Request bricht mit 'Request failed with status code 503' ab
- Der Fehler tritt in Staging oder Produktion auf
- Der Endpunkt antwortet nicht stabil oder nur sporadisch
- Upstream-Dienst ist nicht verfügbar oder nicht gesund (inferred): HTTP 503 ist häufig ein Hinweis darauf, dass der eigentliche Backend-Dienst die Anfrage nicht annehmen kann oder nicht erreichbar ist.
- Proxy, Ingress oder Load Balancer findet kein gesundes Backend (inferred): Wenn die vorgelagerte Schicht keinen gesunden Zielknoten hat, wird häufig 503 zurückgegeben, obwohl der Endpunkt aus Sicht des Clients erreichbar ist.
- Deployment, Rollout oder Konfigurationsänderung hat den Dienst instabil gemacht (inferred): Nach Änderungen können Crash-Loops, Fehlkonfigurationen oder nicht passende Health-Checks dazu führen, dass der Dienst als nicht bereit gilt.
- Ressourcenengpass oder Überlast (inferred): Zu wenig CPU, RAM, Worker, Verbindungen oder Kapazität kann dazu führen, dass der Dienst Anfragen nicht mehr sauber beantwortet.
- Betroffenen Endpunkt und Fehlerbild verifizieren — Prüfe den betroffenen GeoDienst-Endpunkt direkt und bestätige den genauen HTTP-Status sowie den Zeitpunkt des Fehlers. So lässt sich eingrenzen, ob das Problem reproduzierbar ist oder nur vom Monitoring gemeldet wird. Checks: Endpunkt mit einem einfachen HTTP-Check aufrufen und Statuscode prüfen; Zeitpunkt, Umgebung und betroffenen Pfad notieren; Wenn verfügbar: denselben Check über Monitoring-Route und direkt gegen den Dienst vergleichen
- Gesundheit von Dienst und Abhängigkeiten prüfen — Unterscheide zwischen Anwendung, vorgelagerter Infrastruktur und Upstream. Prüfe Health-Checks, Readiness/Liveness-Status, Restart-Zähler und den Zustand des Backends. Checks: Health-Check des Dienstes auswerten; Status von Applikation, Container/Prozess und Restart-Verhalten prüfen; Proxy-, Ingress- oder Load-Balancer-Status auf ein gesundes Backend kontrollieren; Abhängige Upstream-Komponenten auf Erreichbarkeit und Reaktionszeit prüfen
- Logs zum Fehlerzeitpunkt auswerten — Suche in Anwendungs-, Proxy- und Infrastruktur-Logs nach Ursachen wie Crash-Loops, Timeouts, Verbindungsfehlern, Konfigurationsfehlern oder Ressourcenproblemen. Checks: Logs rund um den exakten Fehlerzeitpunkt prüfen; Nach Statusänderungen, Restart-Schleifen, Timeout-Meldungen und Connection-Fehlern suchen; Falls vorhanden, Metriken für CPU, RAM, Verbindungen und Antwortzeiten prüfen
- Letzte Änderung als Ursache ausschließen oder bestätigen — Wenn der Fehler nach Deployment, Update oder Konfigurationsänderung auftrat, prüfe die Änderungskette. Ein kontrollierter Rollback ist oft der schnellste Weg, um eine Regression zu beseitigen. Checks: Letzte Deployments, Konfigurationsänderungen oder Infrastruktur-Änderungen prüfen; Bei offensichtlicher Regression auf den letzten funktionierenden Stand zurückgehen; Nach dem Rollback oder Neustart den Dienstzustand erneut prüfen
- Dienst stabilisieren und bei Bedarf skalieren — Wenn der Dienst nur wegen Überlast oder temporärer Instabilität 503 liefert, stelle die Erreichbarkeit durch kontrollierten Neustart, Neu-Deploy oder Skalierung wieder her. Checks: Kontrollierten Neustart oder Redeploy des betroffenen Dienstes durchführen; Ressourcenlimits, Worker-Limits und Kapazität prüfen; Bei Überlast die Bereitstellung oder Skalierung anpassen
- Der betroffene Endpunkt liefert wieder den erwarteten Erfolgsstatus statt 503.
- Das Monitoring zeigt den Dienst wieder als erreichbar bzw. Up.
- Health-Checks und Backend-Status bleiben über einen kurzen Beobachtungszeitraum stabil.
- In den Logs treten keine neuen 503-bezogenen Fehler oder Restart-Schleifen auf.
- Wenn der 503-Fehler trotz gesundem Monitoring und ohne klaren Befund bleibt, an das zuständige Betriebs- oder Plattformteam eskalieren.
- Bei wiederkehrenden Ausfällen mit gleichem Muster sollten Zeitstempel, betroffener Endpunkt, Health-Check-Ergebnis und relevante Logs mitgegeben werden.
- Wenn mehrere abhängige Komponenten gleichzeitig betroffen sind, ist eine breitere Infrastruktur- oder Incident-Bewertung sinnvoll.
- Ohne dokumentierte Root Cause bleibt die Ursache als wahrscheinlich, nicht als gesichert.
- Die Anleitung beschreibt Triage und Wiederherstellung, aber keine produktspezifische Code-Änderung.
- Je nach Architektur können App, Ingress, Load Balancer und Upstream anders benannt oder geschichtet sein.
- Wenn keine Log- oder Metrikzugriffe vorliegen, ist eine exakte Ursachenbestimmung oft nur eingeschränkt möglich.
Fragen & Antworten
Was soll ich als Erstes prüfen, wenn der GeoDienst HTTP 503 liefert?
Prüfe zuerst, ob der 503-Fehler reproduzierbar ist und welcher Endpunkt betroffen ist. Danach grenzt du ein, ob die Ursache im Dienst selbst, in einer vorgelagerten Komponente oder im Upstream liegt.
- Rufe den betroffenen GeoDienst-Endpunkt direkt auf und bestätige den HTTP-Status sowie den exakten Zeitpunkt des Fehlers.
- Vergleiche, ob der Fehler nur im Monitoring oder auch bei einem direkten Aufruf auftritt.
- Prüfe anschließend den Zustand von Dienst, Upstream und vorgelagerter Schicht wie Proxy, Ingress oder Load Balancer.
- Suche in den Logs rund um den Fehlerzeitpunkt nach Hinweisen auf Timeouts, Neustarts, Verbindungsfehler oder Konfigurationsprobleme.
Der Endpunkt liefert wieder den erwarteten Erfolgsstatus statt 503. Das Monitoring zeigt den Dienst als erreichbar, und die Health-Checks bleiben über einen kurzen Zeitraum stabil.
Wenn der 503-Fehler trotz unauffälligem Monitoring und ohne klaren Befund bestehen bleibt, an das zuständige Betriebs- oder Plattformteam eskalieren. Für die Analyse sind Zeitstempel, betroffener Pfad und relevante Logauszüge wichtig.
Woran erkenne ich, ob der 503-Fehler vom GeoDienst selbst oder von Proxy, Ingress oder Load Balancer kommt?
Ein 503 entsteht häufig dort, wo keine gesunde Zielinstanz verfügbar ist. Deshalb prüfst du zuerst, ob die Anwendung selbst gesund ist oder ob die vorgelagerte Komponente kein brauchbares Backend findet.
- Prüfe den direkten Dienstzustand über Health-Checks, Readiness/Liveness-Informationen und mögliche Restart-Zähler.
- Kontrolliere, ob Proxy, Ingress oder Load Balancer überhaupt ein gesundes Backend sehen und ansteuern.
- Vergleiche die Antwort direkt gegen den Dienst mit der Antwort über die vorgelagerte Komponente.
- Suche in den jeweiligen Logs nach Hinweisen, ob der Fehler schon vor dem Dienst oder erst in der Anwendung entsteht.
Wenn der direkte Dienstaufruf funktioniert, der Zugriff über die vorgelagerte Schicht aber 503 liefert, liegt die Ursache sehr wahrscheinlich in Proxy, Ingress, Load Balancer oder Routing. Wenn schon der direkte Aufruf fehlschlägt, ist der Dienst oder sein Upstream wahrscheinlicher.
Ohne Zugang zu Health-Checks, Logs oder Infrastrukturstatus bleibt die Zuordnung nur eine wahrscheinlichkeitsbasierte Eingrenzung. Bei unklarer Schichtzuordnung an Betrieb oder Plattform eskalieren.
Was prüfe ich, wenn Monitoring den GeoDienst als down markiert, der Dienst aber scheinbar läuft?
Wenn Monitoring „down“ meldet, obwohl der Dienst läuft, ist oft nicht der Prozess selbst das Problem, sondern die Erreichbarkeit, Readiness oder das Backend hinter einer vorgelagerten Schicht.
- Vergleiche die Monitoring-Meldung mit einem direkten Aufruf des Endpunkts.
- Prüfe, ob der Dienst zwar läuft, aber nicht als bereit gilt oder instabile Health-Checks liefert.
- Kontrolliere, ob Proxy, Ingress oder Load Balancer ein gesundes Backend sehen und Requests weiterleiten können.
- Schau in Logs und Metriken nach kurzen Ausfällen, Restart-Schleifen, Zeitüberschreitungen oder Ressourcenengpässen.
Das Monitoring wechselt nach der Behebung wieder auf „up“, und die Health-Checks bleiben über einen Beobachtungszeitraum stabil. Der Endpunkt antwortet reproduzierbar mit dem erwarteten Status.
Wenn die Monitoring-Sicht und der direkte Dienstaufruf widersprüchlich bleiben, sollten die betroffenen Messpunkte gemeinsam mit Zeitstempel und Logs an das Betriebs- oder Plattformteam weitergegeben werden.
Wie gehe ich vor, wenn der 503-Fehler nach einem Deployment oder einer Konfigurationsänderung auftrat?
Nach Deployments oder Konfigurationsänderungen ist eine Regression besonders wahrscheinlich. Prüfe zuerst die Änderungskette und stelle bei Bedarf den letzten funktionierenden Zustand wieder her.
- Ermittle, ob der 503-Fehler zeitlich nach einem Deployment, Update oder einer Infrastrukturänderung begann.
- Prüfe, ob der Dienst danach instabil wurde, zum Beispiel durch Neustarts, Crash-Loops oder fehlerhafte Health-Checks.
- Vergleiche die aktuelle Konfiguration mit dem zuletzt bekannten funktionierenden Stand.
- Wenn ein klarer Zusammenhang besteht, führe einen kontrollierten Rollback oder Neustart durch und beobachte das Ergebnis.
Nach dem Rollback oder der Korrektur liefert der Endpunkt wieder den erwarteten Erfolgsstatus. Die Logs zeigen keine neuen Fehlerketten, und der Dienst bleibt stabil bereit.
Wenn die Änderungskette nicht eindeutig ist oder ein Rollback den Fehler nicht beseitigt, an das zuständige Betriebs- oder Plattformteam eskalieren. Dann sollten Zeitpunkt der Änderung, betroffener Endpunkt und relevante Logauszüge mitgegeben werden.
Welche Logs und Metriken helfen mir bei einem HTTP-503-Problem am meisten?
Am hilfreichsten sind Logs und Metriken rund um den Fehlerzeitpunkt aus Anwendung, vorgelagerter Schicht und Infrastruktur. Sie zeigen meist, ob Timeouts, Restart-Schleifen, Verbindungsprobleme oder Überlast die Ursache sind.
- Prüfe Anwendungs-, Proxy- und Infrastruktur-Logs genau um den Zeitpunkt des ersten 503-Fehlers.
- Suche nach Restart-Schleifen, Timeouts, Verbindungsfehlern, Konfigurationsfehlern und auffälligen Statuswechseln.
- Ergänze die Loganalyse um Metriken wie CPU, RAM, Verbindungen, Antwortzeiten und Fehlerraten.
- Vergleiche die Beobachtungen mit dem Zustand von Health-Checks und Backend-Erreichbarkeit.
Du solltest eine klare zeitliche Korrelation zwischen Fehler, Logeintrag und Metrikabweichung erkennen. Nach der Behebung verschwinden die Fehlermuster, und die Metriken normalisieren sich.
Wenn keine Log- oder Metrikdaten verfügbar sind, ist die Ursachenanalyse deutlich eingeschränkt. In diesem Fall mit allen verfügbaren Zeitstempeln und Beobachtungen an Betrieb oder Plattform eskalieren.
Wie kann ich einen GeoDienst stabilisieren, wenn er wegen Überlast oder Instabilität 503 zurückgibt?
Wenn der 503-Fehler durch Überlast oder temporäre Instabilität ausgelöst wird, helfen kontrollierte Stabilisierungsschritte wie Neustart, Redeploy oder Skalierung. Ziel ist, wieder genügend Kapazität und einen gesunden Dienstzustand herzustellen.
- Prüfe, ob Ressourcenengpässe vorliegen, zum Beispiel bei CPU, RAM, Verbindungen oder Worker-Kapazität.
- Führe, wenn passend, einen kontrollierten Neustart oder ein Redeploy des betroffenen Dienstes durch.
- Beobachte, ob die Dienstinstanzen danach wieder stabil bereit sind und die Health-Checks bestehen.
- Passe bei anhaltender Last die Kapazität, Limits oder Bereitstellung so an, dass der Dienst die Anfragen verarbeiten kann.
Der Endpunkt antwortet wieder stabil, 503 tritt nicht mehr auf, und das Monitoring zeigt keine erneuten Ausfälle oder Restart-Schleifen. Die Last- und Ressourcenwerte bewegen sich wieder im normalen Bereich.
Wenn die Instabilität nach Neustart oder Skalierung sofort zurückkehrt, liegt vermutlich ein tieferes Problem in Abhängigkeiten, Konfiguration oder Infrastruktur vor. Dann an das Betriebs- oder Plattformteam eskalieren.
Welche Informationen sollte ich bei wiederkehrenden 503-Fehlern an das Betriebs- oder Plattformteam weitergeben?
Bei wiederkehrenden 503-Fehlern sind eine saubere Zeitlinie und der technische Kontext entscheidend. So kann das Team die Ursache schneller eingrenzen und Wiederholungen erkennen.
- Dokumentiere den betroffenen Endpunkt, die Umgebung und die genauen Zeitstempel der Fehler.
- Notiere, ob der Fehler direkt reproduzierbar ist oder nur sporadisch auftritt.
- Ergänze den Status von Health-Checks, Backend-Erreichbarkeit, Restart-Verhalten und den wichtigsten Loghinweisen.
- Füge bekannte Auslöser hinzu, zum Beispiel ein Deployment, eine Konfigurationsänderung oder eine Lastspitze.
Das zuständige Team kann anhand der Angaben die betroffene Schicht schneller identifizieren und die Ursache gezielt prüfen. Im Idealfall lässt sich das Muster mit Logs oder Metriken nachvollziehen.
Wenn mehrere abhängige Komponenten gleichzeitig betroffen sind oder kein klarer Auslöser erkennbar ist, ist eine breitere Infrastruktur- oder Incident-Bewertung sinnvoll.