Multi-Tenant Logging mit Kubernetes & OpenSearch
May 20, 2025
Multi-Tenant Logging mit Kubernetes & OpenSearch: Herausforderungen und Lösungen aus der Praxis
In modernen Cloud-Umgebungen ist effektives Logging eine essenzielle Voraussetzung für Betriebssicherheit, Fehlersuche und Compliance. Besonders herausfordernd wird es, wenn ein Logging-System mehrere Mandanten (Tenants) bedienen muss – mit jeweils eigenen Anforderungen an Sicherheit, Skalierung, Sichtbarkeit und Automatisierung. Unser Partner RISE hat sich dieser Herausforderung gestellt und auf der OpenSearchCon 2025 seine Learnings und Best Practices vorgestellt. Interssierte können den Vortrag auch hier nochmals ansehen. In diesem Artikel fassen wir die zentralen Erkenntnisse zusammen und geben praxisnahe Einblicke in die Architektur, Standardisierung und den Betrieb einer Multi-Tenant Logging-Plattform auf Basis von Kubernetes und OpenSearch.
Die Suche nach dem optimalen Logging-Stack: Von Elasticsearch zu OpenSearch
Die Logging-Reise von RISE begann bereits im Jahr 2015, als man erste Projekte mit ELK-Stacks und X-Pack im österreichischen öffentlichen Sektor realisierte – darunter auch z/OS CICS-Anwendungen. Mit wachsender Erfahrung reifte die Entscheidung, sich von proprietären Lizenzmodellen zu lösen. 2021 wurde ein vollständiger Umstieg auf OpenSearch vollzogen, was der Organisation erlaubte, ein eigenständiges, vollständig verwaltetes Logging-Serviceangebot zu etablieren – frei von kommerziellen Einschränkungen und mit höherer Flexibilität im Plattformbetrieb – das hat zu unserem Produkt LOMOC geführt.
Vom Einzelfall zur Plattform: Warum Standardisierung unverzichtbar wurde
Mit dem Wachstum der Plattform nahm auch ihre Komplexität kontinuierlich zu. Neue Kundenprojekte, verschiedene Umgebungen und ein wachsender Bedarf an Wiederverwendbarkeit führten zu einer schleichenden Heterogenität, die den Betrieb zunehmend erschwerte. Um dem entgegenzuwirken, setzte RISE auf ein stringentes Standardisierungskonzept. Technisch bedeutete das die konsequente Automatisierung aller OpenSearch-relevanten Konfigurationsaspekte wie Clusteraufbau oder Zertifikatsmanagement. In der Anforderungsebene etablierte man verbindliche Konventionen für Indexnamen, Feldtaxonomien und Aufbewahrungsfristen. Auch strukturiertes Logging im JSON-Format wurde verpflichtend. Im operativen Betrieb war es besonders wichtig, durch klare Daten- und Zugriffstrennung eine sichere Mandantenstruktur zu gewährleisten und ein einheitliches Monitoring zu ermöglichen.
Mehrwert statt Infrastruktur: Plattform-Engineering bei RISE
Unser Partner RISE verfolgt im Plattformbetrieb einen klaren Paradigmenwechsel – weg von bloßer Infrastrukturbereitstellung, hin zu einem umfassenden Mehrwertmodell. Ziel ist es, Kunden in die Lage zu versetzen, aus ihren Logdaten selbstständig verwertbare Erkenntnisse zu gewinnen. Dafür stellt die Plattform wiederverwendbare Analyse-Tools und standardisierte Schnittstellen bereit, mit denen verschiedene Rollen wie Entwickler, Betriebsverantwortliche oder Security-Teams effizient arbeiten können. Die Komplexität der Infrastruktur bleibt dabei weitgehend verborgen: Ob HA-Setup, Shard-Zuweisung oder Parsing-Logik – all das wird im Hintergrund automatisiert. Was bleibt, ist ein abstrahiertes und nutzerfreundliches Interface, das statt Technologie operative Ergebnisse in den Vordergrund rückt.
Kubernetes als Fundament: Struktur und Zugriff sicher getrennt
Die Kubernetes-Architektur basiert auf einer klaren Trennung zwischen Entwicklungs-, Test- und Produktionsumgebungen. Innerhalb eines Clusters erhält jeder Mandant eigene Namespaces. Der Zugriff und die Deployment-Rechte werden über LDAP-Gruppen gesteuert, wodurch sichergestellt ist, dass nur befugte Entwickler auf ihre jeweiligen Workloads zugreifen können. Die Implementierung folgt einem GitOps-Ansatz mit ArgoCD, sodass Änderungen nachvollziehbar versioniert und über standardisierte Workflows ausgerollt werden.
Logdatenfluss: Integration von Kubernetes und OpenSearch
Um die Integration zwischen Kubernetes und OpenSearch effizient zu gestalten, etablierte RISE eine durchgängige Datenpipeline. Container-Logs werden über den Kubernetes Logging Operator gesammelt und an Logstash übergeben, der sie dann strukturiert an OpenSearch weiterleitet. Dabei erfolgt die Mandantentrennung nicht nur logisch, sondern auch technisch – mit separaten Logflüssen pro Namespace. Zugriffe werden mandantenspezifisch kontrolliert, und vorkonfigurierte Dashboards ermöglichen den Anwendern eine direkte Analyse ihrer Daten ohne Umwege.
Struktur durch Standard: Indexierung und Parsing mit System
Ein zentrales Element der Standardisierung war die Einführung eines durchdachten Indexnamenschemas. Dieses folgt einem festen Muster, das neben dem Logtyp auch den Mandanten, den Cluster, den Lebenszyklus (z. B. „default“ oder „archive“) und das Datum berücksichtigt. Dadurch können Aufbewahrungsrichtlinien (ISM Policies) automatisiert angewendet werden. Die Logstash-Pipelines wurden ebenfalls modular aufgebaut: Eine Default-Pipeline kümmert sich um das Basisparsing, während für spezifische Kundenanforderungen individuelle Pipelines ergänzt werden können. Auch unstrukturierte Logs wurden berücksichtigt – durch eine pragmatische Balance zwischen Standardisierung und notwendiger Flexibilität.
Automatisierte Aufbewahrung mit ISM Policies
Die Plattform unterscheidet zwischen verschiedenen Retentionsklassen, um den unterschiedlichen Anforderungen an die Aufbewahrungsdauer gerecht zu werden. Neben einer allgemeinen Standard-Policy gibt es langfristige Archivlösungen für Compliance-relevante Daten sowie anpassbare Regeln für spezielle Kundenbedarfe. Die korrekte Zuordnung erfolgt dabei automatisch über das Index-Schema, was den Verwaltungsaufwand erheblich reduziert.
Schneller Einstieg durch deklaratives Onboarding
Das Kunden-Onboarding erfolgt über ein deklaratives Modell mit Custom Resources. Die sogenannte OpenSearchSyncData-Definition beschreibt alle notwendigen Parameter eines neuen Mandanten: Clusternamen, LDAP-Gruppen, Projektname und Namespace. Auf Basis dieser Daten wird automatisiert der zugehörige OpenSearch-Tenant eingerichtet, Rollen und Rechte werden zugewiesen, und Standard-Dashboards geladen. Sobald der Setup-Prozess abgeschlossen ist, startet das Logshipping – und der Kunde kann sofort mit der Analyse beginnen.
Transparenz durch Dashboards und Quotenüberwachung
Zur Unterstützung der Nutzer werden automatisch verschiedene Standard-Dashboards bereitgestellt, darunter Ingress- und Containerübersichten sowie Quotenanzeigen. Letztere beruhen auf einer regelmäßigen Abfrage der Speichernutzung über die _cat/indices-API und geben Kunden wie Betreibern jederzeit Auskunft über den Ressourcenverbrauch. Dieses transparente Reporting fördert nicht nur die Kostenkontrolle, sondern auch das Vertrauen in die Plattform.
Technologische Grenzen und Workarounds im Multi-Tenant-Betrieb
Trotz aller Fortschritte stößt man bei der Nutzung von OpenSearch in mandantenfähigen Umgebungen auf gewisse Limitationen. Beispielsweise erlaubt das Alerting-Plugin keine vollständige Mandantentrennung: Nutzer, die dieselbe Backend-Rolle teilen, können unter Umständen die Alerts anderer sehen oder ändern. Auch beim Log Parsing fehlt es an Self-Service-Funktionalitäten. Logstash ist nicht mandantenbewusst und Änderungen erfolgen ausschließlich manuell – mit entsprechendem organisatorischem Aufwand. Ebenso problematisch ist das Fehlen von nativen Ingest-Limits oder tenantbezogenen Quoten in OpenSearch selbst. Ein einzelner Mandant mit hohem Datenvolumen kann die Performance des gesamten Clusters beeinträchtigen. RISE begegnet diesen Einschränkungen durch externe Überwachung, individuelle Alerting-Metriken und klar abgegrenzte Betriebskonzepte.
Was wir gelernt haben: Prozessklarheit, Zuständigkeiten und Monitoring
Ein wichtiger Lerneffekt bei RISE war die Bedeutung klar definierter Supportprozesse. Durch strukturierte Ticketvorlagen, zentrale Kommunikationskanäle und einheitliche Eskalationswege konnten Rückfragen, Missverständnisse und Verzögerungen drastisch reduziert werden. Ebenso essenziell war die Festlegung technischer und organisatorischer Service-Grenzen. Wer für was verantwortlich ist – etwa bei Alerting, Parsing oder Rollenmanagement – muss klar geregelt sein, um unkontrollierte Verantwortungsverschiebungen und unvorhersehbare Änderungen zu vermeiden. Nicht zuletzt zeigte sich: Ohne umfassendes Monitoring ist der Betrieb einer Multi-Tenant-Plattform kaum beherrschbar. Die frühzeitige Erkennung von Ingestion-Lag, Log-Verzögerungen oder Cluster-Instabilitäten macht den Unterschied zwischen proaktivem Betrieb und reaktivem Troubleshooting. RISE setzt hier auf eine Kombination aus Grafana, Prometheus und OpenSearch Dashboards – ergänzt durch eigene Tools wie „LomocTop“ zur Systemanalyse.
Fazit: Multi-Tenant Logging ist mehr als ein technisches Projekt
Der Aufbau einer skalierbaren, sicheren und mandantenfähigen Logging-Plattform erfordert nicht nur tiefes technisches Verständnis, sondern auch eine durchdachte Prozessstruktur, strategische Entscheidungen und konsequente Standardisierung. RISE hat mit seiner Plattform nicht nur eine leistungsfähige Lösung geschaffen, sondern auch eine Blaupause geliefert, die vielen Unternehmen und Organisationen mit ähnlichen Herausforderungen als Vorbild dienen kann. Diese Wissen bündelt RISE für Sie im Produkt LOMOC - und bei der Produkteinführung steht unseren Kunden die Erfahrung der RISE OpenSearch Experten zur Verfügung!
Interesse am Thema? - Reden Sie mit uns!
Kontakt aufnehmen