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

update config dependency #11611

Open
wants to merge 25 commits into
base: main
Choose a base branch
from

Conversation

codeboten
Copy link
Contributor

@codeboten codeboten commented Nov 5, 2024

This PR does a couple of things that I couldn't quite split up so I put together a PR w/ individual commits to help reviewers get through it. This PR does the following:

  1. update go.opentelemetry.io/contrib/config package to latest. this brings in breaking changes. in order to prevent those breaking changes from impacting end users, i've also added a layer of config unmarshaling
  2. updates the collector to instantiate the meter provider (and exporters) via the config package. this allows us to remove all the code in otelinit. the reason for including this change was that unmarshaling the config was causing circular dependencies i didn't want to address by moving code that could be deleted around.

Replacement for #11458.

Fixes #12021

@codeboten codeboten force-pushed the codeboten/update-config-dependency branch 3 times, most recently from 6f225b7 to 47f403a Compare November 6, 2024 21:45
@mjnowen
Copy link

mjnowen commented Nov 12, 2024

Looking forward to seeing this get merged!

Copy link
Contributor

This PR was marked stale due to lack of activity. It will be closed in 14 days.

@github-actions github-actions bot added the Stale label Nov 27, 2024
@mjnowen
Copy link

mjnowen commented Nov 27, 2024

Not stale? @codeboten

@codeboten codeboten removed the Stale label Nov 27, 2024
@codeboten codeboten force-pushed the codeboten/update-config-dependency branch from 47f403a to 2a0e6f8 Compare December 9, 2024 19:03
Copy link

codecov bot commented Dec 9, 2024

Codecov Report

Attention: Patch coverage is 86.12100% with 39 lines in your changes missing coverage. Please review.

Project coverage is 91.64%. Comparing base (a3c7d95) to head (40d3021).

Files with missing lines Patch % Lines
service/telemetry/internal/migration/v0.3.0.go 54.54% 12 Missing and 3 partials ⚠️
service/telemetry/internal/migration/v0.2.0.go 93.67% 8 Missing and 2 partials ⚠️
service/service.go 84.90% 6 Missing and 2 partials ⚠️
component/componenttest/configtest.go 0.00% 2 Missing and 1 partial ⚠️
service/telemetry/metrics.go 60.00% 1 Missing and 1 partial ⚠️
service/telemetry/config.go 80.00% 1 Missing ⚠️
Additional details and impacted files
@@            Coverage Diff             @@
##             main   #11611      +/-   ##
==========================================
- Coverage   91.67%   91.64%   -0.03%     
==========================================
  Files         461      462       +1     
  Lines       24749    24744       -5     
==========================================
- Hits        22689    22677      -12     
- Misses       1678     1681       +3     
- Partials      382      386       +4     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

@codeboten
Copy link
Contributor Author

Could use some feedback from @open-telemetry/collector-approvers on this latest commit to the PR to update the config support from v0.2.0 to v0.3.0.

tl;dr there's a backwards incompatible change in how headers are passed in and I wanted to support users transitioning

i wanted to support both the 0.3.0 and the 0.2.0 schema, which resulted in some migration code. I still have a few tests to add, and this change will need a PR in go-contrib to be merged before it can be completely done. Anyways, i could use your input: df83265

This is waiting on open-telemetry/opentelemetry-go-contrib#6412

@dmitryax
Copy link
Member

The approach to handle the backward incompatible change looks good to me 👍

// compatibility attempts
return err
}
// TODO: add a warning log to tell users to migrate their config
Copy link
Member

Choose a reason for hiding this comment

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

I guess it might be complicated to pass a logger here, but it's pretty important. I think we should come up with a solution by the time we release this change

Copy link
Member

Choose a reason for hiding this comment

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

The way we do this on the Datadog exporter is to have a private field that is written to during unmarshaling and then a method to log warnings.

I don't love it, but I haven't been able to come up with anything better

Copy link
Member

@jpkrohling jpkrohling left a comment

Choose a reason for hiding this comment

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

I appreciate your efforts to not break our current users. And explicitly about this:

Anyways, i could use your input: df83265

I like your approach. We don't have a schema version anywhere, so trying to fallback to the previous version before failing is a good approach. It doesn't scale nicely, but I also don't see a good way to determine the version other than requiring users to provide a schema version (which is bad UX for this specific place of the config, IMO).

@@ -363,3 +385,43 @@ func pdataFromSdk(res *sdkresource.Resource) pcommon.Resource {
}
return pcommonRes
}

func disableHighCardinalityMetrics() []config.View {
Copy link
Member

Choose a reason for hiding this comment

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

looks OK for now, but if we expect this list to grow before we remove the gate, it might make sense to externalize this somehow?

Copy link
Member

Choose a reason for hiding this comment

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

This is the purpose of #11754

service/service.go Show resolved Hide resolved
Copy link
Member

@mx-psi mx-psi left a comment

Choose a reason for hiding this comment

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

I think this is a good opportunity to resolve #10808 by writing down what our plans are regarding this.

// compatibility attempts
return err
}
// TODO: add a warning log to tell users to migrate their config
Copy link
Member

Choose a reason for hiding this comment

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

The way we do this on the Datadog exporter is to have a private field that is written to during unmarshaling and then a method to log warnings.

I don't love it, but I haven't been able to come up with anything better

@@ -363,3 +385,43 @@ func pdataFromSdk(res *sdkresource.Resource) pcommon.Resource {
}
return pcommonRes
}

func disableHighCardinalityMetrics() []config.View {
Copy link
Member

Choose a reason for hiding this comment

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

This is the purpose of #11754

@codeboten codeboten force-pushed the codeboten/update-config-dependency branch 4 times, most recently from 3bcf5f1 to b0021fb Compare December 16, 2024 23:07
@codeboten codeboten marked this pull request as ready for review December 16, 2024 23:07
@codeboten codeboten requested a review from a team as a code owner December 16, 2024 23:07
@codeboten codeboten requested a review from atoulme December 16, 2024 23:07
@codeboten codeboten force-pushed the codeboten/update-config-dependency branch from 41beb42 to e30a736 Compare December 17, 2024 19:44
Copy link
Contributor

github-actions bot commented Jan 1, 2025

This PR was marked stale due to lack of activity. It will be closed in 14 days.

This change updates the dependency on go.opentelemetry.io/contrib/config to the latest in main. This
is because v0.11.0 has a bug that prevents resource attributes to be applied as labels in the
prometheus exporter. This change contains the following pieces:

1. the update of the dependency
2. add a layer to prevent breaking end users' configuration of exporter headers
3. move the meter provider initialization to depend on the config package
instead of otelinit

Number 3 didn't need to happen in this PR, but doing #2 required a bunch of changes
that can be avoided by moving to using the meter provider from config instead of otelinit.

Signed-off-by: Alex Boten <[email protected]>
Signed-off-by: Alex Boten <[email protected]>
Signed-off-by: Alex Boten <[email protected]>
Signed-off-by: Alex Boten <[email protected]>
Signed-off-by: Alex Boten <[email protected]>
Signed-off-by: Alex Boten <[email protected]>
This allows end users to configure their internal metrics export with either
the new v0.3.0 schema or the existing v0.2.0 schema.

Signed-off-by: Alex Boten <[email protected]>
Signed-off-by: Alex Boten <[email protected]>
Signed-off-by: Alex Boten <[email protected]>
Signed-off-by: Alex Boten <[email protected]>
Signed-off-by: Alex Boten <[email protected]>
Signed-off-by: Alex Boten <[email protected]>
Signed-off-by: Alex Boten <[email protected]>
Signed-off-by: Alex Boten <[email protected]>
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.

Mismatch in resource attributes between metrics and everything else
7 participants