netdata collects system metrics by itself. It has many internal plugins for collecting most of the metrics presented by default when it starts, collecting data from /proc, /sys and other Linux kernel sources.

To collect non-system metrics, netdata supports a plugin architecture. The following are the currently available external plugins:

• Web Servers, such as apache, nginx, nginx_plus, tomcat, litespeed
• Web Logs, such as apache, nginx, lighttpd, gunicorn, squid access logs, apache cache.log
• Load Balancers, like haproxy
• Message Brokers, like rabbitmq, beanstalkd
• Database Servers, such as mysql, mariadb, postgres, couchdb, mongodb, rethinkdb
• Social Sharing Servers, like retroshare
• Proxy Servers, like squid
• HTTP accelerators, like varnish cache
• Search engines, like elasticsearch
• Name Servers (DNS), like bind, nsd, powerdns, dnsdist
• DHCP Servers, like ISC DHCP
• UPS, such as APC UPS, NUT
• RAID, such as linux software raid (mdadm), MegaRAID
• Mail Servers, like postfix, exim, dovecot
• File Servers, like samba, NFS, ftp, sftp, WebDAV
• System, for processes and other system metrics
• Sensors, like temperature, fans speed, voltage, humidity, HDD/SSD S.M.A.R.T attributes
• Network, such as SNMP devices, fping, access points, dns_query_time
• Time Servers, like chrony
• Security, like FreeRADIUS, OpenVPN, Fail2ban
• Telephony Servers, like openSIPS
• Go applications
• Household appliances, like SMA WebBox (solar power), Fronius Symo solar power, Stiebel Eltron heating
• Java Processes, via JMX or Spring Boot Actuator
• Provisioning Systems, like Puppet
• Game Servers, like SpigotMC
• Distributed Computing Clients, like BOINC
• Skeleton Plugins, for writing your own data collectors

Check also Third Party Plugins for a list of plugins distributed by third parties.

netdata comes with internal and external plugins:

1. The internal ones are written in C and run as threads within the netdata daemon.
2. The external ones can be written in any computer language. The netdata daemon spawns these as processes (shown with ps fax) and reads their metrics using pipes (so the stdout of external plugins is connected to netdata for metrics collection and the stderr of external plugins is connected to /var/log/netdata/error.log).

To make it easier to develop plugins, and minimize the number of threads and processes running, netdata supports plugin orchestrators, each of them supporting one or more data collection modules. Currently we ship plugin orchestrators for 4 languages: C, python, node.js and bash and 2 more are under development (go and java).

To control which plugins netdata run, edit netdata.conf and check the [plugins] section. It looks like this:

[plugins]
	# enable running new plugins = yes
	# check for new plugins every = 60
	# proc = yes
	# diskspace = yes
	# cgroups = yes
	# tc = yes
	# nfacct = yes
	# idlejitter = yes
	# freeipmi = yes
	# node.d = yes
	# python.d = yes
	# fping = yes
	# charts.d = yes
	# apps = yes

The default for all plugins is the option enable running new plugins. So, setting this to no will disable all the plugins, except the ones specifically enabled.

Each of the plugins may support one or more data collection modules. To control which of its modules run, you have to consult the configuration of the plugin (see table below).

Most modules come with auto-detection, configured to work out-of-the-box on popular operating systems with the default settings.

However, there are cases that auto-detection fails. Usually the reason is that the applications to be monitored do not allow netdata to connect. In most of the cases, allowing the user netdata from localhost to connect and collect metrics, will automatically enable data collection for the application in question (it will require a netdata restart).

You can verify netdata external plugins and their modules are able to collect metrics, following this procedure:

# become user netdata
sudo su -s /bin/bash netdata

# execute the plugin in debug mode, for a specific module.
# example for the python plugin, mysql module:
/usr/libexec/netdata/plugins.d/python.d.plugin 1 debug trace mysql

Similarly, you can use charts.d.plugin for BASH plugins and node.d.plugin for node.js plugins. Other plugins (like apps.plugin, freeipmi.plugin, fping.plugin) use the native netdata plugin API and can be run directly.

If you need to configure a netdata plugin or module, all user supplied configuration is kept at /etc/netdata while the stock versions of all files is at /usr/lib/netdata/conf.d. To copy a stock file and edit it, run /etc/netdata/edit-config. Running this command without an argument, will list the available stock files.

Each file should provide plenty of examples and documentation about each module and plugin.

This is a map of the all supported configuration options:

You can add custom plugins following the External Plugins Guide.

These are all the data collection plugins currently available.