Skip to content

Custom fields & evaluation

Sometimes a built-in check is almost enough, but not quite: you want to hand the check its own value — e.g. "which network profile this server is supposed to be in" — and then say how the result becomes a status ("if the result doesn't match the expected value → CRITICAL"). That's what the "Eigene Felder & Auswertung" (custom fields & evaluation) section of the check editor is for. No script, no JSON — a guided form.

Vesana applies the evaluation centrally on the server: the agent or collector only delivers the raw value/output, and the server derives the status from it. That keeps the logic in one place and identical for every host.

The editor labels are German

The fields-and-evaluation editor currently shows German labels regardless of UI language. This page therefore quotes the on-screen German labels and explains them in English.

Where do I find it?

Profiles → expand a profile → click a check (or + Check) → in the modal, expand the "Erweitert: Eigene Felder & Auswertung" (Advanced: custom fields & evaluation) section.

It has two parts:

Part Answers the question
Eigene Felder (custom fields) Which values can I give this check?
Auswertung (evaluation) How does the result become OK / WARNING / CRITICAL?

Existing checks are untouched

A check without custom fields and without an evaluation contract behaves exactly as before (the check "judges itself"). Nothing to set up — the fields are an option, not a requirement.

Custom fields

Use "+ Feld" (add field) to create an input field. Per field:

Field Meaning
Feld-Name (technisch) Internal name, auto snake_case (e.g. erwartetes_profil). You reference this name later in the evaluation and in messages.
Beschriftung The human label shown in the editor / on the host (e.g. "Erwartetes Profil").
Typ What kind of value (see below).
Geltung (scope) Am Profil (fixed) or Pro Host (settable per host) — see below.
Optionen (Komma-getrennt) Only for type Auswahl: the allowed values, e.g. Public, Private, DomainAuthenticated.
Standard Default if nothing is set.
Pflicht Whether a value is required.

Field types

Editor label Used for
Text free text
Ganzzahl integer (e.g. a port)
Dezimalzahl floating-point number
Ja/Nein toggle (on/off)
Auswahl (Dropdown) exactly one of the values from Optionen
Passwort (verschlüsselt) like text, but masked and never returned in clear text

Scope: Am Profil vs. Pro Host

This is the most important switch — it decides who sets the value:

Scope Editor hint Meaning
Am Profil (at the profile) "Ein Wert für alle Hosts dieses Profils." The value is fixed in the definition. Every host using this profile uses the same value. To change it, edit the profile (an admin action, applies to all at once).
Pro Host (per host) "Jeder Host kann einen eigenen Wert setzen." The field is just a template with a default. Each host enters its own value in the service settings. Hosts without their own value use the default.

Rule of thumb:

  • Am Profil → when the value is the same for everyone (a fixed threshold, an API path).
  • Pro Host → when each host expects something different ("this server should be in Private, that one in Domain").

Per host is the genuinely new part

"Pro Host" turns one check type into many individual target values — without building a separate check per host. Define once in the profile, set the target value per host.

Setting the field value per host

Fields with scope Pro Host appear directly on the host:

Host detail → edit service (pencil) → the "Pro-Host-Einstellungen" (per-host settings, nur für diesen Host = "only for this host") section.

There you'll find exactly this field as an input (e.g. a dropdown "Erwartetes Profil"). Whatever you enter here applies only to this host; all others keep their default or their own value.

Scope Am Profil fields deliberately don't appear here

They're fixed — they can't be overridden per host. Only Pro Host fields are editable here.

Evaluation — how the status is determined

Under "Wie wird das Ergebnis bewertet?" (how is the result evaluated?) you pick one of four modes:

Editor label Used for
Eingebaut (Check urteilt selbst) Default. The check determines its own status (ping, HTTP, agent CPU …). No contract.
Numerisch (Schwellen) The numeric value is checked against warning/critical thresholds.
Vergleich (Wert/Status) The result (a text/value) is compared to an expected value — the "public/private" case.
Script-Ausgabe Status from the exit code (Nagios) or a JSON field.

Numeric

  • Richtung (direction): hoch = schlecht (higher = worse, default) or niedrig = schlecht (lower = worse).
  • Warnung ab / Kritisch ab: the thresholds.

For "higher = worse": value ≥ critical → CRITICAL, else value ≥ warning → WARNING, else OK. For "lower = worse" it's reversed (≤). At least one threshold must be set.

Comparison (value/status)

Here you compare the result of the check to an expected value:

Field Meaning
Vergleich (comparison) ist gleich (equals) · ist eines von (is one of) · enthält (contains) · passt auf Regex (matches regex)
Erwartet (aus Feld) Take the expected value from one of your fields (e.g. erwartetes_profil) — so it resolves per host.
Erwarteter Wert Alternatively a fixed value (when no field is chosen).
Bei Treffer / Sonst Which status on match / on mismatch (e.g. OK / CRITICAL).
Meldung (optional) Free text with placeholders.

Script output

For checks that run a script or a Nagios plugin (agent or collector via SSH):

  • Format:
    • Exit-Code (0/1/2) or Nagios → the exit code sets the status: 0 → OK, 1 → WARNING, 2 → CRITICAL, 3 → UNKNOWN.
    • JSON-Feld → a value is pulled from the output via a JSON path ($.usage). With Status aus = Schwelle (Zahl) it's checked against warn/crit; with Wert ist der Status the read value is interpreted as the status directly.

Prerequisite for collector SSH scripts

For the exit code to arrive, the collector must be up to date (v1.9.1+). Self-hosted collectors update automatically.

Using the field value in the evaluation

There are two ways to actually use a field value.

As the target value in a comparison

In the Vergleich mode, pick your field under "Erwartet (aus Feld)". The server then resolves the value for the respective host (i.e. the per-host value) and compares the check result against it.

In messages (placeholders)

In the "Meldung (optional)" field you can use placeholders in curly braces:

Placeholder Replaced with
{value} the evaluated result (the number for Numeric, the result text for Comparison)
{unit} the unit, if present
{fieldname} the effective value of field fieldname (for this host)

Example message:

Profil ist {value}, erwartet {erwartetes_profil}

On a host with target Private and result Public this becomes: "Profil ist Public, erwartet Private".

The field name must match exactly

expected_param and {placeholder} reference the technical field name. A typo (or a field that doesn't exist) resolves to "nothing" — the comparison then fails, or the placeholder stays literal.

Under the hood: where the 'effective' value comes from

The value used per host is determined in this order (later wins):

  1. Default from the field definition
  2. Per-host value from the service settings
  3. (rare) a value resolved by a policy

A change to the per-host value takes effect from the next check cycle (usually within a few minutes).

Worked example: "expected network profile" per host

The classic case — every Windows server should run in a certain network profile, and which one differs per host.

1. Define it in the profile check (editor → Erweitert):

  • Add a field: name erwartetes_profil, type Auswahl, options Public, Private, DomainAuthenticated, scope Pro Host, default Private.
  • Set evaluation to Vergleich: comparison ist gleich, Erwartet (aus Feld) = erwartetes_profil, Bei Treffer = OK, Sonst = CRITICAL, message Profil ist {value}, erwartet {erwartetes_profil}.

2. Set the target value per host (host detail → edit service → Pro-Host-Einstellungen):

Host "Erwartetes Profil"
Server A Public
Server B (nothing → default Private)

3. What Vesana makes of it — the check (e.g. an agent script) returns the actual profile, the server compares:

Host Result Expected Status Message
Server A Public Public OK "Profil ist Public, erwartet Public"
Server B Public Private CRITICAL "Profil ist Public, erwartet Private"

One check type, two different target states — without duplicates.

Good to know

  • Eingebaut = the edge decides. Without an evaluation contract the status comes straight from the agent/collector. Only a contract (Numeric/Comparison/Script output) moves the status logic onto the server.
  • Incomplete contracts are rejected. Numeric needs at least a warning or critical threshold; Comparison needs an expected field or a fixed value — otherwise the editor shows an error on save.
  • Secrets stay local. Password fields and per-host values do not travel along when you save a host as a profile or export a profile — only the definitions are shared.
  • Robust by design. If the server can't apply a contract (e.g. broken JSON), the check becomes UNKNOWN instead of crashing.