Operations | Monitoring | ITSM | DevOps | Cloud

ClickHouse monitoring guide: the Prometheus endpoint, the system tables that explain slow queries, the Too many parts limits, replication lag and alerts. Sejal Pandey works on content and growth at Last9, writing about observability, reliability, and SRE practices.

GKE monitoring guide: what Google Kubernetes Engine collects by default, which metric packages to turn on, Autopilot limits, and the alerts to set. Sejal Pandey works on content and growth at Last9, writing about observability, reliability, and SRE practices.

✓ operational truth IT finds out late because traditional monitoring is built to detect what goes wrong, not what has quietly stopped happening. Closing that gap requires observability that validates business journeys end to end, detects missing activity, checks its own coverage, and predicts degradation before a threshold is ever crossed.

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.

AI-assisted development can increase the rate at which teams produce code, but teams only realize those velocity gains if CI can keep pace. More pull requests (PRs) mean more builds, tests, and pipeline executions. Slow jobs leave developers and coding agents waiting for feedback, flaky failures consume time in reruns and investigations, and unnecessary test execution increases runner demand as delivery volume grows.

Why is the telemetry AI agents generate so intimidating? If you turn on Claude Code’s internal telemetry it’ll throw a wall of text at you. And, it’s very expensive to store. But, the bigger issue is that you can’t make sense of it. Luckily it’s all OpenTelemetry native. That means you can configure it to send, transform, and store what you really need. Which raises the only question that matters. What do you actually need?

Most IT teams now look after more sites than they have people to visit. Remote infrastructure management covers that gap, and it works differently from the IT infrastructure management you run inside a building where somebody can walk over and look at whatever broke. The technology rarely causes the trouble. Trouble starts when a site goes quiet and there's nobody standing there to look at it.

If your company relies on multiple databases and applications, keeping track of database performance can become difficult. You may face challenges such as: As your database environment grows, identifying the cause of performance issues becomes harder without the right monitoring in place. I get why database monitoring tools have become an important part of managing database performance. They help you monitor database activity, spot performance issues, and find what is causing a slowdown.

Imagine this: you are testing the performance of some part of your application. Everything is going smoothly, the numbers look good, and as a last check you turn on Go’s race detector. Then, out of nowhere, it prints a warning you didn’t expect: So you look at it. You look at it again, and again, and you think: “What the…?” The race is between your code and a goroutine you never started, somewhere deep inside net/http. You have no idea how that is possible, or why.