Most monitoring tools were built for one network: the server sits in the middle and polls every device. That works in your own office. As soon as you look after several customers or branch offices, it means a VPN or open firewall ports into every one of those networks — each with its own credentials, its own failure modes and its own security review.
Outbound only
In Vesana, nothing connects into a monitored network. Two kinds of components live there, and both only open outbound HTTPS connections on port 443 to your Vesana server:
- Agents on Windows and Linux machines run checks locally — CPU, memory, disks, services, event logs, scripts — and send the results.
- Collectors, small Linux VMs in the customer network, check everything that cannot run an agent: switches, firewalls, NAS systems, printers and UPS units, over SNMP, SSH, HTTP or the device's own API.
Port 443 outbound is open in almost every network. The customer's firewall needs no new inbound rule, and there is no tunnel to keep alive.
What the server does
Agents and collectors fetch their configuration from the server and push results back. Thresholds, intervals and checks are changed centrally in the web interface; nobody edits configuration files on customer machines. If a collector goes quiet, Vesana raises that as one event — "collector offline" — instead of marking every device behind it as down.
For targets that are reachable from the server itself, such as public websites, certificates or your own infrastructure, the Vesana server can run checks directly, without any component in between.
Keeping customers apart
One Vesana instance can serve many customers. Each customer is a tenant with its own devices, alert rules and notification channels, and roles are granted per tenant: a technician can be an admin for one customer and read-only for another. A collector belongs to one tenant and only receives the configuration and credentials of that tenant's devices. Several tenants are part of the paid plans; the free plan has one.
When the monitoring server is the risk
A central system that can run scripts on many customer machines is an attractive target. Two safeguards address that:
- Signed updates. Agents and collectors only install updates whose signature matches a key built into the binary. The server cannot point them at different code.
- Agent Lock. Scripts, commands and log sources delivered by the server only run after they have been approved on the host itself. Turning the lock on or off works only with a command on that machine, so a compromised Vesana server cannot switch it off. Built-in checks keep running.
Getting started
The Vesana server runs on Debian or Ubuntu and is installed with one command. For each agent, the interface shows a ready-made install command with the token and server address filled in. Vesana is free for up to 25 hosts.