## Excerpt

Rechenzentren nutzen unterschiedliche Monitoring-Systeme, die Metriken in proprietären Formaten bereitstellen. Für die Anbindung an die NADIKI Observer-Architektur mussten wir bei vier Pilotrechenzentren zwei grundverschiedene Integrationswege entwickeln: In Zabbix ließen sich die Export-Schnittstellen direkt anpassen, bei VictoriaMetrics war eine Datenumwandlung über Telegraf notwendig. Der Artikel beschreibt beide Wege und die Lehren für die Anbindung realer Infrastruktur an den Registrar.

## Content

Die NADIKI Observer-Architektur definiert, welche Metriken ein Rechenzentrum liefern muss, damit Umweltwirkungen berechnet werden können. Die Theorie ist klar — doch reale Rechenzentren betreiben Monitoring-Systeme, die über Jahre gewachsen sind und Daten in eigenen Formaten bereitstellen. Im Arbeitspaket 2.2 des NADIKI Projekts haben wir die Observer-Architektur in vier Pilotrechenzentren integriert und dabei zwei grundverschiedene Integrationswege erprobt.

Zwei Monitoring-Welten, ein Ziel

Unsere Pilotpartner setzen zwei unterschiedliche Monitoring-Systeme ein: Zabbix bei KoloDC (drei Standorte) und VictoriaMetrics bei X-Ion (ein Standort). Beide Systeme erfassen die benötigten Rohdaten — Energieverbrauch, Temperaturen, Kühlleistung —, liefern sie aber nicht in dem Format, das der NADIKI Registrar erwartet.

Das ist keine Überraschung: Monitoring-Systeme in Rechenzentren sind auf Betriebsüberwachung und Alarmierung ausgelegt, nicht auf die Berechnung von Umweltwirkungen. Die Herausforderung liegt weniger in fehlenden Daten als in deren Aufbereitung und Übertragung.

Zabbix: Anpassung der Export-Schnittstellen

Bei den drei KoloDC-Rechenzentren, die alle dieselbe Zabbix-Umgebung nutzen, konnten wir die Export-Schnittstellen direkt anpassen. Zabbix bietet konfigurierbare Exporter, die wir so erweitert haben, dass die Metriken im benötigten Format an den Registrar übermittelt werden. Dieser Integrationsweg ist vergleichsweise unkompliziert: Die Daten werden an der Quelle transformiert und erreichen den Registrar bereits im richtigen Format.

VictoriaMetrics: Datenumwandlung über Telegraf

Bei X-Ion war der Weg komplexer. VictoriaMetrics bietet keine vergleichbar flexible Export-Konfiguration. Die Daten werden über Prometheus Remote Write geschrieben — ein standardisiertes Protokoll, das jedoch ein anderes Datenmodell als die Registrar-Metriken verwendet.

Die Lösung: Telegraf als Umwandlungssystem. Telegraf empfängt die Daten über Prometheus Remote Write, wandelt sie in die für den Registrar notwendigen Formate um und schreibt sie in die InfluxDB des Observer-Systems. Dieser Ansatz erfordert zusätzliche Konfigurationsarbeit, bietet aber einen wiederverwendbaren Baustein für Rechenzentren mit Prometheus-kompatiblen Monitoring-Stacks.

Zwei Muster für die Praxis

Aus den Pilotinstallationen ergeben sich zwei Integrationsmuster, die auf die meisten Rechenzentrumsumgebungen übertragbar sind:

• Quellanpassung: Wenn das Monitoring-System konfigurierbare Exporter bietet, werden die Daten direkt an der Quelle in das Registrar-Format überführt. Geringerer Betriebsaufwand, weniger bewegliche Teile.

• Zwischenschicht: Wenn das Monitoring-System keine flexible Export-Konfiguration bietet, übernimmt Telegraf die Datenumwandlung. Höherer initialer Aufwand, aber entkoppelt vom Monitoring-System des Betreibers.

Beide Wege bestätigen die Designentscheidung der Observer-Architektur: Der Registrar stellt keine Anforderungen an das interne Monitoring eines Rechenzentrums. Er definiert lediglich, welche Metriken in welchem Format ankommen müssen — den Übertragungsweg bestimmt der Betreiber selbst.