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

[receiver/dockerstatsreceiver] Initial PR to onboard dockerstats onto mdatagen #12322

Merged

Conversation

jamesmoessis
Copy link
Contributor

@jamesmoessis jamesmoessis commented Jul 12, 2022

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 as scrapeV2 (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 in receiver_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 in documentation.md.

I've also fixed two bugs:

  • When collecting data from multiple containers, it seems that the resource metrics aren't appended but overridden, so the last container to be collected is the only one that you see metrics for. I made a minor change to fix this.
  • Specifying an HTTP endpoint (not unix socket) for the docker engine resulted in an incorrect dialer being used. It means it was ignoring the endpoint I specified and actually querying my local docker engine's unix socket. I had to make a minor change the to internal docker client to pass it an option, to make sure the correct dialer is being used.

Link to tracking Issue: #9794

Testing:
TestScrapes tests both implementations of scrape 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 in documentation.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 of scrape and a whole bunch of code with it. Would love thoughts and feedback here :)

@jamesmoessis
Copy link
Contributor Author

Hello @rmfitzpatrick @MovieStoreGuy can you please review :)

Copy link
Contributor

@MovieStoreGuy MovieStoreGuy left a 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.

receiver/dockerstatsreceiver/metadata.yaml Show resolved Hide resolved
receiver/dockerstatsreceiver/metadata.yaml Show resolved Hide resolved
receiver/dockerstatsreceiver/metadata.yaml Outdated Show resolved Hide resolved
receiver/dockerstatsreceiver/metadata.yaml Show resolved Hide resolved
receiver/dockerstatsreceiver/metadata.yaml Show resolved Hide resolved
receiver/dockerstatsreceiver/receiver.go Outdated Show resolved Hide resolved
receiver/dockerstatsreceiver/receiver.go Outdated Show resolved Hide resolved
receiver/dockerstatsreceiver/receiver.go Outdated Show resolved Hide resolved
receiver/dockerstatsreceiver/receiver.go Outdated Show resolved Hide resolved
receiver/dockerstatsreceiver/receiver.go Outdated Show resolved Hide resolved
@mx-psi
Copy link
Member

mx-psi commented Jul 15, 2022

@jamesmoessis Note that, per the ref doc

exclude directives only apply in the main module’s go.mod file and are ignored in other modules

So we need to add this:

  1. on the main go.mod file
  2. on the contrib releases manifest

@jamesmoessis
Copy link
Contributor Author

jamesmoessis commented Jul 18, 2022

Thanks @mx-psi for pointing that out. I have updated the main go.mod. I can also raise another PR in the releases repo.

Before I do that, though, I would like to ask your opinion on whether this should be a replace or an exclude? Both seem to work:

replace github.com/docker/go-connections v0.4.1-0.20210727194412-58542c764a11 => github.com/docker/go-connections v0.4.0

or

exclude github.com/docker/go-connections v0.4.1-0.20210727194412-58542c764a

I'm thinking it's possibly better as a replace now that I've properly read those ref docs you linked.

@mx-psi
Copy link
Member

mx-psi commented Jul 18, 2022

@jamesmoessis I am not sure how exclude interacts with pseudoversions, so maybe a replace is indeed better.

Copy link
Contributor

@MovieStoreGuy MovieStoreGuy left a 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) {
Copy link
Contributor

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?

Copy link
Contributor Author

@jamesmoessis jamesmoessis Jul 21, 2022

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

receiver/dockerstatsreceiver/doc.go Show resolved Hide resolved
receiver/dockerstatsreceiver/metadata.yaml Outdated Show resolved Hide resolved
@jamesmoessis
Copy link
Contributor Author

@rmfitzpatrick @mx-psi I believe I have addressed all comments, is there anything else I can do to move this PR forward?

@mx-psi mx-psi requested a review from rmfitzpatrick July 22, 2022 07:43
@mx-psi
Copy link
Member

mx-psi commented Jul 22, 2022

Will wait for @rmfitzpatrick to give a final review

Copy link
Contributor

@rmfitzpatrick rmfitzpatrick left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks!

@mx-psi mx-psi merged commit a088337 into open-telemetry:main Jul 25, 2022
@mx-psi
Copy link
Member

mx-psi commented Jul 25, 2022

@jamesmoessis Regarding

How should transition to using the new implementation by default?

I would suggest using a feature gate for this

@jamesmoessis jamesmoessis deleted the mdatagen-dockerstatsreceiver branch July 25, 2022 23:27
@jamesmoessis
Copy link
Contributor Author

@mx-psi thankyou for the suggestion, I will implement in my next PR!

andrzej-stencel added a commit to andrzej-stencel/opentelemetry-collector-releases that referenced this pull request Sep 25, 2024
…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.
codeboten added a commit to open-telemetry/opentelemetry-collector-releases that referenced this pull request Oct 2, 2024
…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>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants