Wazuh Indexer von 3 Nodes auf 1 Node reduzieren bei ~42 Mio. Discover-Hits/Tag: So bewertest du Risiko, Performance und Datenverlust sauber

von

Einleitung

Viele Wazuh-Installationen starten mit einem Indexer-Cluster, weil Verfügbarkeit, Skalierung und Performance damit grundsätzlich einfacher abzusichern sind. Gleichzeitig ist ein 3-Node-Indexer-Cluster nicht „gratis“: mehr Ressourcen, mehr Betriebsaufwand, mehr Komplexität bei Shards, Replikation und Upgrades. Wenn in Discover im Schnitt ~42.360.000 Hits pro Tag auftauchen, ist die Frage berechtigt: Reicht ein einzelner, ausreichend dimensionierter Indexer? Die kurze Antwort lautet: manchmal ja – aber nur, wenn du die richtigen Metriken prüfst und die Risiken (Bursts, Hot Shards, Replica-Verlust, Recovery) bewusst akzeptierst.

Ausgangslage / Problemstellung

Setup:

  • 1× Wazuh Server (Manager)
  • 1× Wazuh Dashboard
  • 3× Wazuh Indexer Nodes (Cluster)
  • In Discover sichtbar: ~42 Mio. „Hits“ pro Tag

Ziel: Downsizing auf 1 Indexer Node (mit „genug“ CPU/Disk), ohne Datenverlust, ohne instabile Suche/Indexierung und ohne dass Bursts Events droppen.

Typische Stolperstelle: Discover zeigt häufig primär Alerts (wazuh-alerts-*) – nicht zwingend die gesamte Log-/Archive-Menge. Wenn zusätzlich Archives oder andere Indizes in den Indexer laufen, kann das echte Volumen deutlich höher sein als das, was im Alltag „gefühlt“ wird.

Technische Analyse

1) „Hits/Tag“ ist kein Kapazitätswert – Bursts sind entscheidend

Die Indexer-Stabilität hängt nicht am 24h-Mittelwert, sondern am Peak:

  • kurze Spitzen (z. B. Patch-Nacht, Security-Scans, Auth-Stürme, Fehlkonfiguration, Incident)
  • ungleichmäßige Lastverteilung durch Shards
  • Backpressure-/Buffer-Verhalten (Manager → Indexer), bei Überlast ggf. Dropped Events

Ein einzelner Indexer kann im Mittel „locker“ wirken und trotzdem in Bursts ins Straucheln geraten – mit spürbaren Effekten: Latenzen, Queue-Aufbau, erhöhte JVM-Heap-Pressure, Segment-Merges, Disk I/O Sättigung, Such-Timeouts.

2) Ein Node bedeutet: kein Cluster-Failover, keine Replikation im Sinne von HA

Mit 3 Indexern kannst du:

  • Replikate verteilen (HA bei Node-Ausfall)
  • Shards parallel verarbeiten (Indexing & Search)
  • Rolling Upgrades risikoärmer fahren

Mit 1 Indexer gilt:

  • jede Wartung ist Downtime (oder du akzeptierst Datenstau)
  • kein Replica-Fallback bei Disk/Node-Problemen
  • Recovery nach Ausfall dauert länger und ist riskanter, weil alles auf einem Storage-Stack hängt

Downsizing ist deshalb weniger eine Frage von „kann er’s?“, sondern von „akzeptieren wir das Betriebsrisiko?“.

3) Speicher/Heap und Disk I/O sind meist limitierender als „nur CPU“

Indexer-Workloads (OpenSearch-basiert) sind typischerweise limitiert durch:

  • RAM/JVM Heap (Segment-Caches, Query Cache, Fielddata, Merges)
  • Disk I/O (Indexing, Segment merges, Refresh/Flush, Snapshot/Backup)
  • CPU wird dann kritisch, wenn Parsing/Indexing pro Event teuer ist oder viele gleichzeitige Queries laufen

Darum ist „hohe CPU + viel Disk“ als Kriterium zu kurz gegriffen. Ein Node ohne ausreichend RAM und schnelle Disks wird unter Last oft schlechter performen als drei mittelgroße Nodes.

Lösung / Best Practices

Die richtige Vorgehensweise ist eine „Messung vor Migration“ – und zwar anhand von Kennzahlen, die wirklich über Machbarkeit entscheiden.

Schritt 1: Klären, was die 42 Mio. „Hits“ wirklich sind

  • Prüfe, ob du nur Alerts (wazuh-alerts-*) indexierst oder auch Archives / andere Logs.
  • Wenn Archives nicht in den Indexer laufen, ist die Discover-Zahl oft weniger dramatisch als sie klingt – weil Alerts bereits gefiltert/korreliert sind.

Schritt 2: Top-Offender identifizieren und Rauschen reduzieren

Bevor du Hardware kaufst oder Cluster änderst: Finde heraus, ob ein Teil des Volumens „Noise“ ist.

  • Filter nach agent.name und prüfe die stärksten Quellen
  • Aggregiere nach rule.id (häufig sind wenige Regeln für einen Großteil der Alerts verantwortlich)
  • Sieh dir an, ob die Events:
    • legitime Security-Signale sind
    • erwartbare Betriebslogs (Tuning-Kandidaten)
    • Symptome eines Problems am Ursprung (z. B. Loop, fehlerhafte Audit-Policy, Chatty Service)

Das ist der schnellste Hebel, um Last zu senken – unabhängig von 1 oder 3 Indexern.

Schritt 3: Entscheider-Metriken erheben (Peak, Dropped Events, Indexgröße, Shards)

Diese Checks liefern eine belastbare Grundlage:

  • EPS / Burst-Verhalten und ob Events gedroppt werden:
    • Dashboard → Server Management → Statistics → Analysis Engine → Events Dropped (zeigt Verluste)
    • Zusätzlich: Manager/Cluster-Stats (wenn Archives aktiviert sind, ist das besonders aussagekräftig)
  • Indexgröße gesamt:
    • GET wazuh-alerts-*/_stats/store?filter_path=_all.total.store.size_in_bytes
  • Shard-/Disk-Allocation & Nutzung:
    • GET _cat/allocation?v
  • Index-Anzahl (als Proxy für Shard-Management/Overhead):
POST wazuh-alerts-*/_search
{
  "size": 0,
  "aggs": {
    "index_count": { "cardinality": { "field": "_index" } }
  }
}

Damit kannst du abschätzen:

  • wie viel Storage du für Retention wirklich brauchst
  • ob Shard-Overhead hoch ist
  • ob ein Single Node ohne Replica überhaupt Sinn ergibt

Schritt 4: Wenn du auf 1 Indexer gehst, dann bewusst „Single-Node-tauglich“ designen

Best Practices für den 1-Node-Fall:

  • Keine Replikation (replicas=0), sonst hast du unzuweisbare Shards (bei 1 Node).
  • Shard-Anzahl klein halten (zu viele Shards töten Performance auf einem Node).
  • Retention/ILM/Index-Pattern sauber definieren, damit Storage planbar bleibt.
  • Snapshots/Backups obligatorisch, weil du keine HA mehr hast.
  • Monitoring (Heap, GC, Disk I/O, CPU steal, queue/rejections) als Pflicht – nicht Kür.

Schritt 5: Entscheidungsregel (praxisnah)

  • Ein Indexer ist vertretbar, wenn:
    • Archives nicht zusätzlich indexiert werden (oder du das Volumen sauber kennst)
    • Bursts keine Drops verursachen (oder du Bursts durch Tuning/Filter entschärfst)
    • du Downtime/Single-Point-of-Failure akzeptierst und Backups/Snapshots sauber hast
  • Mehrere Indexer sind Best Practice, wenn:
    • hohe Suchlast (viele Nutzer/Detections, Dashboards, API-Abfragen)
    • echte HA-Anforderung (Ausfall darf nicht zu Daten-/Serviceverlust führen)
    • sehr ungleichmäßige Peaks oder sehr große Retention bei hoher Ingest-Rate

Lessons Learned / Best Practices

  • Durchschnittswerte täuschen: Entscheidend sind Peak-EPS und Drops.
  • Noise zuerst reduzieren, bevor du skalierst oder „entskalierst“. Das ist die billigste Performance-Optimierung.
  • Single Indexer = Single Point of Failure. Wenn du das machst, kompensiere mit Snapshots, Monitoring und klarer Wartungsstrategie.
  • Shard-Disziplin ist Pflicht – besonders auf einem Node. Weniger Shards ist oft mehr.
  • RAM und Disk-I/O sind meist die Engpässe, nicht „nur CPU“.

Fazit

Ein Downsizing von 3 Wazuh Indexern auf 1 kann funktionieren – selbst bei zig Millionen Discover-Hits pro Tag – aber nur, wenn du die Discover-Zahl korrekt einordnest (Alerts vs. Archives), Bursts und Drops prüfst und das Single-Node-Risiko bewusst in Kauf nimmst. Die beste Vorgehensweise ist: Volumenquellen identifizieren, Noise reduzieren, Peak-/Drop-Metriken erheben, Indexgröße und Shard-Layout bewerten – und erst dann entscheiden. So vermeidest du, dass die Migration „auf dem Papier“ klappt, aber im Incident oder Patch-Fenster Daten verliert.

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/C07CNG3M11N/p1758824101208279