Operations | Monitoring | ITSM | DevOps | Cloud

Most teams that run on Azure do not run only on Azure. There is a database on a VM nobody wants to move, a Kubernetes cluster somewhere else, a few servers in a rack, and a monitoring setup that grew around all of it. Azure Monitor sees the Azure part very well and nothing else, so the picture of an incident ends up split across two consoles, two alerting configurations and two sets of dashboards. Bleemeo now connects to Azure the same way it already connects to AWS.

Some alerts only need to reach a Slack channel. Some need to reach one specific person, at 3am, and keep trying until they answer. For the second kind, we are partnering with ilert — an incident response platform covering the full lifecycle: from the moment an alert arrives, through paging the right responder, coordinating the response, telling customers what’s happening, and learning from it afterwards. The integration is live today, on both sides.

The default way to adopt log management is to ship everything and search it later. It is the path every vendor’s quickstart puts you on, and it is the reason log bills surprise people: ingestion is priced by volume, so“ship everything” is a spending decision disguised as a configuration default. The uncomfortable part is that most of that volume is never read. Nobody greps last Tuesday’s 200 OK access lines.

Summer is the perfect time to step back from the alert stream and revisit the ideas your whole monitoring practice quietly rests on. Not the newest tool or the shiniest dashboard — the fundamentals: what to measure, how to read it, when to wake someone up, and what to do when something breaks at 2 a.m. We packed six of those fundamentals into a free, no-signup PDF — The DevOps & Monitoring Summer Workbook, complete with hands-on exercises and an answer key.

Modern applications are distributed, ephemeral and built from a dozen moving parts. To keep them reliable, you need real visibility: not just “is the server up?”, but“how is this request behaving, right now, across every component it touches?”. The good news is that the observability world has converged on a handful of open standards.

Monitoring a single server should not require running four daemons. Yet the default open-source recipe for “I just want to watch this one box” still looks like this: install node_exporter, stand up a Prometheus server to scrape it, add Grafana to draw the graphs, and bolt on Alertmanager so you actually hear about a full disk. That is a lot of moving parts — and a lot of YAML — for one machine. This post shows a lighter path.

Prometheus has become the gold standard for monitoring cloud-native applications. But running Prometheus at scale comes with significant operational overhead. Let’s explore why a managed Prometheus solution might be the right choice for your team.

Kubernetes has become the de facto standard for container orchestration, but monitoring a Kubernetes cluster can be challenging. In this guide, we’ll walk through the essential steps to set up effective monitoring for your Kubernetes infrastructure.

Infrastructure monitoring has evolved dramatically over the past decade. What started as simple uptime checks has grown into sophisticated observability platforms. This comprehensive guide covers everything you need to know about infrastructure monitoring in 2024.

The Bleemeo Community Edition is the Open Source and self hosted version of the Bleemeo monitoring solution. It is composed of three main components: And some third party components: In this article, we will show you how to install and configure these components to have a fully working monitoring infrastructure.