Closed pflesar closed 2 months ago
There are any logs while calling http://localhost:9182/metrics ?
Could you post the output of http://localhost:9182/metrics ?
No logs appear when calling the metrics page. No browser console errors (apart from missing favicon). I could post the output, but would have to redact it first (as it now contains full usernames).
However, I checked the recent commits; I think you removed the local_session_count metrics altogether while you were adding the session_info metrics: https://github.com/prometheus-community/windows_exporter/commit/7044b556c27d6ac2b97a08bea9620d5642d337ff#diff-8e34fa71b73f05033f914496ccfd57a8e6cb7dd4c88684a2a032c8c357e54823L103-L106
If thought it was superfluous to collect the number of sessions, while a list of sessions will be collected that can be counted by a query, then the documentation should be updated here: https://github.com/prometheus-community/windows_exporter/blob/master/docs/collector.terminal_services.md Although that would be a "breaking" change for someone who used the local_session_count metrics in alerts and dashboards.
Hi @pflesar
your are right. The changes I did where months ago, I couldn't fully remember about that change. I will adjust the documentation soon. You already mention the reason, why I removed that metric.
0.26 take a while to release and it includes tons of changes. The next releases will be shorted and the Release Notes will better inform about breaking changes.
At the moment, we may decide to do some breaking changes. We will stop doing breaking changes, once we receive the V1. I'm aware that this is may does not fit your satisfactions, but I understand your critic. I will better inform end-users about breaking changes in the coming version, create smaller releases and taking an eye of the documentation.
I am perfectly fine to count the statistics from other metrics. I also don't mind breaking changes before full release. As long as its documented I think everyone should be satisfied.
Thank you
Summary:
I had no idea, what the root cause of High scraping time was.
I saw
windows_exporter 8/12/2024 2:41:12 PM Cannot create another system semaphore.
in your logs which seems suspicious to me and could the root cause for that issue.
I reopen the issue to remember that I have to fix the docs.
I had no idea, what the root cause of High scraping time was.
I saw
windows_exporter 8/12/2024 2:41:12 PM Cannot create another system semaphore.
in your logs which seems suspicious to me and could the root cause for that issue.
I unintentionally removed a firewall exception so the scraping was actually unsuccessful at the time I checked, with connection timeout being 10 seconds. Apologies. please feel free to ignore that.
Current Behavior
If collector terminal_services is enabled, metrics "windows_terminal_services_local_session_count" are not produced. Additionally, scraping takes unexpectedly long (10 sec in my case). There is no associated error in event log - msiexec finishes without issues and no logs are produced during service runtime.
Expected Behavior
Metrics "windows_terminal_services_local_session_count" are produced and the scrape takes a reasonable amount of time. In my case on 0.25.1 it took ~0.5 seconds with the same collectors enabled.
Steps To Reproduce
Environment
windows_exporter logs
Anything else?
No response