Einleitung
Eine All-in-One-Installation von Wazuh – also Server, Indexer und Dashboard auf einem einzelnen Host – ist für kleine bis mittlere Umgebungen ein praktikabler Einstieg. Mit steigender Agentenanzahl und hohem Logaufkommen stößt dieses Modell jedoch schnell an physische und architektonische Grenzen.
In diesem Beitrag analysieren wir ein typisches Szenario mit über 120 Agents und mehr als 4 Millionen Logs pro Tag und zeigen, wie eine saubere Ressourcenplanung sowie eine horizontale Skalierungsstrategie aussehen sollte.
Ausgangslage / Problemstellung
Gegeben ist folgende Umgebung:
- All-in-One Wazuh Deployment
- 120+ Agents
- ca. 4.000.000 Logs pro 24 Stunden
- Rocky Linux 8 VM
- 8 vCPU
- 12 GB RAM
Subjektive Wahrnehmung:
- Performance wirkt zeitweise eingeschränkt
- System reagiert verzögert
- Ressourcen erscheinen nicht ausreichend
Typische Symptome in solchen Umgebungen:
- Verzögerte Alert-Verarbeitung
- Hohe JVM-Auslastung des Indexers
- Steigende Disk-I/O
- Mögliche Event-Drops bei Lastspitzen
Technische Analyse
1. Einordnung des Logvolumens
4.000.000 Logs pro Tag entsprechen:
- ~166.666 Logs pro Stunde
- ~2.777 Logs pro Minute
- ~46 Events pro Sekunde (EPS)
Wichtig:
Das ist der Durchschnitt. In der Praxis treten Lastspitzen auf, z. B.:
- Patch-Zyklen
- Neustarts
- Security-Events
- Log-Bursts bei Firewalls
Reale Peak-EPS können deutlich höher liegen.
2. Engpässe in All-in-One-Installationen
Eine All-in-One-Installation bündelt:
- Wazuh Manager (analysisd, remoted, modulesd)
- Wazuh Indexer (OpenSearch)
- Wazuh Dashboard
Das führt zu Ressourcenkonkurrenz bei:
- CPU (Regel-Engine + JVM)
- RAM (OpenSearch Heap + OS Cache)
- Disk I/O (Indexierung + Logs + Snapshots)
- Netzwerk-Handling
Besonders kritisch ist der Wazuh Indexer, da OpenSearch speicherintensiv arbeitet.
Mit 12 GB RAM gesamt verbleibt:
- ca. 4–6 GB für JVM Heap (Indexer)
- Rest für OS + Wazuh Manager + Cache
Das ist für produktive Umgebungen mit 100+ Agents sehr knapp bemessen.
3. Monitoring auf Event-Verluste
Bevor skaliert wird, sollte objektiv geprüft werden, ob Events verloren gehen.
Wichtige Statusdateien:
/var/ossec/var/run/wazuh-analysisd.state
Wert prüfen:
events_dropped
sowie:
/var/ossec/var/run/wazuh-remoted.state
Wert prüfen:
discarded_count
Steigen diese Werte an, deutet das auf Ressourcenmangel hin.
4. Indexer-Last prüfen
Indexgröße analysieren:
curl -k -u admin:admin https://localhost:9200/_cat/indices/wazuh-alerts-*?v&s=index
Relevante Faktoren:
- Anzahl Shards
- Anzahl Replicas
- tägliches Indexwachstum
- Retention Policy
Zu viele Shards erhöhen CPU- und RAM-Verbrauch signifikant.
Lösung / Best Practices
1. Mindestempfehlung für 100+ Agents
Als grobe Richtlinie für produktive Umgebungen:
Wazuh Server Node:
- 8 vCPU
- 16 GB RAM
Wazuh Indexer Node:
- 16 vCPU
- 32 GB RAM
Diese Empfehlung gilt insbesondere bei >50 EPS und mittlerer Retention.
Eine All-in-One-VM mit 8 vCPU und 12 GB RAM liegt deutlich unter dieser Empfehlung.
2. Horizontale Skalierung statt rein vertikalem Ausbau
Wazuh skaliert primär horizontal.
Empfohlene Architektur bei Wachstum:
- Separater Wazuh Server Node
- Separater Wazuh Indexer Cluster (mindestens 3 Nodes für HA)
- Optional: dedizierter Dashboard Node
Erweiterungsoptionen:
Server-Cluster erweitern:
https://documentation.wazuh.com/current/user-manual/wazuh-server-cluster/adding-new-server-nodes/index.html
Indexer-Cluster erweitern:
https://documentation.wazuh.com/current/user-manual/wazuh-indexer-cluster/add-wazuh-indexer-nodes.html
3. Retention-Strategie optimieren
Retention hat massiven Einfluss auf Ressourcen.
Fragen zur Planung:
- Wie lange müssen Alerts vorgehalten werden?
- Sind Hot/Warm-Strategien erforderlich?
- Werden Snapshots extern gespeichert?
Beispiel:
- 30 Tage Hot Storage
- Danach Snapshot + Löschung
- Reduktion aktiver Indizes
4. Shard-Konfiguration prüfen
Zu viele Shards erzeugen Overhead.
Empfehlung:
- 1–2 Primärshards pro Tagesindex bei moderatem Volumen
- Replikas nur bei Clusterbetrieb
Fehlkonfiguration führt zu:
- hoher Heap-Auslastung
- GC-Pausen
- Dashboard-Verzögerungen
5. Load Balancer für Agent-Traffic
Bei wachsender Agentenzahl:
- Agenten über Load Balancer verteilen
- Mehrere Server Nodes betreiben
- Remoted-Last verteilen
Das verhindert Engpässe bei TLS-Verbindungen und Event-Queues.
Lessons Learned / Best Practices
1. All-in-One ist kein Langzeitmodell für Wachstum
All-in-One eignet sich für:
- Lab
- POC
- Kleine Umgebungen (<50 Agents)
Bei >100 Agents ist Trennung der Komponenten empfehlenswert.
2. RAM ist kritischer als CPU
Indexer (OpenSearch) benötigt:
- ausreichend Heap
- OS Page Cache
- stabile I/O
Unter 16 GB RAM gesamt ist bei 100+ Agents ein Engpass wahrscheinlich.
3. EPS ist die zentrale Planungsgröße
Nicht Agentenzahl, sondern Events per Second bestimmen:
- Clustergröße
- Hardwarebedarf
- Shard-Strategie
- Retention
4. Monitoring ist Pflicht
Regelmäßig prüfen:
- events_dropped
- discarded_count
- JVM Heap Usage
- Disk I/O
- Indexgrößen
Skalieren sollte proaktiv erfolgen – nicht erst bei Datenverlust.
5. Virtualisierung nicht unterschätzen
Bei VM-Betrieb:
- CPU Ready Time prüfen
- Storage-Latenz analysieren
- Keine überprovisionierten Hosts verwenden
Indexer reagiert sehr sensibel auf Storage-Performance.
Fazit
Eine All-in-One-Installation mit 8 vCPU und 12 GB RAM ist für 120+ Agents und 4 Millionen Logs pro Tag grenzwertig dimensioniert – insbesondere bei steigender Last oder längerer Retention.
Wazuh skaliert am stabilsten durch horizontale Erweiterung:
- Separate Server- und Indexer-Nodes
- Optimierte Shard-Strategie
- Klare Retention-Policies
- Kontinuierliches Monitoring
Wer frühzeitig von einer Monolith-Architektur auf ein Cluster-Modell umstellt, stellt Performance, Stabilität und Zukunftssicherheit der Wazuh-Umgebung nachhaltig sicher.
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/p1770017068481719