Expected values & comparison¶
Sometimes a standard check is almost enough, but not quite: you want to give the check a target value — e.g. "which network profile this server should have" — and derive a status from it ("if the result deviates, Critical"). For that the profile editor has the section "Comparison with an expected value". The comparison runs centrally on the server: agent or collector only deliver the output, the server determines the status — the logic lives in one place and applies to all hosts alike.
Only one door left
There used to be three evaluation kinds here (numeric, comparison, script output). What remains is the comparison — the only one without an equivalent elsewhere. Limits belong in the threshold fields of the check (editable per device there and effective immediately), the output format (Nagios/text/JSON) belongs to the script. The former "custom fields" are now called expected values — they are something different from the configurable values of a script.
Where do I find it?¶
Profiles → open profile → edit profile check → expander "Comparison with an expected value". Collapsed, it says in one line what it is for. On the host check the expected value appears as a field that can be overridden per device.
Expected values¶
An expected value is a named field on the profile check (text, number, choice or yes/no) with an optional default. It applies at the profile for all hosts and can be overridden per host — the host value wins. The field name is the key under which the value appears in the comparison and in messages.
The comparison¶
| Field | Meaning |
|---|---|
| Comparison | equals · is one of · contains · matches regex |
| Expected (from field) | take the expected value from one of your expected values — this makes it resolvable per host |
| Expected value | alternatively a fixed value (when no field is chosen) |
| On match / Otherwise | which status on match or deviation (e.g. OK / Critical) |
| Message (optional) | free text with placeholders: {value} = result text, {unit} = unit, {fieldname} = effective value of the expected value for this host |
Example: expected value expected_profile (standard at the profile, dmz on the DMZ host), comparison equals → Expected (from field) expected_profile → on match OK, otherwise Critical, message network profile {value}, expected {expected_profile}.
What became of old evaluations¶
On the first start after the update Vesana automatically moves existing evaluation contracts to where they belong:
- Numeric → limits into the threshold fields of the check.
- Script output → output format onto the script (
expected_output). - Comparison → stays as it is.
Whatever cannot be mapped cleanly stays in force unchanged and is noted with a reason in the diagnostic log — e.g. a custom value path, a script feeding several checks with different formats, or types with locked threshold columns (SSL certificate, internet line). The original contract is logged along with it; nothing disappears silently. Such a legacy contract is still shown in the profile editor with its values, explains where it belongs, and can be removed via "Remove now".
Good to know¶
- The comparison checks the output of the check; for script checks the evaluation "When is this check OK?" sits directly on the check (exit code, compare output or custom pattern) — see Monitoring scripts.
- Thresholds on script checks apply in addition to the script result and can only make the status worse.
- Bulk editing and profile import respect expected values like any other field.
Related topics¶
- Configurable values on scripts — values the script receives from outside
- Monitoring scripts — evaluating script output
- Profiles & checks — inheritance profile → host