Observability: More Than Just a New Trend for Independent Cloud Platforms
In modern cloud and platform environments, observability is no longer just a “nice-to-have” feature that can be addressed later, once the first users have deployed their workloads. Especially in the context of digital independence, monitoring is becoming a cornerstone: Anyone who wants to operate their infrastructure independently in the long term must have a deep understanding of its technical behavior and the characteristics of its users in order to identify emerging problems early, quickly resolve acute issues, and make informed business decisions regarding capacity management.
The following considerations are based on the principles we apply at UhuruTec in the development of our observability platform, uMon.
Why is observability indispensable today?
Observability addresses a fundamental problem of distributed systems.
Modern cloud platforms consist of:
- many interdependent components
- dynamic workloads (e.g., Kubernetes)
- non-deterministic failure patterns
Traditional monitoring is no longer sufficient here. It typically answers the question: “Is something broken?”
Observability, on the other hand, answers: “Why is something broken, and what is actually happening in the system right now?”
What sets open-source observability platforms apart from other proprietary solutions?
Observability platforms therefore ideally complement open-source platforms by providing transparency into implementation, infrastructure, and operational processes, thereby supporting reliable, efficient, and sovereign cloud operations.
- Avoiding black-box dependencies
- No licensing costs, as the platform is vendor-independent
- The ability to act in a crisis lies with the operator, not the vendor
- True data sovereignty through complete control over telemetry data
- Vendor independence means freedom to choose the vendor and the type of support for expansion, implementation, and maintenance
- Product development can be influenced through opportunities for direct participation
- Integrated end-to-end solution through combined, proven open-source components
A functional observability setup is not a single tool, but rather a system composed of principles, technologies, and integrations. It is only through the interaction of all these components that it becomes meaningful and reliable.
What are the key principles of a robust observability platform that must be considered?
A functional observability setup consists not only of a specific technology stack but also represents a system composed of principles, concepts, technologies, and integrations. It is only through the interaction of all components and the adaptation of their defining characteristics that it becomes meaningful, effective, and reliable.
Key requirements for modern observability platforms are:
1. Readiness (“ready-to-use”)
An observability setup must be ready for immediate use, not only after weeks of manual integration.
2. Modularity
Not every environment needs everything. Observability must be adaptable to specific products and use cases.
3. High Availability
The system must always be available in critical situations, as that is when it is needed most.
4. Scalability
The system must be capable of monitoring various operational environments with thousands of nodes, millions of measurement points, and billions of data records within a consolidated observability environment.
5. Compliance and Security
The system must meet current security and certification requirements
(SSO login, access control, encryption, auditing, …)
6. Adaptability
Open-source software and interfaces enable the integration of existing systems and applications (such as ticketing systems and on-call shift management). The system can be extended to meet specific requirements.
7. Integration Capability
Open interfaces enable the integration of existing, high-performance open-source observability technology stacks to leverage and combine the strengths of the respective systems
8. Independence
Observability systems must not be part of the environment being monitored; otherwise, they lose their significance in the event of an emergency.
The Real Core: Meaningful Observability Mechanisms
common mistake is “monitoring for the sake of monitoring.” Effective observability starts with clear questions:
- Which functions are critical for users?
- What types of errors are likely to occur?
- What dependencies exist?
- How should errors be addressed?
- What do I need to plan my platform operations?
- What do I need to evaluate my products and services?
This leads to the following specific requirements:
- Understand system behavior from the user’s perspective
- Understand the technical architecture of the monitored components
- Identify, model, and evaluate specific error scenarios
- Define, understand, and incorporate service quality assurances (SLAs, SLOs, and SLIs)
- Identify and analyze dependencies
- Prepare incident response and mitigation strategies
Observability is an ongoing part of operations and must evolve alongside the system architecture; therefore, every relevant system change also requires adjustments to observability. It serves as a central tool for the operations team to assess the impact of changes and is essential for effectively addressing emerging issues, which is why the entire team should have in-depth knowledge in this area.
Metrics, Logs, and Traces: Why Are All Three Important?
Observability typically rests on three pillars. It is only through their combined effect that true analytical capability is achieved:
1. Metrics
- are time-series-based measurements (e.g., CPU, latency, requests/s)
- are ideal for alerting and capacity planning
- can be efficiently aggregated to provide an overview
Types of Metrics:
- Counters (e.g., total requests)
- Gauges (e.g., current CPU utilization)
- Histograms (e.g., latency distributions)
- Status messages
2. Logs
- are event-based, textual, and structured data
- provide detailed insights into specific individual events
- are important for debugging, auditing, and detailed analysis
Variants:
- Application Logs
- System Logs
- Audit Logs
- Kubernetes Events
3. Traces
- track activities across multiple technical components
- provide detailed information on the implementation- and architecture-specific behavior of the applications in operation
- provide a representative snapshot of system behavior; are captured in regular automated sampling tests
- make dependencies and latency chains understandable
- are essential in microservice architectures
Types:
- Distributed Traces
- Spans (segments of a request)
- Execution Context (similar to a debugger)
Why is the interplay of these three pillars crucial?
Only the combination of these data sources yields a robust root cause analysis.
- Metrics indicate that a problem exists or show how the system behaves from a global perspective.
- Logs show what is happening within the system at the level of technical components.
- Traces show where, how, and why a specific behavior occurs.
A key aspect here is the consolidation of existing observability landscapes.
Instead of fragmented tools, this creates an integrated view of the entire system, enabling an overview and root cause analysis across the entire cloud platform.
The uMon Product Principles
With uMon, UhuruTec takes an approach to providing observability mechanisms in a structured and reproducible manner.
1. A Standardized Product
Existing and established operational knowledge is built into the product:
- Setup and operation of the observability infrastructure
- Data collection, alerting, and integration for typical components such as OpenStack, Ceph, Kubernetes, and Ceph
- Experience gained from using uMon and operating platforms is continuously incorporated into the product
- Scarce engineering resources can be saved during operation and further development
- The operations team’s learning curve can be shortened through training and product maturity
2. Collaboration and Support
Open source makes the product transparent and customizable, and enables a level of collaboration that is not possible with proprietary products:
- Issues and product requirements can be addressed independently as ASL contributions in collaboration with UhuruTec
- Professional feedback on contributions
- Robust support for on-call scenarios and SLA levels through standardized or well-known mechanisms
- For specialists who may be consulted on very rare, niche topics, for example, the product’s implementation and mechanisms are transparent
- An Open Operation Community of Practice offers
3. Product Management and Product Maintenance
In-house developed observability platforms based on open source require a continuous investment of human resources.
The uMon core project provides relief here:
- Issues and product requirements can be outsourced to UhuruTec
- UhuruTec handles the long-term product strategy, standardization, and the product lifecycle
- uMon is maintained by UhuruTec, which ensures that the product remains maintainable
- New implementations, features, and architectural decisions are based on UhuruTec’s cross-organizational experience
4. Freedom of Action and Decision-Making
- Telemetry data is available to you without restriction for analysis, automation, and innovation
- Freedom to make decisions in a crisis: You retain the ability to act and can independently control and adjust systems, configurations, and data
- New features and improvements are driven by your requirements, not primarily by UhuruTec’s product strategy
- Your own ideas, extensions, and automations can be implemented directly and integrated into the platform
- The scope and depth of observability are determined by your requirements, not by licensing models
- Active participation in the open-source project is expressly encouraged and welcomed
- The platform can be customized to meet individual requirements and expanded without vendor restrictions
Open-Source Observability as a Fundamental Principle
Open-source-based cloud environments benefit greatly from open-source-based observability.
While only a limited number of companies currently utilize highly advanced observability, as exemplified by uMon, it is an indispensable solution to the increasing complexity of modern IT infrastructures.
For operations teams, this means, specifically:
- faster fault analysis
- well-informed decisions under time pressure
better capacity planning - greater confidence in their own platform
- the ability to act through understandability and adaptability
- learning from other operations teams or other operational scenarios
For organizations, this means:
- greater control
- fewer dependencies
- greater resilience
- greater investment security
- the usage and participation models within the product can be selected to align with strategic priorities
uMon Availability and Feedback
uMon has been officially available and ready for use since November 2025. Further information, technical details, and download options can be found on the UhuruTec website or directly on GitLab: https://gitlab.com/uhurutec/umon/umon
Feedback from real-world operational scenarios is expressly encouraged and is continuously incorporated into further development.
