Container und Systemzustand
    Aktualisiert am Juni 2026
    Supervisor logo

    Supervisor Überwachung

    Überwachen Sie jeden von Supervisor verwalteten Prozess – Status (`RUNNING`/`FATAL`), Laufzeit, unerwartete Beendigungen, Neustartschleifen und Exit-Codes – in Echtzeit. Agent-basiert über `supervisorctl`, mit einer Benachrichtigung, sobald ein Prozess den Status `FATAL` annimmt.

    Kostenlose Testversion startenDokumente anzeigen

    Warum überwachen Sie Supervisor?

    Supervisor (`supervisord`) hält Ihre Hintergrundprozesse am Laufen – Celery- und Sidekiq-Worker, Gunicorn- und uWSGI-Anwendungsserver, Queue-Consumer und lang laufende Daemons. Nach `startretries` fehlgeschlagenen Neustartversuchen gibt es jedoch auf und versetzt den Prozess in den Status `FATAL`, wo er stillschweigend im nicht aktiven Zustand verbleibt. Die prozessspezifische Überwachung macht den Unterschied zwischen einer einzeiligen Warnmeldung und einer überfüllten Warteschlange, die stundenlang unbemerkt bleibt.

    Automatische Erkennung über Xitogent – alle Programme und Prozessgruppen unter `supervisord` werden automatisch erkannt
    Verfolgung des Zustands pro Prozess über die gesamte Zustandsmaschine hinweg (`RUNNING`, `STARTING`, `BACKOFF`, `EXITED`, `FATAL`, `STOPPED`, `UNKNOWN`)
    `FATAL`-Erkennung – löst eine Warnung aus, wenn der Supervisor einen Prozess abbricht, nachdem die Anzahl `startretries` ausgeschöpft ist
    Restart-Schleife / `BACKOFF`-Erkennung, um instabile Worker zu erkennen, die niemals einen stabilen `RUNNING`-Zustand erreichen
    Verfügbarkeitszeit pro Prozess und PID-Verfolgung („start since“), um unbemerkte Neustarts und kurzlebige Prozesse zu erkennen
    Prüfung des letzten Exit-Codes im Vergleich zu den im Programm konfigurierten `exitcodes`
    Anzahl der laufenden vs. konfigurierten Prozesse – sofort erkennen, wenn Worker fehlen
    Funktioniert in Verbindung mit `numprocs`, Prozessgruppen und dem nach `priority` geordneten Start
    Prozessspezifische Alarmschwellenwerte und Schweregrade, die individuell angepasst werden können
    Agentenbasierte Datenerfassung – keine HTTP/XML-RPC-Schnittstelle, die offengelegt oder gesichert werden muss
    Was versteht man unter Supervisor-Überwachung?

    Überwachung durch den Vorgesetzten, erklärt

    Die Supervisor-Überwachung umfasst die kontinuierliche Verfolgung des Status jedes von supervisord verwalteten Programms sowie die Ausgabe einer Warnmeldung, wenn ein Prozess den Zustand RUNNING verlässt. Supervisor ist hervorragend darin, einen abgestürzten Prozess neu zu starten – allerdings nur startretries Mal innerhalb von startsecs. Wird diese Grenze überschritten, wechselt der Prozess in den Status FATAL und Supervisor stellt weitere Versuche ein. Nichts anderes bemerkt dies: Der Host ist aktiv, der Daemon läuft, die Warteschlange wird lediglich nicht mehr abgearbeitet. Xitoring liest die Live-Prozestabelle über supervisorctl, verfolgt jedes Programm unabhängig und leitet sofort eine Warnmeldung an Ihren Bereitschaftsdienst weiter, sobald ein Worker in den Zustand FATAL wechselt, in einer BACKOFF-Schleife hängt oder mit einem unerwarteten Code beendet wird.

    Kennzahlen

    Was wir überwachen

    Prozessstatus

    Der aktuelle Status jedes Programms (`RUNNING`, `STARTING`, `BACKOFF`, `EXITED`, `FATAL`, `STOPPED`, `STOPPING`, `UNKNOWN`). Das mit Abstand wichtigste Supervisor-Signal – alles andere als `RUNNING` bei einem langlaufenden Worker ist ein Problem.

    FATAL-Status

    Ein Prozess, der die Grenze von `startretries` überschritten hat und vom Supervisor abgebrochen wurde. Er wird nicht von selbst neu gestartet. Jedes Programm im Status `FATAL` ist ein schwerwiegendes Signal, das eine Seite wert ist.

    BACKOFF / Schleife neu starten

    Ein Prozess, der immer wieder vor `startsecs` abstürzt und erneut gestartet wird. Ein anhaltender `BACKOFF` bedeutet, dass ein instabiler Worker bei jedem Neustart CPU-Leistung verschwendet und niemals Datenverkehr verarbeitet.

    Betriebszeit (seit dem Start)

    Wie lange jeder Prozess bereits seine aktuelle PID hält. Ein Worker, dessen Betriebszeit ständig zurückgesetzt wird, befindet sich stillschweigend in einer Crash-Schleife, auch wenn er zwischen den Neustarts kurzzeitig den Status `RUNNING` anzeigt.

    Prozess-PID

    Der aktuelle PID-Wert pro Programm aus `supervisorctl status`. Ist dieser Wert vorhanden, bestätigt dies, dass der Prozess tatsächlich läuft und nicht nur konfiguriert ist.

    Code für den letzten Ausstieg

    Der Exit-Status des letzten Durchlaufs. Vergleichen Sie diesen mit den `exitcodes` des Programms, um zwischen einem erwarteten Beenden und einem unerwarteten Absturz zu unterscheiden.

    Ausgeführt vs. Konfiguriert

    Anzahl der tatsächlich als `RUNNING` laufenden Prozesse im Vergleich zur angegebenen Anzahl (einschließlich `numprocs`). Zeigt auf einen Blick, welche Worker in einer Gruppe fehlen.

    Unerwartete Abgänge

    Beendet das Programm mit einem Code, der nicht in `exitcodes` enthalten ist, wenn `autorestart=unexpected` gesetzt ist. Dies sind Abstürze, die niemals hätten auftreten dürfen – ein Anstieg dieser Werte deutet auf eine Regression hin.

    Zähler für Neustarts

    Wie oft der jeweilige Prozess im Laufe der Zeit neu gestartet wurde. Eine stetige Neustartfrequenz bei einem Prozess, der eigentlich kontinuierlich laufen sollte, ist ein Frühwarnzeichen für Instabilität oder einen Speicherverlust.

    Beendete Prozesse

    Programme im Status `STOPPED` oder `EXITED`, die eigentlich laufen sollten. Erfasst einen Worker, der manuell gestoppt und vergessen wurde, oder einen, der beendet wurde, ohne automatisch neu zu starten.

    Auslöser & Benachrichtigungen

    Konfigurierbare Alarmauslöser

    Richten Sie benutzerdefinierte Trigger in Ihrem Dashboard ein, um benachrichtigt zu werden, sobald die Kennzahlen von „Supervisor“ Ihre festgelegten Schwellenwerte überschreiten.

    Supervisor Dashboard zur Konfiguration von Überwachungsauslösern

    Prozess FATAL

    entscheidend

    Wird ausgelöst, wenn ein Prozess den Status `FATAL` erreicht – der Supervisor hat den Neustart aufgegeben, und der Prozess bleibt inaktiv, bis jemand eingreift.

    Prozess läuft nicht

    entscheidend

    Wird ausgelöst, wenn ein Programm, das den Status `RUNNING` haben sollte, den Status `STOPPED`, `EXITED` oder `UNKNOWN` aufweist.

    Schleife neu starten

    Warnung

    Warnmeldungen bei anhaltendem `BACKOFF` oder wiederholten Neustarts – ein Worker, der ständig abstürzt und sich nie stabilisiert.

    Unerwarteter Exit-Code

    Warnung

    Wird ausgelöst, wenn ein Prozess mit einem Code beendet wird, der nicht zu den konfigurierten `exitcodes` gehört.

    01

    Bedeutung von Überwachung durch den Vorgesetzten

    Der Supervisor startet einen abgestürzten Prozess neu – bis er es nicht mehr tut. Nach `startretries` wird der Prozess in `FATAL` geparkt und bleibt dort, ohne dass der Host eine entsprechende Meldung ausgibt.

    • Prozesse abfangen, bei denen ein `FATAL`-Fehler auftritt, und den Neustart unterbinden
    • Erkennen von „flappenden“ Prozessoren, die in `BACKOFF`-Schleifen feststecken
    • Stille Neustarts anhand der zurückgesetzten Betriebszeit erkennen
    • Erkennen, wenn Mitarbeiter mit unerwarteten Codes das Unternehmen verlassen
    Dashboard zum Prozessstatus des Supervisors
    Analyse von Prozessneustarts und Betriebszeiten
    02

    Warum sich für uns entscheiden? Xitoring

    Agentenbasierte Überwachung durch „Supervisor“ mit Zero-Config-Einrichtung und prozessspezifischer Transparenz für jedes von „supervisord“ verwaltete Programm.

    • Installation und Integration mit einem einzigen Befehl
    • Verfolgung nach Prozess und nach Gruppe
    • Es gibt keine XML-RPC- oder HTTP-Schnittstelle, die bereitgestellt werden könnte
    • Mehrkanal-Benachrichtigungen für Ihren Bereitschaftsdienstplan
    • Historischer Status und Neustartverlauf
    Übersicht über den Xitoring Supervisor
    Alarmkonfiguration pro Prozess
    Anwendungsfälle

    Überwachung durch den gemeinsamen Betreuer Szenarien

    Wo Supervisor normalerweise läuft – und was unbemerkt fehlschlägt, wenn niemand hinschaut.

    Hintergrundprozesse (Celery, Sidekiq, RQ, Resque)

    Queue-Worker sind genau jene Prozesse, die still und leise abstürzen – eine fehlerhafte Bereitstellung oder eine fehlerhafte Nachricht versetzt sie in eine Neustartschleife, gefolgt von einem FATAL. Wir lösen eine Warnmeldung aus, sobald ein Worker nicht mehr läuft, noch bevor es zu einem Stau in der Warteschlange kommt und Jobs das Zeitlimit überschreiten.

    Anwendungsserver und Daemons (Gunicorn, uWSGI, Daphne, Node)

    Wenn Supervisor Ihren Anwendungsserver verwaltet, bedeutet ein Prozess, der nach einer Bereitstellung nicht startet, dass die Website ausgefallen ist, obwohl der Hoststatus weiterhin „grün“ ist. Wir erkennen FATAL- und BACKOFF-Fehler sofort, sodass bei einer fehlgeschlagenen Bereitstellung sofort jemand benachrichtigt wird, anstatt auf eine Meldung des Kunden zu warten.

    Prozesse in Containern und auf älteren Hosts

    In vielen Containern und älteren Servern wird Supervisor anstelle von systemd eingesetzt, um mehrere Prozesse an einem Ort am Laufen zu halten. Wir überwachen jeden Prozess einzeln, damit ein einzelner abgestürzter Prozess in einem stark ausgelasteten Container nicht hinter den anderen verborgen bleibt.

    Bevor Sie beginnen

    Voraussetzungen für Supervisor

    Stellen Sie sicher, dass diese Punkte erfüllt sind — danach ist die Installation eine Sache von 60 Sekunden.

    • Ein Linux-Server, auf dem Supervisor (supervisord) installiert ist und der mindestens ein Programm verwaltet
    • Xitogent ist auf demselben Host installiert, sodass der Befehl supervisorctl status ausgeführt werden kann
    • Führen Sie den Befehl sudo xitogent integrate aus und wählen Sie die Supervisor-Integration aus.
    Einrichtungsanleitung

    Erste Schritte in Minuten

    1

    Installieren Sie Xitogent auf Ihrem Server

    Installieren Sie den ressourcenschonenden Xitogent-Überwachungsagenten auf dem Host, auf dem Supervisor ausgeführt wird.

    curl -s https://xitoring.com/install.sh | sudo bash -s -- --key=YOUR_API_KEY
    2

    Supervisor-Integration aktivieren

    Führen Sie den Befehl `sudo xitogent integrate` aus und wählen Sie „Supervisor“ aus. Xitogent erstellt die Datei `/etc/xitogent/integrations/supervisor_integration.conf`, liest die Prozesstabelle über `supervisorctl` aus und erkennt automatisch alle Programme und Gruppen unter `supervisord` – es sind keine Änderungen an der Supervisor-Konfiguration erforderlich.

    sudo xitogent integrate
    3

    Trigger konfigurieren (optional)

    Legen Sie im Xitoring-Dashboard prozessspezifische Trigger und Schweregrade fest – beispielsweise eine Benachrichtigung, sobald ein Prozess den Status `FATAL` erreicht, sowie eine Warnung bei anhaltendem `BACKOFF` oder einem unerwarteten Exit-Code –, damit Fehler den Bereitschaftsdienst erreichen, bevor sich die Warteschlange staut.

    4

    Funktion überprüfen

    Führen Sie diesen Befehl auf dem Server aus, um zu bestätigen, dass Xitogent die Integration erkannt hat. Innerhalb von etwa 30 Sekunden werden frische Metriken in Ihr Dashboard gestreamt.

    sudo xitogent status
    Vergleichen

    Erwägen Sie Alternativen?

    Sehen Sie, wie sich Xitoring gegen die Alternativen für Supervisor-Monitoring schlägt — Pauschalpreise, tiefere Integrationen und ein Agent, der Ihren gesamten Stack abdeckt.

    Alle Vergleiche ansehen

    Häufig gestellte Fragen

    Was versteht man unter Supervisor-Überwachung?
    Die Supervisor-Überwachung umfasst die kontinuierliche Verfolgung des Status jedes von `supervisord` verwalteten Programms – `RUNNING`, `STARTING`, `BACKOFF`, `EXITED`, `FATAL`, `STOPPED`, `UNKNOWN` – zusammen mit der Laufzeit pro Prozess, PID, den Exit-Code und den Neustartverlauf eines jeden Prozesses sowie die Ausgabe von Warnmeldungen, wenn ein Prozess den Zustand `RUNNING` verlässt. Da Supervisor den Neustart eines Prozesses nach `startretries`-Versuchen einstellt und ihn in den Zustand `FATAL` versetzt, ist die Überwachung die einzige Möglichkeit, um festzustellen, dass ein verwalteter Worker ausgefallen ist.
    Wie erfasst Xitoring Daten von Vorgesetzten?
    Auf Agentenseite. Xitogent führt in kurzen Intervallen den Befehl `supervisorctl status` aus und wertet den Status, die PID und die Laufzeit der einzelnen Programme aus. Es ist nicht erforderlich, den `inet_http_server` von Supervisor zu aktivieren oder dessen XML-RPC-Schnittstelle freizugeben – der Agent liest lokal dieselben Daten aus wie die Befehlszeilenschnittstelle.
    Wie richte ich die Supervisor-Integration ein?
    Installieren Sie Xitogent (`curl -s https://xitoring.com/install.sh | sudo bash -s -- --key=YOUR_API_KEY`), führen Sie anschließend `sudo xitogent integrate` aus und wählen Sie „Supervisor“ aus. Xitogent erstellt die Datei `/etc/xitogent/integrations/supervisor_integration.conf`, erkennt automatisch alle von `supervisord` verwalteten Programme und Gruppen und beginnt mit deren Überwachung. Es sind keine Änderungen an Ihrer Supervisor-Konfiguration erforderlich.
    Was bedeuten die Prozesszustände des Supervisors?
    `STOPPED` – noch nicht gestartet. `STARTING` – gestartet, wartet `startsecs`, bis der Status `RUNNING` gilt. `RUNNING` – läuft und ist stabil. `BACKOFF` – gestartet, aber vor Ablauf von `startsecs` abgestürzt; der Supervisor versucht es erneut. `EXITED` – wurde ausgeführt und beendet (erwartet oder unerwartet, gemäß `exitcodes`). `FATAL` – `startretries` überschritten; der Supervisor hat aufgegeben und wird den Prozess nicht neu starten. `STOPPING` – wird heruntergefahren. `UNKNOWN` – der Supervisor hat den Überblick über den Prozess verloren. Bei lang laufenden Workern erfordert jeder Status außer `RUNNING` besondere Aufmerksamkeit.
    Was bedeutet der Status „FATAL“ und warum ist er von Bedeutung?
    Ein Prozess wird als `FATAL` eingestuft, wenn er innerhalb von `startsecs` mehr als `startretries` Mal nicht am Laufen gehalten werden konnte. Zu diesem Zeitpunkt bricht Supervisor die Versuche ab und lässt den Prozess im nicht mehr funktionierenden Zustand. Nichts auf dem Host stellt ihn automatisch wieder her – der Server läuft, der `supervisord`-Daemon läuft, aber Ihr Worker ist nicht mehr vorhanden. `FATAL` ist die mit Abstand wichtigste Supervisor-Warnung: Sie bedeutet fast immer, dass ein Deployment fehlgeschlagen ist, eine Abhängigkeit fehlt oder der Prozess beim Start abstürzt.
    Wie kann ich eine Neustartschleife des Supervisors erkennen?
    Beobachten Sie den Zustand `BACKOFF` und das Zurücksetzen der Laufzeit. Ein flatternder Prozess wechselt wiederholt zwischen `STARTING` → stirbt vor Ablauf von `startsecs` ab → `BACKOFF` → erneuter Versuch, ohne jemals einen stabilen Zustand `RUNNING` zu erreichen. Xitoring zeigt sowohl anhaltende `BACKOFF`-Zustände als auch einen Prozess an, dessen Laufzeit sich ständig zurücksetzt, sodass Sie die Schleife erkennen, während sie noch CPU-Leistung beansprucht, anstatt erst, nachdem sie im Zustand `FATAL` gelandet ist. Die Behebung besteht in der Regel darin, `startsecs`/`startretries` erst dann zu erhöhen, nachdem die Ursache für das vorzeitige Beenden des Prozesses behoben wurde.
    Was ist der Unterschied zwischen „autorestart true“, „false“ und „unexpected“?
    `autorestart=true` startet den Prozess nach jedem Beenden automatisch neu. `autorestart=false` tut dies niemals. `autorestart=unexpected` (eine gängige Standardeinstellung) startet den Prozess nur dann neu, wenn der Beendigungscode nicht in der Liste `exitcodes` des Programms enthalten ist – d. h., ein in der Liste aufgeführter Code wird als ordnungsgemäßes Beenden gewertet, alles andere als ein Absturz. Xitoring vergleicht den letzten Beendigungscode mit den `exitcodes`, sodass Sie gezielt bei unerwarteten Beendigungen alarmieren können, anstatt bei jedem beabsichtigten Abbruch.
    Kann ich mehrere Prozesse und Prozessgruppen überwachen?
    Ja. Xitogent erkennt automatisch jedes von `supervisord` verwaltete Programm, einschließlich gruppierter Prozesse und Programme mit `numprocs > 1` (z. B. `worker:worker_00`, `worker:worker_01`). Jeder Prozess wird unabhängig verfolgt, gemeldet und protokolliert, sodass ein einzelner abgestürzter Worker in einer stark ausgelasteten Gruppe niemals hinter den noch laufenden Prozessen verborgen bleibt.
    Supervisor vs. systemd – warum sollte man gerade Supervisor überwachen?
    Zahlreiche Systemstapel stützen sich nach wie vor auf Supervisor: Docker-Container, in denen mehrere Prozesse laufen, ältere Hosts aus der Zeit vor der breiten Einführung von systemd sowie Python-/Ruby-Anwendungen, deren Bereitstellungstools auf Supervisor standardisiert wurden. Auch das Neustartverhalten von Supervisor unterscheidet sich von dem von systemd – es gibt einen Prozess nach `startretries`-Versuchen als `FATAL` auf, anstatt unendlich lange zu warten. Durch die direkte Überwachung der Zustandsmaschine von Supervisor lassen sich diese abgebrochenen Prozesse erfassen, unabhängig davon, was sonst noch auf dem Host läuft.

    Supervisor überwachen heute

    In weniger als 60 Sekunden eingerichtet. Keine Kreditkarte erforderlich. Umfassende Kennzahlen vom ersten Tag an.

    Kostenlose Testversion starten

    Entdecke weiter

    Verwandte Themen Integrationen