Thanks for trying Netdata! In this getting started guide, we'll quickly walk you through the first steps you should take after getting Netdata installed.
Netdata can collect thousands of metrics in real-time without any configuration, but there are some valuable things to know to get the most out of Netdata based on your needs.
We'll skip right into some technical details, so if you're brand-new to monitoring the health and performance of systems and applications, our step-by-step tutorial might be a better fit.
If you haven't installed Netdata yet, visit the installation instructions for details, including our one-liner script, which automatically installs Netdata on almost all Linux distributions.
Open up your web browser of choice and navigate to http://YOUR-HOST:19999
. Welcome to Netdata!
What's next?:
Netdata primarily uses the netdata.conf
file for custom configurations.
On most systems, you can find that file at /etc/netdata/netdata.conf
.
Some operating systems will place your
netdata.conf
at/opt/netdata/etc/netdata/netdata.conf
, so check there if you find nothing at/etc/netdata/netdata.conf
.
The netdata.conf
file is broken up into various sections, such as [global]
, [web]
, [registry]
, and more. By
default, most options are commented, so you'll have to uncomment them (remove the #
) for Netdata to recognize your
change.
Once you save your changes, restart Netdata to load your new configuration.
What's next?:
history
option or switching to the database engine.netdata.conf
options in our daemon configuration documentation.When Netdata starts, it auto-detects dozens of data sources, such as database servers, web servers, and more. To auto-detect and collect metrics from a service or application you just installed, you need to restart Netdata.
There is one exception: When Netdata is running on the host (as in not in a container itself), it will always auto-detect containers and VMs.
However, auto-detection only works if you installed the source using its standard installation procedure. If Netdata isn't collecting metrics after a restart, your source probably isn't configured correctly. Look at the external plugin documentation to find the appropriate module for your source. Those pages will contain more information about how to configure your source for auto-detection.
Some modules, like chrony
, are disabled by default and must be enabled manually for auto-detection to work.
Once Netdata detects a valid source of data, it will continue trying to collect data from it. For example, if Netdata is collecting data from an Nginx web server, and you shut Nginx down, Netdata will collect new data as soon as you start the web server back up—no restart necessary.
Even if Netdata auto-detects your service/application, you might want to configure what, or how often, Netdata is collecting data.
Netdata uses internal and external plugins to collect data. Internal plugins run within the Netdata dæmon, while external plugins are independent processes that send metrics to Netdata over pipes. There are also plugin orchestrators, which are external plugins with one or more data collection modules.
You can configure both internal and external plugins, along with the individual modules. There are many ways to do so:
netdata.conf
, [plugins]
section: Enable or disable internal or external plugins with yes
or no
.netdata.conf
, [plugin:XXX]
sections: Each plugin has a section for changing collection frequency or passing
options to the plugin..conf
files for each external plugin: For example, at /etc/netdata/python.d.conf
..conf
files for each module : For example, at /etc/netdata/python.d/nginx.conf
.It's complex, so let's walk through an example of the various .conf
files responsible for collecting data from an
Nginx web server using the nginx
module and the python.d
plugin orchestrator.
First, you can enable or disable the python.d
plugin entirely in netdata.conf
.
[plugins]
# Enabled
python.d = yes
# Disabled
python.d = no
You can also configure the entire python.d
external plugin via the [plugin:python.d]
section in netdata.conf
.
Here, you can change how often Netdata uses python.d
to collect metrics or pass other command options:
[plugin:python.d]
update every = 1
command options =
The python.d
plugin has a separate configuration file at /etc/netdata/python.d.conf
for enabling and disabling
modules. You can use the edit-config
script to edit the file, or open it with your text editor of choice:
sudo /etc/netdata/edit-config python.d.conf
Finally, the nginx
module has a configuration file called nginx.conf
in the python.d
folder. Again, use
edit-config
or your editor of choice:
sudo /etc/netdata/edit-config python.d/nginx.conf
In the nginx.conf
file, you'll find additional options. The default works in most situations, but you may need to make
changes based on your particular Nginx setup.
What's next?:
systemd
to expose systemd services
utilization metrics automatically.netdata.conf
.Netdata comes with hundreds of health monitoring alarms for detecting anomalies on production servers. If you're running Netdata on a workstation, you might want to disable Netdata's alarms.
Edit your /etc/netdata/netdata.conf
file and set the following:
[health]
enabled = no
If you want to keep health monitoring enabled, but turn email notifications off, edit your health_alarm_notify.conf
file with edit-config
, or with the text editor of your choice:
sudo /etc/netdata/edit-config health_alarm_notify.conf
Find the SEND_EMAIL="YES"
line and change it to SEND_EMAIL="NO"
.
What's next?:
By default, Netdata uses a custom database which uses both RAM and the disk to store metrics. Recent metrics are stored in the system's RAM to keep access fast, while historical metrics are "spilled" to disk to keep RAM usage low.
This custom database, which we call the database engine, allows you to store a much larger dataset than your system's available RAM.
If you're not sure whether you're using the database engine, or want to tweak the default settings to store even more historical metrics, check out our tutorial: Changing how long Netdata stores metrics.
What's next?:
If you have Netdata installed on multiple systems, you can have them all appear in the My nodes menu at the top-left corner of the dashboard.
To show all your servers in that menu, you need to register for or sign in to Netdata Cloud from each system. Each system will then appear in the My nodes menu, which you can use to navigate between your systems quickly.
Whenever you pan, zoom, highlight, select, or pause a chart, Netdata will synchronize those settings with any other agent you visit via the My nodes menu. Even your scroll position is synchronized, so you'll see the same charts and respective data for easy comparisons or root cause analysis.
You can now seamlessly track performance anomalies across your entire infrastructure!
What's next?:
When you install Netdata, it's configured to start at boot, and stop and restart/shutdown. You shouldn't need to start or stop Netdata manually, but you will probably need to restart Netdata at some point.
service netdata start
.service netdata stop
.service netdata restart
.The service
command is a wrapper script that tries to use your system's preferred method of starting or stopping
Netdata based on your system. But, if either of those commands fails, try using the equivalent commands for systemd
and init.d
:
systemctl start netdata
, systemctl stop netdata
, systemctl restart netdata
/etc/init.d/netdata start
, /etc/init.d/netdata stop
, /etc/init.d/netdata restart
Even after you've configured netdata.conf
, tweaked alarms, learned the basics of performance troubleshooting, and
added all your systems to the My nodes menu, you've just gotten started with Netdata.
Take a look at some more advanced features and configurations:
Or, learn more about how you can contribute to Netdata core or our documentation!