Kohlenstoff als Signal erster Klasse: Software-Kohlenstoffintensität in OpenTelemetry bringen
🇬🇧 Read in English~4 min read
devopscloud-nativeopentelemetrycarbonkeplerobservability
GPU-Teams stehen vor einem schlechten Kompromiss: ein Control Plane pro Team oder schwache Isolation in einem gemeinsamen Cluster. Dieses reproduzierbare Labor kombiniert Kamaji (Control Planes als Pods) und HAMi (fraktionierte GPUs) auf einer einzigen Maschine ohne GPU, unter Verwendung von HAMis Mock-Device-Plugin.
Cloud-native Systeme sind darauf ausgelegt, observabel zu sein. Wir sammeln Metriken, Logs und Traces, um das Anwendungsverhalten zu verstehen, Engpässe zu finden und Entscheidungen über die Infrastruktur zu treffen. Wir beobachten CPU-Auslastung, Speicherverbrauch, Anforderungslatenz und Ressourcenzuweisung. Eine Dimension der Systemeffizienz fehlt in dieser operativen Sicht jedoch weitgehend: Kohlenstoffemissionen.
Da Nachhaltigkeit Einzug in die Cloud-native-Diskussion hält, ist die Herausforderung nicht mehr, ob wir Energieverbrauch messen oder Emissionen schätzen können. Es geht darum, ob wir diese Informationen mit den Workloads, Diensten und Engineering-Entscheidungen verbinden können, die sie beeinflussen.
Das Ökosystem verfügt bereits über Werkzeuge für Energie- und Infrastrukturdaten. Kepler stellt energiebezogene Metriken aus Kubernetes-Umgebungen bereit. Andere Projekte machen Infrastrukturauslastung, Energieverbrauch und die Kohlenstoffintensität des zugrunde liegenden Stroms sichtbar.
Das Sammeln von Messwerten ist nur ein Teil des Puzzles. Betrachten wir einen Workload, der nach einer Optimierung weniger Energie verbraucht – ist er tatsächlich kohlenstoffeffizienter? Was, wenn er nun doppelt so viele Anfragen verarbeitet? Was, wenn der zugrunde liegende Strom eine andere Kohlenstoffintensität hat? Und wie ordnet man den Verbrauch gemeinsamer Infrastruktur einzelnen Anwendungen zu?
Traditionelle Observability beantwortet, was das System tut. Kohlenstoffmessungen fügen Kontext hinzu, aber ohne eine konsistente Möglichkeit, diesen Kontext mit Softwareaktivitäten zu verknüpfen, scheitern Vergleiche. Das Ziel ist, von isolierten Messungen zu einem Verständnis der Kohlenstoffauswirkungen der von Software ausgeführten Arbeit zu gelangen.
Die Software Carbon Intensity (SCI)-Spezifikation der Green Software Foundation bietet eine Methodik zur Messung der mit Software verbundenen Kohlenstoffemissionen. Statt nur der Gesamtemissionen setzt SCI Emissionen in Beziehung zu einer funktionalen Einheit der Softwareaktivität:
Die funktionale Einheit macht SCI nützlich. Zwei Versionen einer Anwendung: Version A emittiert 100 kg CO₂e bei der Verarbeitung von einer Million Transaktionen; Version B emittiert 110 kg CO₂e bei der Verarbeitung von zwei Millionen. Version B hat höhere Gesamtemissionen, aber eine niedrigere Kohlenstoffintensität pro Transaktion (0,000055 vs. 0,0001 kg CO₂e). Die Reduzierung des Gesamtenergieverbrauchs und die Verbesserung der Effizienz pro Arbeitseinheit sind verwandt, aber nicht austauschbar – SCI gibt Ingenieuren eine strukturierte Möglichkeit, beides zu untersuchen.
OpenTelemetry hat der Community eine gemeinsame Sprache für den Austausch von Telemetrie gegeben. Seine Semantikkonventionen definieren, wie Attribute und Messwerte konsistent über Systeme, Sprachen und Infrastruktur hinweg dargestellt werden.
Derselbe Ansatz könnte Kohlenstoffdaten interoperabel machen. Heute legen verschiedene Werkzeuge Energieverbrauch, Kohlenstoffintensität oder geschätzte Emissionen unter unterschiedlichen Namen, Einheiten und Granularitäten offen – und die Verbindung mit einem bestimmten Workload erfolgt manuell. Die SCI-for-OpenTelemetry-Initiative untersucht, wie SCI-Konzepte mit OpenTelemetry-Semantikkonventionen dargestellt werden können: ein gemeinsames Vokabular für Energieverbrauch, Kohlenstoffintensität, graue Emissionen und die funktionale Einheit, sodass Implementierungen Nachhaltigkeitsinformationen ohne toolspezifische Definitionen austauschen können.
Wichtig ist, dass diese Arbeit sich noch in der Entwicklung befindet – die vorgeschlagenen Konventionen sind noch nicht finalisiert oder offiziell als OpenTelemetry-Semantikkonventionen übernommen.
Attribution ist der Punkt, an dem SCI-for-OpenTelemetry schwierig wird. Gemeinsame Infrastruktur – ein GPU-Pool, ein gemeinsames Redis, ein Multi-Tenant-Knoten – muss auf die Workloads verteilt werden, die sie nutzen. Entscheidungen darüber, wann ein Job ausgeführt wird (die Netzkohlenstoffintensität variiert stündlich) und wo (eine grünere Region), werden Teil des Bildes. Die Verbindung einer Energiemessung mit einem Trace-Span oder einer Metrikreihe erfordert dieselbe sorgfältige Kontextweitergabe, mit der sich Observability bereits auseinandersetzt – plus Konventionen, die noch niemand standardisiert hat.
Die Arbeit, vorangetrieben von den Kepler-Maintainern und der Green Software Foundation, weist auf eine Zukunft hin, in der Kohlenstoff ein Signal erster Klasse in OpenTelemetry ist – neben CPU und Speicher: konsistent gemessen, ehrlich zugeordnet und behandelt wie jede andere operative Metrik.
SCI gibt Teams eine vertretbare Metrik für Kohlenstoffeffizienz pro Einheit nützlicher Arbeit. OpenTelemetry gibt ihnen einen Ort, um sie abzulegen. Die Kombination ist noch im Entstehen, aber die Richtung ist klar: Nachhaltigkeit gehört in dieselben Observability-Werkzeuge, die Sie bereits betreiben – nicht in ein paralleles Berichts-Silo.