Active Collector (Active checker)¶
The Active Collector is the third monitoring mode: instead of a Linux VM in the customer network, the Vesana server itself runs the checks. Technically it is the same collector binary as the regular collector — it just runs as its own service directly on the Vesana machine. In the UI you meet it under two names: the admin tab is called Active checker, host dialogs say "Active Collector (server probes itself)". It used to be called check executor.
Properties¶
- Server-global, across tenants: one Active Collector serves checks of all tenants of the instance. It therefore never appears as a collector of a tenant and does not use up any collector quota.
- At most one per instance.
- Never selectable as a host's collector. A host without an assigned collector automatically runs via the Active Collector; a collector that is removed or deleted hands its hosts over to it and their checks keep running (from v1.9.437 also on deletion — before, they stayed on No Data).
- Short poll cycle (2 seconds for immediate jobs) — this polling counts as a heartbeat, so the Active Collector is not considered offline after two minutes without a result.
When it makes sense¶
- Checks against targets the server itself can reach (websites, DNS, certificates, devices in the server's network).
- Fast start: checks run from day one without rolling out a collector at the customer first.
- As a complement while no dedicated collector exists (yet) — once there is one, move hosts over individually.
Setup¶
Admin → Agents & Collectors → Active checker shows the status (Not installed / Online / Offline) and a 7-day availability bar. The tenant page and the host detail show the same bar with the same rating (from v1.9.437) — periods without a verdict, for example before the first heartbeat of a freshly created collector, stay neutral grey instead of wrongly green; without a single verdict it reads "—".
On freshly installed instances the Active Collector sets itself up as soon as the setup wizard is finished — "Start Vesana" even waits until it is running. If that fails, the page shows a banner with the waiting or error state and retries at regular intervals. Manual setup is always available at the press of a button: the page creates the collector record, shows the API key once in plain text and provides the install snippet for the Vesana machine.
The Active Collector updates itself — even when Vesana does not run on port 443 (it uses the address under which it demonstrably reaches the server).
Allowing server-side checks per tenant¶
From v1.9.437 the super admin decides per tenant what may run on the server — two switches per tenant under Admin → Agents & Collectors → Active checker:
| Switch | Effect |
|---|---|
| Network checks via the server | Checks in Active checker mode (ping, HTTP, SNMP, SSH …) for users of this tenant |
| Custom plugins on the server | Script/command checks that execute custom code on the Vesana machine |
- Instances with a single tenant are approved automatically; super admins are never restricted — the approval applies to all other users of the tenant.
- Checks that existed before this rule was introduced keep running unchanged — they count as set up by the operator (from v1.9.444; in v1.9.437–443 they went Unknown after the update on instances with several tenants).
- Without approval Vesana rejects creating or changing such checks immediately with a clear message (wizard, editor, bulk edit, Automatic Setup). A blocked check does not run and reports the reason as Unknown; the check detail shows the way to the approval.
- Before switching off, the page states the number of affected checks; every change is written to the audit log. Under Default for new tenants you define what newly created tenants may do from the start.
- Server-internal addresses (loopback, Docker networks, own interface addresses) are blocked for non-privileged checks — unless the check was saved by a super admin (this is then shown on the check). A dedicated collector in the customer network still probes its own network without restriction.
Immediate checks¶
"Check now" works with the Active Collector just like with agent and regular collector: the job arrives within seconds and the result appears directly in the panel. For long measurements (e.g. the internet line speed test) "still running …" stays visible until the result is in; "Check now" is locked meanwhile. If the Active Collector does not respond, Vesana shows this as "not reachable" — distinguishable from a running measurement.
When the Active Collector is offline (server fallback)¶
If no Active Collector is online, the server itself takes over part of the checks:
- Ping, HTTP, SNMP standard values as well as SSH script, process and service checks keep running via this fallback — reduced, but not down.
- Check types only the collector binary can run (e.g. special SNMP walks, internet line) go to Unknown with a clear message as long as no Active Collector is running.
As soon as it is back online it takes over the affected checks automatically — no double execution, no manual switching.
Warning: regenerating the API key disconnects immediately¶
Never regenerate the API key without an immediate plan
When the Active Collector's API key is regenerated, the old key is deactivated immediately — the running service loses its connection at once until the new key is entered on the machine and the service restarted. Only regenerate the key if you have access to the Vesana machine right afterwards. The same applies to API keys of regular collectors.
Limits¶
- Only one Active Collector per instance — no cluster.
- It sees the network from the server's point of view, not from the customer network. For checks that need the customer network's view, the regular collector remains the right choice.