How monitoring works

Monitoring is part of the Tenvara agent. Every device sends metrics (CPU, memory, disks, network, load and temperature where the system reports them), the state of its services, its patch status and the results of any checks you give it. Tenvara keeps the history, works out each device's health, and raises alerts when a threshold is crossed or a check fails.

Devices and monitoring come with the Monitoring module, switched on in Settings > Modules. While it is off, the Devices area is gone from the rail and search.

There is no separate monitoring console. Monitoring shows up where you already work:

• Devices > Health: the whole fleet at a glance, with a Battery health tab for laptops. See Device health.
• Infrastructure > Uptime checks: websites, VPN endpoints and mail servers checked without an agent on them. See Script, file and server checks.
• The device page: on its Overview tab, health, charts, checks, services, availability and the monitoring that applies. Its Policies tab lists every policy that reaches it.
• Alerts: every monitoring alert, with what raised it and the chart around when it fired. See Alerts.
• Alerts > Alert types: every kind of alert Tenvara can raise, to turn on or off overall or for one customer. See Alert types.
• The device list: Health and Fullest disk columns, and the Needs attention, Unhealthy, Not reporting and Disks nearly full views in the view picker.
• Customer pages and Home: each customer's device health, and a health card on Home.
• Settings > Monitoring: the policies, ready-made templates by server role on the Templates tab, Alert noise (the settings that keep alerts to what matters, including One cause, one alert) and Our own work, the addresses Tenvara treats as your own. See How Tenvara decides what reaches someone. Settings > Alert rules decides which alerts become tickets, and Settings > Alert remediation which alerts offer or run a fix.

Policies#

What a device collects and when it alerts comes from policies. A policy holds settings, checks, thresholds and maintenance windows, and applies at one of five levels. From least to most specific:

1. Global default: every device starts here. There is exactly one.
2. Customer policies: change what a customer's devices do.
3. Site policies: change what the devices at one site do, over their customer's policies.
4. Device group policies: change what a group's devices do, over their site's and customer's policies.
5. Device overrides: one device's own changes, over everything else.

The most specific level wins. At one level, the policy with the higher Priority wins. A policy only changes what it sets:

• A setting left unticked is inherited from less specific policies.
• A check or threshold with the same key as one below it replaces it, so a customer policy can raise the CPU threshold or switch off the disk warning without copying everything else.
• Anything else is added.

For example, a Servers group policy might set offline after 3 minutes and a tighter disk warning, while a site policy for a depot raises offline alerts only in business hours.

Each device's Policies tab shows every policy that reaches it, from every module, in the order it applies. See Policies and where settings come from.

The global default#

A new workspace starts with a global default that suits most MSPs:

Change any of these in Settings > Monitoring > Global default, or override them for a customer, group or device. See Policies, checks and thresholds.

Health#

Each monitored device has a health:

"Needs a look" on the Health page means critical or warning, or offline with its offline alert open. Desktops and laptops that are simply switched off are counted under Offline instead, so they do not bury the real problems.

Offline detection#

A device counts as offline when nothing has been heard from it (neither the agent's check-in nor monitoring data) for its policy's Offline after minutes. A device that enrolled and then never reported counts from when it enrolled, and raises Never reported since enrolment.

Being offline is normal for desktops and laptops: they are switched off at night, taken home and put to sleep. So only some devices raise an is offline alert:

• servers, virtual machines and network devices, by default;
• any device, group or policy you mark Always on, such as a kiosk or a reception PC.

The device types that alert are set in Settings > Monitoring > Alert noise, and a customer can have its own list. A device that does not alert still shows as Offline, and one not seen for a long while becomes a quiet Stale device. See Quiet monitoring and onboarding findings.

An agent that restarts to update itself is not a device going offline or an agent being removed. It only alerts if the agent stays away well past a normal update (30 minutes by default).

Note: Nothing resolves without evidence. When a device goes offline its other alerts stay open until data proves the problem has gone, and when it comes back each rule carries on from the device's own data.

Baselines are not changes#

The first time Tenvara reads anything (a device's inventory, a domain's DNS, a certificate, a network scan, a Microsoft 365 tenant's settings) is its baseline. It is recorded as first seen, never as a change, so connecting a customer does not fill the timeline with changes that are not really changes. From then on, only real differences are reported.

The same idea applies to alerts. The first scan of a new customer, tenant, domain or set of devices, and the first run of a new check, a module you have just switched on or a large import, goes into one findings report rather than a flood of alerts. See Alert storms and first-run findings.

Alerts that stay quiet unless something is wrong#

Every alert and every security detection, from every module, passes the same checks before anyone is told: a short wait for problems that fix themselves, your own work (agent updates, scripts, patch runs, scans) kept as information, planned states such as maintenance, test or retired, and one alert for one cause. When an alert is closed, Tenvara asks how it ended and uses the answers to lower kinds of alert that are mostly noise for a customer. See How Tenvara decides what reaches someone and How did it end? Closing alerts and the noise figures.

Anything Tenvara finds on its own (hypervisors, web servers, printers, hosts on the network and more) waits to be adopted, and can be ignored instead. See Found, adopted and ignored.

History#

Tenvara keeps every sample, 5-minute averages, hourly averages and check results for as long as you choose. The History part of Settings > Monitoring shows how much each takes and how far back it goes. Only administrators can change it. Shorter history uses less disk, and older data goes within a few hours of a change.