Policies — manage hosts by rules¶

Preview feature

Policies are off by default — menu entry, page and API are locked until a super admin enables the area under Admin → System → Preview features. The area is not stable yet.

A policy is a declarative rule: "hosts matching condition X should get Y." Instead of touching every host by hand, you describe the condition and the desired effect once — the policy then keeps that in place for all matching hosts, including ones added later.

Typical uses:

Give every host tagged production an extra check automatically.
Set uniform thresholds on every switch from a given vendor.
Automatically tag new Linux servers linux.

Anatomy of a policy¶

Each policy has conditions (who does it apply to?) and actions (what happens?).

Conditions¶

You build a condition tree with AND/OR over host attributes, including:

host.name, host.ip_address, host.active, host.agent_managed
host.tags (operator has_tag)
host.profile.category, host.profile.vendor, host.profile.os_family
Profile capabilities (operator has_profile_capability): agent_capable, snmp_enabled, ip_required

Operators: equals, in, contains, matches (regex), has_tag, has_profile_capability. Conditions can be freely nested into AND/OR groups.

Actions¶

Three action types are applied:

Assign tag — adds one or more tags to matching hosts. These show up as policy tags (dashed border) and are maintained by the policy — you don't remove them by hand, you change the policy.
Add check — adds a specific check (from a profile-check definition) to matching hosts.
Patch check config — overrides check configuration (e.g. thresholds) on matching hosts' checks.

Only these three actions

The editor only offers the action types that are actually applied. Others (e.g. automatically creating alert rules or dependencies) are not part of the feature set yet.

The dry-run is mandatory¶

Before you save a policy, you must run a dry-run. It shows you exactly which hosts the condition matches and which operations (tags, checks, config changes) would actually happen — without changing anything yet. Only then can you save. That way an overly broad rule can't surprise you.

Adoption mode (collision with manual work)¶

When a policy wants to create something you already created by hand (e.g. the same check), the adoption mode decides what happens:

never (default) — the policy leaves your manual version alone and skips it. The safest setting.
ask — the collision is queued for manual approval; your version stays untouched for now.
force — the policy takes over management (this is logged).

Safety net¶

Circuit breaker: if a run would change too much at once (mass deletions or a very large number of operations), it aborts instead of doing damage. An accidentally too-broad rule can't wipe things out.
Clean removal: when a host no longer matches the policy, or you delete the policy, the tags/checks it managed are removed again — manual objects stay untouched.
Priority: when several policies touch the same thing, priority sets the order.

More helpers¶

AI draft: describe what you want in natural language — Vesana proposes a matching policy as a draft for you to review and adjust.
Create from a bulk action: a bulk action (e.g. "this check on all selected hosts") can be turned into a permanent policy.
Revisions: every change to a policy is versioned — you can see the history and trace earlier states.
Enable/disable and run now (force the next run) per policy.