D34DC3N73R

It doesn't look like everything from the python plugin has been added to the go plugin yet. I would hope they're coming, but the change was probably necessary for the new interface. These are what show up for me

Excellent. Glad it's working for you. I believe there is still more work to be done on the go.d plugin, and honestly it seemed a bit premature to deprecate the python.d version, but hopefully it'll catch up soon. Let me know if you run into any issues. Thanks for trying out the new version of the template.

I haven't written it all out yet, but I do have a template that works. It need some documentation updates since the python nvidia-smi has been deprecated. If you'd like to test it out, you can follow these steps. Stop and delete the existing container. (configuration, not data) download the XML template wget -O /boot/config/plugins/dockerMan/templates-user/my-netdata-gpu.xml https://raw.githubusercontent.com/D34DC3N73R/unraid-templates/netdata-image/netdata-glibc.xml In the unraid docker page, scroll to the bottom and click 'add container'. Select netdata-gpu from the template dropdown. The standard paths should be good for most new installs. The data and paths are compatible with the previous version of my image. However, my image shipped with python nvidia-smi enabled by default. Since that is now deprecated, you should disable it and enable the go.d implementation. To do that, you should start the new container and then use the built in .edit-config If you're using an existing configuration, you should edit python.d.conf docker exec -it netdata bash cd /etc/netdata ./edit-config python.d.conf You'll need to add a # in front of nvidia-smi to disable the python nvidia-smi module. Save and quit vi If you're using a new configuration or you've disabled the python nvidia-smi, then you can edit go.d.conf docker exec -it netdata bash cd /etc/netdata ./edit-config go.d.conf That will open the default go.d.conf file using vi, and save changes in your mounted directory /mnt/user/appdata/netdata/config. You'll need to delete the # and change 'no' to 'yes'. # nvidia_smi: no so it becomes nvidia_smi: yes The two spaces before nvidia-smi are important. When you're done editing, save, exit the container cli, and restart the container. If you have questions or run into problems please let me know. I'll be pushing the new template soon after I have time to run some more tests. Edit: Tip: If you'd like to use an alternate editor in place of vi, you can add the nano package for instance to the NETDATA_EXTRA_APK_PACKAGES environment variable (default `gcompat`). add a space between package names `gcompat nano`. Then you'll be able to call the edit config script using the new editor ./edit-config --editor nano python.d.conf

That seems correct. Did you make any edits to the template or run it as is?

I moved my entire netdata appdata folder to netdata.bak and started from scratch, but I'm not able to reproduce that with the latest or stable images and the current template from CA. Do you have auto-updates enabled? Is it possible you're using old images? Can you confirm it's running netdata v1.39.0?

/mnt/user/appdata/netdata/config will be populated on first run with the following folders & files: From here, you should use the netdata edit-config script to make changes to any conf. For instance, to make changes to python.d.conf root@Tower:~# docker exec -it netdata-glibc bash unraid:/# cd /etc/netdata unraid:/etc/netdata# ./edit-config python.d.conf That will open up the default /usr/lib/netdata/conf.d/python.d.conf in a vi editor where you can make any changes. That fill will be saved to /etc/netdata as an override. This is the same functionality as the default netdata image. At this point, the only difference between this image and the default image is the glibc library required for nvidia GPUs and nvidia-smi being enabled by default in python.d.conf I do have a template I'm testing for the default netdata image now that it's compatible. If you want to test it out, see this post.

You happen to install right before some significant changes to the template and image. I would suggest removing the container and reinstalling from the community app store. Afterwards, you can copy configuration files from /mnt/user/appdata/netdata/override to /mnt/user/appdata/netdata/config. These are the new folders for persistent data There are also now environment variables to enter a netdata cloud token and room ID. Let me know if you run into any trouble.

Some exciting news, the official Netdata image can now be used to enable nvidia GPUs! I've submitted a PR (recently merged) to netdata/netdata documentation as to how this works. d34dc3n73r/netdata-glibc will be deprecated in favor of using the official image, but I will keep the template up with the required configuration to enable nvidia GPUs. For anyone who wants to test the template, you can run this command to get the new version using netdata/netdata wget -O /boot/config/plugins/dockerMan/templates-user/my-netdata-test.xml https://raw.githubusercontent.com/D34DC3N73R/unraid-templates/netdata-image/netdata-glibc.xml It's fully compatible with the previous dev image so the same directories can be used. A couple of important notes: - This is currently works with :edge and :latest tags. When the next stable build of Netdata is released it will work will all tags. - You will likely have to edit python.d.conf to uncomment nvidia_smi: yes. More about that here: https://learn.netdata.cloud/docs/data-collection/monitor-anything/Hardware/nvidia_smi-python.d.plugin#docker-troubleshooting Let me know if you have any questions or problems.

I'd recommend trying out the dev image & template. It's much more similar to stock netdata now that their image has override support. If it's a recent install, you're essentially using the new `edit-config` with the old method of custom override support. In the dev image, the only difference between this and stock netdata is the glibc support layer, enabling nvidia-smi by default, and adding nano as a config editor.

Thanks for trying out the dev image. The CA template and image will be updated with the next netdata release. The only thing you'll need to do is change the image tag from :dev to :stable or :latest depending on your preference.

I'm curious if you've tried to connect to netdata cloud or tried any custom configs using netdata edit-config. I have some general info about the dev container here for your reference. Thanks for trying out this new image and template!

I have a test template and image available to try out. To get the template, in unraid terminal or ssh run wget -O /boot/config/plugins/dockerMan/templates-user/my-netdata-glibc-dev.xml https://raw.githubusercontent.com/D34DC3N73R/unraid-templates/dev/netdata-glibc.xml In the unraid docker page, scroll to the bottom and click 'add container'. Select 'netdata-glibc-dev' from the template dropdown and change the image (Repository:) to d34dc3n73r/netdata-glibc:dev If you've never installed before, this should be all it takes. If you have files and folders in /mnt/user/appdata/netdata, I recommend moving them to a temp directory like netdata-temp, and then starting the container once, stopping it and copying any configs you want to keep to the new netdata folders. The new environment variables NETDATA_CLAIM_TOKEN, NETDATA_CLAIM_URL, and NETDATA_CLAIM_ROOMS are not required, but if you want to connect to netdata cloud, see https://learn.netdata.cloud/docs/agent/claim#connect-an-agent-running-in-docker for instructions on how to get the claim token and claim room (claim url is prefilled). I'd appreciate any feedback or experiences.

The container logs, or from unraid terminal / ssh docker logs netdata-glibc 2>&1 | grep "go.d ERROR: ping"

Also, to give everyone an update on the state of the image, Netdata has reworked edit-config so the method I was using is no longer necessary. I'm still finishing up some cleanup and testing, but there will be an updated template and image soon.

If you search the logs for "go.d ERROR: ping" you'll likely see "listen ip4:icmp : socket: operation not permitted" when using ping, you can get around this by using unprivileged udp pings For example jobs: - name: pihole hosts: - 192.168.0.231 - 192.168.0.232 privileged: no After a reboot you'll see ping show up under sensors