-
Notifications
You must be signed in to change notification settings - Fork 2.4k
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
[receiver/dockerstatsreceiver] Initial PR to onboard dockerstats onto mdatagen #12322
[receiver/dockerstatsreceiver] Initial PR to onboard dockerstats onto mdatagen #12322
Conversation
Hello @rmfitzpatrick @MovieStoreGuy can you please review :) |
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.
There is just a few things I have comments on atm, I will come back to review this in further detail.
@jamesmoessis Note that, per the ref doc
So we need to add this:
|
Thanks @mx-psi for pointing that out. I have updated the main Before I do that, though, I would like to ask your opinion on whether this should be a
or
I'm thinking it's possibly better as a replace now that I've properly read those ref docs you linked. |
@jamesmoessis I am not sure how |
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.
I am happy with these changes, only nits that really shouldn't matter
@@ -56,11 +56,13 @@ type Client struct { | |||
logger *zap.Logger | |||
} | |||
|
|||
func NewDockerClient(config *Config, logger *zap.Logger) (*Client, error) { | |||
func NewDockerClient(config *Config, logger *zap.Logger, opts ...docker.Opt) (*Client, 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.
If we have reverted the go-connections
version, does this still need to happen?
Or is this just a safe nice to have?
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.
Yeah, it doesn't need to be there anymore, but imo it doesn't hurt to leave it in, and it could be nice to have for future purposes or similar issues. I don't feel strongly either way
@rmfitzpatrick @mx-psi I believe I have addressed all comments, is there anything else I can do to move this PR forward? |
Will wait for @rmfitzpatrick to give a final review |
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.
Thanks!
@jamesmoessis Regarding
I would suggest using a feature gate for this |
@mx-psi thankyou for the suggestion, I will implement in my next PR! |
…nnections` package The package `github.com/docker/go-connections` only exists in contrib's generated `go.mod` file in version `v0.5.0`, and does not exist in the replaced version `v0.4.1`. The distro also builds and runs fine without the replace directive. I believe the [reason](open-telemetry/opentelemetry-collector-contrib#12322 (comment)) for the replace directive to have been added is out of date. To be sure, I have run the repro scenario described [here](docker/go-connections#99 (comment)) and the behavior with go-connections v0.5.0 was correct - the Docker client tried to connect to the TCP port.
…nnections` package (#677) The package `github.com/docker/go-connections` only exists in contrib's generated `go.mod` file in version `v0.5.0`, and does not exist in the replaced version `v0.4.1`. The distro also builds and runs fine without the replace directive. I believe the [reason](open-telemetry/opentelemetry-collector-contrib#12322 (comment)) for the replace directive to have been added is out of date. To be sure, I have run the repro scenario described [here](docker/go-connections#99 (comment)) and the behavior with go-connections v0.5.0 was correct - the Docker client tried to connect to the TCP port. Co-authored-by: Alex Boten <223565+codeboten@users.noreply.github.com>
First of all, apologies for the size of the PR. Thankfully, most of it is generated code/docs or mock/test data. Additionally, there is no change to the behaviour, since I haven't enabled the new implementation.
Description:
I wanted the initial PR to be backwards compatible with the existing implementation. So, I've re-implemented the
scrape
function asscrapeV2
(leaving the original) and testing them both alongside each other to ensure they produce the same metrics, and to give the reviewer confidence that feature parity is maintained. The bulk of the new implementation is all inreceiver_v2.go
.I've defined the metrics to be recorded in
metadata.yaml
. With this, the new implementation (which isn't enabled yet) you can turn off and on each metric via the config, and all metrics have generated docs indocumentation.md
.I've also fixed two bugs:
Link to tracking Issue: #9794
Testing:
TestScrapes
tests both implementations ofscrape
and ensures they emit the same metrics for the same datasource. I have mocked the docker engine using the HTTP test server.Documentation:
mdatagen
generates documentation indocumentation.md
.Discussion points:
How should transition to using the new implementation by default? There are a few breaking changes that are needed to move the component forward here. With the two implementations, we could temporarily expose a config which allows users to stay on the "deprecated" implementation, giving them time to migrate, as we make the breaking changes to the new implementation of
scrape
only. Eventually, we delete the old implementation ofscrape
and a whole bunch of code with it. Would love thoughts and feedback here :)