Agents & collectors¶
Vesana has three monitoring modes for gathering data:
| Component | Where | What |
|---|---|---|
| Agent | On the monitored machine | Local checks: CPU, RAM, disk, service status, logs, custom scripts |
| Collector | Linux VM in customer network | Remote checks: SNMP, ping, SSH, HTTP, discovery |
| Active collector | On the Vesana machine itself (more on separate machines possible) | The server checks by itself — for checks that don't need a dedicated customer VM |
All three are push-based — no inbound ports on monitored devices, no inbound from server to customer network.
When agent¶
- Linux/Windows servers where you can install software
- Workstations
- Container hosts (Docker, Podman)
- Anywhere local data is needed (service status, event log, per-mount disk)
When collector¶
- Switches, routers, firewalls, UPSes, storage — anything reachable only via SNMP/ping
- „We can't install anything there"
- Discovery scans
- When monitoring an isolated network (collector is the only outbound talker)
When active collector¶
The active collector is the third mode: instead of a VM in the customer network, the Vesana server itself runs the checks. Useful for:
- Checks against externally reachable targets where a dedicated customer VM isn't worth it
- A quick start without rolling out a collector at the customer first
- Environments where no collector exists (yet)
The active collector works across all tenants. Besides the one on the Vesana machine you can add more (on another machine or as an additional instance on the Vesana server); active checks are then distributed among them per device. Details: Active collector.
When both¶
Combined is fine and common:
- Linux server: agent for local stuff, collector for ping (sees if routing works)
- Storage: collector for SNMP, agent (on a server nearby) for pings
Architecture comparison¶
flowchart TB
subgraph "Customer network"
S1[Server with agent]
S2[Server with agent]
SW[Switch via SNMP]
UPS[UPS via SNMP]
C[Collector VM]
SW -.SNMP.-> C
UPS -.SNMP.-> C
end
subgraph "Vesana server"
R[Receiver]
AC[Active collector]
end
S1 -->|HTTPS POST| R
S2 -->|HTTPS POST| R
C -->|HTTPS POST| R
AC -->|checks directly| R
In this section¶
-
Installation, configuration, systemd / Windows service, token rotation, troubleshooting.
-
One-command installer, distros, discovery prerequisites.
-
The server checks by itself — setup, instant checks, additional active collectors.
-
Automatic, signed updates of agent and collector.
-
Changing the server URL & agent gateway
Server migration, pending-URL workflow, separate machine port for agents/collectors.