|Jeffrey Paul cc7c54fa39 fix stupid binary downloader thing||1 year ago|
|scripts||1 year ago|
|.drone.yml||1 year ago|
|.gitignore||1 year ago|
|Dockerfile||1 year ago|
|LICENSE||1 year ago|
|README.md||1 year ago|
This repository is forked from titpetric/netdata, which embeds the netdata spyware and refuses to patch it out.
Dockerfile for building and running a netdata deamon for your host instance.
Netdata monitors your server with thoughts of performance and memory usage, providing detailed insight into very recent server metrics. It’s nice, and now it’s also dockerized.
More info about project: https://github.com/firehol/netdata
docker run -d --cap-add SYS_PTRACE \ -v /proc:/host/proc:ro \ -v /sys:/host/sys:ro \ -p 19999:19999 \ --restart unless-stopped \ sneak/netdata
Note: Remove the
--restart unless-stoppedparameter if you don’t need the netdata container to start automatically on boot.
Open a browser on http://server:19999/ and watch how your server is doing.
By default netdata listens to 0.0.0.0 (any address). You might want to change this if you’re running netdata in
--net=host mode. You can pass the following environment variable:
127.0.0.1for localhost only.
If you need to pass some custom options to netdata, you can pass the following environment variable:
-e NETDATA_ARGS="-i 127.0.0.1"for same effect.
Netdata supports forwarding alarms to an email address. You can set up msmtp by setting the following ENV variables:
For example, using gmail:
-e SMTP_TOemail@example.com -e SMTP_USER=user -e SMTP_PASS=password
Alternatively, if you already have s msmtp config, you can use that config with:
See the following link for details on setting up msmtp: MSMTP - ArchWiki
To add custom alarms, charts or to override any default configuration file, mount a volume to the container to /etc/netdata/override, like
-v /opt/netdata/override:/etc/netdata/override:ro. Then, place your config files in the directory as if it was /etc/netdata/.
For example to create a custom alarm for system temperature, create a
health.d folder in your local directory (
/opt/netdata/override in the example above) and place a
sensors.conf file with your alarm configuration inside the
Netdata supports sending alerts to slack via webhooks. You can set that up by setting the following ENV variables:
-e SLACK_WEBHOOK_URL=https://hooks.slack.com/services/XXXX -e SLACK_CHANNEL=alerts
Netdata supports sending alerts to Discord via webhooks. You can set that up by setting the following ENV variables:
-e DISCORD_WEBHOOK_URL=https://discordapp.com/api/webhooks/XXXX -e DISCORD_RECIPIENT=alerts
Netdata supports sending alerts to Telegram via token and chat ID. You can set that up by setting the following ENV variables:
-e TELEGRAM_BOT_TOKEN=22624413:AAGy12TkSMBYVBTe4lQt3BfUYvUs5h7I1jn -e TELEGRAM_CHAT_ID=137165138
For more details about Telegram alerts, see this page - GitHub
Netdata supports sending alerts to Pushbullet via API token. You can set that up by setting the following ENV variables:
-e PUSHBULLET_ACCESS_TOKEN=o.l8VuizWhXgbERf2Q78ghtzb1LDCYvbSD -e PUSHBULLET_DEFAULT_EMAILfirstname.lastname@example.org
More details about Pushbullet alerts are provided here - GitHub
On a client netdata set this destination to be the HOST[:PORT] of the
central netdata, and give an
API_KEY that is secret and only known internally
to the netdata clients, and netdata central. See this page - GitHub
HOST[:PORT]to stream to
API_KEYto send to central net data
-e NETDATA_STREAM_DESTINATION=netdata.service:19999 -e NETDATA_STREAM_API_KEY=1h213ch12h3rc1289e
On the central netdata set 1 or more
NETADATA_API_KEY_ENABLE env variables that matches the
that you used on the client above, this will enable the netdata client node to communicate with the netdata central
Netdata supports fetching container data from
docker.sock. You can forward it to the netdata container with:
This will allow netdata to resolve container names.
Note: forwarding docker.sock exposes the administrative docker API. If due to some security issue access has been obtained to the container, it will expose full docker API, allowing to stop, create or delete containers, as well as download new images in the host.
On debian jessie only ‘cpu’ and ‘disk’ metrics show up under individual docker containers. To get the memory metric, you will have to add
cgroup_enable=memory swapaccount=1 to
/etc/default/grub, appending the
$ cat /etc/default/grub | grep GRUB_CMDLINE_LINUX_DEFAULT GRUB_CMDLINE_LINUX_DEFAULT="quiet cgroup_enable=memory swapaccount=1"
After rebooting your linux instance, the memory accounting subsystem of the kernel will be enabled. Netdata will pick up additional metrics for the containers when it starts.
It’s possible to pass a NETDATA_PORT environment variable with -e, to start up netdata on a different port.
docker run -e NETDATA_PORT=80 [...]
Docker needs to run with the SYS_PTRACE capability. Without it, the mapped host/proc filesystem is not fully readable to the netdata deamon, more specifically the “apps” plugin:
16-01-12 07:58:16: ERROR: apps.plugin: Cannot process /host/proc/1/io (errno 13, Permission denied)
See the following link for more details: /proc/1/environ is unavailable in a container that is not priviledged
In addition to the above requirements and limitations, monitoring the complete network interface list of the host is not possible from within the Docker container. If you’re running netdata and want to graph all the interfaces available on the host, you will have to use
See the following link for more details: network interfaces missing when mounting proc inside a container
The script refreshes network information about every 250ms (four times per second). The interval may be increased to give better accuracy of netdata, but CPU usage will also increase. Because of this, the data is not very accurate and some spikes and valleys will occur because of a shifting window between when the reading was taken (fakeproc) and between when the reading was read by netdata. This means the margin for error is whatever data can be collected in ~250ms.
While the solution might not fit everybody, it’s security-positive because the netdata container can only inspect the fake proc/net location, and can’t actually access any of the networks because it runs on a private LAN / custom network which is managed and firewalled by docker. You may even open access via application, like a nginx reverse proxy where you can add authentication etc.
Netdata provides monitoring via a plugin architecture. This plugin supports many projects that don’t provide data over the
/proc filesystem. When you’re running netdata in the container, you will have difficulty providing many of these paths to the netdata container.
What you do get (even with the docker version) is:
You will not get detailed application metrics (mysql, ups, etc.) from other containers or from the host if running netdata in a container. It may be possible to get some of those metrics, but it might not be easy, and most likely not worth it. For most detailed metrics, netdata needs to share the same environment as the application server it monitors. This means it would need to run either in the same container (not even remotely practical), or in the same virtual machine (no containers).
Note: if you have some custom hardware like a UPS which is monitored via USB and netdata supports it, you will most likely need to add new software to the netdata docker image to support it. The correct way to do it is to create your own Dockerfile, start with “FROM sneak/netdata” and then add all your installation commands to build your own image which will support your hardware setup. Most likely if it’s not a very common setup (i.e. available on most machines), the software will not be added to
sneak/netdata- that being said, your use case might be useful for others so feel free to submit issues with your extensions or feature requests in terms of new software. I’ll gladly add your project/extension to the README here.