-
Notifications
You must be signed in to change notification settings - Fork 2.5k
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
windowsservicereceiver wireframe #35362
base: main
Are you sure you want to change the base?
windowsservicereceiver wireframe #35362
Conversation
bcf5660
to
6055531
Compare
This PR was marked stale due to lack of activity. It will be closed in 14 days. |
I'll be reviewing this PR. |
5b0fb01
to
c179923
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Some initial feedback for the wireframe
scraperhelper.ControllerConfig `mapstructure:",squash"` | ||
Services []string `mapstructure:"services"` // user provided list of services to monitor with receiver | ||
MonitorAll bool `mapstructure:"monitor_all"` // monitor all services on host machine. supercedes services | ||
} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Assuming the default values for Services
and MonitorAll
it is not clear what would be the result: all services or none? It seems none giving that the boolean is false and the list of services is empty. Let me look at the rest of the code before making a suggestion here.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looking at the previous art from telegraf: it seems reasonable to have a include and a exclude list of services. If the include is empty it assumes all services minus the exclude list.
c179923
to
731526c
Compare
6358dd5
to
0566f19
Compare
} | ||
|
||
func (m *Manager) Disconnect() error { | ||
return windows.CloseServiceHandle(m.Handle) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
What happens if the Handle has the default value? Does it return an error?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It absolutely can return an error. obviously should be handled by the caller
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looking above I don't think this is an issue anymore with the current code: SCConnect
will only succeed with a valid Handle
.
} | ||
|
||
func GetService(sname string) (*ServiceStatus, error) { | ||
m, err := SCConnect() |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We should connect at Start instead of on every call to GetService
.
|
||
func GetService(sname string) (*ServiceStatus, error) { | ||
m, err := SCConnect() | ||
defer m.Disconnect() |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Typically you should add this defer only if connect succeeded.
func (s *ServiceStatus) getStatus() error { | ||
st, err := s.service.Query() | ||
if err != nil { | ||
return err |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is not a problem with the current code since the handle to the service is opened every time a GetService
call is made. However, it is good to pay attention here that the value of s.ServiceStatus
in case of error will be the default value for the type (0 in this case).
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Similar in the call to Config
below.
description: Gauge value containing service status as an integer value. | ||
extended_documentation: > | ||
Gauge values map to service status as follows: | ||
1 - Stopped, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
1 - Stopped, | |
0 - Failed to retrieve service status, | |
1 - Stopped, |
a9bf88e
to
7bc070a
Compare
7a65265
to
26077db
Compare
26077db
to
f934e59
Compare
f934e59
to
4846d0c
Compare
component: windowsservicereceiver | ||
|
||
# A brief description of the change. Surround your text with quotes ("") if it needs to start with a backtick (`). | ||
note: receiver for scraping windows service information from a host or properly configured remote machine. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
note: receiver for scraping windows service information from a host or properly configured remote machine. | |
note: Introduce a new receiver to retrieve Windows services status information. |
Initially is just the wire-frame and separating the support of remote that can be added later with the caveat that we should create a config that is compatible with later adding remote without breaking the initial config. Anyway, there is still more flexibility while the component is still in development.
|
||
Gauge value containing service status as an integer value. | ||
|
||
Gauge values map to service status as follows: 0 - Failed to retrieve service status, 1 - Stopped, 2 - Start Pending, 3 - Stop Pending, 4 - Service Running, 5 - Continue Pending, 6 - Pause Pending, 7 - Service Paused |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
nit: it will be nice to have this as a list with each value and meaning on a single line, or perhaps row in a table.
@@ -0,0 +1,37 @@ | |||
// Copyright The OpenTelemetry Authors | |||
// SPDX-License-Identifier: Apache-2.0 | |||
//go:build windows |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
nit: per convention add a blank line above
require ( | ||
github.com/google/go-cmp v0.6.0 | ||
github.com/stretchr/testify v1.9.0 | ||
go.opentelemetry.io/collector/component v0.114.0 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
After taking the comments versions should be updated to match the latest of the collector.
err := wss.mgr.Disconnect() | ||
return err |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Because there is no guarantee that start
is called prior to calling shutdown
, this should check if mgr
is not nil:
err := wss.mgr.Disconnect() | |
return err | |
if wss.mgr == nil { | |
return nil | |
} | |
return wss.mgr.Disconnect() |
} | ||
|
||
func (m *Manager) Disconnect() error { | ||
return windows.CloseServiceHandle(m.Handle) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looking above I don't think this is an issue anymore with the current code: SCConnect
will only succeed with a valid Handle
.
There is no additional comments needed from me, @pjanotti has done an amazing job :) If I can ask you to resolve comments as they are completed or addressed, and welcome to ping me to get this merged. |
Description: wireframe and early pass at api for a windowsservices receiver as requested in issue 31377
Link to tracking Issue: 31377
Testing: none yet
Documentation: documentation around receiver scope in README.md