New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Windows service collector takes over 500s to scrape data #1458
Comments
That feels strange, because service collector doesn't interact with perflib |
@paologallinaharbur by any chance, I would like to know, if #1497 help you.
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 |
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 🤔
I'll test out the solution proposed, but I wonder if the perflib "time" would be reduced as well |
It could be possible that query nothing takes up to 300 seconds on your system. |
I am not following.. is that an actual possibility? 😅 If so:
|
Maybe you are hitting a bug in windows_exporter. With
you only have enabled a collectors which does not register and request any perflib counters. This leads to an situation where is 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
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
which should do nothing. But with zero collectors, windows_exporter would still ask for perfdata. |
We have been noticing the exporter taking more time to scrape data than expected both if executed with
use-api
or with the oldWMI
while filtering servicesWe have a "normal" number of services that are scraped, but the exporter takes a lot to answer, in particular I find weird the following metrics
I have the feeling that scraping the services is "quick" but crating a perflib snapshot wastes a lot of time, even thought the service has an empty list of perfCounters
The text was updated successfully, but these errors were encountered: