Was gemessen wird
Der Agent erhebt eine bewusst kurze, kuratierte Liste von Kennzahlen -- keine tausend Metriken, sondern die, die dir bei einem Ausfall tatsächlich weiterhelfen. Alle stammen aus den Statistik-Schnittstellen des Kernels; keine liest Inhalte deiner Anwendungen. Details dazu unter Sicherheit & Transparenz.
Wie oft gemessen wird
Der Agent tastet die Werte im Sekundentakt-Bereich ab und schickt sie gebündelt im Report-Intervall an LIVCK. Das Intervall stellst du je Server ein: Server → Server öffnen → Bearbeiten → Konfiguration → Report-Intervall.
| Plan | Kürzestes Report-Intervall |
|---|---|
| Free | 120 Sekunden |
| Ab Solo-Plan Solo | 60 Sekunden |
| Ab Team-Plan Team | 30 Sekunden |
| Ab Business-Plan Business | 30 Sekunden |
Länger geht bis zu einer Stunde. Kürzere Intervalle bedeuten feinere Diagramme und schnellere Alarme -- der Ressourcenverbrauch auf dem Server ändert sich dadurch praktisch nicht.
Kurze Ausfälle gehen nicht verloren
Erreicht der Server LIVCK vorübergehend nicht, puffert der Agent die Messwerte und liefert sie nach, sobald die Verbindung zurück ist. Auch ein sauberer Neustart geht nicht verloren -- der Puffer wird vor dem Beenden auf die Platte geschrieben.
Prozessor & Systemlast
| Messwert | Was er dir sagt |
|---|---|
| CPU-Auslastung gesamt | Wie ausgelastet der Prozessor ist -- der wichtigste Einzelwert |
| User / System / I/O-Wait | Wofür die CPU-Zeit draufgeht: eigene Programme, Kernel, oder Warten auf die Festplatte. Hoher I/O-Wait heißt: nicht die CPU ist das Problem, sondern der Speicher |
| Steal | Wie viel CPU-Zeit dir dein Virtualisierungs-Host wegnimmt. Dauerhaft hohe Werte heißen: dein Cloud-Nachbar ist zu laut |
| Systemlast 1 / 5 / 15 Min. | Wie viele Prozesse im Schnitt auf Ausführung warten -- der klassische Load Average |
| Prozesse gesamt / Zombies | Anzahl laufender Prozesse; viele Zombie-Prozesse deuten auf eine fehlerhafte Anwendung hin |
| Laufzeit | Wie lange der Server ohne Neustart läuft |
Der Agent sammelt keine Prozessdaten
Er zählt Prozesse, liest aber weder Namen noch Kommandozeilen. Eine „Top-Prozesse"-Liste gibt es bewusst nicht.
Arbeitsspeicher
| Messwert | Was er dir sagt |
|---|---|
| Belegt / Verfügbar / Gesamt | Die Grundwerte. Achte auf verfügbar, nicht auf belegt -- Linux nutzt freien Speicher absichtlich als Cache |
| Cache / Puffer | Der Anteil, den der Kernel jederzeit wieder freigeben kann |
| Belegung in Prozent | Der Wert, auf den du üblicherweise eine Alarm-Regel setzt |
| Out-of-Memory-Kills | Wie oft der Kernel einen Prozess wegen Speichermangel abgeschossen hat. Steigt der Zähler, gibt es zusätzlich ein Ereignis |
| Swap gesamt / belegt / in Prozent | Wandert dein System in den Swap, wird alles langsam -- oft der frühere Hinweis als die reine Speicherbelegung |
Ressourcen-Druck (PSI)
Die Pressure Stall Information des Linux-Kernels misst, wie viel Zeit Prozesse mit Warten verbringen -- auf CPU, auf Speicher, auf die Festplatte. Sie zeigt Engpässe oft früher als reine Auslastungswerte: Eine CPU kann zu 100 % ausgelastet sein, ohne dass jemand wartet -- und bei 70 % kann trotzdem alles hakeln.
Erfasst wird der Druck auf CPU, Arbeitsspeicher und I/O.
Nicht überall verfügbar
PSI braucht einen Kernel ab Version 4.20. Auf RHEL 9 und dessen Ableitungen ist es zwar einkompiliert, aber standardmäßig deaktiviert -- es lässt sich mit dem Kernel-Parameter psi=1 und einem Neustart einschalten. Fehlt PSI, bleiben diese Werte einfach leer; alles andere funktioniert normal.
Festplatten
| Messwert | Was er dir sagt |
|---|---|
| Belegung je Einhängepunkt | Belegt, gesamt und in Prozent -- für jede eingehängte Partition getrennt |
| Inode-Belegung | Der zweite Weg, eine Platte vollzumachen: viele winzige Dateien. „No space left on device" bei 60 % Belegung kommt daher |
| Lesen / Schreiben je Laufwerk | Durchsatz in Byte pro Sekunde |
| IOPS je Laufwerk | Lese- und Schreiboperationen pro Sekunde -- die eigentliche Grenze bei Datenbanklast |
Der Agent überspringt automatisch Pseudo- und Netzwerkdateisysteme und meldet sys.agent.stuck_mounts, wenn ein Einhängepunkt nicht mehr antwortet -- ein zuverlässiger Frühwarnwert für hängende NFS-Mounts.
Läuft eine Partition vollständig voll oder wird ein Dateisystem schreibgeschützt umgehängt, erzeugt der Agent zusätzlich ein Ereignis.
Netzwerk
Je Netzwerkschnittstelle:
| Messwert | Was er dir sagt |
|---|---|
| Empfangen / Gesendet | Durchsatz in Byte pro Sekunde |
| Empfangsfehler / Sendefehler | Fehlerhafte Pakete pro Sekunde -- Hinweis auf defekte Kabel, überlastete Switches oder MTU-Probleme |
Die Loopback-Schnittstelle (lo) wird standardmäßig ausgelassen.
Grafikkarten (GPU)
Wird eine unterstützte GPU erkannt, misst der Agent zusätzlich Auslastung, belegten und gesamten Grafikspeicher, Temperatur und Leistungsaufnahme je Karte.
| Hersteller | Wie ausgelesen | Voraussetzung |
|---|---|---|
| NVIDIA | über nvidia-smi | Treiber und nvidia-smi müssen installiert sein |
| AMD | direkt aus /sys | keine zusätzliche Software nötig |
| Intel | derzeit nicht unterstützt | -- |
Findet der Agent keine unterstützte Karte, bleibt der Reiter Grafik in der Detailansicht leer und nennt den Grund.
Festplattengesundheit (SMART)
Ist smartctl auf dem Server installiert, liest der Agent die Gesundheitswerte deiner Laufwerke aus: Gesamtstatus, Temperatur, Abnutzung, verbleibende Reserveblöcke, reallozierte und schwebende Sektoren, Betriebsstunden, Einschaltzyklen, Medienfehler und kritische Warnungen.
SMART braucht in der Regel Root-Rechte
Der Agent läuft bewusst ohne Root-Rechte. Viele Laufwerke geben ihre SMART-Werte nur an einen privilegierten Prozess heraus -- dann bleibt der Reiter SMART leer, obwohl smartctl installiert ist. Die Detailansicht nennt dir den konkreten Grund (Werkzeug fehlt, keine unterstützten Laufwerke, Collector deaktiviert).
Erreichbarkeits-Prüfungen
Zusätzlich kann der Agent von deinem Server aus prüfen, ob andere Systeme antworten -- interne Datenbanken, Gateways, Registries oder DNS-Resolver. Gemessen werden Erreichbarkeit, Antwortzeit, Paketverlust, HTTP-Statuscode und Zertifikatsrestlaufzeit.
Das ist standardmäßig aus und wird pro Server konfiguriert: Erreichbarkeits-Prüfungen.
Der Agent über sich selbst
Damit du siehst, dass er sich benimmt: Arbeitsspeicherverbrauch, CPU-Anteil, Puffer-Füllstand und verworfene Reports. Im Normalbetrieb liegt der Verbrauch weit unter den harten Grenzen von 64 MB RAM und 40 % eines Kerns.
Server-Steckbrief
Einmalig bei der Anmeldung und danach bei Änderungen meldet der Agent: Betriebssystem und Version, Kernel, Architektur, CPU-Modell und Kernanzahl, RAM-Größe, Startzeitpunkt, Hostname, Agent-Version und ob ein Neustart aussteht. Diese Angaben findest du in der Detailansicht in der Karte Host.
Mengenbegrenzungen
Damit ein Server mit hundert Einhängepunkten die Diagramme nicht unlesbar macht, gelten Obergrenzen je Server:
| Kategorie | Höchstzahl |
|---|---|
| Einhängepunkte | 20 |
| Laufwerke (I/O) | 10 |
| Netzwerkschnittstellen | 10 |
| GPUs | 8 |
| Laufwerke (SMART) | 16 |
| Erreichbarkeits-Ziele | 15 |
Wie lange die Werte verfügbar sind
Frische Messwerte liegen in voller Auflösung vor. Ältere Zeiträume verdichtet LIVCK automatisch zu Stunden- und danach zu Tageswerten -- die Diagramme bleiben dadurch auch über 30 Tage flüssig, ohne dass Spitzen verloren gehen (Minimum, Maximum und Perzentile werden mit verdichtet).
Wie weit du zurückblicken kannst, richtet sich nach der Datenaufbewahrung deines Plans: 30 Tage (Free), 90 Tage (Solo), 180 Tage (Team), 365 Tage (Business).
Wo du die Werte siehst
- Live-Ansicht -- Sekundentakt, solange die Detailseite offen ist
- Detailansicht -- die letzten 60 Minuten plus Geräte-Reiter für Speicher, Grafik, SMART und Erreichbarkeit
- Analyse -- Langzeitdiagramme mit Perzentilen über 1 Stunde bis 30 Tage
- Alarm-Regeln -- jeder Messwert lässt sich als Schwellwert überwachen
- Statuspage -- ausgewählte Werte öffentlich zeigen
Weiterführende Themen
- Serverliste & Detailansicht -- wo welche Werte auftauchen
- Alarm-Regeln -- Schwellwerte auf diese Messwerte setzen
- Ereignisse & Benachrichtigungen -- Neustarts, OOM-Kills, volle Platten
- Erreichbarkeits-Prüfungen -- vom Server aus messen