This week, security researchers at Wiz published a report about an internal database at DeepSeek being exposed to the internet. This kind of security risk is surprisingly common and can affect any company. The only way to prevent it is through continuous monitoring. But in modern infrastructures, services can be exposed in many different ways, making detection tricky. At Coroot, we realized that the telemetry data we already collect can help identify these risks — without requiring any extra setup.

AI is now a go-to tool for everything from writing to coding. Modern LLMs are so powerful that, with the right prompt and a few adjustments, they can handle tasks almost effortlessly. At Coroot, we’ve been experimenting with AI for observability. Our goal is to make it useful in the final stage of troubleshooting—when we’ve already identified which service is causing issues, like Postgres, but finding the exact root cause is still tricky due to the many possible scenarios.

At Coroot, we started using eBPF to give users insights into their system performance without needing them to change code or redeploy services. This approach not only makes setup easier but also ensures full visibility, even for third-party and legacy services. To truly achieve this, though, the tool needs to support a wide range of application protocols. Coroot has long supported popular ones like HTTP, gRPC, Postgres, MySQL, Redis, Memcached, MongoDB, Kafka, and Cassandra.

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?