Wazuh in groß: Architektur, Sizing und Hot/Warm-Indexer für 2.500 Agents, 5.000 EPS und 90 Tage Retention

von

Einleitung

Wazuh skaliert gut – aber bei mehreren tausend Agents, zusätzlicher Syslog- und Datenbank-Ingestion sowie 90 Tagen Aufbewahrung entscheidet die Architektur über Stabilität, Kosten und Betriebskomplexität. Besonders kritisch sind dabei die Trennung von Analyse (Manager-Cluster) und Storage/Search (Indexer-Cluster), eine saubere Hot/Warm-Strategie im Indexer sowie ein realistisches Kapazitätsmodell (EPS, Eventgröße, Index-Overhead, Replikate, Shards).

Dieser Beitrag konsolidiert bewährte Community- und Dokumentations-Empfehlungen zu Node-Count, Rollenverständnis, Hot/Warm-ILM sowie Installationsvorgehen für Bare Metal.

Ausgangslage / Problemstellung

Umgebung (Zielbild):

  • ~2.500 Wazuh Agents (Endpoints)
  • 2 Firewalls (Sophos, Sangfor) + 2 Datenquellen (Datenbanken) → sollen in Wazuh ingestiert werden
  • ~5.000 EPS gesamt, 90 Tage Retention
  • Hot/Warm Indexer-Architektur (Performance vs. Kosten)
  • Bare Metal, idealerweise Assisted Installation – gleichzeitig Bedarf an HA und Skalierbarkeit

Typische Symptome/Fehlannahmen in dieser Phase:

  • Manager- und Indexer-Rollen werden vermischt (z. B. “Manager-Rollen in opensearch.yml”)
  • EPS wird “roh” an Manager oder direkt an Indexer geschickt, ohne Pufferung/Filterung
  • Hot/Warm wird nur als Hardware-Thema gesehen, nicht als ILM-/Shard-/Allocation-Design
  • Assisted Install wird mit “produktionsreif für Large Scale ohne Tuning” gleichgesetzt

Technische Analyse

1) Komponenten und Verantwortlichkeiten (wichtig für korrektes Sizing)

Wazuh Manager (Cluster: Master + Worker)

  • Nimmt Agent-Daten an, dekodiert/normalisiert, korreliert, erzeugt Alerts
  • Verwaltet Agent-Konfigurationen, Status, Remediation/Response
  • Skalierung primär über Worker (EPS/Parsing/Rule-Matching), Master für Koordination/State

Wazuh Indexer (OpenSearch-basiert)

  • Speichert/indiziert Alerts/Events, ermöglicht Suche/Aggregationen
  • Skalierung primär über Data-Nodes (Hot/Warm) + Cluster-Manager (Steuerung)
  • Hot/Warm ist ein Datenlebenszyklus- und Allocation-Problem, nicht nur “schnell vs. langsam”

Wazuh Dashboard

  • UI/Visualisierung/Abfragen
  • In HA-Szenarien typischerweise mehrfach hinter Load Balancer/Reverse Proxy

Kernpunkt zur Rollenklärung:
opensearch.yml betrifft nur den Indexer (Indexer-Cluster-Rollen). Wazuh Manager-Rollen werden nicht in opensearch.yml definiert.

2) Ingestion-Design: Warum Syslog besser über Agent + rsyslog läuft

Für Netzwerkgeräte (Firewalls, Switches etc.) ist es best practice, Syslog nicht direkt an den Manager zu senden, sondern an einen dedizierten “Relay”-Host mit Wazuh Agent + rsyslog. Das bringt drei operative Vorteile:

  • Beweissicherung: Syslog bleibt im nativen Format lokal verfügbar
  • Pufferung bei Verbindungsproblemen: lokale Queue statt Datenverlust
  • EPS-Kontrolle: Vorfilterung (z. B. Noise-Events) und gezielte Weiterleitung reduziert Last im Wazuh-Cluster

Zusätzlich kann im Agent über localfile-Konfiguration und Ignore-/Filtermechanismen unnötiges Volumen reduziert werden. Das ist bei 5.000 EPS oft der Unterschied zwischen “stabil” und “dauerhaft am Limit”.

3) Sizing-Logik statt “magischer Node-Zahlen”

Exakte Node-Zahlen hängen an messbaren Variablen:

  • Durchschnittliche Eventgröße (nach Parsing)
  • Anteil “schwerer” Decoder/Rules und Module (z. B. FIM/Vuln/Compliance)
  • Query-Last (Dashboards, Hunting, Reports)
  • Replikationsfaktor, Shard-Design, Index-Rollover
  • Hardware (CPU-Generation, NVMe/SAS, RAM, Netzwerk)

Best Practice für Large Scale: Mit konservativem Baseline-Design starten, dann mit Lasttests (synthetische Events + realistische Queries) validieren und iterieren.

Lösung / Best Practices

1) Empfohlene Baseline-Architektur (Startpunkt für 2.500 Agents / ~5.000 EPS / 90 Tage)

Als konservatives, HA-fähiges Startdesign auf Bare Metal:

Wazuh Manager Cluster

  • 1× Master
  • 2× Worker (bei 5.000 EPS oft sinnvoll; bei intensiven Modulen ggf. 3–4 Worker)
  • Optional: dedizierte Syslog-Relay-Agents (siehe unten) statt Manager als Syslog-Sink

Wazuh Indexer (Hot/Warm, HA)

  • 3× Cluster-Manager-fähige Nodes (Quorum/HA; können bei kleinerem Setup kombiniert sein, bei Large Scale lieber sauber geplant)
  • Hot Tier: 2–4 Data-Nodes (NVMe, viel RAM, hohe CPU), für frische Daten und häufige Queries
  • Warm Tier: 2–6 Data-Nodes (günstiger Storage, weniger CPU), für “ältere” Daten
  • Replikation: mindestens 1 Replica (damit ein Node-Ausfall nicht sofort Daten/Verfügbarkeit gefährdet)

Wazuh Dashboard

  • 2× Dashboard Nodes hinter Reverse Proxy/Load Balancer (Session-Handling beachten)
  • In kleineren Umgebungen reicht 1, bei HA und Wartungsfenstern sind 2 empfehlenswert

Syslog-Relays (stark empfohlen)

  • 1–2 dedizierte Hosts (oder VMs) als Syslog Concentrator: rsyslog nimmt UDP/TCP Syslog an, schreibt lokal, der Wazuh Agent liest und forwardet kontrolliert
  • Bei zwei Relays: aktive/aktive Verteilung per Firewall-Targets oder VIP

Wichtig: Das ist ein belastbarer Startpunkt – kein Ersatz für Kapazitätsmessung. Für 90 Tage Retention ist der Indexer fast immer der dominante Kosten-/Sizing-Treiber.

2) Rollen im Indexer sauber definieren (opensearch.yml)

Im Indexer-Cluster werden Rollen/Attribute so gesetzt, dass Cluster-Koordination und Datenhaltung stabil bleiben.

a) Cluster-Manager (ehem. Master)

  • Verantwortlich für Cluster-State, Shard-Allocation, Wahlen
  • Best practice: 3 Cluster-Manager-Instanzen für Quorum/HA
  • In kleineren Setups oft kombiniert mit Data, bei Large Scale eher getrennt oder “manager+hot” auf kräftiger Hardware

b) Data Nodes (Hot / Warm)

  • Halten Shards, führen Such-/Aggregations-Workloads aus
  • Hot: Performance-Tier (NVMe, mehr RAM)
  • Warm: Kapazitäts-Tier (mehr Storage, weniger Performance)

c) Node Attribute für Hot/Warm

  • Hot/Warm wird typischerweise über Node-Attribute abgebildet, z. B.:
    • node.attr.data_tier: hot
    • node.attr.data_tier: warm

Diese Attribute sind später die Grundlage für ILM-/Allocation-Regeln, damit Indizes automatisch vom Hot- in den Warm-Tier wandern.

3) Hot/Warm-ILM für 90 Tage Retention: praxistaugliches Modell

Ein bewährtes Schema für 90 Tage bei 5.000 EPS:

  • Hot Phase (z. B. 7–14 Tage)
    • volle Performance, häufige Dashboards/Hunting
    • Indizes liegen auf data_tier=hot
    • Rollover nach Indexgröße oder Alter (z. B. 30–50 GB oder 1 Tag, je nach Eventgröße und Queryprofil)
  • Warm Phase (Rest bis Tag 90)
    • weniger häufige Queries, mehr Retention pro Euro
    • Allocation auf data_tier=warm
    • Optional: Force-merge / reduzierte Segmente (abhängig von Query-Anforderungen)
  • Delete Phase (Tag 90)
    • automatisches Löschen zur Kapazitätsgarantie

Warum ILM auf Größe oft besser als “1 Index pro Tag” ist:
Bei stark schwankendem EPS erzeugt tägliche Rotation mal sehr kleine, mal sehr große Indizes. Größe-basiertes Rollover stabilisiert Shard-Größen und verbessert Cluster-Gesundheit (Shard-Management, Merge, Caches).

4) Shards & Replicas: stabiler Betrieb statt Shard-Explosion

Grundregeln (praktisch bewährt):

  • Lieber wenige, sinnvoll große Shards als viele kleine
  • Shards so dimensionieren, dass sie pro Node gut zu handhaben sind (zu kleine Shards = Overhead; zu große Shards = langsame Recovery)
  • Replicas = 1 als Minimum für HA (bei 3+ Data-Nodes gut tragbar)

Startempfehlung als Baseline:

  • Pro Index zunächst 1–2 Primärshards
  • 1 Replica
  • Bei Wachstum eher über mehr Data-Nodes skalieren als über aggressiv erhöhte Shard-Anzahl

5) Assisted Installation vs. Step-by-step auf Bare Metal

Assisted Installation ist grundsätzlich brauchbar – aber bei Large Scale ist Kontrolle entscheidend:

  • Für PoC / Pilot / kleine bis mittlere Setups ist Assisted oft ideal
  • Für produktionsnahe Großumgebungen empfiehlt sich häufig Step-by-step, weil:
    • Rollen/Topologie (Cluster-Manager vs Hot vs Warm) gezielter gesetzt werden
    • TLS/Cert-Handling, JVM/OS-Tuning, Storage-Layout, Systemlimits sauber kontrolliert werden
    • spätere Standardisierung (Ansible, Immutable Builds) einfacher ist

Best practice in der Praxis:
Assisted für schnelle Validierung → anschließend Step-by-step für Production-Rollout mit reproduzierbaren Playbooks.

Lessons Learned / Best Practices

  1. Syslog immer entkoppeln
    Netzwerkgeräte via rsyslog-Relay + Agent einsammeln, puffern, filtern. So bleibt der Manager-Cluster stabil und EPS kontrollierbar.
  2. Indexer ist der Kapazitätsanker
    90 Tage Retention + 5.000 EPS bedeutet: Storage, Shards, Replikation, ILM und Tiering sind die entscheidenden Stellhebel.
  3. Hot/Warm nur mit ILM/Allocation sinnvoll
    Ohne saubere Node-Attribute und ILM-Phasen landet alles dauerhaft im Hot-Tier oder verteilt sich unkontrolliert – beides teuer/instabil.
  4. Shard-Disziplin schützt die Betriebsfähigkeit
    Shard-Explosion ist einer der häufigsten Gründe für instabile Suchcluster. Mit wenigen Shards starten, über Messwerte skalieren.
  5. Step-by-step zahlt sich bei HA aus
    Gerade bei Bare Metal und mehreren Rollen ist reproduzierbares, fein steuerbares Setup langfristig weniger riskant als “schnell installiert, später gefrickelt”.

Fazit

Für 2.500 Agents, ~5.000 EPS und 90 Tage Retention ist eine HA-fähige Wazuh-Architektur gut erreichbar – wenn Manager, Indexer und Dashboard sauber getrennt gedacht werden und die Indexer-Hot/Warm-Strategie konsequent über Node-Attribute und ILM umgesetzt wird. Ein konservatives Baseline-Design (Manager: 1 Master + 2 Worker, Indexer: Quorum + getrennte Hot/Warm Data-Nodes, Dashboard redundant) kombiniert mit Syslog-Relays und diszipliniertem Shard-/Rollover-Design liefert die beste Ausgangsbasis für kontrolliertes Wachstum.

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/p1769090998921179