-
Notifications
You must be signed in to change notification settings - Fork 1
Tracing Options
When you compile netdata with debugging:
-
compiler optimizations for your CPU are disabled (netdata will run somewhat slower)
-
a lot of code is added all over netdata, to log debug messages to
/var/log/netdata/debug.log. However, nothing is printed by default. netdata allows you to select which sections of netdata you want to trace. Tracing is activated via the config optiondebug flags. It accepts a hex number, to enable or disable specific sections. You can find the options supported at log.h. They are theD_*defines. The value0xffffffffffffffffwill enable all possible debug flags.
Once netdata is compiled with debugging and tracing is enabled for a few sections, the file /var/log/netdata/debug.log will contain the messages.
Do not forget to disable tracing (
debug flags = 0) when you are done tracing. The filedebug.logcan grow too fast.
To compile netdata with debugging, use this:
# step into the netdata source directory
cd /usr/src/netdata.git
# run the installer with debugging enabled
CFLAGS="-O1 -ggdb -DNETDATA_INTERNAL_CHECKS=1" ./netdata-installer.shThe above will compile and install netdata with debugging info embedded. You can now use debug flags to set the section(s) you need to trace.
We have made the most to make netdata crash free. If however, netdata crashes on your system, it would be very helpful to provide stack traces of the crash. Without them, is will be almost impossible to find the issue (the code base is quite large to find such an issue by just objerving it).
To provide stack traces, you need to have netdata compiled with debugging. There is no need to enable any tracing (debug flags).
Then you need to be in one of the following 2 cases:
-
netdata crashes and you have a core dump
-
you can reproduce the crash
If you are not on these cases, you need to find a way to be (i.e. if your system does not produce core dumps, check your distro documentation to enable them).
you need to have netdata compiled with debugging info for this to work (check above)
Run the following command and post the output on a github issue.
gdb $(which netdata) /path/to/core/dumpyou need to have netdata compiled with debugging info for this to work (check above)
Install the package valgrind and run:
valgrind $(which netdata) -Dnetdata will start and it will be a lot slower. Now reproduce the crash and valgrind will dump on your console the stack trace. Open a new github issue and post the output.
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)