Skip to content
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

Add Windows Service status metrics #31377

Open
dodegaard opened this issue Feb 21, 2024 · 19 comments
Open

Add Windows Service status metrics #31377

dodegaard opened this issue Feb 21, 2024 · 19 comments
Labels
os:windows Sponsor Needed New component seeking sponsor

Comments

@dodegaard
Copy link

Component(s)

receiver/hostmetrics

Is your feature request related to a problem? Please describe.

Currently there is not a metric that can relay the running status of a Windows Service.

Describe the solution you'd like

In the hostmetrics receiver there is a library called github.com/shirou/gopsutil that is able to tap into Windows Service running status data and it would be helpful to gain access and scrape this information along with attributes that describe the service. This should most likely be an opt-in to perform this function. The process_scraper_windows.go module could be the home for the method(s).

Describe alternatives you've considered

No response

Additional context

No response

@dodegaard dodegaard added enhancement New feature or request needs triage New item requiring triage labels Feb 21, 2024
Copy link
Contributor

Pinging code owners:

See Adding Labels via Comments if you do not have permissions to add labels yourself.

@dodegaard
Copy link
Author

This is the corresponding library that can gain access to that information. https://github.com/shirou/gopsutil/blob/master/winservices/winservices.go

Copy link
Contributor

This issue has been inactive for 60 days. It will be closed in 60 days if there is no activity. To ping code owners by adding a component label, see Adding Labels via Comments, or if you are unsure of which component this issue relates to, please ping @open-telemetry/collector-contrib-triagers. If this issue is still relevant, please ping the code owners or leave a comment explaining why it is still relevant. Otherwise, please close it.

Pinging code owners:

See Adding Labels via Comments if you do not have permissions to add labels yourself.

@dconnolly-sfdc
Copy link

+1
would love to see this capability added

@crobert-1 crobert-1 added Sponsor Needed New component seeking sponsor and removed receiver/hostmetrics labels Aug 29, 2024
@syron
Copy link

syron commented Aug 29, 2024

Not aware of the library capabilities you mentioned, but what's your guys opinion on whether to use one instance of the OTEL collector to catch several servers' Windows Services like diagram 1 below or is it to install one instance per Windows server?

One OTEL collector for multiple servers

One OTEL collector per server

The question is what's more maintainable.

@hhgsplk
Copy link

hhgsplk commented Aug 29, 2024 via email

@syron
Copy link

syron commented Aug 29, 2024

I think that is an important part in the topic, because this will potentially set different parameters to be configured. I am a bit unsure which path to go here. I have developed a software widely used within the systemintegration area where we have written an agent like system that calls remote servers. However, we have experienced limitations when the number of servers to fetch services & processes from became bigger than 20 and that was due to it taking too much time. Never experienced any instability though.

I mean, in a scenario where we would use otel collectors to fetch this kind of information of multiple servers we need to think about maintainability, but maybe I am overthinking it. I just think - for us at our consultancy firm, it's not unusual within integration, that we have 12 different windows servers that need to be monitored (not only cpu, but windows server specific features). Meaning we would need to install 12 otel collectors. But of course we have ci/cd set up to all of them so maybe that's not an issue, but those would be 12 additional services to keep track of and monitor.

@pjanotti
Copy link
Contributor

pjanotti commented Aug 30, 2024

The concern about the configuration is good: we want to define it supporting remote servers even if we don't implement it on first release. It likely should be done in a similar fashion to what was proposed here and implemented here for the Windows Event Log receiver - with the difference that for the case here we likely can't ask for credentials, the computer/account running the collector as a service must have that right IIRC (we will have to double check that).

@atoulme
Copy link
Contributor

atoulme commented Sep 4, 2024

What's the configuration looking like? Do you have a working prototype somewhere we can review?

Copy link
Contributor

github-actions bot commented Nov 4, 2024

This issue has been inactive for 60 days. It will be closed in 60 days if there is no activity. To ping code owners by adding a component label, see Adding Labels via Comments, or if you are unsure of which component this issue relates to, please ping @open-telemetry/collector-contrib-triagers. If this issue is still relevant, please ping the code owners or leave a comment explaining why it is still relevant. Otherwise, please close it.

@stampflit
Copy link

+1 I'd be interested in this feature

@github-actions github-actions bot removed the Stale label Nov 7, 2024
@pjanotti
Copy link
Contributor

pjanotti commented Nov 8, 2024

@dodegaard @dconnolly-sfdc @hhgsplk @syron @atoulme @stampflit PTAL #35362 by @shalper2 it is just the initial wireframe but it make more concrete conversations about configuration and generated metrics.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
os:windows Sponsor Needed New component seeking sponsor
Projects
None yet
Development

No branches or pull requests

8 participants