Monitoring
Wisse es vor deinen Nutzern
Jeder Server meldet einmal pro Minute CPU, Last, Arbeitsspeicher, Festplatte und Netzwerk, und jede Site wird alle 15 Minuten von außen geprüft. Lege Schwellenwerte fest, füge Heartbeats für deine Jobs hinzu und erhalte eine Nachricht, wenn sich etwas ändert, statt einer pro Minute.
Servermetriken
Jeder Server, jede Minute gemessen
Die Provisionierung installiert einen kleinen Bash-Agenten, den Cron einmal pro Minute ausführt. Er misst den Server und sendet die Werte über HTTPS mit einem Token, der nur für diesen Server gilt. Es wird kein Port geöffnet und kein Daemon gestartet.
Die Seite Monitoring zeigt die aktuellen Werte und Diagramme für 1 Stunde, 6 Stunden, 24 Stunden, 7 Tage oder 30 Tage. CPU, Arbeitsspeicher und Festplatte werden ab 75 % orange und ab 90 % rot. Messwerte werden 31 Tage aufbewahrt.
Was der Agent misst
CPU und Last
Der Anteil der CPU-Zeit, die über eine Sekunde ausgelastet war, und die Load Average über eine Minute neben der Anzahl der Kerne.
Arbeitsspeicher
Belegter Arbeitsspeicher, also gesamt minus verfügbar, in Prozent.
Festplatte
Belegter Platz auf der Root-Festplatte, damit du eine volle Platte kommen siehst.
Netzwerk
Ein- und ausgehende Bytes auf der Haupt-Netzwerkschnittstelle, angezeigt in Mbit/s.
SSH-Anmeldungen
Jede erfolgreiche SSH-Anmeldung, mit Benutzer, IP-Adresse und Schlüssel, auf der Seite Sicherheit des Servers.
Neustart nötig
Wenn Ubuntu nach Updates einen Neustart verlangt, und für welche Pakete.
Monitore
Alarme, die auf ein echtes Problem warten
Ein Monitor überwacht CPU-Auslastung, CPU-Last, Arbeitsspeicher- oder Festplattennutzung gegen einen Schwellenwert über 1 bis 60 Minuten. Er schlägt nur Alarm, wenn der Wert in jeder Minute dieses Zeitfensters auf oder über dem Schwellenwert lag; eine Minute ohne Daten zählt nie mit, eine Lücke kann also keinen Alarm auslösen.
Du erhältst eine E-Mail, wenn der Alarm beginnt, etwa *Warnung: CPU-Auslastung auf web-1 ist 96 %*, und eine, wenn sich der Wert erholt. Gute Startwerte: CPU bei 90 % für 5 Minuten, Arbeitsspeicher bei 90 % für 5 Minuten, Festplatte bei 85 % für 1 Minute.
Heartbeats
Merke, wenn ein geplanter Job verstummt
Cron sagt dir nicht, wenn ein Job aufhört zu laufen. Ein Heartbeat schon: Lege einen mit Intervall und Kulanzzeit an und lass den Job seine URL aufrufen, wenn er erfolgreich war. Kommt der Aufruf nicht rechtzeitig, wechselt der Heartbeat auf Verpasst und du bekommst eine E-Mail; meldet sich der Job wieder, erfährst du auch das.
Heartbeats werden jede Minute geprüft. Die URL akzeptiert GET und POST und antwortet mit OK.
php /home/vimonto/example.com/current/artisan backup:run \
&& curl -fsS -m 10 https://deploy.example.com/heartbeat/your-tokenUptime-Monitoring
Jede Site von außen geprüft, alle 15 Minuten
Uptime-Checks sind für jede Site von Anfang an aktiv, ohne dass du etwas installieren musst. Die Übersicht der Site zeigt den aktuellen Status, die Uptime über 24 Stunden, 7, 30 und 90 Tage und die durchschnittliche Antwortzeit.
Geprüft wie ein Besucher
Ein
GETan die primäre Domain, über HTTPS, wenn die Site ein Zertifikat hat, folgt bis zu fünf Weiterleitungen, mit 10 Sekunden Timeout.Keine Fehlalarme
Eine Site gilt nach zwei fehlgeschlagenen Checks in Folge als down und nach einem erfolgreichen wieder als up. Eine Site hinter einem Passwort gilt bei
401als up.90-Tage-Raster
Ein Kästchen pro Tag, eingefärbt nach Uptime, mit Checks und Ausfallminuten beim Hovern, dazu eine Leiste der letzten 96 Checks.
Deine Health-Route
Prüfe statt der Startseite einen Pfad wie Laravels
/upoder schalte die Checks für geplante Wartungen ab.
Statusseiten
Öffentliche Statusseiten
Gib deinen Kunden eine Seite, die zeigt, ob alles funktioniert. Eine Statusseite unter eigener Adresse zeigt deine Sites, Heartbeats und Server, jeweils mit einem Balken der letzten 90 Tage, und die Störungen und Wartungen, die du meldest.
- Komponenten aus Uptime-Checks von Sites, Heartbeats und Servern, in Abschnitte gruppiert
- Eine Überschrift für alles: in Betrieb, eingeschränkte Leistung, teilweiser oder schwerer Ausfall
- Störungen mit Updates und geplante Wartungen
- Öffentlich: Besucher brauchen kein Konto
Benachrichtigungen
Einmal informiert, so wie jede Person es möchte
Monitor-Alarme, verpasste Heartbeats, ausgefallene Sites, fehlgeschlagene Backups, Deploys und Zertifikate erreichen jedes Mitglied, das den Server sehen kann, über die Glocke in der App und per E-Mail. Jede Person wählt pro Art von Benachrichtigung den gewünschten Kanal und kann Server stummschalten, denen sie nicht folgt.
Standardmäßig kommen Fehler per E-Mail und in der App, gute Nachrichten nur in der App. Ein Monitor oder Heartbeat kann außerdem eine gemeinsame Adresse anschreiben, etwa das Postfach deines Teams, ohne dass diese Person Mitglied sein muss.
Fragen zum Monitoring
Kostet Monitoring extra oder bremst es meinen Server?
Nein. Monitoring ist in jedem Tarif enthalten. Der Agent läuft jede Minute etwa eine Sekunde lang und sendet ein paar Zahlen.
Kann ich meine Sites öfter als alle 15 Minuten prüfen?
Nein. Jede Site wird alle 15 Minuten geprüft, und die Checks werden 90 Tage aufbewahrt.
Kann ich Alarme an Slack senden?
Eine Slack-Integration gibt es nicht. Alarme kommen per E-Mail und über die Glocke in der App; trag ein gemeinsames Postfach als Empfängeradresse ein. Für Deploys kann der Deploy-Hook einer Site an deinen eigenen Endpunkt senden.
Kann ich einen Datenbank- oder Cache-Server überwachen?
Ja. Der Agent läuft auf jedem Servertyp, auch auf Datenbank-, Cache-, Meilisearch- und Load-Balancer-Servern.
Taucht der Uptime-Check in meinen Statistiken auf?
Nur in Statistiken, die das Access-Log auswerten. Der Check nutzt den User-Agent VimontoDeploy-Uptime/1.0, sodass du ihn herausfiltern kannst. Browser-Analytics sehen ihn nicht.
Verwandte Seiten
- ServerProvisionierung für jede Rolle: App-, Web-, Worker-, Datenbank-, Cache-, Such- und Load-Balancer-Server.
- Datenbanken und BackupsMySQL, MariaDB oder PostgreSQL, Datenbankbenutzer und geplante Backups in deinen eigenen Bucket.
- AutomatisierungEine REST-API, eine CLI für die CI, Deploy-URLs, Rezepte für wiederkehrende Skripte und Deploy-Hooks.
Dein nächster Deploy ist live, bevor dein Kaffee fertig ist.
Erstelle eine Organisation, verbinde einen Server und pushe. Mehr nicht.