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 it is mostly called Active checker ("Active-Checker" in some places) — as the admin tab and as the execution path in host and check dialogs; the Agent Lock overview calls it "Active collector (Vesana server)". 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.
- One or several: additional Active Collectors — on this or another machine — share the checks (see Several Active Collectors).
- 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 / Installed · 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). 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.
Discovery settings only for super admins¶
The Active Collector applies to the whole instance. Its discovery settings — DNS servers, SNMP communities, subnet exclusions, manual subnets and network labels — can therefore only be changed by super admins; other accounts are refused on save (403), even with the permission to edit collectors. For regular collectors the tenant permission still applies. On instances with one tenant whose admin is a super admin nothing changes.
On instances with several tenants, also: networks the Active Collector knows itself (interfaces, routes, ARP, LLDP) are visible only to accounts with access to all tenants; everyone else sees only networks from scans of their own tenant. Scans, schedule and "Scan all" via the Active Collector belong to the user's tenant and need its server approval (see above). The Active Collector learns SNMP communities from scans only if the instance has exactly one tenant.
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.
Several Active Collectors¶
One Active Collector uses all cores of its machine. If that is not enough — the page then shows "Cannot keep up" and the instance health names the reason — add another one. Every active check then belongs to exactly one Active Collector; checks are assigned per device, all checks of a device run on the same one.
Adding: Admin → Agents & Collectors → Active checker → Add active collector. You choose where it runs:
- Another machine — the usual way. The command verifies the server certificate with a pin (also for a self-signed certificate) and runs as root on the new machine. The machine must reach the same targets as the server — every Active Collector can get any active check.
- This server (another instance) — a second service
(
vesana-active-collector-<name>) on the Vesana machine. Rarely worth it, because one Active Collector already uses all cores.
A new Active Collector gets its share once it has been running for 5 minutes without interruption; until then the others keep checking. The only exception: when all of them start together (first installation, return after a longer server outage), those starting within one minute share the checks right away. The list shows, per Active Collector, its state (online, starting, offline), how many devices and checks it currently runs, whether it keeps up, and its machine.
The primary (marked in the list, normally the one on the Vesana machine) also runs what is tied to the server: discovery scans, network finding, the internet line and local plugins. If it fails, these checks run in the server fallback (see below) — the others take over the remaining checks. "Make primary" moves the role; the primary itself cannot be removed.
Failure and return:
- If an Active Collector does not report for 2 minutes, the others take over
its checks. After 3 minutes the diagnose log shows
active_collector_offline(who took over), and the admin overview names the reason. Checks with a very short interval can briefly show "No Data" during this time — the data really was missing. - When it returns, it gets its share back only after 5 minutes without interruption; an Active Collector that keeps dropping out does not shuffle checks back and forth.
- If an Active Collector loses its connection to the server, it stops checking: an additional one after 90 seconds (before another one takes over), the primary after 2½ minutes (shortly after another one has taken over) — no device is checked twice for long. With only one Active Collector (or distribution switched off) it always keeps checking.
"Check now" goes to the Active Collector the check belongs to.
Agent Lock applies per Active Collector: every machine (and every instance) has its own approval.
Removing: the others take over its checks immediately, its key stops working. Remove the service on the machine itself — the installer prints the complete command at the end. For the default instance:
sudo systemctl disable --now vesana-active-collector-update.path vesana-active-collector
sudo rm -f /etc/systemd/system/vesana-active-collector.service \
/etc/systemd/system/vesana-active-collector-update.{path,service}
sudo systemctl daemon-reload
sudo rm -rf /var/lib/vesana-active-collector /etc/vesana-active-collector /opt/vesana-active-collector
For an additional instance, append -<name> to every name.
Server-internal addresses on additional Active Collectors: an additional Active Collector blocks the same targets as the server for checks without a super-admin release — the server's networks (reported to it by the primary) and the networks of its own machine (loopback, its own addresses, local subnets). It therefore checks devices in the local network of the second machine only with checks a super admin saved. It knows the server's networks only through the primary: if the primary does not run on the Vesana machine (for example after "Make primary" for a remote one), it reports the networks of ITS machine — the Vesana server's networks are then no longer blocked for the others. The primary therefore belongs on the Vesana machine.
Emergency switches¶
Both switches are system settings and take effect within seconds, without a restart. Distribution can also be switched off in the list.
| Key | Value for "as before" | What it does | When to switch back |
|---|---|---|---|
active_collector_sharing_enabled |
false |
Off: only the primary runs all active checks, additional Active Collectors get none. | When checks do not work on another machine (different network, missing reachability) or the diagnose log shows ac_result_not_responsible. |
collector_native_ping_enabled |
false |
Ping checks use an ICMP socket of the collector instead of the ping program — same result, much less load. Off: back to the program. Applies to all collectors from this version on. |
When ping values look different after the update. If the operating system does not allow the socket, the collector falls back to the program by itself and reports collector_ping_fallback in the diagnose log. |
INSERT INTO system_settings (key, value) VALUES ('active_collector_sharing_enabled', 'false')
ON CONFLICT (key) DO UPDATE SET value = EXCLUDED.value;
When the Active Collector is offline (server fallback)¶
If no Active Collector is online (with several: none of them), the server itself takes over part of the checks:
- Ping, port, HTTP and HTTP JSON, simple SNMP values (
snmp,snmp_string,snmp_interface) and SSH checks (CPU, RAM, disk, command/script, process, service) keep running via this fallback — reduced, but not down. Server approval and the block on server-internal addresses apply here too. - Check types only the collector binary can run (e.g. SNMP walks and tables, SSL certificate, vSphere, internet line, plugins) 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¶
- Several Active Collectors share the checks by device, not by network: each must be able to reach all targets. For networks that are only reachable from a specific place, a regular collector is the right choice.
- 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.