Backup monitoring in Zabbix

Import one template, and every backup job and tier you have in Servatum appears in Zabbix as items with triggers already defined. New jobs show up by themselves through low-level discovery. Your Zabbix only makes outbound HTTPS requests; nothing has to be opened to the internet.

Two ways to connect

Method	How it works	Network
Pull (recommended) HTTP agent item	Zabbix fetches one JSON document from Servatum. Dependent items split it into values per job and tier.	Outbound HTTPS from your Zabbix server or proxy only.
Push Trapper or `history.push`	Servatum sends values into Zabbix, using the Zabbix sender protocol or the `history.push` API method (Zabbix 7.0 and later).	Your Zabbix server, proxy or frontend must be reachable from the internet, and Servatum's addresses must be in the item's Allowed hosts.

The Servatum template

The template is built entirely from standard Zabbix pieces:

Piece	What it does
Master item	An HTTP agent item that fetches Servatum's status JSON every few minutes, with your read-only token in a custom header.
Discovery rule	A dependent low-level discovery rule that reads the list of jobs and tiers from the same JSON, so new jobs are picked up without editing anything.
Item prototypes	Per tier: status, hours since the last good run, last backup size and restore points. Each is a dependent item using JSONPath preprocessing, so Zabbix makes one request, not one per value.
Trigger prototypes	A tier failed. A tier is past its schedule plus grace. Restore points are below target. Thresholds come from the schedule and retention you set in Servatum, passed through discovery macros.
Watchdog trigger	Fires if the master item receives no data for 30 minutes, using Zabbix's `nodata()` function. If Servatum or the network path is down, you hear about it in Zabbix.

We'll publish the Zabbix versions the template is tested on when it ships.

What Servatum returns

{
  "jobs": [
    {
      "job": "nightly-full",
      "tier": "offsite",
      "status": 1,
      "hours_since_success": 7,
      "expected_hours": 25,
      "grace_hours": 3,
      "size_bytes": 48211993600,
      "restore_points": 34,
      "restore_points_target": 30
    }
  ]
}

The discovery rule maps job and tier to {#JOB} and {#TIER}. Each item prototype then picks its value with JSONPath, for example:

$.jobs[?(@.job=='{#JOB}' && @.tier=='{#TIER}')].hours_since_success.first()

Setting it up

In Servatum, create a read-only token for Zabbix.
In Zabbix, import the Servatum template and link it to a host (any host works; it doesn't need an agent).
Set the host macro {$SERVATUM.TOKEN} to your token.
Wait for the first discovery run. Your jobs and tiers appear under Latest data.

The token can only read status. It can't change jobs or see anything else in your account.

Push instead of pull

If your Zabbix is reachable from outside and you'd rather receive data than fetch it, the template's master item has Enable trapping switched on, so the same item also accepts pushed values. Servatum can send them two ways:

Zabbix sender protocol to your server or proxy, port 10051 by default.
history.push over HTTPS to your Zabbix frontend's API, using an API token (Zabbix 7.0 and later).

Either way, Zabbix only accepts values from addresses permitted in the item's Allowed hosts field. You'd add Servatum's published sending addresses there. The nodata() watchdog works the same in push mode.

What ships when

Piece	Status
Status JSON endpoint with read-only tokens	Planned for launch
Importable template with discovery, triggers and watchdog	Planned for launch
Push via sender protocol or `history.push`	Planned

Running Zabbix for several clients or sites? Join the waitlist and tell us how your hosts are organized.

Join the waitlist

Zabbix is a trademark of Zabbix LLC. Servatum is not affiliated with Zabbix.

Sources

Zabbix 7.0 documentation: