Einen VPS mit Signalen überwachen, die zu einer nützlichen ersten Reaktion führen
Monitoring ist nützlich, wenn es die nächste Entscheidung beeinflusst. Ein Server kann auf Ping antworten, während die Anwendung ausfällt, und eine ausgelastete CPU kann bei erwarteter Arbeit gesund sein. Beginnen Sie mit dem, was Nutzer benötigen, und sammeln Sie dann genügend Belege, um zu erklären, wann sich dieses Erlebnis ändert.
Das Wichtigste in Kürze
Beobachten Sie die Anwendung von außen und ihre Ressourcenbeschränkungen von innen, vergleichen Sie Änderungen mit einer Baseline, und geben Sie jedem dringenden Alarm einen klaren Verantwortlichen und eine erste Maßnahme.
Definieren Sie Gesundheit anhand eines wichtigen Nutzerpfads
Wählen Sie einen Anwendungsablauf, der zählt: eine öffentliche Seite öffnen, sich anmelden oder eine repräsentative API-Ressource lesen. Definieren Sie, wie ein erfolgreiches Ergebnis aussieht, einschließlich Antwortinhalt und einer angemessenen Abschlusszeit. Eine HTTP-200-Antwort mit einer Fehlerseite sollte nicht automatisch als Erfolg gelten. Halten Sie synthetische Prüfungen sicher und vermeiden Sie echte Bestellungen oder das Senden von Kundennachrichten.
Führen Sie eine externe Prüfung von außerhalb des VPS aus, damit sie Ausfälle bemerkt, die ein interner Prozess nicht sehen kann. Ergänzen Sie interne Dienst- und Host-Messungen, um den Ausfall zu erklären. Zusammen beantworten sie zwei verschiedene Fragen: Kann ein Nutzer die Anfrage abschließen, und welcher Teil des Systems steht unter Druck? Keine der beiden Sichten ersetzt die andere.
Dokumentieren Sie Identität, Häufigkeit und erwartete Berechtigungen der Prüfung. Wenn sie ein Konto verwendet, geben Sie diesem Konto nur den für den synthetischen Ablauf nötigen Zugriff. Überwachen Sie, ob das Überwachungssystem selbst Daten erfasst. Ein leerer Graph kann eine fehlende Erfassung statt null Verkehr bedeuten, und diese beiden Situationen erfordern unterschiedliche erste Maßnahmen.
Erstellen Sie ein kleines Dashboard rund um Symptome und Beschränkungen
| Signal | Nützliche Ansicht | Beantwortete Frage |
|---|---|---|
| Anfrage-Latenz | Erfolgreiche und fehlgeschlagene Anfragen, einschließlich langsamerer Perzentile | Welche Nutzer warten länger? |
| Traffic | Anfragen, Jobs oder Verbindungen pro Intervall | Hat sich die Nachfrage oder Hintergrundarbeit geändert? |
| Fehler | Fehlerrate mit der zugrunde liegenden Anfragezahl | Wie viel nützliche Arbeit schlägt fehl? |
| Sättigung | CPU, verfügbarer Speicher, Speicherdruck und Warteschlangen | Welche Ressource könnte den Fortschritt begrenzen? |
| Betriebliche Änderungen | Releases, Konfigurationsänderungen und geplante Jobs | Was hat sich kurz vor Beginn des Symptoms geändert? |
Verlassen Sie sich nicht allein auf eine durchschnittliche Latenz. Eine kleine Gruppe sehr langsamer Anfragen kann von vielen schnellen verdeckt werden. Trennen Sie wichtige Routen oder Workload-Klassen, ohne jedem Kundenbezeichner ein eigenes Metrik-Label zu geben. Halten Sie die Messungen stabil genug, um einen Dienstagmorgen mit einem vergleichbaren früheren Zeitraum zu vergleichen, statt unzusammenhängenden Verkehr in einer beruhigenden Zahl zu vermischen.
Ein CPU-Diagramm braucht Anwendungskontext. Eine hohe Auslastung während eines geplanten Batch-Jobs kann erwartet sein, während steigende Anfragelatenz und eine Warteschlange bei normalem Verkehr auf ein Kapazitätsproblem hindeuten können. Prüfen Sie ebenso den verfügbaren Arbeitsspeicher und das Anwendungsverhalten, statt jeden Dateisystem-Cache als Leck zu interpretieren. Achten Sie auf anhaltenden Druck und relevante Fehler, bevor Sie sich für eine Größenänderung des Servers entscheiden.
Wählen Sie Alarme, auf die jemand reagieren kann
Ein dringender Alarm sollte ein aussagekräftiges Symptom und eine Reaktion beschreiben, mit der der Empfänger beginnen kann. Ein fehlgeschlagener externer Anwendungsablauf, der über mehrere Prüfungen hinweg anhält, unterscheidet sich von einem kurzen CPU-Ausschlag. Leiten Sie geplante Kapazitätsarbeiten an eine Prüfwarteschlange weiter, wenn eine sofortige Unterbrechung nicht nötig ist. Jeder Alarm benötigt einen Verantwortlichen, einen funktionierenden Benachrichtigungspfad und eine kurze Diagnosenotiz.
Schwellenwerte sind Workload-Entscheidungen. Ein Team könnte beispielsweise untersuchen, wenn eine normalerweise schnelle API zehn Minuten lang eine Latenz im 95-Perzentil über 900 Millisekunden aufweist und dabei genügend Anfragen erhält, damit die Messung aussagekräftig ist. Das ist eine beispielhafte Richtlinie, kein allgemeingültiger Grenzwert und keine HM Bastion-Latenzgarantie. Prüfen Sie Fehlalarme und verpasste Vorfälle anhand der tatsächlichen Auswirkungen auf Nutzer.
Speicheralarme sollten berücksichtigen, wie schnell sich der freie Speicher ändert. Zwanzig Gigabyte verbleibend bedeuten etwas anderes, wenn das Wachstum ein Gigabyte pro Tag oder zehn Gigabyte pro Stunde beträgt. Beziehen Sie gegebenenfalls Inode-Druck ein und unterscheiden Sie persistentes Anwendungswachstum von einem außer Kontrolle geratenen Log. Bevorzugen Sie eine frühzeitige, umsetzbare Kapazitätswarnung, statt zu warten, bis Schreibvorgänge bereits fehlgeschlagen sind.
Nutzen Sie den ersten Diagnosedurchlauf, um die fehlerhafte Schicht einzugrenzen
- Bestätigen Sie das Symptom von einem unabhängigen Standort aus und notieren Sie den Startzeitpunkt.
- Prüfen Sie, ob DNS, der Verbindungsaufbau, HTTPS oder die Anwendungsantwort fehlschlägt.
- Vergleichen Sie Anfragefehler und Latenz mit dem Verkehr und den jüngsten Änderungsmarkierungen.
- Prüfen Sie den Status des betroffenen Dienstes, begrenzte aktuelle Logs und die Konnektivität der Abhängigkeiten.
- Vergleichen Sie CPU, Arbeitsspeicher, Speicher und Warteschlangenverhalten mit der normalen Baseline.
- Eskalieren Sie mit der beobachteten fehlerhaften Schicht, bevor Sie unzusammenhängende Änderungen vornehmen.
Angenommen, die Startseite funktioniert, aber API-Anfragen geben nach einem Release 502 zurück. Beginnen Sie mit dem Proxy-Fehler und dem referenzierten Anwendungsprozess oder Socket, statt einen größeren Netzwerkvorfall anzunehmen. Wenn alle lokalen Prüfungen bestehen, aber externe Anfragen in einen Timeout laufen, untersuchen Sie den öffentlichen Pfad und den lauschenden Einstiegspunkt. Dies sind zu prüfende Diagnosezweige, keine automatischen Schlussfolgerungen aus einem Statuscode.
Auf einem systemd-basierten Linux-Server kann das Journal auf die betroffene Unit und den Zeitraum gefiltert werden. Vergleichen Sie es mit Anwendungs- und Reverse-Proxy-Logs anhand konsistenter Zeitstempel. Behalten Sie genügend Kontext, um einen Fehler einer Anfrage zuzuordnen, aber schwärzen Sie Zugangsdaten und sensible Nutzdaten, bevor Sie Auszüge teilen. Ein gezielter aktueller Zeitraum ist meist nützlicher als ein vollständiges ungefiltertes Log-Archiv.
Abdeckung prüfen und aus Nachweisen eine Kapazitätsentscheidung ableiten
Metriken beschreiben Trends, Logs beschreiben einzelne Ereignisse, und Traces können zeigen, wie eine Anfrage Zeit über Komponenten hinweg verbringt. Führen Sie die kleinste Kombination ein, die Ihre aktuellen Fragen beantwortet. Ein aufwendiges Tracing-System bringt wenig, wenn niemand den Alarm bei Anwendungsausfall erhält oder der Backup-Job seit einer Woche kein verwertbares Ergebnis gemeldet hat.
Bestätigen Sie nach einem Release oder einer wesentlichen Änderung der Last, dass die Prüfungen weiterhin den richtigen Ablauf abdecken und die Erfassung weiterhin funktioniert. Nutzen Sie anhaltende Messungen, um zu entscheiden, ob eine Anwendungskorrektur, eine Abfrageverbesserung, eine Zeitplanänderung oder eine andere Ressourcenzuweisung gerechtfertigt ist. Halten Sie Incident-Koordination und Service-Wiederherstellung in einem separaten Verfahren, damit das Dashboard ein klarer Ausgangspunkt bleibt und nicht zu einer Sammlung von Notfallanweisungen wird.
