Agents & collectors¶
Vesana has two ways to gather 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 |
Both 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 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]
end
S1 -->|HTTPS POST| R
S2 -->|HTTPS POST| R
C -->|HTTPS POST| R
In this section¶
-
Installation, configuration, systemd / Windows service, token rotation, troubleshooting.
-
One-command installer, distros, discovery prerequisites.
-
Auto-update mechanism, VERSION file, rollout pause, NSIS wizard.