As more organizations move their databases to cloud-native environments, effectively managing and monitoring these systems becomes crucial. According to Coroot’s anonymous usage statistics, 64% of projects use PostgreSQL, making it the most popular RDBMS among our users, compared to 14% using MySQL. This is not surprising since it is also the most widely used open-source database worldwide.

There is a phenomenal amount of Observability tools on the market, coming in all shapes and sizes, offering many tools and approaches to solve what seems to be an endless number of problems. It also can be overwhelming to use, hard to set up and expensive to run, especially if you are going with SaaS based market leaders like DataDog.

When you build software, its terminology, concepts and relationship between them is quite obvious to you, when you’re starting to use software built by someone else – might not be so much so. In this blog post I tried to cover most important Coroot concepts and terminology – reading it will hopefully help you to understand Coroot much better if you’re just starting up with it.

At Coroot, we’re passionate about providing developers with the tools they need to build and maintain high-performing applications. Recently, we had the opportunity to help a team using FerretDB, the open-source document database offering MongoDB compatibility with a PostgreSQL backend, significantly improve their monitoring and performance. This is their story.

We’re excited to announce Coroot v1.6, packed with major improvements and new features to make observability even better! Here’s what’s new.

If you’re an experienced engineer, you likely have comprehensive observability and monitoring set up for your production systems. So if issues arise, you’re empowered to resolve them quickly. Yet, there are way too many systems out there, especially smaller and simpler ones, which are running with only rudimentary observability systems, or no observability at all. This means when an application goes down or starts to perform poorly, it may be very hard to pinpoint and resolve the issue.

You are running a complex, mission-critical application, and you understand you need an advanced Observability solution to efficiently troubleshoot and proactively prevent issues. Yet you have a choice to make—should you choose a “Fully Managed” SaaS solution such as Datadog, Newrelic, or Dynatrace, or should you pick an Open-Source solution that you can host yourself?

I’ve heard this story many times from production engineers: ‘We use tools like Datadog and NewRelic, but to keep costs from skyrocketing, we’re only monitoring our most critical services. We’re storing just 10% of our logs and traces and only the metrics we consider essential. It’s a frustrating situation. Engineers want full visibility across their systems, but cloud storage costs make it impossible to monitor everything.

eBPF is a powerful technology used by many observability solutions, including Coroot. While web-based observability tools like Coroot are invaluable, there’s a specific class of eBPF tools that often go overlooked (besides Brendan Gregg of course): eBPF Linux Command Line Tools. These tools are essential for diving deep into complex performance issues. But first – why would you need those at all if you have convenient observability focused web applications?

In this blog post we will look at runqlat and runqslower commands. They are available in both BCC and bpftrace tool collections. One of the core functions of Linux operating system is to schedule processes across available CPUs. When service gets a request, Linux typically will need to schedule the process, processing that request to run on one of CPUs. This might be very quick process if idle CPU is available or it can take significant time, if all CPUs are currently busy running different processes.