Windows service collector takes over 500s to scrape data about windows_exporter HOT 10 CLOSED

That feels strange, because service collector doesn't interact with perflib

from windows_exporter.

@paologallinaharbur by any chance, I would like to know, if #1497 help you.

Do you have any idea why this could be happening?

WMI is slow, and the API based approach is asking each single service about status and query.

#1497 is using a different approach by asking the Windows API once. On my local system, it's quite fast but It wont provide all information, like run_as, pid or start mode

from windows_exporter.

WMI is slow, and the API based approach is asking each single service about status and query.

Still I see the exporter wasting more time on perflib rather then collecting metrics and in VMs having similar number of services the perflib_snapshot si close to zero 🤔

windows_exporter_collector_duration_seconds{collector="service"} 0.543678
windows_exporter_perflib_snapshot_duration_seconds 286.9878764

I'll test out the solution proposed, but I wonder if the perflib "time" would be reduced as well

from windows_exporter.

It could be possible that query nothing takes up to 300 seconds on your system.

from windows_exporter.

I am not following.. is that an actual possibility? 😅 If so:

• how is actually doing during those 300s?
• is there a way to run the exporter with "no collectors" and test that? I've tried with --collectors.enabled, but I think at least one should be enabled 😕

from windows_exporter.

Maybe you are hitting a bug in windows_exporter.

With

windows_exporter.exe --collectors.enabled service

you only have enabled a collectors which does not register and request any perflib counters.

This leads to an situation where is where clause gets empty. (This is what I mean with query nothing). I guess thats unknown behavior here. An empty where clause cloud also leads to return all data. But I'm unable to verify that.

Background: In windows_exporter, perfdata is always collected before collectors are called. On startup, collectors can register perfdata counters. Then if Prometheus is calling /metrics, windows_exporter scrape all registered perfdata once and will provide the data to each collector.

if you configure

windows_exporter.exe --collectors.enabled service,os

then, there is a where clause. It would be great to know if this helps and validate the assumption.

From perfdata point of view, there is no difference between zero collector or service collector enabled.

You can also try to use

windows_exporter.exe --collectors.enabled textfile --collector.textfile.directories=path_to_dir_with_empty_file

which should do nothing. But with zero collectors, windows_exporter would still ask for perfdata.

from windows_exporter.

This issue has been marked as stale because it has been open for 90 days with no activity. This thread will be automatically closed in 30 days if no further activity occurs.

from windows_exporter.

@paologallinaharbur In case, you are still active, do you want to try out an snapshot build which should resolve your issue?`

https://github.com/prometheus-community/windows_exporter/actions/runs/10670590125/artifacts/1883017045

from windows_exporter.

Hello! sadly I have no access to the environment.
Back then in order to avoid breaking the metrics (since we were using an old version and we were not able to upgrade) we added a new collector interacting with perflib just ti register and request some perflib counters.
That reduced dramatically the time needed to execute from 500s to 3s. That worked for us. 😄

I think that in that old version perflib was always scraped and without any counter specified it was scraping them all 🤯

from windows_exporter.

I think that in that old version perflib was always scraped and without any counter specified it was scraping them all 🤯

Yeah, I go down the path until ReqQueryCommand and it's documented that if the key is empty, then "default" is returned.

from windows_exporter.