OpenSearch-Mapping-Konflikte in Wazuh beheben: Netflow-Bytes aggregierbar machen und Visualisierungen retten

von

Einleitung

Wer Netzflussdaten (z. B. Netflow via Filebeat) in Wazuh nutzt, möchte früher oder später Bandbreite historisch auswerten: Bytes über Zeit, getrennt nach „intern → extern“ und „extern → intern“. In der Praxis scheitert das oft nicht an der Visualisierung selbst, sondern an Index-Mappings, Konflikten über Tagesindizes hinweg und „kaputten“ Saved Objects im Dashboard. Dieser Beitrag zeigt, wie man die Felder sauber als numerisch indexiert, Mapping-Konflikte auflöst und bestehende Visualisierungen wieder funktionsfähig macht.

Ausgangslage / Problemstellung

Die Telemetrie wird auf einem Client über Filebeat + Netflow Modul erfasst und in Wazuh sichtbar gemacht. In den Dokumenten sind Bytes vorhanden, z. B.:

  • network.bytes
  • source.bytes
  • destination.bytes

Symptome in Wazuh Dashboard / OpenSearch Dashboards:

  • Felder wie data.network.bytes tauchen nicht (oder nicht nutzbar) im Visualisierungseditor auf, insbesondere nicht als Aggregationsfeld (SUM).
  • In der Index-Pattern-Ansicht werden Felder als String geführt (nicht aggregierbar).
  • Nach Korrekturen treten Mapping conflict Warnungen auf (z. B. „string in alten Indizes, long in neuen“).
  • Visualisierungen werfen Fehler wie null_pointer_exception ... reducePhase.aggregations is null oder „Bad Request“.
  • Nach Löschen von Indizes/Patterns melden alte Visualisierungen:
    „The index pattern associated with this object no longer exists.“

Technische Analyse

1) Warum bytes nicht aggregierbar ist

Für Area-Chart/SUM braucht OpenSearch ein numerisches Feld (long, integer, double, …). Wird ein Feld in einem Index einmal als text/keyword (String) gemappt, kann OpenSearch im selben Index nicht plötzlich numerisch aggregieren. In Dashboards zeigt sich das als „Feld nicht auswählbar“ oder „nicht aggregierbar“.

2) Warum trotz Template weiterhin Probleme auftreten

Ein Index-Template wirkt nur auf neu erzeugte Indizes, nicht rückwirkend. In Wazuh-Setups mit täglichen Indizes (wazuh-alerts-YYYY.MM.DD) führt das zu einem typischen Zustand:

  • Index A (gestern): data.network.bytes = String
  • Index B (heute): data.network.bytes = long
    → Das Index Pattern zeigt Mapping conflict, und jede Aggregation über beide Tage bricht.

3) Warum Visualisierungen „kaputt“ wirken, obwohl Daten da sind

Zwei Klassiker:

  • Zeitfilter umfasst alte, konfliktbehaftete Indizes → Aggregation schlägt fehl.
  • Index Pattern ID hat sich geändert: Visualisierungen referenzieren intern nicht den Pattern-Namen, sondern dessen ID. Wenn das Pattern neu erstellt wurde, kann die ID abweichen. Besonders wichtig: Wazuh autogeneriert wazuh-alerts-* oft mit einer festen ID wazuh-alerts-*, während manuell erstellte Patterns eine UUID bekommen.

Lösung / Best Practices

Schritt 1: Prüfen, wie das Feld im Index Pattern typisiert ist

In den Dashboards:

  • Menu → Dashboard Management → Index Patterns → wazuh-alerts-*
  • „Refresh“ (Feldliste aktualisieren)
  • data.network.bytes, data.source.bytes, data.destination.bytes suchen und Typ prüfen

Wichtig: Nur wenn der Typ numerisch ist (z. B. number, long), kann SUM funktionieren.

Schritt 2: Index-Template setzen (damit neue Indizes korrekt mappen)

Wenn die Netflow-Felder nicht Teil der Standard-Wazuh-Mappings sind, braucht ihr ein Template, das die Felder als long setzt (Beispiel für OpenSearch Index Templates):

{
  "index_templates": [
    {
      "name": "wazuh-alerts-bytes-template",
      "index_template": {
        "index_patterns": ["wazuh-alerts-*"],
        "template": {
          "mappings": {
            "properties": {
              "data": {
                "properties": {
                  "network": { "properties": { "bytes": { "type": "long" } } },
                  "source":  { "properties": { "bytes": { "type": "long" } } },
                  "destination": { "properties": { "bytes": { "type": "long" } } }
                }
              }
            }
          }
        },
        "priority": 10
      }
    }
  ]
}

Hinweis: Welche Pfade ihr exakt braucht, hängt davon ab, ob eure Netflow-Dokumente in data.* landen oder (wie bei ECS üblich) in network.bytes, source.bytes, destination.bytes. Entscheidend ist: Template muss zum realen Pfad passen, den ihr in Discover seht.

Schritt 3: Mapping-Konflikte beseitigen (sonst brechen Aggregationen weiterhin)

Wenn es bereits Indizes gibt, in denen bytes als String gespeichert wurde, habt ihr drei saubere Optionen:

A) Alte Indizes löschen (nur wenn vertretbar, z. B. Demo/POC)
Im Dev Tools / Console:

DELETE /wazuh-alerts*

Danach neu anfallende Daten laufen in frische Indizes mit dem neuen Template.

B) Reindex (produktionsgeeignet, aber aufwendiger)
Reindexing migriert alte Dokumente in neue Indizes mit korrektem Mapping. Das ist der richtige Weg, wenn historische Daten erhalten bleiben müssen.

C) Zeitfilter strikt auf konfliktfreie Indizes setzen
Kurzfristiger Workaround: Visualisierung nur ab dem Tag anzeigen lassen, an dem das Mapping korrekt ist. Sobald „alte“ Indizes nicht mehr in den Query fallen, funktionieren SUM-Aggregationen.

Schritt 4: „Index pattern associated … no longer exists“ bei alten Visualisierungen reparieren

Wenn Visualisierungen nach dem Aufräumen kaputt sind, liegt das häufig an einer Index-Pattern-ID-Diskrepanz:

  • Visualisierung referenziert z. B. d9634429-46d2-4a77-b4d9-4a71fc458c78
  • Tatsächliches (autogeneriertes) Pattern hat ID: wazuh-alerts-*

Fix ohne Neuklicken aller Visualisierungen: NDJSON exportieren, ID ersetzen, reimportieren

  1. Saved Object(s) exportieren (NDJSON)
  2. In der NDJSON-Datei die alte ID ersetzen, z. B.:
  • Suche: d9634429-46d2-4a77-b4d9-4a71fc458c78
  • Ersetze durch: wazuh-alerts-*
  1. NDJSON wieder importieren

Damit zeigen bestehende Visualisierungen wieder auf das Pattern, das Wazuh automatisch pflegt.

Schritt 5: Bandbreite „intern → extern“ und „extern → intern“ in einer Visualisierung darstellen

Wenn die Bytes-Felder numerisch sauber sind, geht die Logik konzeptionell so:

  • Metrik: SUM(bytes) (z. B. network.bytes)
  • X-Achse: Zeit-Histogramm (@timestamp)
  • Split series / Breakdown:
    • Serie 1: source.locality: internal AND destination.locality: external
    • Serie 2: source.locality: external AND destination.locality: internal

Je nach Visualisierungstyp (Lens/TSVB/Area) setzt ihr das als:

  • Filters aggregation (zwei Filter als separate Serien) oder
  • Terms + zusätzliche Filter (weniger sauber, wenn beides in einem Feld abgebildet werden soll)

Der wichtigste Punkt: „Incoming/Outgoing“ ist in Netflow-Daten nicht automatisch gleich „source/destination“, sondern hängt von eurer Definition (aus Sicht des Sensors, des Hosts, des Netzsegments) ab. Mit *.locality habt ihr aber bereits eine belastbare Semantik, um es als zwei Filter-Serien sauber zu trennen.

Lessons Learned / Best Practices

  • Templates zuerst, Daten danach: Sobald Fremd-Telemetrie (Filebeat Module, Custom Logs, Cloud-Feeds) in wazuh-alerts-* landet, sollten Templates/Mappings früh definiert werden, damit Felder nicht versehentlich als String „festgenagelt“ werden.
  • Index-Pattern-Refresh ist Pflicht nach Mapping-Änderungen, sonst sieht die UI veraltete Feldtypen.
  • Mapping conflicts sind ein Multi-Index-Problem: Selbst wenn „heute“ alles richtig ist, bricht jede Aggregation, sobald „gestern“ mit falschem Typ in den Query fällt.
  • Saved Objects hängen an IDs, nicht an Namen: Beim Neuaufbau von Index Patterns immer an die interne ID denken. In Wazuh-Umgebungen ist wazuh-alerts-* als feste ID ein Vorteil, den man bewusst nutzen sollte.
  • Fehlerbilder wie NPE/Bad Request sind oft Sekundärsymptome einer Aggregation über konfliktierende Mappings, nicht zwingend ein „defektes Dashboard“.

Fazit

Das eigentliche Hindernis für Bandbreiten-Visualisierungen in Wazuh ist meist kein UI-Thema, sondern Mapping-Disziplin: Bytes müssen als numerische Felder gemappt sein, alte Indizes dürfen keine Konflikte mehr erzeugen, und Saved Objects müssen auf die richtige Index-Pattern-ID zeigen. Wer diese drei Ebenen sauber trennt (Template → Indizes → Saved Objects), kann Netflow-Traffic zuverlässig als historische Area-Charts darstellen und bestehende Dashboards ohne Neuanlage wiederherstellen.

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