Operations | Monitoring | ITSM | DevOps | Cloud

GPU infrastructure is expensive and increasingly central to production workloads. Whether you’re running ML training jobs, inference serving, video transcoding, or HPC workloads, understanding what your GPUs are actually doing, and what’s going wrong when performance degrades, is not optional.

Netdata ships with hundreds of stock alerts. They cover a wide range of infrastructure conditions and they’re designed with sensible defaults. But “sensible defaults” and “correct for your environment” are not the same thing. A CPU threshold that’s perfectly reasonable for a build server might generate constant noise on a machine running batch jobs.

If you’re running infrastructure on Azure, you’ve probably dealt with the split between your Azure-native monitoring and the rest of your stack. Your VMs, databases, and Kubernetes clusters generate platform metrics through Azure Monitor, but those metrics live in a separate world from the OS-level, application, and on-prem metrics you’re already watching in Netdata.

Netdata has always collected database metrics: connections, throughput, replication lag, buffer cache hit ratios, and so on. These tell you that something is wrong, but they don’t tell you why. When your PostgreSQL response time spikes, the metric alone doesn’t tell you which query is responsible. For that, you’ve traditionally needed to SSH into the box, connect to the database, and run diagnostic queries manually. Or set up a separate database monitoring tool entirely.

A lot of teams have a collection of Nagios plugins and custom monitoring scripts that have been running reliably for years. Some are standard community plugins for checking disk health or SSL certificate expiry. Others are homegrown Bash or Python scripts that check something very specific to the business: whether an API endpoint returns the right payload, whether a batch job completed on time, whether a queue depth is within bounds.

If you’re running Netdata collectors that connect to databases, APIs, or other authenticated services, there’s a good chance you have passwords sitting in plain-text configuration files right now. It works, but it’s the kind of thing that makes security teams nervous and makes credential rotation painful. Every password change means editing config files and restarting collectors.

Alert fatigue usually isn’t caused by one thing. It’s the accumulation of thresholds that are slightly too sensitive, alerts that fire during known maintenance windows, and historical patterns that nobody has the tools to review easily. Fixing it requires better visibility into how alerts actually behave over time, and a way to test changes before they hit production. We’ve shipped three improvements to alerting in Netdata that address different parts of this problem.

One of the most common requests we’ve gotten since launching custom dashboards is deceptively simple: “How do I put this on a TV?” Teams want their dashboards on wall-mounted screens in NOCs, war rooms, and open office spaces. The dashboard is already built. The data is already there. They just need a way to display it on a screen that nobody is logged into, without exposing the full Netdata Cloud interface. TV mode does exactly this.