Wazuh-Indexer: Warum 130 GB/Tag nicht einfach 11,7 TB für 90 Tage sind (und wie du sauber dimensionierst)

von

Ausgangslage:
Du planst eine Wazuh-Umgebung mit ~130 GB Log-Ingestion pro Tag (hauptsächlich High-Volume-Quellen wie Server, Cloud-Logs, Network Devices) und 90 Tage Retention. Dazu ein Indexer-Cluster (≥3 Nodes) mit 1 Replica.

1) Die Grundrechnung (Raw-Volumen)

  • 130 GB/Tag × 90 Tage = 11.700 GB ≈ 11,7 TB Rohdaten

Das ist aber nicht das, was am Ende auf dem Indexer liegt.

2) Warum der Index größer wird als die Rohdaten

OpenSearch/Wazuh speichert nicht nur „Logzeilen“, sondern erzeugt u. a.:

  • Inverted Index / Doc Values (Suchbarkeit & Aggregationen)
  • Segment-Dateien, Metadaten, Dictionaries
  • temporäre Daten bei Merges

Das erzeugt Index-Overhead (je nach Mapping, Felder, Kardinalität, Message-Größe etc. sehr unterschiedlich). Dazu kommt deine Replica.

3) Replication verdoppelt (typisch) den Storage

Wenn du 1 Replica nutzt, wird jedes Shard einmal zusätzlich gespeichert → ~2× Daten. OpenSearch/Wazuh steuert das über number_of_replicas.

4) Praktische Faustformel für Planung (komfortabel, nicht „auf Kante“)

Ich empfehle für einen belastbaren Plan:

Gesamt-Storage ≈ Raw × Retention-Tage × (Index-Overhead) × (1 + Replicas) × Headroom

Mit realistischen Annahmen:

  • Index-Overhead: 1,2–1,6× (oft in dieser Größenordnung, kann aber höher sein je nach Feldern/Parsing)
  • Replicas: 1 → Faktor 2
  • Headroom: 1,25–1,35× (damit Merges, Peaks, Watermarks, Rebalancing nicht alles abwürgen)

Beispielrechnung (konservativ & „sicher“):

  • Raw 90 Tage: 11,7 TB
  • Overhead 1,4×: 16,4 TB
  • Mit 1 Replica (×2): 32,8 TB
    • 30% Headroom (×1,3): 42,6 TB

✅ Empfehlung: Plane ~35–45 TB „usable“ Cluster-Kapazität (nach RAID/Filesystem-Overhead) für 130 GB/Tag und 90 Tage mit 1 Replica – abhängig davon, wie „feldreich“ die Events sind.

Wenn du eher „schlanke“ Logs hast (wenig Felder, wenig lange Strings), kommst du ggf. näher an 30–35 TB. Bei sehr feldreichen Cloud-/Security-Events (viele Nested Fields, hohe Kardinalität) sind >45 TB nicht ungewöhnlich.

5) Was du konkret prüfen/optimieren solltest

A) Replica-/Shard-Strategie

  • Prüfe number_of_replicas und Shard-Anzahl für deine Indexgrößen.
  • Zu viele Shards erzeugen Overhead; zu große Shards können Merges/Recovery belasten.

B) ILM/ISM richtig aktiv nutzen (Retention wirklich erzwingen)

Setze eine Lifecycle-/State-Management-Policy, die Indizes nach 90 Tagen löscht/archiviert, sonst wächst alles weiter. Wazuh beschreibt dafür Index Lifecycle Management im Indexer-Cluster.

C) Kompression: Default vs. „best_compression“

OpenSearch bietet Index-Codecs:

  • Standard ist LZ4 (schnell, weniger CPU)
  • best_compression nutzt zlib (spart meist Platz, kostet CPU und kann Indexing/Search verlangsamen)
  • Wichtig: Codec greift nur bei neu erstellten Indizes bzw. wenn du reindexierst/neu schreibst.

➡️ Impact in der Praxis:
Wenn CPU ohnehin knapp ist oder du am Limit ingestierst, kann best_compression die Ingestion verschlechtern. Wenn Storage das Hauptproblem ist und CPU-Reserve da ist, kann es sich lohnen (am besten A/B über ein paar Tage messen).

6) „Next steps“ (Checkliste fürs saubere Sizing)

  1. Ist-Zustand messen: aktuelles Index-Wachstum pro Tag im Indexer (nicht Rohlog-Volumen schätzen).
  2. Replica-Faktor verifizieren: number_of_replicas je Index prüfen.
  3. Retention erzwingen: ILM/ISM Policy aktiv + prüfen, ob wirklich gelöscht/verschoben wird.
  4. Headroom einplanen: Ziel < 70–75% Disk dauerhaft (Watermarks vermeiden).
  5. Optional: best_compression nur nach Performance-Test (CPU/Latency).

Wenn du mir sagst, ob ihr wazuh-alerts (nur Alerts) oder zusätzlich archives/weitere Indizes schreibt und wie viele Replicas/Shards ihr aktuell nutzt, kann ich die 35–45 TB-Spanne noch enger und belastbarer für euren Fall rechnen.

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