Einleitung
Die Integration von Grafana in eine Wazuh-Umgebung ist ein häufiger Wunsch, insbesondere wenn es um individuelle Dashboards, Langzeitvisualisierung oder die Korrelation von Security-Daten geht. In produktiven Setups wird der Wazuh Indexer jedoch meist als Cluster betrieben. Genau hier entstehen typische Fragen: Welcher Indexer ist der richtige Anlaufpunkt für Grafana? Was passiert bei einem Node-Ausfall? Und wie sind die Daten im Cluster überhaupt organisiert?
Dieser Artikel klärt diese Fragen aus architektonischer Sicht und zeigt bewährte Vorgehensweisen für eine stabile und hochverfügbare Grafana-Anbindung an den Wazuh Indexer.
Ausgangslage / Problemstellung
Die betrachtete Umgebung besteht aus einem Wazuh Indexer Cluster mit drei Nodes:
- 1 Cluster-Manager (Master)
- 2 Worker-Nodes (Data Nodes)
Ziel ist es, Grafana so anzubinden, dass:
- alle relevanten Wazuh-Daten abgefragt werden können
- kein Single Point of Failure entsteht
- ein Indexer-Ausfall keinen Visualisierungsstillstand verursacht
Die zentrale Unsicherheit liegt darin, ob die Daten zwischen den Indexern geteilt werden und ob Grafana nur auf einen bestimmten Node zeigen darf oder muss.
Technische Analyse
Der Wazuh Indexer basiert auf OpenSearch und folgt dessen Cluster-Prinzipien. Entscheidend sind dabei drei Kernpunkte:
1. Gemeinsamer Datenbestand im Cluster
Die Index-Daten werden im Cluster verteilt und repliziert. Jeder Index besteht aus Shards und Replikas, die über mehrere Nodes verteilt sind. Dadurch ist der Datenbestand logisch „geteilt“, auch wenn physisch nicht jeder Node alle Daten hält.
Für Abfragen bedeutet das:
- Jede Suchanfrage kann über jeden erreichbaren Node im Cluster gestellt werden
- Der angesprochene Node fungiert als Koordinator und sammelt die Ergebnisse clusterweit
2. Rolle des Cluster-Managers
Der Cluster-Manager (Master) steuert Metadaten, Shard-Zuweisung und Cluster-Status.
Er ist nicht exklusiv für Leseabfragen vorgesehen und sollte aus Stabilitätsgründen nicht als einziger Query-Endpunkt für externe Tools missbraucht werden.
3. Abfrageverhalten externer Clients (Grafana)
Grafana nutzt den Elasticsearch/OpenSearch-Datasource-Typ und führt ausschließlich Leseabfragen aus. Es ist demnach vollkommen unerheblich, ob Grafana einen Manager- oder Worker-Node anspricht – solange dieser Teil des Clusters ist.
Lösung / Best Practices
Grundsatz:
Grafana kann technisch auf jeden beliebigen Indexer-Node zeigen.
Empfohlene Best Practice für Hochverfügbarkeit:
- Grafana sollte mehrere Indexer-Nodes als Endpunkte kennen
- Fällt ein Node aus, kann Grafana automatisch einen anderen verwenden
- Die Last wird gleichmäßiger im Cluster verteilt
Je nach Grafana-Version und Plugin-Stand gibt es dafür zwei gängige Ansätze:
Variante 1: Mehrere Endpunkte in der Grafana-Datasource
Einige Grafana-Setups erlauben die Angabe mehrerer Hosts für eine OpenSearch-/Elasticsearch-Datenquelle. Grafana nutzt dann Fallback- oder Round-Robin-Mechanismen.
Variante 2: Load Balancer vor dem Indexer-Cluster (empfohlen)
Ein dedizierter Load Balancer (z. B. HAProxy, NGINX, Cloud-LB) vor den Indexern bietet:
- saubere Entkopplung von Grafana und Cluster-Topologie
- Health Checks pro Node
- transparente Failover-Logik
Grafana spricht in diesem Fall nur den Load Balancer an, nicht einzelne Indexer.
Wichtiger Hinweis:
Grafana benötigt keinen direkten Zugriff auf alle Shards. Jede Abfrage wird intern im Cluster aufgelöst.
Lessons Learned / Best Practices
- Indexer-Daten sind clusterweit verfügbar, nicht nodegebunden
- Grafana kann jeden Indexer als Einstiegspunkt nutzen
- Niemals nur einen einzelnen Node ohne Fallback konfigurieren
- Externe Abfragen sollten den Cluster-Manager nicht exklusiv belasten
- Ein Load Balancer vereinfacht Betrieb und Skalierung erheblich
Gerade in sicherheitskritischen Umgebungen ist Hochverfügbarkeit der Visualisierung ein oft unterschätzter Faktor für Incident Response und Monitoring.
Fazit
In einem Wazuh Indexer Cluster sind die Daten logisch gemeinsam nutzbar, unabhängig davon, welcher Node angesprochen wird. Für Grafana bedeutet das maximale Flexibilität: Jede Indexer-Instanz kann als Query-Endpunkt dienen. Für einen stabilen, ausfallsicheren Betrieb empfiehlt sich jedoch immer eine Multi-Node- oder Load-Balancer-Strategie. So bleibt die Visualisierung auch dann verfügbar, wenn einzelne Indexer temporär nicht erreichbar sind.
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/C07BZJY86G3/p1770456893096739