By Diana Todea, CNCF Ambassador and Head of Developer Relations Engineering at VictoriaMetrics
Observability is built around signals. We collect metrics to understand system behavior, traces to follow requests across distributed systems, and logs to investigate what happened at a particular point in time. Together, these signals help engineers answer familiar questions about latency, reliability, capacity and cost.
But there is another dimension of our systems that is largely absent from this picture: carbon.
Software consumes energy. The hardware running it has embodied emissions, and the electricity powering that hardware has a carbon intensity that changes depending on where and when it is generated. The environmental impact exists whether we observe it or not. Yet when we investigate a service, workload or trace, that context is usually missing.
What would change if carbon became another observable property of our systems?
From carbon accounting to engineering data
Carbon is already measurable data outside the software world. Electricity grids, for example, track the carbon intensity of electricity over time and across locations. In software, meanwhile, we already know a great deal about the workloads consuming that electricity: CPU utilization, infrastructure location, request volume, latency, errors and resource consumption.
The challenge is connecting those two worlds.
One important building block is the Software Carbon Intensity (SCI) specification from the Green Software Foundation. SCI expresses software carbon emissions relative to a functional unit. That last part is particularly interesting from an engineering perspective.
Instead of asking only how much carbon an entire system emitted, we can start asking questions such as: How much carbon was associated with a transaction? An API request? Serving a user? Processing a job?
The functional unit connects environmental impact to useful work performed by software.
At a high level, SCI considers four components: energy consumed by the software, the carbon intensity of that energy, embodied emissions associated with the hardware, and the functional unit representing the work performed.
That gives us a methodology for calculating software carbon intensity. It does not, however, solve the observability problem.
SCI can standardize the calculation. OpenTelemetry can standardize the signal.
This distinction is important.
SCI provides a model for what we are measuring. OpenTelemetry addresses a different problem: creating common ways to describe, generate and transport telemetry across languages, platforms and tools.
Bringing the two together raises an interesting possibility. If sustainability data can be represented using shared telemetry conventions, carbon information does not necessarily need to live inside a separate sustainability system. It could travel through the same observability ecosystem engineers already use for other operational signals.
This is the idea being explored through work between the Green Software Foundation and the OpenTelemetry community. Rather than inventing another carbon methodology, the goal is interoperability: examining SCI through the OpenTelemetry model and determining which concepts already exist, which are missing, what should be represented as metrics or context, and what vocabulary implementations could share.
The two communities approach the problem from complementary directions. The Green Software Foundation brings the carbon methodology and sustainability expertise. OpenTelemetry brings experience with telemetry models, semantic conventions, instrumentation and interoperability.
That separation of responsibilities matters. The objective is not to make OpenTelemetry a carbon accounting system. It is to investigate whether carbon data can become interoperable telemetry.
The building blocks already exist
This idea is less theoretical than it might initially sound.
The cloud-native ecosystem already contains many of the individual components required to build carbon-aware observability. Energy information can be obtained from infrastructure such as CPUs and GPUs. Projects such as Kepler can expose energy-related information as telemetry, while existing monitoring systems can collect it. That information can then potentially be enriched with carbon-intensity or cost data.
Operational systems can already act on telemetry as well. Autoscaling, workload scheduling and removal of unnecessary resources are familiar automation patterns. What does not yet exist is one universally integrated stack connecting all of these pieces into a standardized carbon signal.
That distinction is useful because it changes the problem. We do not necessarily need an entirely new observability architecture for sustainability. We need better ways of connecting information that is currently fragmented.
Carbon as operational context
Consider an engineer investigating a slow request.
Today, they might look at its latency, resource consumption, infrastructure location and perhaps its cost. Now imagine that the same investigation could also show that the request was unusually carbon intensive.
Carbon would not replace performance, reliability or cost. It would provide another dimension for understanding the system.
That additional context could affect familiar engineering decisions: when a workload runs, where it runs, how much infrastructure it requires, or whether some work needs to happen at all.
This also highlights why sustainability should not be treated simply as another optimization target. Cost, energy consumption and carbon frequently overlap, but they are not interchangeable. Using fewer resources can reduce both cost and energy consumption, for example, while deleting unused infrastructure can improve efficiency across several dimensions.
But the cheapest infrastructure is not automatically the lowest-carbon option, and the most energy-efficient decision can depend on location and time. Observability gives engineers the context needed to understand these trade-offs rather than optimizing one dimension in isolation.
Making carbon actionable
There is still substantial work ahead before carbon could reasonably be described as a mature first-class OpenTelemetry signal.
Semantic conventions need to be challenged against real systems. Implementations need to be built. Engineers need to determine where proposed models work, where they fail and which assumptions do not survive contact with production infrastructure.
But engineers do not necessarily have to wait for every standard to be finished before thinking about the problem.
We can start with the systems we already optimize: compute, infrastructure, cost, performance and capacity. Many of those decisions already influence energy consumption and carbon emissions. The question is whether sustainability information can become another piece of context within those existing workflows rather than another isolated operational silo.
That leads to a relatively simple progression: measure it, connect it to cost and performance, and use it when making engineering decisions.
SCI gives us a way to measure. OpenTelemetry gives us a potential common language for telemetry. The opportunity is to connect the two so carbon can eventually become something engineers can observe alongside the signals they already understand.
Because what we make observable, we can make actionable.
KubeCon + CloudNativeCon is taking place in Salt Lake City, Utah from November 9 to 12. Register Now!
##
ABOUT THE AUTHOR
Diana is a CNCF Ambassador and Operational Resilience TAG lead, co-leads the Neurodiversity Merge Forward community, and organizes Cloud Native Days Romania. Professionally, she is the Head of Developer Relations Engineering at VictoriaMetrics, where she works at the intersection of developer experience, observability, and open source community engagement.
