All the Netdata Agents and Parents (centralization points) you install, are transparently integrated to one uniform observability platform, capable of scaling both vertically and horizontally as your infrastructure grows. This design:

• distributes the observability workload across the infrastructure,
• eliminates saturation and bottlenecks while improving performance,
• eliminates egress bandwidth costs by keeping the data near the edge, and
• enables the use of resources that are already available and spare.

When viewing dashboards, queries are automatically split and spread to your Netdata Agents and Parents, each of which executes a small part of the original query, multiplying the compute power and providing faster responses than any single system can offer.

Netdata is generally able to respond to composite single-chart queries involving several dozens of thousands of time-series. Queries that are usually rejected by other monitoring solutions.

Our goal is to kill the console, eliminate the need to access the console for performance monitoring and troubleshooting.

So, Netdata collects, stores and visualizes all the available metrics at the resolution the console tools provide (per-second).

Furthermore, data collection to visualization latency in Netdata, is constant and less than 1 second.

Unlike most other monitoring solutions that smooth out missed data collections, Netdata works at a beat. Missed data collections are presented as gaps at the charts. These gaps provide crucial information in virtualized and cloud environments where system resources availability may fluctuate or not be linear.

To minimize disk footprint, Netdata supports 3 storage tiers:

• 1-second resolution
  usually for 7 days, at 0.6 bytes per sample,
• 1-minute resolution
  usually for 3 months, at 6 bytes per sample,
• 1-hour resolution
  usually for 1+ year, at 18 bytes per sample.

Note that unlike most other monitoring solutions, lower-resolution tiers in Netdata provide accurate arithmetic operations for average, min, max, sum and anomaly rate. So, after downsampling to per-minute or to per-hour, Netdata still maintains the min, max, sum, average and anomaly rate of the original per-second samples.

Anomaly information is stored together with the samples, in the database. When querying metrics, Netdata calculates the anomaly rate of each query, based on the percentage of samples that were anomalous at collection time. Anomaly rates are used in:

• Visualization
  all Netdata charts have an anomaly ribbon indicating the query anomaly rate across time,
• Alerts
  alerts can be configured to query anomaly rates for triggering notifications,
• Spotting areas on interest
  at a press of a button Netdata can highlight the most anomalous sections of the dashboard for any given timeframe,
• Scoring metrics
  several dashboard tools allow filtering and scoring metrics based on their anomaly rate, making it possible to identify the root cause of issues using Machine Learning.

Note that Machine Learning in Netdata is unsupervised. It just works for all metrics, without any input from users.

For systemd-journal logs centralization points, Netdata automatically provides aggregated, multi-node, logs dashboards, merging the logs of all servers into the same view.

Netdata provides tools (log2journal and systemd-cat-native) for converting plain text log files, json log files and logfmt log files, into structured journal entries, taking advantage of the advanced indexing capabilities of systemd-journald.

For systems with a steady and high rate of logs, Netdata uses dynamic and adaptive sampling mechanisms to provide prompt responses to logs queries, even when the log entries in the visible timeframe are dozens of millions.

It detects docker containers, kubernetes pods and containers, lxc containers, KVM VMs, libvirt VMs, Proxmox VMs, systemd services, and generally any kind of container technology that uses Linux kernel namespaces and cgroups.

For each container detected, Netdata automatically collects additional metadata information from docker, kubernetes, etc. to enrich the labels of the metrics.

• Native Plugins
  Native plugins speak the protocol and the language monitored applications prefer or require. So, our prostresql, redis, mongodb, etc plugins speak the protocol of these applications.
• OpenMetrics
  Netdata collects metrics from OpenMetrics / Prometheus endpoints, either natively when the monitored applications expose OpenMetrics, or via Prometheus exporters.
• StatsD
  All Netdata Agents are also StatsD servers (both UDP and TCP), making it easy to push metrics to Netdata from all applications running in localhost, or even from shell scripts and cron jobs.
• Custom Plugins
  Netdata plugins can be written in any language. All communication is text via stdin/stdout, making it easy to write custom plugins in python, go, bash, node, java, or any language users prefer.

The following synthetic tests are provided:

• HTTP/HTTPS endpoints
  Check the availability of remote APIs and web servers, validate their responses and measure their response time.
• Ping endpoints
  Check the availability and measure round-trip time and packet loss of remote network endpoints.
• TCP endpoints
  Check the availability of TCP ports and track response times.
• DNS Domain expiration
  Monitor DNS domains expiration time.
• X.509 Certificates
  Test the expiration and revocation status of certificates.
• I/O Ping
  Measure I/O latency, read/write speeds, errors and more.
• Monit
  Check filesystems, directories, files, UNIX domain sockets, and more.