Betrieb & Monitoring
OpenSearch
OpenSearch ist eine quelloffene Such-/Analytics-Engine (Apache 2.0), 2021 aus Elasticsearch geforkt, seit 2024 bei der Linux Foundation; für Log-Analytics und SIEM.
- Verteilte Such-/Analytics-Engine (Lucene)
- Log-Analytics, Volltextsuche, SIEM
- Security-Plugin (TLS, RBAC) inklusive
- Cluster, Shards, Replicas
- Apache 2.0, Linux Foundation
OpenSearch ist eine verteilte Such- und Analytics-Engine auf Basis von Apache Lucene, ergänzt um OpenSearch Dashboards zur Visualisierung. Sie entstand 2021, als AWS die letzte Apache-2.0-Version von Elasticsearch (7.10.2) und Kibana forkte, nachdem Elastic auf restriktivere Lizenzen umgestellt hatte. Seit 2024 liegt das Projekt unter der OpenSearch Software Foundation der Linux Foundation und ist damit nicht mehr von einem einzelnen Anbieter abhängig.
Dieser Artikel erklärt die Fork- und Lizenz-Historie, die Cluster-Architektur mit Nodes, Shards und Replicas, die Anwendungsfälle Log-Analytics, Volltextsuche und SIEM, das kostenfreie Security-Plugin, das Index State Management für Log-Retention, die Ingest-Wege sowie die Betriebsfragen rund um RAM und Shard-Management. Eine sachliche Abgrenzung zu Elastic Stack und Loki gehört dazu.
1. Herkunft und Lizenz
Anfang 2021 stellte Elastic Elasticsearch und Kibana ab Version 7.11 von Apache 2.0 auf die nicht-quelloffenen Lizenzen SSPL und Elastic License um. AWS reagierte mit einem Fork der letzten Apache-Version (7.10.2) und nannte ihn OpenSearch; er blieb unter Apache 2.0. 2024 übergab AWS das Projekt an die neu gegründete OpenSearch Software Foundation unter dem Dach der Linux Foundation, was eine herstellerneutrale Governance schafft.
2. Cluster, Nodes, Shards, Replicas
Ein OpenSearch-Cluster besteht aus mehreren Nodes mit Rollen: Cluster-Manager (verwaltet den Cluster-Zustand), Data (speichert und durchsucht Daten), Coordinating (verteilt Anfragen und aggregiert Ergebnisse) und weitere. Ein Index ist eine Sammlung von JSON-Dokumenten und wird in Primary Shards zerlegt; jeder Shard ist eine eigene Lucene-Instanz. Replica Shards sind Kopien auf anderen Nodes für Ausfallsicherheit und Lese-Skalierung. Die Zahl der Primary Shards ist nach Index-Erstellung fix.
Shards und RAM sind die Stellschrauben
OpenSearch läuft auf der JVM und ist speicherhungrig. Faustregeln aus dem Betrieb: JVM-Heap auf rund die Hälfte des RAM, höchstens etwa 31 GB; und nicht zu viele Shards pro Heap-GB. Zu kleine, zu viele Shards (Over-Sharding) sind ein häufiger Performance-Killer.
3. Anwendungsfälle: Logs, Suche, SIEM
Der häufigste Einsatz ist Log-Analytics/Observability: Logs werden über Fluent Bit, Logstash oder Data Prepper eingespeist, in zeitbasierten Indizes gespeichert und über Dashboards ausgewertet. Dazu kommt klassische Volltextsuche über die Query DSL. Mit dem integrierten Security-Analytics-Plugin wird OpenSearch zum SIEM: Detektoren auf Basis von MITRE-ATT&CK-Regeln korrelieren Findings über viele Log-Typen. Neuere Versionen bieten zudem Vektor-/k-NN-Suche für KI-Anwendungen.
4. Security-Plugin und Index-Lifecycle
Das Security-Plugin ist in jeder Distribution ohne Aufpreis enthalten und bietet TLS, Authentifizierung (LDAP, Active Directory, SAML, OpenID Connect), rollenbasierte Zugriffskontrolle bis auf Dokument- und Feldebene sowie Audit-Logging. Das Index State Management (ISM) automatisiert den Lebenszyklus: Policies definieren Zustände und Übergänge (Rollover nach Größe/Alter, Verschiebung auf günstigere Knoten, Snapshot, Löschung), was für eine kontrollierte Log-Retention zentral ist.
5. Ingest, Wazuh und Einordnung
Zum Einspielen dient bevorzugt Data Prepper (serverseitige Aufbereitung), daneben Fluent Bit, Fluentd oder Logstash-OSS. Für die Verbindung zur Sicherheits-Welt relevant: Der Wazuh Indexer ist selbst ein OpenSearch-Fork und dient als Speicher-Backend des Wazuh-SIEM. Gegenüber Loki ist der Unterschied grundlegend: OpenSearch baut einen Volltext-Index (schnelle Suche, aber ressourcenintensiv), Loki indiziert nur Labels (günstig, aber ohne echten Volltext).
Die Wahl zwischen einem Volltext-System wie OpenSearch und einem Label-System wie Loki ist keine Glaubensfrage, sondern eine Kostenfrage: Wer schnelle Suche über beliebige Felder braucht, zahlt sie mit Speicher und RAM; wer nur grep-artig filtert, kommt mit Loki deutlich günstiger weg.
6. Stärken und Grenzen
| Stärken | Grenzen |
|---|---|
| Apache 2.0, herstellerneutrale Governance (Linux Foundation) | Ressourcenhungrig: JVM/RAM, sorgfältiges Cluster-Sizing nötig |
| Security-Plugin (TLS, RBAC, SAML/OIDC) frei enthalten | Cluster-Betrieb komplex (Rolling Upgrades, Snapshots) |
| Skalierbare Log-Analytics plus SIEM in einem Stack | Primary-Shard-Zahl nach Index-Erstellung unveränderlich |
| Schnelle Volltextsuche über die Query DSL | Over-Sharding ist ein häufiger Performance-Fehler |
| Vektor-/k-NN-Suche für KI-Anwendungen | API zunehmend von Elasticsearch divergiert |
Häufige Fragen zu OpenSearch
OpenSearch ist 2021 als Apache-2.0-Fork der letzten frei lizenzierten Elasticsearch-Version (7.10.2) entstanden, nachdem Elastic auf SSPL/Elastic License umgestellt hatte. Seitdem entwickeln sich beide getrennt; das Security-Plugin ist bei OpenSearch frei, und OpenSearch steht heute unter der Linux Foundation.
OpenSearch baut einen Volltext-Index und eignet sich für schnelle Suche über beliebige Felder und SIEM, kostet dafür aber mehr RAM und Speicher. Loki indiziert nur Labels, ist deutlich günstiger für Langzeit-Logs, bietet aber keinen echten Volltext-Index. Die Wahl hängt vom Such-Bedarf ab.
Auch der Autor ist nur ein Mensch, dem Fehler unterlaufen können. Wenn in diesem Beitrag etwas nicht stimmt oder unklar ist, freuen wir uns über einen kurzen Hinweis über das Kontaktformular unten, wir prüfen und korrigieren das.
Der nächste Schritt
OpenSearch im eigenen Haus richtig einsetzen?
Wir klären, ob und wie der Baustein zu Ihrer Infrastruktur passt, und sagen offen, wann sich der Aufwand lohnt und wann nicht.