Server-Monitoring
CPU, RAM, Festplatte, laufende Dienste und Sicherheits-Updates Ihrer Server im Blick — mit einem einzigen Installationsbefehl.
Agent installieren
Im Dashboard unter Monitoring → Server auf „Server hinzufügen" klicken. Vergeben Sie einen Namen (z. B. „Webserver Produktion").
Nach dem Speichern wird ein Installations-Befehl angezeigt:
curl -sL __APP_DOMAIN__/api/monitoring/install.sh | bash -s -- IHR_TOKEN
Diesen Befehl in das Terminal Ihres Servers eingeben. Das Skript installiert den Agenten und richtet einen Cronjob ein.
Nach ca. 1–2 Minuten erscheint der Server in der Übersicht mit Status „Aktiv". Sie sehen sofort die ersten Metriken.
Welche Metriken werden erfasst?
System-Ressourcen
- CPU-Auslastung — aktueller Prozentsatz, gemittelt über 1 Sekunde Messzeit
- Arbeitsspeicher (RAM) — genutzt / gesamt in MB, Auslastung in %
- Festplatten — alle echten Dateisysteme (z. B.
/,/var/www,/boot) mit genutzt / gesamt und Auslastung in %; ohne tmpfs, Overlay und andere Pseudo-Dateisysteme. Die Alarm-Schwelle gilt für das am stärksten belegte Dateisystem - Top-Prozesse — die acht Programme mit der höchsten CPU-Last (je Programmname zusammengefasst) samt RAM-Anteil, nur der letzte Stand
- System-Load — Last-Durchschnitt über 1, 5 und 15 Minuten
- Uptime und Prozessanzahl
- Netzwerk — empfangene / gesendete Daten in MB
GPU-Monitoring (KI-Server)
Hat der Server eine GPU, meldet der Agent sie automatisch mit — NVIDIA über nvidia-smi (Treiber muss installiert sein), AMD über die Kernel-Schnittstelle unter /sys/class/drm (Auslastung, VRAM, Temperatur, Leistung soweit vom Treiber geliefert), unter Windows NVIDIA. Im Menüpunkt GPU sehen Sie je GPU Auslastung, VRAM, Temperatur und Leistung sowie drei Verlaufsdiagramme mit einer Linie je GPU. Ohne GPU erscheint der Menüpunkt nicht. Die Kachel „GPU“ in der Übersicht färbt sich nach der Temperatur (ab 80 °C Warnung, ab 90 °C kritisch); hohe Auslastung gilt bei KI-Servern als Normalbetrieb und löst keine Warnfarbe aus. Alarm-Schwellen für GPUs gibt es noch nicht.
Dienste überwachen
Der Agent meldet alle laufenden Dienste (systemd) und den Zustand der Dienste, die Sie ausdrücklich überwachen. Im Menüpunkt Dienste der Server-Detailseite wählen Sie aus der Liste der laufenden Dienste (oder tragen den Namen ein, z. B. nginx, mariadb, php8.2-fpm), was laufen muss:
- Alarm, wenn ein überwachter Dienst in zwei aufeinanderfolgenden Meldungen nicht läuft (kurze Neustarts lösen keinen Alarm aus). Zustände: gestoppt, fehlgeschlagen, nicht gefunden.
- Entwarnung, sobald der Dienst wieder läuft.
- Die Alarme gehen über dieselben Kanäle wie alle Server-Alarme (E-Mail, SMS, Slack, Teams, Discord, Webhook, je nach Paket).
- Die Dienst-Überwachung ist ab Monitor Basic enthalten (höchstens 30 Dienste je Server).
Unter Windows erscheinen die Windows-Dienste (Name wie in Get-Service, z. B. W3SVC).
Momentaufnahme bei Alarmen
Jeder Alarm für Auslastung, Dienste oder Erreichbarkeit enthält eine Momentaufnahme: Last (1 / 5 / 15 Minuten, mit Kernzahl), CPU, RAM, Festplatten und die Top-Prozesse nach CPU und nach Speicher zum Alarmzeitpunkt. So sehen Sie direkt, was die Last verursacht hat (z. B. ein Webserver-Prozess oder ein Backup), ohne sich erst auf dem Server anmelden zu müssen. Die Momentaufnahme steht in der Alarm-Mail, in Chat-Meldungen (Slack, Teams, Discord) und im Alarm-Protokoll des Servers. Bei einem Ausfall zeigt sie den letzten Stand vor dem Ausfall (mit Angabe, wie alt er ist), weil der Server dann nichts mehr melden kann. Verfügbar ab Agent 1.4.7 (Linux) bzw. 1.3.6 (Windows); die Top-Prozesse stammen vom letzten Agenten-Bericht.
Sicherheits-Updates
Der Agent zählt ausstehende Sicherheits-Updates auf Debian/Ubuntu, RHEL/AlmaLinux/Rocky, SUSE, Alpine und Windows. Auf Systemen mit Sicherheitshinweisen (RHEL-Familie, SUSE, Windows) wird nach Hinweisen (Advisories bzw. KB-Nummern) gezählt, nicht nach einzelnen Paketen – so entsteht keine künstlich hohe Zahl durch Abhängigkeiten. Der Kernel wird getrennt ausgewiesen (laufende und verfügbare Version); ist Live-Patching aktiv (KernelCare/Imunify360, Canonical Livepatch, kpatch), zählen Kernel-Hinweise nicht als offen. Auf der Seite „Sicherheit“ sehen Sie die Liste der offenen Hinweise, die Zählweise und einen eventuell nötigen Neustart. Die Prüfung läuft alle 6 Stunden. Zusätzlich werden bekannte Kernel-Schwachstellen (CVE) zur Kernel-Version angezeigt.
Alerts konfigurieren
Über das Regler-Symbol in der Kopfzeile der Server-Detailseite setzen Sie Schwellenwerte für Warnung und Kritisch:
- CPU, RAM, Festplatte (%) und Load (5 Min.)
- Offline-Erkennung — Alarm, wenn der Agent länger als X Minuten keine Daten sendet (Standard 10 Minuten; Server down oder Agent ausgefallen)
- Dienste — siehe oben (pro Dienst, ohne Schwellenwert)
Die Empfänger legen Sie über das Glocken-Symbol fest. Jede Alarm-Mail enthält einen Abmelde-Link für den jeweiligen Empfänger.
Benachrichtigungen konfigurieren →
Detail-Ansicht
Die Server-Detailseite hat ein Seitenmenü; jeder Menüpunkt öffnet seine eigene Ansicht (der Link bleibt teilbar, z. B. …/server-detail.html?id=…#disk). Oben rechts neben der Überschrift führt Monitoring zurück zur Serverliste.
- Übersicht — Ampel-Kacheln für Status, CPU, RAM, Festplatte, Load, Dienste, Sicherheits-Updates und Agent plus ein Gesamtzustand (das schlechteste Ergebnis); Klick auf eine Kachel öffnet die Details. Letzte Alarme darunter.
- CPU — Verlauf der CPU-Auslastung, dazu die Top-Prozesse
- Load — Load Average (1 / 5 / 15 Minuten) in eigenem Diagramm, mit Kernzahl und „Last je Kern“ (eine Last in Höhe der Kernzahl ist volle Auslastung)
- Alarme — Protokoll aller Alarme und Entwarnungen dieses Servers (auch „Server neu gestartet“, erkannt an der zurückgesetzten Betriebszeit) (auch Ausfälle und Spam-Listen); Alarme, zu denen eine Entwarnung kam, tragen das Kennzeichen „behoben“; bei Alarmen mit Kamera-Symbol die Momentaufnahme
- GPU (nur mit GPU) — Tabelle und Verläufe je GPU
- Speicher — RAM-Verlauf, aktuelle Belegung (belegt / verfügbar / gesamt mit Balken) und Top-Prozesse nach Speicherverbrauch
- Festplatte — alle Dateisysteme mit Balken, dazu Verlauf der Hauptpartition
- Netzwerk — RX/TX-Verlauf
- Dienste — überwachte Dienste mit Zustand; darunter eine sortier- und durchsuchbare Tabelle aller laufenden Dienste mit Beschreibung, Laufzeit, Speicherverbrauch und Autostart, aus der Sie Dienste per Klick in die Überwachung aufnehmen
- Sicherheit — ausstehende Updates, Betriebssystem/Kernel, Kernel-CVEs, Blacklist-Prüfung der öffentlichen IP
- Agent — Version, Update-Status, Befehle zum manuellen Installieren, Aktualisieren und Entfernen
Die Verläufe bieten Zeiträume von 1 Stunde bis 1 Jahr — je nach Paket sind längere Zeiträume verfügbar.
Meldeintervall
Der Agent meldet sich standardmäßig im Intervall Ihres Pakets: Monitor Free alle 5 Minuten, Monitor Basic jede Minute, Monitor Pro, Monitor Business, Agentur und Agentur Pro bis herunter auf 30 Sekunden (Windows: mindestens jede Minute). Im Menüpunkt Agent wählen Sie für jeden Server ein eigenes Intervall (30 Sekunden, 1, 3, 5, 10 oder 15 Minuten), nie kürzer als das Paket erlaubt. Der Offline-Alarm wartet mindestens drei Meldeintervalle ab, bevor er auslöst.
Neustart-Erkennung und Alarm-Momentaufnahme
Springt die Betriebszeit zurück, protokollieren wir „Server neu gestartet“ und melden es über Ihre Kanäle, auch wenn der Neustart zu kurz für einen Offline-Alarm war. Jeder Alarm trägt eine Momentaufnahme (Last, CPU, RAM, Festplatte, Top-Prozesse); bei Ausfällen den letzten bekannten Stand mit Altersangabe.
Agent-Updates
Der Agent meldet seine Version bei jedem Heartbeat. Gibt es eine neuere Version (Linux: 1.5.0, Windows: 1.5.0), antwortet der Server mit update_available: true; der Agent lädt den Installer erneut und ersetzt sich selbst. Schlägt das fehl, steht der Grund im Fehlerprotokoll /opt/auditcollector-agent/error.log, und Sie können im Menüpunkt Agent den Befehl für die manuelle Aktualisierung kopieren. Der Windows-Agent (aktuell 1.3.4) aktualisiert sich ab dieser Version ebenfalls selbst: Er ersetzt nur seine Skriptdatei, die geplante Aufgabe bleibt unverändert, ein Fehlversuch wird höchstens alle 6 Stunden wiederholt und steht in %ProgramData%\auditcollector-agent\error.log. Ältere Windows-Agenten (1.3.0 und früher) müssen Sie einmal von Hand aktualisieren, indem Sie den Installationsbefehl erneut ausführen.
Fehlgeschlagene Updates: Scheitert ein Selbst-Update (z. B. Download oder Installer), meldet der Agent beim nächsten Heartbeat den Grund. Sie sehen ihn im Menüpunkt Agent der Server-Seite und bekommen einen Alarm über Ihre Benachrichtigungskanäle; der Betreiber von EMPEDIAcloud erhält zusätzlich eine E-Mail mit Server, System, Version und Fehlertext. Der Agent läuft mit der alten Version weiter und versucht es frühestens nach 6 Stunden erneut.
Server und Agent entfernen
Entfernen Sie den Server im Dashboard (Papierkorb-Symbol in der Liste oder auf der Detailseite). Der Dialog weist darauf hin: Der Agent wird dabei automatisch mit deinstalliert. Der Server verschwindet sofort aus der Liste und löst keine Alarme mehr aus; sobald sich der Agent das nächste Mal meldet (meist innerhalb weniger Minuten), entfernt er sich selbst (Cron-Eintrag bzw. geplante Aufgabe und Programmordner). Ein Server, der sich noch nie gemeldet hat, wird sofort vollständig gelöscht.
Ist der Server ausgeschaltet oder nicht erreichbar, entfernt sich der Agent später von allein: Erkennt er, dass sein Token nicht mehr bekannt ist, deinstalliert er sich nach mehr als 24 Stunden und mindestens 5 Fehlversuchen. Wer es sofort will, entfernt ihn manuell auf dem Server:
curl -sL https://empedia.cloud/api/monitoring/install.sh | sudo bash -s -- --uninstall
Windows (PowerShell als Administrator):
irm https://empedia.cloud/api/monitoring/install.ps1 | iex; Uninstall-AuditCollectorAgent
Die Befehle mit Ihrer Domain zeigt der Entfernen-Dialog und der Menüpunkt Agent an.
Voraussetzungen
- Linux (Debian 10–12, Ubuntu 18.04–24.04, CentOS 7/8, AlmaLinux/Rocky 8/9, RHEL, SUSE, Alpine …) oder Windows Server (PowerShell 5.1+)
curl,bashundawk; Auf Systemen mit systemd läuft der Agent als systemd-Timer (Status mitsystemctl status auditcollector-agent.timer, Logs mitjournalctl -u auditcollector-agent), sonst per Cron (wird bei Bedarf automatisch nachinstalliert). Ältere Cron-Installationen stellen sich beim Selbst-Update automatisch auf den Timer um.opensslist optional (signierte Meldungen)- Ausgehende HTTPS-Verbindungen (Port 443) müssen erlaubt sein — es wird kein Port geöffnet
- Die Installation und Entfernung brauchen root bzw. Administrator-Rechte; der Agent läuft anschließend per
/etc/cron.dund liest nur Systemwerte (kein Zugriff auf Inhalte)