Operations | Monitoring | ITSM | DevOps | Cloud

The first minutes of an incident are spent asking questions a monitoring tool can answer but rarely in the form you asked them: which servers are in trouble right now, is it the same thing as last night, what did memory do on the web servers before it started? Each answer is a few clicks away, on a different page.

Dashboards answer the questions you knew you would ask. The other kind — “is it only this server, or all of them?”, “since when?”, “what does memory look like on the ones that restarted?” — used to start with creating a dashboard, adding a widget, picking a metric, and deleting the whole thing afterwards. Bleemeo now has a page for those questions. It is called Metrics: you write a PromQL query, run it, and look at the answer.

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.