Zum Inhalt

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):

  1. Ruhe-Ping — Basis-Latenz, Jitter, Paketverlust
  2. 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")
  3. Upload — NDT7-Speedtest, server-seitig gezählt

Zusätzlich wird die öffentliche IP der Linie erfasst — IP-Wechsel = Reconnect, sichtbar als Zeitleiste.

Einrichtung

  1. Host anlegen mit Profil „Internetlinie" (bringt die Visualisierung mit), oder bei einem bestehenden Host die Geräte-Visualisierung „Internetlinien-Panel" wählen.
  2. 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).
  3. 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.