Toward an Architectural Blueprint to Observe Sustainability in and by Software Systems

Abstract: Enabling observability in software systems brings many benefits. It can, for example, ease the identification of issues or the implementation of improvements. It is especially critical to be able to observe sustainability-related dimensions of systems to know and mitigate their impact. However, adding observability to a system, especially related to software sustainability, requires technical knowledge that may not be available in every project that would benefit from it. In this work, we propose an architectural blueprint along with its deployment code that can be used to facilitate the addition of observability in software systems. As a special case, it includes measuring the energy consumption of software. This toolkit provides support in defining which components are necessary for a given use case and for structuring their deployment. Moreover, we exemplify the addition of observability in two different use cases.

• The paper proposes a domain-agnostic blueprint that integrates sustainability metrics like energy consumption into software observability systems.
• It details a layered architecture covering metric collection, aggregation, processing, and visualization, validated by use cases in urban agriculture and HPC.
• The approach addresses challenges such as observer effect and data granularity, offering practical, modular deployment guidance for practitioners.

Architectural Blueprint for Sustainability-Driven Observability in Software Systems

Introduction

The paper "Toward an Architectural Blueprint to Observe Sustainability in and by Software Systems" (2604.09278) addresses a critical gap in the current observability landscape: the absence of structured, accessible methodology for integrating sustainability-related metrics into software monitoring solutions. The work proposes a domain-agnostic architectural blueprint and an associated toolkit, allowing software practitioners (SPs) with moderate technical expertise to deploy observability stacks focused not only on traditional system metrics, but also on sustainability indicators such as energy consumption. The authors bridge three elements—blueprint, deployment guidance, and domain-focused case studies—demonstrating the operational value of their approach across urban agriculture and high-performance computing (HPC) domains.

Architectural Blueprint: Structure and Operational Layers

The architectural blueprint is the core artifact of this research. Structured in layered fashion, it delineates distinct concerns: metric collection, data aggregation/storage, processing, and visualization.

Figure 1: The blueprint outlines modular layers for collection, aggregation and storage, analytics processing, and visualization, emphasizing extensibility and domain-independence.

The Collection Layer is responsible for sourcing both conventional system metrics (e.g., CPU, memory, energy) and domain-specific data (e.g., user interactions), emphasizing flexibility in granularity and data type. Data transition to the Aggregation and Storage Layer involves normalization and harmonization, using both time-series and relational databases to efficiently manage high-frequency signals and contextual metadata. The Processing Layer supports complex analytics such as anomaly detection and root-cause analysis, with capabilities for compressing and distilling time-series, thus maintaining storage efficiency while supporting insightful analysis. The Visualization Layer is realized primarily as customizable dashboards, offering perspectives for heterogeneous stakeholders, from non-technical users to system administrators, with integration for alerts and real-time feedback.

The blueprint explicitly targets stack deployers capable of managing infrastructure but not familiar with end-to-end observability platform construction. The provided repository includes templates and deployment instructions, advocating consistent, reproducible, and adaptable integration of observability into new or legacy systems.

Deployment Methodology and Tooling

The work includes operational guidance and deployment exemplars, supporting practitioners in selecting and tailoring stack components to their use case. The repository facilitates environmental configuration via templated files and supports modular or consolidated deployment using orchestration manifests. This approach enables both system-level and user-centric analytics, supporting differentiated access, e.g., isolated sub-dashboard views for non-administrative stakeholders.

The blueprint is not prescriptive regarding underlying tools, advocating modularity and leveraging well-documented, open-source collection, storage, and visualization platforms, such as Grafana, OpenTelemetry, and mainstream time-series databases. The toolkit thus maximizes component reusability and extensibility.

Empirical Use Cases

The blueprint's practical utility is validated across two divergent use cases: urban agriculture (Feed4Food) and distributed resource profiling in HPC (GreenLab). These serve as open-source exemplars, covering both physical/analog domains and compute-intensive software environments.

Urban Agriculture: Feed4Food Stack

In the Feed4Food project, the observability stack is leveraged to monitor sustainability and operational outcomes across urban gardens in multiple living labs. The architecture handles both manual (human-recorded) and automated (software-collected) data, supporting tailored visualizations addressing the requirements of individual gardeners, living lab managers, and project researchers.

Figure 2: The Feed4Food stack integrates dual data sources—manual and automated—and accommodates differentiated dashboard needs for diverse actors within the urban agriculture ecosystem.

Distinct dashboard configurations support bookkeeping, aggregate key performance indicators, and custom exploratory analytics for advanced users. The system's dual-database approach is essential for managing heterogeneous data flows, affirming the blueprint’s flexibility for physical domains with non-traditional data sources.

Distributed Monitoring: GreenLab HPC Stack

In the GreenLab HPC context, collection and aggregation are distributed across compute nodes, automating resource and energy telemetry capture. For administrators, the stack provides system-wide insights and efficient anomaly detection, while for researchers, it supports reproducible experiment monitoring with customizable dashboards and direct export features.

Figure 3: The GreenLab monitoring stack exemplifies distributed collection and aggregation to enable real-time, fine-grained profiling of HPC workloads.

This case highlights the blueprint's ability to manage granularity versus overhead trade-offs: full-stack deployment benefits cluster-level observability, whereas single-process experiments may warrant lighter-weight instrumentation.

Challenges and Trade-Offs

The authors rigorously dissect the technical challenges inherent in sustainability-oriented observability:

• Observer Effect: Profiling overhead can bias measured metrics, necessitating careful trade-offs between data fidelity and system perturbation. Excessive tracing can lead to throughput reductions up to 80% and latency increases of 175%, as demonstrated in prior work [nou2025investigating].
• Security: Sensitive data are at risk throughout the observability pipeline; anonymization and sanitization strategies are necessary but may impede analytics utility [aghili2024empirical].
• Aggregation Versus Granularity: Aggregated metrics can obscure critical outliers necessary for root-cause analysis, while excessive disaggregation overloads storage and hinders real-time capabilities. Tools like TraceRank [yu2023tracerank] illustrate the need for sophisticated, automated analysis of disaggregated traces.
• Dashboard Interpretability: Effective visualization requires both robust design templates and clear documentation to prevent stakeholder misinterpretation, especially in sustainability-focused contexts where domain expertise may be limited.

The modular, domain-agnostic approach facilitates addressing many of these challenges, though further work is emphasized in automating trade-off management, improving deployment documentation, and advancing metrics isolation.

Implications and Future Directions

The blueprint lowers the technical barrier for embedding sustainability metrics into observability infrastructure. It supports comparability, reproducibility, and multi-stakeholder engagement across diverse domains, incentivizing broader adoption of sustainability as an operational first-class concern. The authors identify future work in systematic validation (usability, adaptability), the development of domain-specific modules (collectors, dashboards), and rigorous analysis of trade-offs regarding measurement overhead and data granularity.

Continued advancements are likely to include:

• Automated component selection and deployment via AI-guided orchestration, contingent on robust component documentation.
• Expansion of pre-built, domain-specific modules and visualization schemes.
• Co-design of observability stacks with privacy- and security-preserving data flows.
• Deeper integration with SLCA tools and emission modeling platforms to advance full-cycle sustainability analytics.

Conclusion

This work provides a practical, modular architectural blueprint and supporting toolkit for implementing observability stacks that incorporate sustainability metrics. Demonstrated in the Feed4Food and GreenLab contexts, the approach enables scalable, reproducible deployments across varied domains and stakeholder requirements. By emphasizing extensibility, usability for intermediate practitioners, and robust operational guidance, the blueprint sets a foundation for advancing sustainability-aware software engineering and cross-domain monitoring solutions. Further work is required to validate, optimize, and extend the blueprint for increasingly complex systems and regulatory demands.