Überblick über die Überwachung
Diese Seite ist für Systemadministratoren, die die Überwachung für Exponential-Websites aufbauen, und für Support-Mitarbeitende, die wissen müssen, wo sie zuerst nachsehen. Sie beantwortet: welche Signale Exponential gibt, welche davon ein Überwachungssystem lesen kann (Exit-Codes, JSON, HTTP-Endpunkte) und welche in die Hände eines Menschen gehören, der einmal pro Woche auf eine Seite schaut.
Es gibt keine einzelne Zustands-URL; kombinieren Sie eine Prüfung von außen mit den Statusbefehlen im Inneren (10.11 Überwachung und Zustandsprüfungen). Die externen Prüfungen stehen auf Zustandsprüfungen und Verfügbarkeit.
Inhalt
- Vier Schichten der Überwachung
- Statusbefehle für ein Überwachungssystem
- Seiten für einen Menschen
- Die eigenen Endpunkte von Velocity
- Alarme, die die Website selbst sendet
- Viele Kunden-Websites überwachen
- Checkliste
Vier Schichten der Überwachung
| Schicht | Frage | Die Werkzeuge von Exponential |
|---|---|---|
| Erreichbarkeit | Antwortet die Website, schnell genug? | eine HTTP-Prüfung von außen; /Q/health von Velocity |
| Plattform | Sind PHP, OPcache, die Datenbank, die Festplatte, Cron in Ordnung? | exp:systeminfo, exp:cache status, crontab:list |
| Anwendung | Gibt es neue Fehler, Angriffe, gescheiterte Jobs, Probleme mit Mail? | die Logs, die Fehlerübersicht, exp:mail:status, exp:notificationstatus |
| Integrität | Hat jemand etwas geändert, was er nicht sollte? | das Prüfprotokoll und exp:audit verify |
Statusbefehle für ein Überwachungssystem
Alle laufen aus dem Wurzelverzeichnis der Installation als Benutzer der Website. Die meisten haben --json für eine Maschine
und enden mit einem erkennbaren Status oder einem Exit-Code.
| Prüfung | Befehl | Gesund |
|---|---|---|
| Zustandsprüfungen der Plattform | ./console exp:systeminfo --json | Exit-Status 0; er endet mit 1, wenn eine Prüfung scheitert |
| Caches | php bin/php/cache.php status --json --allow-root-user | endet mit PASS |
| Velocity | php bin/php/console exp:velocity status --json --allow-root-user | läuft, Worker wie konfiguriert |
| Benachrichtigungen | php bin/php/console exp:notificationstatus | keine wartenden Ereignisse ohne kürzlichen Lauf |
| Prüfprotokoll | php bin/php/audit.php verify --allow-root-user | Exit-Status 0 (1 bedeutet, dass eine Kette gebrochen ist) |
| E-Mail-Einstellungen | ./console exp:mail:status | fünf Tabellen ok, keine Probleme aufgeführt |
| Cron | php bin/php/console crontab:list und die Daten der Cron-Logs | Einträge vorhanden, Logs aktuell |
| Festplatte | df -h /path/to/installation | Platz für Caches, Logs und ein Backup |
| Leistung | php bin/php/console exp:benchmark --baseline=var/benchmark/base.json | Exit-Status 0 (keine Verschlechterung) |
| Datenbank | SQLite: Eine SQLite-Website überwachen; Oracle: ext:ezoracle:health |
Quellen: 10.11, Systeminformationen, E-Mail-Einstellungen, Benchmark.
Für einen einzelnen Server genügt ein kleines Skript in der Crontab des Benutzers der Website, das diese ausführt und bei einem Exit-Status ungleich null eine Mail schickt. Für viele Server führen Sie dieselben Befehle aus Ihrem Überwachungsagenten aus und sammeln die Exit-Codes.
Hinweis
exp:systeminfoauf der Kommandozeile meldet das PHP der Kommandozeile, nicht den PHP-FPM-Pool oder Velocity, der die Website ausliefert. Die Seite Setup > Systeminformationen der Administration zeigt den Server, der die Anfrage beantwortet hat; öffnen Sie sie über jeden Server, den Sie betreiben (Systeminformationen, welcher Server geantwortet hat).
Seiten für einen Menschen
| Seite | Was sie zeigt | Wer sie öffnen darf |
|---|---|---|
Setup > Systeminformationen (/setup/info) | welcher Server geantwortet hat, Zustandsprüfungen mit dem, was zu tun ist, Versionen, OPcache, Datenbank, Speicher, Cron, Mail | setup/system_info |
Setup > Logdateien > Zustand der Logs (/setup/logshealth) | von Logs belegter Platz gegenüber einem Budget, am schnellsten wachsende Logs, Dateien, die der Webserver nicht schreiben kann, der neueste Fehler jedes Logs | setup/logs |
Setup > Logdateien > Fehlerübersicht (/setup/logsdigest) | die verschiedenen Fehler und Warnungen der letzten 24 Stunden, gruppiert und gezählt | setup/logs |
Reiter Audit (/audit/dashboard) | der Zustand der Kette jedes Kanals, aktuelle Ereignisse, Alarme | audit/read |
| Setup > Cronjobs | Teile, Zeitpläne, letzte Läufe, Teile, die Aufmerksamkeit brauchen | setup/managecronjobs |
| Setup > E-Mail-Einstellungen | Zustand der Mail-Sperre, Probleme, Zahlen | mailpreferences/administrate |
Zustand der Logs warnt ab 80 % von logviewer.ini [HealthSettings] DiskBudget (mitgeliefert 256 MB) und kennzeichnet Logs mit
gemischten Eigentümern, die die Rotation aufhalten (Zustand der Logs). Siehe
Log-Viewer und Log-Rotation.
Tipp Ein wöchentlicher Blick auf die Fehlerübersicht und
security.logsteht in der eigenen Checkliste des Projekts: Ein plötzlicher Anstieg einer Regel ist einen Blick wert (Sicherheitshärtung).
Die eigenen Endpunkte von Velocity
Wenn Exponential Velocity eine Website ausliefert, hat der Server eigene Ansichten (Kontrollzentrum von Velocity):
| Endpunkt | Format | Nutzung |
|---|---|---|
/Q/health | JSON, für Monitore | antwortet jedem mit {"status":"ok"}; Kennzahlen nur für einen Administrator |
/Q/metrics | Text für Prometheus | Abruf in ein Kennzahlensystem |
/Q/stats | JSON, die volle Nutzlast | Dashboards wie Grafana |
/Q/dashboard | HTML | eine Ansicht für Menschen auf Worker, Speicher und Verkehr |
Wer sie öffnen darf, wird in settings/velocity.ini [DashboardSettings] festgelegt: standardmäßig nur von derselben Maschine;
Token= setzt ein Geheimnis, das sie von außen öffnet (?token=... oder ein Header Authorization: Bearer); Remote=enabled
öffnet sie ohne Token, nur für einen Port, den eine Firewall bereits auf vertrauenswürdige Adressen beschränkt.
Der Watchdog von Velocity (exp:velocity watchdog install, ein systemd-Timer) startet die Standard-Engine wieder, wenn sie
nicht läuft und niemand das wollte, und schreibt in var/log/velocity-watchdog.log, was er getan hat
(Der Watchdog). Er rührt nie einen laufenden Server
an; einen Server, der läuft, aber nicht antwortet, muss Ihre Überwachung erkennen.
Alarme, die die Website selbst sendet
Das Prüfprotokoll wertet Alarmregeln im Cronjob-Teil audit aus (Teil von frequent): Brute-Force-Anmeldungen, die Vergabe einer
Administratorrolle, außerhalb der Arbeitszeit geschriebene Einstellungen, Massenlöschungen, ein ausgeschaltetes Audit und eine
gebrochene Kette (Das Prüfprotokoll). Alarme gehen an die Empfänger einer Regel, sonst an
die konfigurierten, sonst an die AdminEmail der Website:
./console exp:audit alerts recipients --allow-root-userEntscheiden Sie auf einer gehosteten Website, ob Alarme an den Kunden, an Ihr Support-Team oder an beide gehen, und stellen Sie
sicher, dass der Teil frequent läuft (Cronjobs). Senken leiten das Protokoll an syslog oder einen Webhook für
ein zentrales System weiter (Sicherheitslog).
Viele Kunden-Websites überwachen
- Überall dieselben Befehle. Jede Installation hat die Befehle oben; führen Sie sie pro Installationsverzeichnis aus, als Benutzer dieser Installation.
- Exit-Codes, nicht Text. Werten Sie den Exit-Status und das JSON aus; der Text für Menschen kann sich zwischen Releases ändern.
- Eine externe Prüfung pro Adresse einer Website, dazu eine pro Knoten oder Engine-Port, wo Sie mehrere betreiben (Apache und Velocity auf verschiedenen Ports zeigen verschiedene Zahlen).
- Schwellen pro Tarif. Antwortzeit und Festplattennutzung unterscheiden sich je Kunde; halten Sie nach dem Go-Live eine
Basislinie pro Website fest (
exp:benchmark --save) und vergleichen Sie damit.
Checkliste
- To do: Eine externe HTTP-Prüfung deckt die Website und die Anmeldeseite der Administration ab.
- To do:
exp:systeminfo, der Cache-Status, die Prüfung des Audits und die Festplatte werden nach Zeitplan per Exit-Code geprüft. - To do: Die Cron-Logs sind aktuell, und
crontab:listzeigt die erwarteten Zeilen. - To do: Die Dashboard-Ansichten von Velocity sind nur lokal oder durch ein Token geschützt.
- To do: Die Empfänger von Alarmen des Audits sind mit dem Kunden vereinbart.
- To do: Jemand liest wöchentlich die Fehlerübersicht und
security.log.
Verwandte Seiten
- Zustandsprüfungen und Verfügbarkeit
- Log-Viewer und Log-Rotation
- Anfrage-Logs, Sicherheitslog
- Benchmark einer gehosteten Website
- Langsame Website, Website nicht erreichbar (Runbooks)
- Freie Dokumentation: Diese Seite darf unter der GNU FDL 1.3 frei kopiert, übersetzt und verbessert werden.
Werden Sie Exponential-Partner
Partner teilen ihre Informationen, stellen Mittel bereit, geben Beiträge zurück und entwickeln die Produkte mit uns, und so wächst Exponential. Eine Partner-Website und ein Dashboard sind für Mitte 2027 geplant: Werden Sie noch heute Partner, damit wir schneller wachsen und neue Funktionen früher liefern.