Kubernetes Support

In 2025, a monitoring solution without support for Kubernetes would be a strange thing. Reassuringly, the Netdata developers now offer a containerized version of their agent (Figure 4) and ensure the appropriate Kubernetes integration.

Figure 4: Netdata records the metrics of individual processes, as well as the data of active containers.

If you primarily operate your setups in the context of containers and in conjunction with Kubernetes, you are likely to benefit from various features. For example, the Netdata agent in Kubernetes can be controlled directly as a native resource over the Kubernetes API, which makes it possible to roll the agent out as part of a network along with other applications. Moreover, Netdata can correlate the collected metrics data with the Kubernetes metadata in this way.

It would not be very helpful just to know that an instance of MySQL started by Kubernetes (K8s) is running on some system, because it would not give you any insights into which specific workload the instance belongs. To counter this, Netdata also docks to the K8s API and reads the metadata for each monitored container. In this way, Netdata can display a coherent view in the user interface, providing information on both the service itself and the Kubernetes context in which it is running (Figure 5).

Figure 5: Netdata connects directly to the Kubernetes API and reads the metrics data available there before displaying the information in the GUI.

However, the developers go even further by adding support in Netdata for extensions that are often used in the Kubernetes context. For example, Cilium [3] is considered one of the most comprehensive software-defined network (SDN) solutions for K8s. Netdata can seamlessly monitor the Cilium agent and the Cilium operator in K8s as well as the Cilium proxy. Also, Netdata lets you check the Rancher Kubernetes manager.

Although K8s is already considered a cloud in many places, it's a different story when it comes to classic infrastructure-as-a-service (IaaS) platforms or hyperscalers. Netdata offers comprehensive integration for AWS, Azure, and Google Cloud Platform (GCP) and support for several private cloud products. If you use Akamai's services as a content delivery network (CDN), for example, you dock Netdata onto the API to field most of the metrics data. The same applies to practically all standard services in AWS, including Amazon Elastic Compute Cloud (EC2), Elastic Container Service (ECS), and Simple Storage Service (S3). Netdata can also handle basic Azure resources. If you operate Nextcloud, you can monitor it with Netdata just as seamlessly as you can the OpenStack private cloud environment.

Chatty Tool

If you are looking to deploy Netdata in your setup, you will need to decide whether or not you really want to put all of your metrics data in Netdata's hands. The developers bandy superlatives about here, too: Infinite aggregation , for example, is claimed by nesting multiple Netdata agents. Individual instances on the target systems first send their data to intermediary agents, which then communicate with Netdata Cloud. Because any number of incarnations of each element in this construct can exist at any level, the whole enchilada will scale infinitely, at least in theory.

Unfortunately, the proprietary Netdata dashboard and Netdata Cloud components make you dependent on the manufacturer. If you want to avoid this vendor lock-in, you will need to store your metadata locally besides storing in the Netdata Cloud. It is to the credit of the developers that they provide comprehensive interfaces in their agent for this purpose. For example, if you run a local Prometheus instance parallel to Netdata and want to send the metrics data from the installation to the Netdata Cloud at the same time, you can simply configure the appropriate Prometheus endpoint in the Netdata agent. The same applies to other well-known time series databases such as InfluxDB, Gnocchi, M3, and OpenTSDB.

VictoriaMetrics and Thanos are also supported target platforms. The Netdata agent uses the Prometheus interface, which VictoriaMetrics and Thanos both support; the same applies to Cortex. If Prometheus is your preferred time series database, sooner or later you will need M3, Cortex, or Thanos [4] anyway; otherwise, you will just be cluttering your local Prometheus setup with metrics data, and experience shows that this will slow down Prometheus over time. Either way, anyone who uses a reasonably up-to-date time series database will have no difficulty exporting their data to Netdata. If you decide against Netdata at some later stage, you will still have the data available for use in Grafana or another user interface.

Performance Questions

Anyone who has lived with Prometheus in the recent past might also have experienced its temporary performance bottlenecks. Large instances of the service in particular often become unbearably slow, and that doesn't even take into account the load on the monitored systems.

Prometheus also relies on a server-agent architecture to collect metrics data, although many target services have separate agents, known as exporters. Depending on the data collection type and scope, some Prometheus exporters can take quite a big bite out of RAM and compute resources, none of which detracts from Prometheus's popularity and widespread use.

This is probably why the Netdata developers chose it as the target for a direct comparison with their software. The figures provided by Netdata speak for themselves: The Netdata agent, as a single tool trimmed for efficiency, is said to generate an average of 40 percent less CPU load and use a maximum of just over half the available RAM. Mind you, this is based on the premise of Netdata storing almost three days' more metrics data than Prometheus in the comparison.

Moreover, Netdata supports a significantly higher sampling rate. By default, the agent reads the configured metrics data once per second, whereas most admins tend to set the Prometheus query interval to 20 seconds. Objectively, Netdata achieves a significantly higher level of detail in its metrics data, although not every setup will benefit.