Zum Inhalt

Policies — Hosts regelbasiert verwalten

Vorschau-Funktion

Policies sind standardmäßig ausgeschaltet — Menüpunkt, Seite und API sind gesperrt, bis ein Super-Admin den Bereich unter Admin → System → Vorschau-Funktionen freischaltet. Der Bereich ist noch nicht stabil.

Eine Policy ist eine deklarative Regel: „Hosts, die auf Bedingung X passen, sollen Y bekommen." Statt jeden Host einzeln anzufassen, beschreibst du einmal die Bedingung und die gewünschte Wirkung — die Policy hält das dann laufend für alle passenden (auch neu hinzukommende) Hosts aufrecht.

Typische Einsätze:

  • Allen Hosts mit Tag produktion automatisch einen zusätzlichen Check geben.
  • Jedem Switch eines Herstellers einheitliche Schwellwerte setzen.
  • Neuen Linux-Servern automatisch das Tag linux verpassen.

Aufbau einer Policy

Jede Policy besteht aus Bedingungen (wen trifft sie?) und Aktionen (was passiert?).

Bedingungen

Du baust einen Bedingungsbaum mit UND/ODER über Host-Eigenschaften. Verfügbar sind u. a.:

  • 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
  • Profil-Fähigkeiten (Operator has_profile_capability): agent_capable, snmp_enabled, ip_required

Operatoren: equals, in, contains, matches (Regex), has_tag, has_profile_capability. Bedingungen lassen sich frei zu UND/ODER-Gruppen verschachteln.

Aktionen

Drei Aktionstypen werden angewendet:

  • Tag zuweisen — vergibt ein oder mehrere Tags an passende Hosts. Diese erscheinen als Policy-Tags (gestrichelter Rahmen) und werden von der Policy gepflegt — du entfernst sie nicht von Hand, sondern über die Policy.
  • Check hinzufügen — legt einen bestimmten Check (aus einer Profil-Check- Definition) auf passenden Hosts an.
  • Check-Config anpassen — überschreibt Check-Konfiguration (z. B. Schwellwerte) auf den Checks passender Hosts.

Nur diese drei Aktionen

Der Editor bietet ausschließlich die tatsächlich umgesetzten Aktionstypen an. Andere (z. B. Alert-Regeln oder Abhängigkeiten automatisch anlegen) sind noch nicht Teil des Funktionsumfangs.

Der Trockenlauf ist Pflicht

Bevor du eine Policy speicherst, musst du einen Trockenlauf (Dry-Run) ausführen. Er zeigt dir exakt, welche Hosts die Bedingung trifft und welche Operationen (Tags, Checks, Config-Änderungen) tatsächlich passieren würden — noch ohne etwas zu verändern. Erst danach kannst du speichern. So gibt es keine Überraschungen durch eine zu weit gefasste Regel.

Adoption-Modus (Kollision mit Handarbeit)

Wenn eine Policy etwas anlegen will, das du von Hand bereits erstellt hast (z. B. denselben Check), entscheidet der Adoption-Modus, was passiert:

  • never (Default) — die Policy lässt deine manuelle Version in Ruhe und überspringt sie. Sicherste Einstellung.
  • ask — die Kollision wird zur manuellen Freigabe vorgemerkt; deine Version bleibt zunächst unberührt.
  • force — die Policy übernimmt die Verwaltung (wird protokolliert).

Sicherheitsnetz

  • Circuit-Breaker: Würde ein Lauf zu viel auf einmal verändern (Massen- Löschungen oder sehr viele Operationen), bricht er ab, statt Schaden anzurichten. Eine versehentlich zu breite Regel kann so nichts wegräumen.
  • Sauberes Aufräumen: Passt ein Host nicht mehr auf die Policy oder löschst du die Policy, werden die von ihr verwalteten Tags/Checks wieder entfernt — manuelle Objekte bleiben unberührt.
  • Priorität: Greifen mehrere Policies auf dasselbe zu, bestimmt die Priorität die Reihenfolge.

Weitere Helfer

  • KI-Entwurf: Beschreibe in natürlicher Sprache, was du erreichen willst — Vesana schlägt eine passende Policy als Entwurf vor, den du prüfst und anpasst.
  • Aus Bulk-Aktion erzeugen: Eine Sammelaktion (z. B. „diesen Check auf alle markierten Hosts") lässt sich in eine dauerhafte Policy umwandeln.
  • Revisionen: Jede Änderung an einer Policy wird versioniert — du siehst den Verlauf und kannst frühere Stände nachvollziehen.
  • Aktivieren/Deaktivieren und Jetzt ausführen (nächsten Lauf erzwingen) je Policy.

Anschluss

  • Host-Tags — wo Policy-Tags (gestrichelt) vs. manuelle Tags erscheinen.
  • Profile & Checks — woher die Check-Definitionen für „Check hinzufügen" kommen.