-
Notifications
You must be signed in to change notification settings - Fork 1
New Module PR Checklist
This is a generic checklist for submitting a new Python or Node.js module for Netdata. It is by no means comprehensive.
At minimum, to be buildable and testable, the PR needs to include:
- The module itself, following proper naming conventions:
- For Python modules, it should be
python.d/<module_name>.chart.py - For Node.js modules, it should be
node.d/<module_name>.node.js
- For Python modules, it should be
- The configuration file for the module:
- For Python modules, this should be
conf.d/python.d/<module_name>.conf. Python config files are in YAML format, and should include comments describing what options are present. Take a look at other config files for Python modules for an idea of what is expected. - For Node.js modules, you instead need to provide a Markdown document explaining the configuration process with usable examples for the configuration. The actual configuration files are in JSON format (which doesn't support comments, hence the need for a file explaining the configuration). Take a look at the other config descriptions for Node.js modules for an idea of what is expected.
- For Python modules, this should be
- A basic configuration for the plugin in the appropriate global config file:
- For Python modules, this should be
conf.d/python.d.conf, which is also in YAML format. Either add a line that reads# <module_name>: yesif the module is to be enabled by default, or one that reads<module_name>: noif it is to be disabled by default. - For Node.js modules, this should be
conf.d/node.d.conf, which is also in JSON format. If the module should be enabled by default, add a section for it in themodulesdictionary.
- For Python modules, this should be
- A line for the plugin in the appropriate
Makefile.amfile:- For a Python module, you need a line in
python.d/Makefile.amunderdist_python_DATA. - For a Node.js module, you need a line in
node.d/Makefile.amunderdist_node_DATA.
- For a Python module, you need a line in
- A line for the plugin configuration file in
conf.d/Makefile.am:- For Python plugins, the line should be under
dist_pythonconfig_DATA - For Node.js plugins, the line should be under
dist_nodeconfig_DATA
- For Python plugins, the line should be under
- A section for the plugin in the appropriate README file, including basic information about what stats the plugin collects, as well as some example configuration, and info about what dependencies (if any) it has.
- For Python plugins, this is
python.d/README.md - For Node.js plugins, this is
node.d/README.md
- For Python plugins, this is
- Optionally, chart information in
web/dashboard_info.js. This generally involves specifying a name and icon for the section, and may include descriptions for the section or individual charts.
Once the PR has been accepted and merged, there are two more things you should ideally take care of:
General
- Home
- Why netdata
- Installation
- Installation with docker
- Command Line Options
- Configuration
- Log Files
- Tracing Options
Running Netdata
Special Uses
-
netdata for IoT
lower netdata resource utilization -
high performance netdata
netdata public on the internet
Notes on memory management
-
Memory deduplication
half netdata memory requirements - netdata virtual memory size
Database Replication and Mirroring
- Replication Overview
-
monitoring ephemeral nodes
Use netdata to monitor auto-scaled cloud servers. -
netdata proxies
Streaming netdata metrics between netdata servers.
Backends
archiving netdata collected metrics to a time-series database
-
netdata-backends
graphite,opentsdb,kairosdb,influxdb,elasticsearch,blueflood - netdata with prometheus
- Walk Through: netdata with prometheus and grafana
Health monitoring - Alarms
alarms and alarm notifications in netdata
- Overview
-
Reference
reference for writing alarms -
Examples
simple how-to for writing alarms -
Notifications Configuration
- health API calls
- troubleshooting alarms
Netdata Registry
Monitoring Info
-
Monitoring web servers
The spectacles of a web server log file -
monitoring ephemeral containers
Use netdata to monitor auto-scaled containers. - monitoring systemd services
-
monitoring cgroups
Use netdata to monitor containers and virtual machines. -
monitoring IPMI
Use netdata to monitor enterprise server hardware - Monitoring disks
- Monitoring Go Applications
Netdata Badges
Data Collection
- Add more charts to netdata
- Internal Plugins
- External Plugins
-
statsd
netdata is a fully featured statsd server -
Third Party Plugins
netdata plugins distributed by third parties
Binary Modules
Python Modules
- How to write new module
- apache
- beanstalk
- bind_rndc
- ceph
- couchdb
- cpuidle
- cpufreq
- dns_query_time
- dovecot
- elasticsearch
- exim
- fail2ban
- freeradius
- go_expvar
- haproxy
- hddtemp
- httpcheck
- icecast
- ipfs
- isc_dhcpd
- litespeed
- mdstat
- megacli
- memcached
- mongodb
- mysql
- nginx
- nginx_plus
- nsd
- ntpd
- ovpn_status_log
- phpfpm
- portcheck
- postfix
- postgres
- powerdns
- puppet
- rabbitmq
- redis
- rethinkdbs
- retroshare
- sensors
- spigotmc
- springboot
- squid
- smartd_log
- tomcat
- traefik
- unbound
- varnish
- w1sensor
- web_log
Node.js Modules
BASH Modules
Active BASH Modules
Obsolete BASH Modules
- apache
- cpufreq
- cpu_apps
- exim
- hddtemp
- load_average
- mem_apps
- mysql
- nginx
- phpfpm
- postfix
- sensors
- squid
- tomcat
API Documentation
Web Dashboards
-
Learn how to create dashboards with charts from one or more netdata servers!
Running behind another web server
Package Maintainers
Donations
Blog
-
December, 2016
Linux console tools, fail to report per process CPU usage properly
-
April, 2016
You should install QoS on all your servers (Linux QoS for humans)
Monitor application bandwidth with Linux QoS (Good to do it, anyway)
Monitoring SYNPROXY (Linux TCP Anti-DDoS)
-
March, 2016
Article: Introducing netdata (the design principles of netdata)