Carbon as a first-class signal: bringing software carbon intensity to OpenTelemetry
~4 min read
devopscloud-nativeopentelemetrycarbonkeplerobservability
Cloud-native systems are built to be observable. We collect metrics, logs, and traces to understand application behavior, find bottlenecks, and decide about infrastructure. We watch CPU utilization, memory consumption, request latency, and resource allocation. One dimension of system efficiency is still largely missing from that operational view: carbon emissions.
As sustainability enters the cloud-native conversation, the challenge is no longer whether we can measure energy consumption or estimate emissions. It is whether we can connect that information to the workloads, services, and engineering decisions that influence it.
The ecosystem already has tools for energy and infrastructure data. Kepler exposes energy-related metrics from Kubernetes environments. Other projects surface infrastructure utilization, energy consumption, and the carbon intensity of the electricity powering it.
Collecting measurements is only part of the puzzle. Consider a workload that consumes less energy after an optimization — is it actually more carbon-efficient? What if it now processes twice as many requests? What if the underlying electricity has a different carbon intensity? And how do you attribute shared infrastructure consumption to individual applications?
Traditional observability answers what the system is doing. Carbon measurements add context, but without a consistent way to tie that context to software activity, comparisons fail. The goal is to move from isolated measurements toward understanding the carbon impact of the work software performs.
The Software Carbon Intensity (SCI) specification from the Green Software Foundation provides a methodology for measuring the carbon emissions associated with software. Rather than total emissions alone, SCI relates emissions to a functional unit of software activity:
The functional unit is what makes SCI useful. Two versions of an application: Version A emits 100 kg CO₂e processing one million transactions; Version B emits 110 kg CO₂e processing two million. Version B has higher total emissions but a lower carbon intensity per transaction (0.000055 vs 0.0001 kg CO₂e). Reducing total energy and improving efficiency per unit of work are related, but not interchangeable — SCI gives engineers a structured way to examine both.
OpenTelemetry gave the community a common language for exchanging telemetry. Its semantic conventions define how attributes and measurements are represented consistently across systems, languages, and infrastructure.
That same approach could make carbon data interoperable. Today different tools expose energy consumption, carbon intensity, or estimated emissions under different names, units, and granularities — and connecting them to a specific workload is manual. The SCI-for-OpenTelemetry initiative explores representing SCI concepts with OpenTelemetry semantic conventions: a shared vocabulary for energy consumption, carbon intensity, embodied emissions, and the functional unit, so implementations can exchange sustainability information without tool-specific definitions.
Importantly, this work is evolving — the proposed conventions are not yet finalized or officially adopted OpenTelemetry semantic conventions.
Attribution is where SCI-for-OpenTelemetry gets difficult. Shared infrastructure — a GPU pool, a shared Redis, a multi-tenant node — must be allocated across the workloads that use it. Decisions about when to run a job (grid intensity varies by hour) and where (a greener region) become part of the picture. Connecting an energy measurement to a trace span or a metric series requires the same careful context propagation observability already wrestles with — plus conventions nobody has standardized yet.
The work, driven by Kepler maintainers and the Green Software Foundation, points toward a future where carbon is a first-class OpenTelemetry signal alongside CPU and memory: measured consistently, attributed honestly, and acted on like any other operational metric.
SCI gives teams a defensible metric for carbon efficiency per unit of useful work. OpenTelemetry gives them a place to put it. The combination is still forming, but the direction is clear: sustainability belongs in the same observability tooling you already run, not in a parallel reporting silo.