Category: Uncategorized

I have been exploring NetData for a while as I was looking for a better solution to monitor my small homelab. For alerting I have Nagios running on a Raspberry Pi 2, which suffices to get alerts when something is wrong. As this does not really provide useful insights on what happened over time and lacked detailed insight for network equipment, I looked into various solutions over time but did not find what I was looking for. For a long time I tried Observium, but as that was primarily intended for the network side and did not fully meet my needs. It did do what it promised but the SNMP setup required everywhere, the slow SNMP polling mechanism and issues it caused made me decide to move on to something else.

Currently I am trying out Netdata and have a simple setup with a central NetData parent / collector running on a Pi5 (data is stored on an NVMe disk) with all other systems in my homelab streaming the data to and minimum local processing (Thin Mode as per the Netdata documentation). Setting up monitoring for network over SNMP is also pretty simple and although the UI is a lot simpler than Observium, it does what I need right now. NetData documentation is pretty good, so I will not cover my basic setup or the various options available in this post but focus on adding a Synology NAS..

Today I added my Synology DS1618+ to this setup so that I can get metrics and alerts via NetData for it as well (currently Nagios uses SNMP to monitor some aspects to it and that simply fails too often causing false alarms that I want to get rid of.

The initial install was based on the Install Netdata on Synology page. Then why still a blog post? The good news is that the basic installation now supports Synology DSM 7.2.2 and higher. However, the description was not accurate and left me with a NetData system that had warning alerts that still had to be resolved.. Therefore I share the steps I used install and resolve the issues (and update these when needed).

Initial installation

To install the stable version (now 2.5.1) of NetData, enable automatic update and disable the sharing of usage datas, ssh into the Synology NAS using an account that can run sudo and run the command:

wget -O /tmp/netdata-kickstart.sh https://get.netdata.cloud/kickstart.sh && sh /tmp/netdata-kickstart.sh --stable-channel --disable-telemetry

Now I do want NetData to run as non-root, but despite the statements on the installation page (at this moment) that this would require additional steps, this turned out not to be true. The installation script already created a netdata user and group and is also running as this. However, the delivered setup is not quite correct as created netdata user was not member of the netdata group. To correct this (or just to be sure) and make this change active run:

sudo synogroup --memberadd netdata netdata
sudo systemctl restart netdata

Netdata is now running on the NAS on port 19999 and it’s web UI can be accessed on that port. Please note that you may need to open your NAS’ firewall to be able to connect to it. Alternatively, you can also use SSH port forwarding (add -L 19999:localhost:19999 to your SSH command and NetData will be available as http://localhost:19999 as long as your SSH session is active).

Move Netdata to Storage [Addition 2025-05-18]

After running NetData for a while and despite being in Thin Client (i.e. streaming) mode, it will fill-up your root partition (the one where DSM lives), which is not good. To prevent this from becoming a problem, I moved NetData to a data volume post installation by running the following commands prior to the installation:

sudo systemctl stop netdata
sudo mv /opt/netdata /volume1/
sudo ln -s /volume1/netdata /opt/
sudo systemctl start netdata

Resolve restricted access to Synology’s Docker

After installation, NetData was unable to get the docker container names from the Docker engine running on my Synology NAS. This was caused by /var/run/docker.sock not being accessible. The easiest solution for this I found was to add user netdata to the group root, which owned the socket with:

sudo synogroup --memberadd root netdata

To make this change changes active run:

sudo systemctl restart netdata

Resolve system_clock_sync_state Alert

For unclear reasons, Synology DSM 7.2.2 does not seem to synchronize the system time with the real-time clock when NTP is enabled. Suggestions were provided in this forum post, which were in the right direction but outdated. To disable this error I found that editing /etc/chrony.conf.user and adding:

rtcsync

would do the trick after restarting chronyd with sudo systemctl restart chronyd the alert was cleared within seconds.

Setup Metric Streaming

As I had my existing setup and did not want the NAS to be busy with monitoring or stream it’s data to the (relatively slow) disks it has, I performed the following configuration changes:

1. stop the running netdata with: sudo systemctl stop netdata
2. change to the config directory: cd /opt/netdata/etc/netdata
3. edit the main config file with sudo ./edit-config netdata.conf and change:
   1. to disable to web UI, add/change in section [web]:
      mode = none
   2. to disable the machine learning, add/change in section [ml]:
      enabled = no
   3. to disable health alerts, add/change in section [heath]:
      enabled = no
4. create and edit the stream config file with sudo ./edit-config stream.conf and add/change in section [stream]:
   1. enabled = yes
   2. destination = <<YOUR NETDATA PARENT>>:19999
   3. api key = <<YOUR NETDATA STREAM API KEY>>
5. change ownership and permissions of the created files with:
   1. sudo chgrp netdata netdata.conf stream.conf
   2. sudo chmod 640 netdata.conf stream.conf
6. start netdata with: sudo systemctl start netdata

Netdata will soon start streaming metrics to you parent / collector server.

Conclusion

Having NetData running on my Synology NAS immediately gives me an insight in what is happening on the NAS out of the box. I still would be interested to see if more sensors area available via other plugins, but the basic metrics provided out of the box are already very useful.

The work is not yet done, as I currently still get 3 alerts for 10min_disk_backlog, this seems to happen more often and is something that can be tweaked according to this bug report. For now I have silenced them and will look into that at a later moment.