Ilya Mashchenko 09711ae4a1 fix charts.d.plugin configuration directory names (#16939) 1 год назад
..
apps.plugin a08fa6f82c fix verify_netdata_host_prefix log spam (#16814) 1 год назад
cgroups.plugin a08fa6f82c fix verify_netdata_host_prefix log spam (#16814) 1 год назад
charts.d.plugin 09711ae4a1 fix charts.d.plugin configuration directory names (#16939) 1 год назад
checks.plugin 0541c97e53 Introduce the new Structure of the documentation (#13915) 2 лет назад
cups.plugin fb828e7ef3 cups exit on sigpipe (#16691) 1 год назад
debugfs.plugin a08fa6f82c fix verify_netdata_host_prefix log spam (#16814) 1 год назад
diskspace.plugin 096d1b1b2b Code cleanup (#16448) 1 год назад
ebpf.plugin a08fa6f82c fix verify_netdata_host_prefix log spam (#16814) 1 год назад
freebsd.plugin 096d1b1b2b Code cleanup (#16448) 1 год назад
freeipmi.plugin 3ab4c07118 convert some error messages to info (#16508) 1 год назад
idlejitter.plugin f0bd8662c5 Regenerate integrations.js (#16291) 1 год назад
ioping.plugin e1b95a1db8 fix logs bashism (#16461) 1 год назад
log2journal 8f9dea2726 Update README.md 1 год назад
macos.plugin 096d1b1b2b Code cleanup (#16448) 1 год назад
nfacct.plugin 3e508c8f95 New logging layer (#16357) 1 год назад
perf.plugin 3e508c8f95 New logging layer (#16357) 1 год назад
plugins.d 58f0d6aeec increase max response size to 100MiB (#16649) 1 год назад
proc.plugin efa9d109c9 Fix for AMD GPU drm different format proc file (#16561) 1 год назад
profile.plugin 0e230a260e Revert "Refactor RRD code. (#15423)" (#15723) 1 год назад
python.d.plugin 750bf63998 include more cases for megacli degraded state (#16522) 1 год назад
slabinfo.plugin 3e508c8f95 New logging layer (#16357) 1 год назад
statsd.plugin 096d1b1b2b Code cleanup (#16448) 1 год назад
systemd-journal.plugin a08fa6f82c fix verify_netdata_host_prefix log spam (#16814) 1 год назад
tc.plugin 5230b15f59 fixes for logging (#16459) 1 год назад
timex.plugin f0bd8662c5 Regenerate integrations.js (#16291) 1 год назад
xenstat.plugin 81f3679d3a Regenerate integrations.js (#16442) 1 год назад
COLLECTORS.md c1fc7d522b Regenerate integrations.js (#16536) 1 год назад
Makefile.am a64c8cdb43 log2journal moved to collectors (#16481) 1 год назад
README.md ab944a349f Update README.md (#14647) 2 лет назад
REFERENCE.md 1413b5bac3 Reorg learn 021723 (#14556) 2 лет назад
all.h 4e512411ec Logs Management (#13291) 1 год назад

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.