Clone this wiki locally
Welcome to netdata!
(the figures come from netdata registry data, showing only installations that use the public global registry, counting since May 16th 2016)
Check Generating Badges for more information.
Netdata is featured at GitHub's State Of The Octoverse 2016
Oct 4th, 2016
- the fastest netdata ever (with a better look too)!
- improved IoT and containers support!
- alarms improved in almost every way!
- new plugins: softnet netdev, extended TCP metrics, UDPLite, NFS v2, v3 client (server was there already), NFS v4 server & client, APCUPSd, RetroShare
- improved plugins: mysql, cgroups, hddtemp, sensors, phpfm, tc (QoS)
Live demo installations of netdata are available at http://netdata.rocks:
|Location||netdata demo URL||60 mins reqs||VM Donated by|
(this is the global netdata registry and has named and mysql charts)
(with named and mysql charts)
|New York (USA)||newyork.netdata.rocks||DigitalOcean.com|
|San Francisco (USA)||sanfrancisco.netdata.rocks||DigitalOcean.com|
Netdata dashboards are mobile and touch friendly.
Want to set it up on your systems now? Jump to Installation.
What is it?
netdata is scalable, distributed real-time performance and health monitoring:
A netdata should be installed on each of your servers. It is the equivalent of a monitoring agent, as provided by all other monitoring solutions. It runs everywhere a Linux kernel runs: PCs, servers, embedded devices, IoT, etc.
Netdata is very resource efficient and you can control its resource consumption. It will use:
- some spare CPU cycles, usually just 1-3% of a single core (check Performance),
- the RAM you want it have (check Memory Requirements), and
- no disk I/O at all, apart its logging (check Log Files). Of course it saves its DB to disk when it exits and loads it back when it starts.
Unlike traditional monitoring solutions that move all the metrics collected on all servers, to a central place, netdata keeps all the data on the server they are collected.
This allows netdata to collect thousands of metrics per second on each server.
When you use netdata, adding 10 more servers or collecting 10000 more metrics does not have any measurable impact on the monitoring infrastructure or the servers they are collected. This provides virtually unlimited scalability.
netdata collected metrics can be pushed to central time-series databases (like
opentsdb) for archiving (check netdata backends), and netdata can push these data at a lower frequency/detail to allow these servers scale, but this is not required. It exists only for long-term archiving of the data and netdata never uses these databases as a data source.
Everything netdata does is per-second so that the dashboards presented are just a second behind reality, much like the console tools do. Of course, when netdata is installed on weak IoT devices, this frequency can be lowered, to control the CPU utilization of the device.
netdata is adaptive. It adapts its internal structures to the system it runs, so that the repeating task of data collection is performed utilizing the minimum of CPU resources.
The web dashboards are also real-time and interactive. netdata achieves this, by splitting to work load, between the server and the dashboard client. Each server is collecting the metrics and maintaining a very fast round-robin database in memory, while providing basic data manipulation tasks (like data reduction functions), while each web client accessing these metrics is taking care of everything for data visualization. The result is:
- minimum CPU resources on the servers
- fully interactive real-time web dashboards, with some CPU pressure on the web browser while the dashboard is shown.
netdata collects and visualizes metrics. If it is a number and it can be collected somehow, netdata can visualize it. Out of the box, it comes with plugins that collect hundreds of system metrics and metrics of popular applications.
netdata provides powerful alarms and notifications. It comes preconfigured with dozens of alarms to detect common health and performance issues and it also accepts custom alarms defined by you.
This wiki is the whole of it. Other than the wiki, currently there is the... source code.
You should at least walk through the pages of the wiki. They have a good overview of netdata, what it can do and how to use it.
If you need help, please use the github issues section.
Is it ready?
Software is never ready. There is always something to improve.
Netdata is stable. We use it on production systems without any issues.
Is it released?
Yeap! Check the releases page.
Why you wrote data collection?
Well, there are plenty of data collectors already. But we have one or more of the following problems with them:
- They are not able for per second data collection
- They can do per second data collection, but they are not optimized enough for always running on all systems
- They need to be configured, when we need auto-detection
Of course, we could use them just to get data at a slower rate, and this can be done, but it was not our priority. netdata proves that real-time data collection and visualization can be done efficiently.
Is it practical to have so short historical data?
For a few purposes yes, for others no.
Our focus is real-time data collection and visualization. Our (let's say) "competitors" are the console tools, neither grafana nor collectd, statsd, nagios, zabbix, etc. All these are perfect tools for what they do (and they do a lot). But we think they provide "statistics about past performance" (of course with alarms, health monitoring, etc). netdata provides "real-time performance monitoring", much like the console tools do. Different things.
Of course, historical data is our next priority.
Why there is no "central" netdata?
We strongly believe monitoring should be scaled out, not up. A "central" monitoring server is just another problem and should be avoided. Of course it is needed for health monitoring, but for real-time performance monitoring it will just add delays and eventually destroy the whole idea.
We all have a wonderful tool on our desktops, that connects us to the entire world: the web browser! This is the "central" netdata that connects all the netdata installations. We have done a lot of work towards this and we believe we are very close to show you what we mean. Patience...
Can I help?
Of course! Please do!
As with all open source projects, the more people using it, the better the project is. So give it a github star, post about it on facebook, twitter, reddit, google+, hacker news, etc. Spreading the word costs you nothing and helps the project improve. It is the minimum you should give back for using a project that has thousands of hours of work in it and you get it for free.
Also important is to open github issues for the things that are not working well for you. This will help us make netdata better.
These are others areas we need help:
Can you code?
- you can write plugins for data collection. This is very easy and any language can be used.
- you can write dashboards, specially optimised for monitoring the applications you use.
Can you write documentation?
- We have left the wiki open for anyone to edit. If any area needs further details, you can edit that page. (of course we monitor all edits - so please try to contribute and not destroy things).
Do you have special skills?
- are you a marketing guy? Help us setup a social media strategy to build and grow the netdata community.
- are you a devops guy? Help us setup and maintain the public global servers.
- are you a linux packaging guy? Help us distribute pre-compiled packages of netdata for all major distributions, or help netdata be included in official distributions.
Is there a roadmap?
These are what we currently work on (in that order):
Finish packaging for the various distros.
Add health monitoring (alarms, notifications, etc)
More plugins - a lot more plugins!
- monitor more applications (hadoop and friends, postgres, etc)
- rewrite the netfilter plugin to use libnlm.
- allow internal plugins to be forked to external processes (this will protect the netdata daemon from plugin crashes, allow different security schemes for each plugin, etc).
Improve the memory database (possibly using an internal deduper, compression, disk archiving, mirroring it to third party databases, etc).
Invent a flexible UI to connect multiple netdata server together. We have done a lot of progress with the registry and the
my-netdatamenu, but still there are a lot more to do.
Document everything (this is a work in progress already).
There are a lot more enhancements requested from our users (just navigate through the issues to get an idea). Enhancements like authentication on UI, alarms and alerts, etc will fit somehow into this list. Patience...