## What is Netdata?
Netdata is an open-source, distributed observability agent designed to collect rich, per-second metrics from systems, hardware, and applications with zero initial configuration. It operates as a lightweight daemon on individual nodes, utilizing a custom high-performance database engine to store time-series data locally while optionally streaming to centralized pipelines or the Netdata Cloud.
The system addresses the problem of visibility latency in complex infrastructure. Unlike traditional monitoring solutions that aggregate data over minute-long intervals, Netdata prioritizes high-resolution granularity (1s) to detect transient anomalies and micro-outages. Its architecture decentralizes data collection, processing, and alerting, effectively turning each node into a self-contained monitoring endpoint that integrates into broader observability ecosystems.
## Key Features & Capabilities
* **Zero-Configuration Auto-Discovery**: The agent automatically detects running services (e.g., Nginx, Docker, PostgreSQL) and activates the relevant collectors without manual script configuration.
* **eBPF Integration**: Utilizes **Extended Berkeley Packet Filter (eBPF)** technology to monitor kernel-level metrics, system calls, and network interactions with minimal overhead and without application instrumentation.
* **Unsupervised Anomaly Detection**: Includes a pre-trained **Machine Learning (ML)** engine at the edge that establishes baseline behavior for metrics and flags statistical outliers in real-time.
* **Per-Second Granularity**: Captures and visualizes data at 1-second intervals by default, providing higher fidelity for debugging performance spikes than polling-based alternatives.
* **Interoperability**: Exports data to **Prometheus**, Graphite, OpenTSDB, and other time-series databases, acting as a high-resolution metric forwarder.
## Architecture & Technology Stack
Netdata is primarily written in **C** to ensure low resource consumption and high performance, with specific collectors implemented in **Go** and **Python**. The architecture follows a distributed agent model where data processing occurs at the edge rather than a central ingest server.
* **Core Daemon**: Written in C, responsible for data collection orchestration, query execution, and the web server API.
* **Storage Engine (DBENGINE)**: A tiered, circular time-series database optimized for high-write throughput and compression, minimizing disk I/O and RAM usage.
* **Collectors**: Modular plugins that interface with system APIs (procfs, sysfs) and application endpoints. External collectors often run as separate processes to isolate stability.
* **Streaming Protocol**: Uses a custom, lightweight binary protocol for streaming metrics between parent/child nodes or to Netdata Cloud.
## Comparison: Netdata vs Alternatives
| Feature | Netdata | Prometheus | Zabbix |
| :--- | :--- | :--- | :--- |
| **Data Granularity** | 1-second (default) | Scrape interval (typically 15s+) | Polling interval (typically 1m+) |
| **Architecture** | Distributed Agent (Push/Stream) | Centralized Pull-based | Centralized Server-Agent |
| **Configuration** | Zero-config / Auto-discovery | Manual Exporter Setup | Manual Template/Agent Setup |
| **Resource Usage** | Moderate (Edge Processing) | Low (Agent), High (Server) | Low (Agent), High (DB/Server) |
| **Storage** | Tiered Local Storage (RAM/Disk) | Local TSDB (Server-side) | SQL Database (MySQL/PG) |
| **License** | GPL v3 | Apache 2.0 | GPL v2 |
## Technical Constraints
* **Edge Resource Consumption**: While optimized, the agent performs processing and ML inference on the monitored node. On extremely resource-constrained devices (e.g., small IoT gateways), CPU usage may be noticeable.
* **Long-Term Storage**: By design, local retention is finite and dependent on disk allocation. Long-term historical analysis requires streaming data to an external backend or Netdata Cloud.
* **Configuration Complexity for Custom Apps**: While auto-discovery covers standard services, defining custom charts or log processing pipelines requires manual editing of YAML configuration files.
