Internetlinien überwachen¶
Der Check „Internetlinie (Speedtest)" (internet_line) misst eine Internetlinie aktiv durch und beantwortet die Fragen, die sonst erst beim Kundenanruf auftauchen: Kommt an, was bezahlt wird? Wird die Leitung unter Last träge? Fliegt sie nachts raus?
Was gemessen wird¶
Jede Messung läuft in drei Phasen (insgesamt ~30–40 s):
- Ruhe-Ping — Basis-Latenz, Jitter, Paketverlust
- Download — NDT7-Speedtest; parallel wird weiter gepingt → aus dem Latenz-Anstieg unter Last entsteht die Bufferbloat-Note A+–F (erklärt „Videocall ruckelt, obwohl der Speedtest gut aussieht")
- Upload — NDT7-Speedtest, server-seitig gezählt
Zusätzlich wird die öffentliche IP der Linie erfasst — IP-Wechsel = Reconnect, sichtbar als Zeitleiste.
Einrichtung¶
- Host anlegen mit Profil „Internetlinie" (bringt die Visualisierung mit), oder bei einem bestehenden Host die Geräte-Visualisierung „Internetlinien-Panel" wählen.
- Pro Linie einen Check „Internetlinie (Speedtest)" hinzufügen — Ausführung Collector (ein Collector im Kundennetz misst dessen Linie) oder Active-Checker (der Vesana-Server misst seine eigene; bei mehreren Aktiven Collectors misst immer der primäre).
- Am Check die gebuchte Bandbreite hinterlegen (Down/Up in Mbit/s). Ohne Sollwert entfällt die Bewertung gegen das Soll — eine tote Linie meldet der Check trotzdem als CRITICAL, eine gescheiterte Messung als UNKNOWN.
Mehrere Linien an einem Standort = mehrere Checks auf demselben Host. Ein Collector führt immer nur eine Linienmessung gleichzeitig aus (über alle Hosts), damit sich die Messungen nicht gegenseitig verfälschen. Wartet eine Messung länger als 60 Sekunden, wird sie mit UNKNOWN „Messung ausgelassen" übersprungen.
Bewertung¶
| Zustand | Bedeutung |
|---|---|
OK |
schlechtester Wert (Down oder Up) mindestens auf der WARNING-Schwelle — oder kein Soll hinterlegt |
WARNING |
schlechtester Wert unter „WARNING unter % vom Soll" (Vorgabe 70 %) |
CRITICAL |
schlechtester Wert unter „CRITICAL unter % vom Soll" (Vorgabe 50 %) — oder Linie komplett tot (Ping UND Messung fehlgeschlagen) |
UNKNOWN |
Linie erreichbar, aber die Messung scheitert (z. B. M-Lab-Störung) — bewusst kein Fehlalarm |
Weitere Felder: Ping-Ziel (Vorgabe 1.1.1.1, für Ruhe-Ping und Ping unter Last) und Eigener ndt-Server (siehe unten).
Das Linien-Panel¶
Auf der Host-Seite unter Gerät zeigt das Panel pro Linie: Soll/Ist für Down und Up mit Verlaufs-Sparkline, Bufferbloat-Note, Ping Ruhe→Last, Jitter, Paketverlust, öffentliche IP mit Reconnect-Zeitleiste (30 Tage) — und ab 12 Messpunkten eine Tageszeit-Heatmap des Downloads der letzten 7 Tage („abends bricht die Leitung ein" auf einen Blick).
Datenvolumen & Intervall¶
Eine Messung überträgt je nach Linie einige hundert MB. Deshalb:
- Default-Intervall 6 h (4 Messungen/Tag) — bewusst grob wählen
- Eingebauter Schutzboden: der Check läuft planmäßig nie öfter als alle 15 min, egal wie er konfiguriert wurde (ein manuelles „Jetzt prüfen" ist davon ausgenommen)
- Bei Volumen-Tarifen (LTE/5G-Backup!) Intervall weiter strecken, z. B. 24 h
Eigener Messserver¶
Standardmäßig sucht der Check automatisch den nächstgelegenen M-Lab-Server. Wer keine Fremd-Infrastruktur will, trägt unter Eigener ndt-Server einen self-hosted ndt-server ein — dann bleibt die Messung komplett im eigenen Haus.
Misst der Vesana-Server selbst (Active-Checker), dürfen ndt-Server und Ping-Ziel nicht in die internen Netze des Vesana-Servers zeigen — außer der Check wurde von einem Super-Admin gespeichert oder interne Ziele sind für den Tenant freigegeben. Sonst meldet der Check UNKNOWN (SERVER_INTERNAL_TARGET). Für Messungen über einen Collector im Kundennetz gilt das nicht.