Data centers utilize various monitoring systems that provide metrics in proprietary formats. For integration with the NADIKI Observer architecture, we had to develop two fundamentally different integration methods at four pilot data centers: In Zabbix, export interfaces could be directly adjusted, while with VictoriaMetrics, data transformation via Telegraf was necessary. The article outlines both methods and the lessons learned for connecting real infrastructure to the Registrar.
## Excerpt
Data centers utilize different monitoring systems that provide metrics in proprietary formats. To integrate with the NADIKI Observer architecture, we had to develop two fundamentally different integration methods for four pilot data centers: In Zabbix, the export interfaces could be directly adjusted, while in VictoriaMetrics, data conversion via Telegraf was necessary. The article describes both methods and the lessons learned for connecting real infrastructure to the Registrar.
## Content
The NADIKI Observer architecture defines which metrics a data center must deliver to calculate environmental impacts. The theory is straightforward — but real data centers operate monitoring systems that have evolved over the years and provide data in proprietary formats. In work package 2.2 of the NADIKI project, we integrated the Observer architecture into four pilot data centers and tested two fundamentally different integration approaches.
Two Monitoring Worlds, One Goal
Our pilot partners use two different monitoring systems: Zabbix at KoloDC (three locations) and VictoriaMetrics at X-Ion (one location). Both systems capture the necessary raw data — energy consumption, temperatures, cooling capacity — but do not deliver it in the format expected by the NADIKI Registrar.
This comes as no surprise: Data center monitoring systems are designed for operational monitoring and alerting, not for calculating environmental impacts. The challenge lies less in missing data than in their processing and transfer.
Zabbix: Adjusting Export Interfaces
At the three KoloDC data centers, all of which use the same Zabbix environment, we were able to directly adapt the export interfaces. Zabbix offers configurable exporters, which we extended so that the metrics are transmitted to the Registrar in the required format. This integration approach is relatively straightforward: The data is transformed at its source and reaches the Registrar already in the correct format.
VictoriaMetrics: Data Conversion via Telegraf
At X-Ion, the process was more complex. VictoriaMetrics does not offer a comparably flexible export configuration. The data is written via Prometheus Remote Write — a standardized protocol, but with a different data model than the Registrar metrics.
The solution: Telegraf as a conversion system. Telegraf receives the data via Prometheus Remote Write, converts it into the necessary formats for the Registrar, and writes it to the InfluxDB of the Observer system. This approach requires additional configuration work but offers a reusable component for data centers with Prometheus-compatible monitoring stacks.
Two Patterns for Practice
From the pilot installations, two integration patterns emerge that can be applied to most data center environments:
Source Adjustment: When the monitoring system offers configurable exporters, data is converted directly at the source into the Registrar format. Lower operational effort, fewer moving parts.
Intermediary Layer: When the monitoring system does not offer flexible export configuration, Telegraf handles data conversion. Higher initial effort, but detached from the operator's monitoring system.
Both methods confirm the design decision of the Observer architecture: The Registrar does not impose requirements on the internal monitoring of a data center. It merely defines which metrics must arrive in which format — the transmission method is determined by the operator.
