At the recent Observability Summit Europe, the CNCF announced a draft to embed Software Carbon Intensity (SCI) into OpenTelemetry’s data model. By turning carbon‑related metrics into a standard observability signal, engineers can now attach emissions data to the same traces, metrics, and logs they already use for performance debugging.
Why Software Carbon Intensity matters now
SCI expresses emissions per functional unit—such as a request or transaction—rather than total kilograms of CO₂e. The specification separates raw energy use (E), electricity carbon intensity (I), and embodied hardware emissions (M) and then divides by the work performed (R). This approach lets teams compare two versions of an application on a per‑request basis, revealing that a higher total emission figure can still represent a more efficient service if it processes more work.
OpenTelemetry conventions under development
The proposed conventions would add attributes for energy consumption, carbon intensity, embodied emissions, and the functional unit used in the SCI calculation. The goal is not to replace existing performance signals but to provide a consistent vocabulary that any OpenTelemetry‑compatible collector can understand. The draft is still evolving; it is explicitly noted that the conventions are not yet finalized or officially adopted.
Architectural and operational considerations
Existing cloud‑native stacks already expose energy‑related data. Projects such as Kepler can emit Kubernetes‑level power metrics, while other tools report grid carbon intensity. The new conventions require that this raw data be correlated with the specific workload that generated it. Practically, this means:
- Instrumenting services to propagate a functional‑unit identifier (e.g., request ID) into telemetry so that energy and emissions attributes can be attached to the same span.
- Extending metric pipelines (Prometheus, OpenTelemetry Collector) to ingest additional attributes without breaking existing dashboards.
- Designing attribution logic for shared resources (nodes, storage) to allocate a portion of their energy use to each running pod or service.
- Ensuring that data retention policies account for the potentially larger cardinality introduced by per‑request carbon attributes.
Because the conventions are not yet stable, teams should treat any early implementation as experimental. Integration points that rely on hard‑coded attribute names may need to be refactored once the spec is finalized.
Related CloudNinjas coverage: hands-on guides.
What This Means For Practitioners
Engineers should monitor the SCI‑for‑OpenTelemetry proposal as it moves through CNCF review. In the meantime, evaluate whether your observability stack can accept custom attributes and whether your energy‑monitoring tools (e.g., Kepler) already expose the raw signals needed for SCI calculations. If you plan to report carbon metrics to stakeholders, prototype a lightweight attribution layer that ties pod‑level power readings to request identifiers. Finally, be prepared to update instrumentation and dashboards when the conventions graduate to an official release.
