problem with windows monitoring

Hi. I have installed successfully the netdata agent in docker on a linux mahchine in my network. Now I want to use this node to collect metrics from a windows machine on my network. I attached within the docker container and implemented the instructions in Windows machine monitoring with Netdata | Learn Netdata

The windows machine is reachable via ping from within the container.

The windows machine is not showing up in netdata.cloud.

Please help. I have read all windows-related content on this forum but no success.

Here is the debug output of the collector as per the Troubleshooting section of the above article by running “./go.d.plugin -d -m wmi”:
[ DEBUG ] main[main] main.go:111 plugin: name=go.d, version=v0.31.2
[ DEBUG ] main[main] main.go:113 current user: name=root, uid=0
[ INFO ] main[main] agent.go:106 instance is started
[ INFO ] main[main] setup.go:39 loading config file
[ INFO ] main[main] setup.go:47 looking for ‘go.d.conf’ in [/etc/netdata /usr/lib/netdata/conf.d]
[ INFO ] main[main] setup.go:54 found ‘/usr/lib/netdata/conf.d/go.d.conf
[ INFO ] main[main] setup.go:61 config successfully loaded
[ INFO ] main[main] agent.go:110 using config: enabled ‘true’, default_run ‘true’, max_procs ‘0’
[ INFO ] main[main] setup.go:66 loading modules
[ INFO ] main[main] setup.go:85 enabled/registered modules: 1/63
[ INFO ] main[main] setup.go:90 building discovery config
[ INFO ] main[main] setup.go:116 looking for ‘wmi.conf’ in [/etc/netdata/go.d /usr/lib/netdata/conf.d/go.d]
[ INFO ] main[main] setup.go:123 found ‘/etc/netdata/go.d/wmi.conf
[ INFO ] main[main] setup.go:128 dummy/read/watch paths: 0/1/0
[ INFO ] discovery[manager] manager.go:90 registered discoverers: [file discovery: [file reader]]
[ INFO ] discovery[manager] manager.go:95 instance is started
[ INFO ] run[manager] run.go:30 instance is started
[ INFO ] discovery[file manager] discovery.go:71 instance is started
[ INFO ] build[manager] build.go:106 instance is started
[ INFO ] discovery[file reader] read.go:39 instance is started
[ INFO ] discovery[file reader] read.go:40 instance is stopped
[ DEBUG ] build[manager] build.go:153 received config group (’/etc/netdata/go.d/wmi.conf’): 1 jobs (added: 1, removed: 0)
[ DEBUG ] build[manager] build.go:302 building wmi[konto_old] job, config: map[provider:file reader source:/etc/netdata/go.d/wmi.conf autodetection_retry:0 module:wmi name:konto_old priority:70000 update_every:5 url:http://xx.xx.xx.xx:9182/metrics]
[ DEBUG ] run[manager] run.go:41 tick 0
[ DEBUG ] run[manager] run.go:41 tick 1
[ DEBUG ] run[manager] run.go:41 tick 2
[ DEBUG ] run[manager] run.go:41 tick 3
[ DEBUG ] run[manager] run.go:41 tick 4
[ ERROR ] wmi[konto_old] wmi.go:87 Get “http://xx.xx.xx.xx:9182/metrics”: context deadline exceeded (Client.Timeout exceeded while awaiting headers)
[ ERROR ] wmi[konto_old] job.go:157 check failed
[ DEBUG ] run[manager] run.go:41 tick 5

I just saw that it shows up at the bottom of the linux node but not as a separate node. This is confusing. Is it possible to track it as a separate node?
BR

1 Like

You know, it would be nice if the Vnode settings meant that, it would show up as a node, just like any other docker, pve, pi, or linux box -

I have 2 (Virtual machine windows) fully locked in, and with the provided settings - I see a “Windows” but, I don’t see Windows11 or Windows-2021svr as the names - I just see it all loaded into the one area - lots of data and working good but, I don’t think the “vnode” is what I was thinking the “vnode” should be - I removed that vnode and, left it like it was - collecting but, all but useless.

It does my PI, lxc, docker, and Linux items without a problem. … I guess I’ll yield but, would love to toss Windows-11 / -2021svr over under the “nodes” and check a box next to them. :wink:

Great job so far, gotta love it.

Hi, @crunchtoinfo.

[ ERROR ] wmi[konto_old] wmi.go:87 Get “http://xx.xx.xx.xx:9182/metrics”: context deadline exceeded (Client.Timeout exceeded while awaiting headers)

This message means that Netdata didn’t get the response from “http://xx.xx.xx.xx:9182/metrics” in timeout seconds. The default timeout is 5. If that is expected that the node responds slowly, you can increase both update_every and timeout parameters and run the plugin in the debug mode to see if that helps. Try increasing them to 10.