Monitoring internet lines

The "Internet line (speed test)" check (internet_line) actively measures an internet line and answers the questions that otherwise only surface when the customer calls: Do we get what we pay for? Does the line choke under load? Does it drop at night?

What is measured

Each measurement runs in three phases (~30–40 s total):

1. Idle ping — baseline latency, jitter, packet loss
2. Download — NDT7 speed test; pinging continues in parallel → the latency increase under load becomes the bufferbloat grade A+–F (explains "video calls stutter although the speed test looks fine")
3. Upload — NDT7 speed test, counted server-side

The line's public IP is captured as well — an IP change means a reconnect, shown as a timeline.

Setup

1. Create a host with the "Internetlinie" profile (brings the visualization), or pick the "Internet line panel" device visualization on an existing host.
2. Add one "Internet line (speed test)" check per line — execution Collector (a collector in the customer network measures its line) or Active checker (the Vesana server measures its own line; with several active collectors the primary one always measures).
3. Set the booked bandwidth (down/up in Mbit/s) on the check. Without a target the evaluation against the target is skipped — a dead line is still reported as CRITICAL, a failed measurement as UNKNOWN.

Multiple lines at one site = multiple checks on the same host. A collector only ever runs one line measurement at a time (across all hosts) so the measurements don't distort each other. If a measurement has to wait longer than 60 seconds, it is skipped with UNKNOWN "measurement skipped".

Evaluation

State	Meaning
OK	worst value (down or up) at least at the WARNING threshold — or no target set
WARNING	worst value below "WARNING below % of target" (default 70 %)
CRITICAL	worst value below "CRITICAL below % of target" (default 50 %) — or the line is completely dead (ping AND measurement failed)
UNKNOWN	line reachable but the measurement fails (e.g. M-Lab outage) — deliberately no false alarm

Further fields: Ping target (default 1.1.1.1, for idle ping and ping under load) and Custom ndt server (see below).

The line panel

On the host page under Device, the panel shows per line: target/actual for down and up with history sparklines, bufferbloat grade, ping idle→load, jitter, packet loss, public IP with a reconnect timeline (30 days) — and from 12 data points on, a time-of-day heatmap of the download over the last 7 days ("the line degrades every evening" at a glance).

Data volume & interval

One measurement transfers several hundred MB depending on the line. Therefore:

• Default interval 6 h (4 measurements/day) — keep it deliberately coarse
• Built-in guard: on schedule the check never runs more often than every 15 min, no matter how it is configured (a manual "Check now" is exempt)
• On metered plans (LTE/5G backup!) stretch the interval further, e.g. 24 h

Own measurement server

By default the check automatically locates the nearest M-Lab server. If you don't want third-party infrastructure, enter a self-hosted ndt-server under Custom ndt server — the measurement then stays entirely in-house.

When the Vesana server measures itself (Active checker), the ndt server and ping target must not point into the Vesana server's internal networks — unless the check was saved by a super admin or internal targets are allowed for the tenant. Otherwise the check reports UNKNOWN (SERVER_INTERNAL_TARGET). This does not apply to measurements through a collector in the customer network.