Ilya Mashchenko 37fd96700b fix not handling N/A value in python.d/nvidia_smi (#15231) 1 year ago
..
apps.plugin 588096c6b6 Debugfs collector (#15017) 1 year ago
cgroups.plugin 836a56a956 Adjust buffers to prevent overflow (#15025) 1 year ago
charts.d.plugin 1aef5a70d8 Split plugins to individual packages for DEB/RPM packaging. (#13927) 1 year ago
checks.plugin 0541c97e53 Introduce the new Structure of the documentation (#13915) 2 years ago
cups.plugin 8e1cb764b3 add metrics.csv to some c collectors (#14974) 1 year ago
debugfs.plugin 53b9133679 send EXIT before exiting in freeipmi and debugfs plugins (#15140) 1 year ago
diskspace.plugin 89f22f056c Try to detect bind mounts (#14831) 1 year ago
ebpf.plugin 8c3d78a227 Fix issues in sync thread (eBPF plugin) (#15174) 1 year ago
freebsd.plugin 3d8a4d82f4 add metrics.csv to macos, freebsd and cgroups plugins (#14977) 1 year ago
freeipmi.plugin 892255b237 freeipmi: add availability status chart and alarm (#15151) 1 year ago
idlejitter.plugin 8e1cb764b3 add metrics.csv to some c collectors (#14974) 1 year ago
ioping.plugin 8e1cb764b3 add metrics.csv to some c collectors (#14974) 1 year ago
macos.plugin 3d8a4d82f4 add metrics.csv to macos, freebsd and cgroups plugins (#14977) 1 year ago
nfacct.plugin 1aef5a70d8 Split plugins to individual packages for DEB/RPM packaging. (#13927) 1 year ago
perf.plugin 1aef5a70d8 Split plugins to individual packages for DEB/RPM packaging. (#13927) 1 year ago
plugins.d 80d83b7bd1 api v2 nodes for streaming statuses (#15162) 1 year ago
proc.plugin 46653e901d delay collecting virtual network interfaces (#15244) 1 year ago
python.d.plugin 37fd96700b fix not handling N/A value in python.d/nvidia_smi (#15231) 1 year ago
slabinfo.plugin 1aef5a70d8 Split plugins to individual packages for DEB/RPM packaging. (#13927) 1 year ago
statsd.plugin 9385b062f6 Replace hardcoded links pointing to "learn.netdata.cloud" with github absolute links (#14779) 1 year ago
tc.plugin 66c8546019 Re-write of SSL support in Netdata; restoration of SIGCHLD; detection of stale plugins; streaming improvements (#15113) 1 year ago
timex.plugin 770ec8339d add metrics.csv to timex.plugin (#14970) 1 year ago
xenstat.plugin 13896f8ac8 add metrics.csv to xenstat.plugin (#14972) 1 year ago
COLLECTORS.md 6bb3b56010 Remove lighttpd2 from docs (#14997) 1 year ago
Makefile.am 588096c6b6 Debugfs collector (#15017) 1 year ago
README.md ab944a349f Update README.md (#14647) 2 years ago
REFERENCE.md 1413b5bac3 Reorg learn 021723 (#14556) 2 years ago
all.h 588096c6b6 Debugfs collector (#15017) 1 year ago

README.md

Collectors

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 Netdata.

All collectors are installed by default with every installation of Netdata. You do not need to install collectors manually to collect metrics from new sources. See how you can monitor anything with Netdata.

Upon startup, Netdata will auto-detect any application or service that has a collector, as long as both the collector and the app/service are configured correctly. If you don't see charts for your application, see our collectors' configuration reference.

How Netdata's metrics collectors work

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. The endpoint is user-configurable, as are many other specifics of what a given collector does.

Collector architecture and terminology

  • Collectors are the processes/programs that actually gather metrics from various sources.

  • Plugins help manage all the independent data collection processes in a variety of programming languages, based on their purpose and performance requirements. There are three types of plugins:

    • Internal plugins organize collectors that gather metrics from /proc, /sys and other Linux kernel sources. They are written in C, and run as threads within the Netdata daemon.

    • External plugins organize collectors that gather metrics from external processes, such as a MySQL database or Nginx web server. They can be written in any language, and the netdata daemon spawns them as long-running independent processes. They communicate with the daemon via pipes. All external plugins are managed by plugins.d, which provides additional management options.

  • Orchestrators are external plugins that run and manage one or more modules. They run as independent processes. The Go orchestrator is in active development.

    • go.d.plugin: An orchestrator for data collection modules written in go.

    • python.d.plugin: An orchestrator for data collection modules written in python v2/v3.

    • charts.d.plugin: An orchestrator for data collection modules written inbash v4+.

  • Modules are the individual programs controlled by an orchestrator to collect data from a specific application, or type of endpoint.