Extending the OpenTelemetry java auto-instrumentation agent to publish green software metrics
Status:: π©
Links:: OpenTelemetry Java Agent Extension by RETIT
Metadata
Authors:: Brunnert, Andreas; Gutzy, Ferdinand
Title:: Extending the OpenTelemetry java auto-instrumentation agent to publish green software metrics
Date:: 2024
Publisher:: Gesellschaft fΓΌr Informatik e.V.
URL:: https://dl.gi.de/handle/20.500.12116/45524
DOI::
Brunnert, A. and Gutzy, F. (2024) βExtending the OpenTelemetry java auto-instrumentation agent to publish green software metricsβ, in. Softwaretechnik-Trends Band 44, Heft 4, Gesellschaft fΓΌr Informatik e.V. Available at: https://dl.gi.de/handle/20.500.12116/45524 (Accessed: 19 January 2025).
Related:: @Brunnert.2024.GreenSoftwareMetrics
The increasing focus on the carbon emissions of the IT sector has led to the creation of green software metrics that attempt to quantify the environmental impact of software in terms of carbon emissions. One of the most prominent examples is the Software Carbon Intensity (SCI) metric, recently standardized as ISO/IEC 21031:2024, which is defined as the rate of carbon emissions for a software system. Despite the merits of these metrics, development teams often lack the tools to capture them for their software systems. This paper attempts to address this challenge by presenting an extension to the OpenTelemetry Java Auto-Instrumentation Agent to collect not only traditional performance metrics such as response time, throughput, and resource utilization, but also carbon emission data for an instrumented software system.
Notes & Annotations
Color-coded highlighting system used for annotations
π Annotations (imported on 2025-01-19#10:26:16)
We use OpenTelemetry4 as standard for capturing and transferring the metrics from the application to Prometheus5 as time series database. Grafana6 is used to visualize and calculate the carbon emissions per transaction as well as per server, container, or virtual machine involved in processing a transaction over time.
The reason for this change is that we are now using freely available data8 from the Cloud Carbon Footprint (CCF)9 project to calculate the emissions, which are bundled with the application and do not change over time.
Figure 2: Resource Profile
We use the same concepts to capture the resource demand (d) values for CPU (dCPU), memory (dMEM), storage (dSTO), and network (dNET) for each method (or transaction) by extending the existing measurement probes injected by the OTel Java AutoInstrumentation Agent using a SpanProcessor10.
As the total CPU utilization (CPUutil) is not directly related to the CPU demands of a single transaction of a system, we need to measure CPUutil in order to calculate the current power consumption of the CPU, and then we can allocate the power consumption proportionally to single transactions of the system. To do this, the CPU demand data needs to be converted into a utilization value (CPUutilT) by summing up all CPU demand values (measured in ms) of a transaction in a given time period (where t0 is the start timestamp of the time period in ms and tn is the end of the end timestamp of the time period in ms) and dividing this sum by the total time the CPU was busy in that time period
The R value can be omitted because all values are already scoped to a single functional unit, namely the transaction for which the resource demand values were measured.
The current implementation state of the emission calculation relies on many data sources that are based on assumptions and configurations. In addition, the data sources are static which is not realistic considering the GEF differences during day and night for renewable energy sources. Therefore, we are working on integrating other data sources that are more up-to-date with the current grid system on the one hand and the actual energy consumption of the system on the other hand. In addition, we plan to perform evaluations comparing our calculations with real measurements to see how well they represent the reality.