Wazuh von All-in-One zu Cluster skalieren: Sizing nach EPS statt Agent-Zählerei, Migration ohne Risiko und Konsolidierungsstrategie

von

Einleitung

Sobald Wazuh von „Proof of Concept“ in den produktiven SOC-Betrieb wächst, kippt ein All-in-One-Setup oft genau dort um, wo es weh tut: CPU/RAM-Spitzen durch Analyse und Korrelationsarbeit, I/O-Engpässe in /var/ossec, und vor allem Storage- und Performance-Druck im Indexer durch steigende Datenvolumina und Retention. Mit ~700 Agents plus zusätzlichen Integrationen (z. B. Firewalls via Syslog) ist der Schritt zu einer verteilten Architektur nicht nur sinnvoll, sondern in der Praxis der typische nächste Meilenstein.

Ausgangslage / Problemstellung

  • Heute: All-in-One Wazuh Stack (Manager/Indexer/Dashboard auf einer Maschine oder einem Knoten)
  • Umfang: ~700 Agents, „viele Logs“ → Ressourcenengpässe
  • Planung: Agent-Zahl verdoppeln (≈ 1400) + Netzwerkgeräte/Firewalls (hohe Eventrate)
  • Fragen:
    1. Wie viele Agents pro Node? Welche CPU/RAM/Disk-Ressourcen je Komponente?
    2. Kann man bestehende Konfigurationen in ein neues Cluster übernehmen?
    3. Drei getrennte Wazuh-Umgebungen: zusammenführen oder getrennt lassen?

Technische Analyse

1) Warum „Agents pro Node“ die falsche Kennzahl ist

Es gibt kein belastbares „X Agents = Y vCPU/RAM“, weil Agents extrem unterschiedlich „laut“ sein können. Entscheidend sind:

  • EPS/APS (Events/Alerts pro Sekunde) aus Agents und Syslog-Quellen
  • aktivierte Module pro Agent (z. B. FIM/Syscheck, SCA, Vulnerability Detection, Inventarisierung)
  • Log-Quellen und Parsing-Komplexität (Firewall-Syslog kann massiv sein)
  • Index-Volumen pro Tag (GB/Tag) und Retention
  • Replica-Faktor und Sharding im Indexer
  • Query-Last (Dashboard, Hunting, Reports)

Die Manager-Last skaliert primär mit Analyse/Decoding/Rule-Processing und Agent-Management; der Indexer skaliert mit ingest/segment merges/query und wird bei Retention + EPS meist zuerst der Flaschenhals.

2) Faustwerte als Startpunkt, nicht als Garantie

Eine häufig genannte Community-Baseline ist, dass ein Manager-Node mit ~8 vCPU / 16 GB RAM in „durchschnittlichen“ Szenarien grob in der Größenordnung von ~1000 Agents liegen kann – aber das muss gegen die reale EPS validiert werden. In Umgebungen mit vielen Syslog-Quellen oder aggressiven FIM/SCA-Profilen kann der Bedarf deutlich höher liegen.

3) Storage ist der eigentliche Game-Changer

Viele Deployments scheitern nicht an CPU, sondern daran, dass:

  • Indexer-Disk zu klein dimensioniert ist,
  • Hot-Storage zu langsam ist (SSD/NVMe ist Pflicht),
  • zu wenig Headroom für Merges/Segments vorhanden ist (nicht >70–75% füllen),
  • Retention + Replikas unterschätzt werden.

Lösung / Best Practices

A) Empfohlene Zielarchitektur für ~1400 Agents + Firewalls (Startpunkt)

Wazuh Manager Cluster

  • 1× Master + 2× Worker (horizontal skalierbar: weitere Worker bei Sustained Load)
  • Pro Node als Start:
    • 4–8 vCPU
    • 8–16 GB RAM
    • SSD/NVMe (insb. für /var/ossec, Queue/Logs)
  • Hinweis: Syslog-Integrationen (Firewalls) erhöhen Last; je nach EPS kann ein zusätzlicher Worker früher nötig sein als erwartet.

Wazuh Indexer (OpenSearch) Cluster

  • Minimum 3 Nodes (Quorum/HA)
  • Pro Node als Start:
    • 4–8 vCPU
    • 16 GB RAM (oft sinnvoller als 8 GB, weil JVM/OS Cache)
    • NVMe/SSD zwingend
  • Disk-Sizing (praktische Formel):
    • Total Disk ≈ (GB/Tag × Retention_Tage × (Replicas+1)) × Overhead
    • Overhead als Sicherheitsaufschlag (Segments/Merges/OS/Headroom): mindestens 1.3–1.5×
    • Zusätzlich: nicht über 70–75% Belegung fahren

Dashboard

  • getrennt oder klein dimensioniert:
    • 2 vCPU
    • 4 GB RAM
  • selten der Bottleneck, aber getrennt hilft bei Stabilität und Upgrades.

Wichtig: Diese Werte sind bewusst konservative Startpunkte. Die saubere Vorgehensweise ist: aktuelles GB/Tag und grobe EPS messen, dann hochrechnen.

B) Wie du „GB/Tag“ und EPS aus deinem All-in-One ableitest

Ohne neue Tools einzuführen gilt als pragmatische Betriebsregel:

  • Miss, wie viel Daten täglich in wazuh-alerts-* geschrieben werden (Index-Stats/Storage Growth).
  • Identifiziere „noisy“ Agent-Gruppen (z. B. FIM auf großen Verzeichnissen, Debug-Logs, Chatty Services).
  • Plane Wachstum: Agent-Verdopplung + Firewall-Syslog bedeutet oft nicht „2ד, sondern eher „2× + X“, weil Network Devices stark variieren.

C) Migration: Konfigurationen übernehmen, aber selektiv

Ja, du kannst Konfigurationen übernehmen – empfehlenswert ist jedoch kein blindes Kopieren des gesamten Dateibaums.

Bewährte Migrationsreihenfolge:

  1. Neues Cluster „clean“ deployen (Manager/Indexer/Dashboard getrennt).
  2. Nur Customizations migrieren:
    • ossec.conf (oder gezielte Snippets)
    • custom rules/decoders/lists
    • Integrationsskripte + Konfig
    • Agent Groups & Shared Agent Config
  3. Staging:
    • erst wenige Agent-Gruppen migrieren (Pilot)
    • Monitoring von CPU/RAM/Queue/Indexer ingest und Disk Growth
  4. Rollout in Wellen.

Cluster-Mechanik: Inhalte wie Rules/Decoders/Lists werden typischerweise vom Master an Worker synchronisiert. Das heißt, Änderungen gehören kontrolliert auf den Master und sollten über Change-Management (Versionierung) eingeführt werden.

D) Drei getrennte Wazuh-Umgebungen konsolidieren oder getrennt lassen?

Beides ist möglich – die richtige Entscheidung hängt an „Blast Radius“ und Differenzen:

Konsolidieren (eine große Plattform)

  • Vorteile:
    • einheitliche Dashboards, User-/RBAC-Verwaltung, weniger Betriebskosten
    • bessere Ressourcenausnutzung
  • Risiken:
    • ein fehlerhaftes Rule-Update/Decoder kann alle betreffen
    • schwierigeres Change-Management bei stark divergenten Anforderungen

Getrennt lassen (mehr Isolation)

  • Vorteile:
    • klare Trennung nach Compliance/Retention/Integrationsrisiko
    • Experimente/Änderungen ohne Impact auf andere
  • Nachteile:
    • mehr Infrastruktur, mehr Updates, mehr Betriebsaufwand

Praxis-Kompromiss

  • Konsolidieren, wenn Retention/Use-Cases ähnlich sind und Change-Management reif ist.
  • Separat lassen, wenn sich Retention stark unterscheidet, Integrationen häufig wechseln, oder klare Compliance-/Mandanten-Trennung benötigt wird.

Lessons Learned / Best Practices

  • Sizing beginnt immer mit EPS + GB/Tag, nicht mit Agent-Anzahl.
  • Indexer zuerst richtig dimensionieren: Retention × Replikas × Overhead wird fast immer unterschätzt.
  • Noisy Agents entschärfen (FIM-Scope, Log-Level, Ausschlüsse), bevor du „nur“ Hardware draufwirfst.
  • Staged Rollouts bei Regel-/Decoder-Änderungen: erst kleine Agent-Gruppe, dann expandieren.
  • Konfigurationen versionieren (Git), besonders in Cluster-Setups.
  • Bei Konsolidierung: starke Guardrails (Agent Groups, RBAC, klare Release-Prozesse), um Fehlkonfigurationen einzudämmen.

Fazit

Für 700 Agents auf All-in-One ist der Schritt in eine verteilte Architektur die richtige Richtung – vor allem, wenn du auf ~1400 Agents plus Firewalls wachsen willst. Statt „Agents pro Node“ solltest du nach EPS und täglichem Index-Volumen dimensionieren, denn der Indexer wird mit Retention und Syslog-Integrationen meist zum Engpass. Migration funktioniert zuverlässig, wenn du selektiv nur Customizations übernimmst und in Wellen ausrollst. Ob du deine drei Umgebungen konsolidierst oder getrennt betreibst, entscheidet sich am besten entlang von Retention-Unterschieden, Compliance-Grenzen und dem gewünschten Risiko-Profil.

Mehr zu Wazuh …
https://wazuh.com/?utm_source=ambassadors&utm_medium=referral&utm_campaign=ambassadors+program

Mehr zum Wazuh Ambassador Program …
https://wazuh.com/ambassadors-program/?utm_source=ambassadors&utm_medium=referral&utm_campaign=ambassadors+program

https://wazuh.slack.com/archives/C0A933R8E/p1769553841497789