Um im WWU Kube Monitoring und Overvability anbieten zu können, setzen wir auf einen in Kubernetes-Umbebungen klassischen Stack aus Grafana, Prometheus, Loki und Tempo.

Diese Seite soll zum einen beschreiben, wie diese Dienste als Tenant genutzt werden können und auch die Möglichkeiten und Grenzen unserer aktuellen Lösungen aufzeigen.

Organisationen der Daten

Die Metriken, Logs und Traces, die gesammelt werden, werden anhand der organisationalUnit zusammengefasst. Schreib- und Lese-zugriffe der Daten einer organisationalUnit können nicht mehr weiter unterteilt werden.

Frontend

Wir nutzen Grafana als web-basiertes UI. Hier ist es möglich die unterschiedlichen gesammelten Daten zu explorieren und über Dashboards visuell aufzuarbeiten.

Grafana ist unter der grafana.wwu.de erreichbar.

Für die Benutzung von Grafana selbst sei auf die Grafana's Dokumentation verwiesen.

Organisationen

Der Informationszugang in Grafana ist über Organisationen geregelt. Diese Organisationen korrespondieren mit den organisationalUnit aus den Projektanträgen.

Boarding

Die Anmeldung bei Grafana erfolgt über die WWU Kennung. Nach der ersten Anmeldung bekommen Tenants erst einmal nur sehr limitierten Zugriff zu einer Boarding Organisation. Diese ist nur dafür gedacht neue Nutzer aufzufangen. Nach der ersten Anmeldung können dann die Administratoren der unterschiedlichen Organisationen den neuen Nutzer der eigenen Organisation zuweisen. Ein Nutzer kann in mehreren Organisationen sein, aber um die Daten einer Organisation einsehen zu können, muss diese als aktive Organisation erst in der UI ausgewählt werden.

Datasources

In den einzelnen Organisationen sind einige vorkonfigurierte Datasources:

  • Mimir enthält die Metriken des Staging und Produktion Cluster.
  • WWU Kube Staging: Loki enthält die Logs des Staging Cluster.
  • WWU Kube Staging: Tempo enthält die Traces des Staging Cluster.
  • WWU Kube: Loki enthält die Logs des Produktion Cluster.
  • WWU Kube: Tempo enthält die Traces des Produktion Cluster.

Logging

Wir nutzen Loki in Kombination mit Promtail, um Logs im WWU Kube zu sammeln. Hierbei ist Promtail für das sammeln der Daten verantwortlich und diese werden dann in Loki gespeichert und können dort über die Query Language LogQL abgerufen werden. Es ist über diese auch möglich Metriken aus diesen Logs zu erzeugen.

Die Logs aller Pods in den Namespaces der WWU Kubes werden automatisch unter der entsprechenden organisationalUnit gesammelt. Technisch wird dies über die owner Annotation an den Pods gemacht.

Es ist auch möglich externe Dienste und VMs in den Loki im WWU Kube mit einzubinden. Hierfür kann ein eigenes Logtool, wie Promtail oder Vector genutzt werden, um die Logs zu sammeln und dann an die externe Schnittstelle von Loki mit den passenden Credentials zu schicken. Solche Credentials können in Absprache mit den WWU Kube Admins erhalten werden.

Metriken

Um Metriken zu sammeln nutzen wir im WWU Kube Prometheus in Kombination mit dem Prometheus Operator und als Langzeitspeicher dieser Metriken Mimir.

Metriken von Diensten aus dem WWU Kube

Um die Metriken solcher Dienste zu sammeln, gibt es einige CRDs im WWU Kube, die genutzt werden können, um zu beschreiben, welche Metriken gesammelt werden sollen. Eine genauere Beschreibung dieser CRDs kann in der Dokumetantion des Prometheus Operator gefunden werden. Der häufigste Fall ist vermutlich ein ServiceMonitor, um die Metriken eines Service zu bekommen.

Um den Einstieg hier zu erleichtern gibt es Beispiele, wie solche Metriken im WWU Kube gesammelt werden können.

Metriken vom Cluster

Einige Metriken, wie beispielsweise, ob ein Dienst up ist oder der CPU- und Memory-Verbrauch sind nicht Metriken der eigenen Dienste, sondern werden von externen Clusterdiensten gesammelt. Damit solche Metriken, trotzdem von unseren Tenants genutzt werden können, versuchen wir die Metriken der organisationalUnit mit einigen Clustermetriken anzureichern. Natürlich aber nur mit Metriken, die mit den entsprechenden Namespaces der organisationalUnit korrespondieren.

Momentan ist dies eine Teilmenge der Metriken des Kubelet und des Dienstes kube-state-metrics.

Wenn weitere Clustermetriken benötigt werden, werden wir schauen, ob wir diese zur Verfügung stellen können.

Alerting

Leider ist es momentan noch nicht möglich auf Basis von Metriken Alerts zu generieren. Dies ist jedoch etwas, dass wir anbieten wollen und wir arbeiten daran auch dieses Feature Multi-Tenant-fähig in den WWU Kube zu bringen.

Tracing

Der WWU Kube ist auch in der Lage Traces von Diensten zu sammeln. Hierfür nutzen wir den OpenTelemetry Collector, um die Daten in unterschiedlichen Formaten anzunehmen und Tempo, um diese zu speichern und auslesen zu können.

Senden von Traces

Auf jedem Node im WWU Kube läuft ein OpenTelemetry Collector Agent, der über diverse Ports und Protokolle Traces entgegen nimmt. Dieser ist dann von innerhalb der Pods über host:<port> erreichbar.

Momentan unterstützen wir im WWU Kube die folgenden Schnittstellen:

ProtokollPort
otlptcp/4317
Jaeger GPRCtcp/14250
Jaeger Thrifttcp/14268
Jaeger Thrift Binaryupd/6832
Jaeger Thrift Compactudp/6831
zipkintcp/9411

Im WWU Kube setzen wir, soweit es geht, auf otlp und empfehlen das auch unseren Kunden. Momentan wirkt es so als würde sich das Tracing so langsam auf dieses Protokoll konsolidieren. In der Zukunft planen wir auch Protokolle, die sich nicht durchgesetzt haben wieder auszuschalten.

Um den Einstieg hier zu erleichtern gibt es Beispiele, wie solche Traces verschickt werden können.

Trace IDs in Logs und Grafana

Damit man die die Trace ID zu einzelnen Anfragen oder ähnlichem bekommt, loggen die meisten Dienste diese. Grafana versucht per Regex die Trace ID in Logs zu erkennen und kann dann direkt in der UI zwischen Logs und Traces hin und her schalten. Falls diese nicht erkannt wird, können wir schauen, ob wir die Regex dafür in Grafana anpassen können.

Aktivieren der Funktionalität

Da es noch einige manuelle Handgriffe erfordert, können diese Funktionalitäten für jeden Tenant erst nach Absprache mit den WWU Kube Admins angeschaltet werden.

Dafür reicht eine einfache Email an cloud@wwu.de mit den Informationen, um welche organisationalUnit es sich handelt und an welchen Dienste Interesse besteht.

  • Keine Stichwörter