How Stonal Accelerated Issue Diagnosis and Met European Compliance Standards while Decreasing Observability Costs with OpenObserve

About Stonal

Stonal is a 120-person French PropTech company that helps real estate clients, primarily in the social housing sector, better manage their property assets. The company collects and consolidates data to give property managers a comprehensive view of their buildings and portfolios.

Stonal runs a sophisticated Kubernetes infrastructure across four clusters serving both multi-tenant and single-tenant customer deployments.

The Challenge(s)

When Florent Clairambault joined Stonal as CTO, the company was using an on-premise solution based on the EFK stack (Elastic, Fluentd, Kibana). As it was very storage-intensive and had significant limitations (only 15 days of retention due to storage costs), Florent looked for alternatives, someone mentioned SigNoz, a cloud-based observability solution and the team went for it.

Several pain points quickly emerged:

• Unpredictable and growing costs, especially around metrics. "The pricing was inconvenient because they were invoicing us for metrics, which had a very high price," Florent explains. The budget allocated for observability was frequently exceeded, creating internal friction.

• Developer experience gaps. The development team struggled with SigNoz's user interface. "Developers weren't big fans of the UI. The SigNoz UI is a bit flashy, kind of unconventional," Florent notes. This friction slowed adoption and made troubleshooting more difficult.

• Data residency concerns. With GDPR compliance requirements and growing concerns around the Cloud Act, keeping observability data outside of European infrastructure was becoming increasingly problematic for Stonal's clients.

The Solution with OpenObserve

A senior engineer of the team, Patrice, discovered OpenObserve and suggested they could test it, Florent tested it and was immediately struck by its deployment simplicity. He was able to get OpenObserve up and running in minutes. "The first time I tried it, I created a user on the PostgreSQL instance, started the deployment on Kubernetes, and it just worked," Florent recalls. "I switched our OpenTelemetry collectors from SigNoz to OpenObserve, and it worked fine." This seamless transition allowed Stonal to run both platforms in parallel before fully migrating.

Beyond fast set up, OpenObserve provided a familiar, developer-friendly experience. "The OpenObserve UI is a lot more similar to Kibana or Datadog. It doesn't feel like a whole new universe and that's a good thing." The SQL-based query language proved especially valuable: "Since it supports SQL, we are not lost in it. The developers get comfortable with it really fast."

While adoption of a new tool is not always frictionless, Florent specifically cites how helpful and responsive the product team was. When Stonal encountered challenges with memory consumption, the OpenObserve team delivered a solution within days. "I told them it would be simpler to just split streams per app using dynamic streams. They did it in two or three days. I was amazed."

Today, Stonal runs OpenObserve across four Kubernetes clusters with three-tier OpenTelemetry collectors, ingesting 200-400 GB daily. They leverage logs (structured JSON via stdout), metrics (OpenTelemetry-native with RabbitMQ dashboards), and traces (distributed tracing across Kotlin, Java, and Go services).

Key Results

Since implementing OpenObserve, Stonal has seen a marked improvement in how quickly the team diagnoses and resolves issues. Distributed tracing, in particular, has transformed their approach to performance problems. "Diagnosing SQL performance issues is usually difficult," Florent explains. "With tracing, you quickly see where you're spending time. Most of the time, if you open a trace and look at why an API took 20 seconds to respond, you'll see the SQL queries or REST API calls that are responsible."

The team also built a sophisticated alerting pipeline that routes OpenObserve alerts through an internal webhook to RabbitMQ, then to Slack, complete with smart grouping and automatic thread updates when alerts clear. This proactive approach means problems rarely catch them off guard. "We use alerts pretty intensively," Florent says. "It's really rare that someone reports something and we haven't seen it before."

For a company that relies heavily on RabbitMQ, queue health is critical. Stonal created a custom metric that calculates the estimated time to clear each queue at the current consuming rate. "That's the most important thing for us," Florent notes. "When we have a burst issue on the database, it's really important to be notified quickly."

Beyond operational improvements, the move to self-hosted OpenObserve solved Stonal's original pain points. The unpredictable SaaS costs that created internal friction are gone. There are no more per-metric or per-GB surprises. And with all observability data staying within their own Kubernetes clusters in Europe, Stonal can confidently address GDPR requirements and their clients' concerns about the Cloud Act.

Summary

Stonal replaced their cloud-hosted SigNoz deployment with self-hosted OpenObserve, eliminating unpredictable costs while gaining a developer-friendly platform their team adopted quickly. The combination of simple deployment (PostgreSQL + S3), familiar SQL queries, and responsive product support made the transition seamless. Today, Stonal runs full-stack observability across their Kubernetes infrastructure with distributed tracing, proactive alerting, and complete control over their European data residency.

"OpenObserve has proven to be a reliable solution. The developers get comfortable with it really fast, and it helps us diagnose issues much more efficiently." — Florent Clairambault, CTO, Stonal