When Netdata starts, and with zero configuration, it auto-detects thousands of data sources and immediately collects per-second metrics.
Netdata can immediately collect metrics from these endpoints thanks to 300+ collectors, which all come pre-installed when you install the Netdata Agent.
Every collector has two primary jobs:
- Look for exposed metrics at a pre- or user-defined endpoint.
- Gather exposed metrics and use additional logic to build meaningful, interactive visualizations.
If the collector finds compatible metrics exposed on the configured endpoint, it begins a per-second collection job. The Netdata Agent gathers these metrics, sends them to the database engine for storage, and immediately visualizes them meaningfully on dashboards.
Each collector comes with a pre-defined configuration that matches the default setup for that application. This endpoint can be a URL and port, a socket, a file, a web page, and more.
For example, the Nginx collector searches
http://127.0.0.1/stub_status, which is the default endpoint for exposing Nginx metrics. The web log collector for
Nginx or Apache searches at
/var/log/apache2/access.log, respectively, both of which are standard locations for
access log files on Linux systems.
The endpoint is user-configurable, as are many other specifics of what a given collector does.
What can Netdata collect?
To quickly find your answer, see our list of supported collectors.
Generally, Netdata's collectors can be grouped into three types:
- Systems: Monitor CPU, memory, disk, networking, systemd, eBPF, and much more.
Every metric exposed by
/sys, and other Linux kernel sources.
- Containers: Gather metrics from container agents, like
kubectl, along with the resource usage of containers and the applications they run.
- Applications: Collect per-second metrics from web servers, databases, logs, message brokers, APM tools, email servers, and much more.
Collector architecture and terminology
Collector is a catch-all term for any Netdata process that gathers metrics from an endpoint.
While we use collector most often in documentation, release notes, and educational content, you may encounter other terms related to collecting metrics.
- Modules are a type of collector.
- Orchestrators are external plugins that run and manage one or more modules. They run as independent processes.
The Go orchestator is in active development.
- go.d.plugin: An orchestrator for data
collection modules written in
- python.d.plugin: An orchestrator for data collection modules written in
- charts.d.plugin: An orchestrator for data collection modules written in
- node.d.plugin: An orchestrator for data collection modules written in
- go.d.plugin: An orchestrator for data collection modules written in
- External plugins gather metrics from external processes, such as a webserver or database, and run as independent processes that communicate with the Netdata daemon via pipes.
- Internal plugins gather metrics from
/sys, and other Linux kernel sources. They are written in
C, and run as threads within the Netdata daemon.
Enable or configure a collector if the default settings are not compatible with your infrastructure.
See our collectors reference for detailed information on Netdata's collector architecture, troubleshooting a collector, developing a custom collector, and more.