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

feat: informative user-agent for otlp exporters #3970

Merged
merged 18 commits into from
Dec 3, 2021

Conversation

vreynolds
Copy link
Contributor

Description: This adds a default user-agent header to outgoing requests by the OTLP/gRPC and OTLP/HTTP exporters. The default user-agent contains build information about the collector.

Behavior details:

  • Currently, it's possible to add a user-agent header to the HTTP exporter via the headers config. This change preserves this behavior, and only sets the collector user-agent, if one is not present in config headers.
  • Currently, it's not possible to do the above with a gRPC exporter. This change does not affect that, and only updates the existing gRPC client user-agent.

Link to tracking Issue: Fixes #2209

Testing: Updated/added to existing unit tests. Built a local collector and verified outgoing user-agent headers in both exporters.

Documentation: N/A?

- add collector build info to otlp/otlphttp exporter headers
@vreynolds vreynolds requested review from a team and codeboten September 3, 2021 19:41
config/confighttp/confighttp.go Outdated Show resolved Hide resolved
config/configgrpc/configgrpc.go Outdated Show resolved Hide resolved
exporter/exporterhelper/common.go Outdated Show resolved Hide resolved
- move user-agent additions to the exporters
- add OS and ARCH to user-agent
Copy link
Contributor

@codeboten codeboten left a comment

Choose a reason for hiding this comment

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

👍 this is a good feature to add. Just one question regarding the following in the description:

Currently, it's possible to add a user-agent header to the HTTP exporter via the headers config. This change preserves this behavior, and only sets the collector user-agent, if one is not present in config headers.
Currently, it's not possible to do the above with a gRPC exporter. This change does not affect that, and only updates the existing gRPC client user-agent.

My understanding is that this is currently possible for the grpc exporter via the headers configuration and and not for the http exporter, but the comment in the description makes me think it's the other way around. Can you confirm this?

exporter/otlpexporter/otlp.go Outdated Show resolved Hide resolved
@vreynolds
Copy link
Contributor Author

My understanding is that this is currently possible for the grpc exporter via the headers configuration and and not for the http exporter, but the comment in the description makes me think it's the other way around. Can you confirm this?

Confirmed in local testing: http exporter allows setting user-agent via headers config, grpc does not

  • For the http client, config headers are set as request headers, which is how a user-agent gets added canonically.
  • For the grpc client, config headers are set as metadata, whereas a user-agent needs to be set as a dial option.

@codeboten
Copy link
Contributor

My understanding is that this is currently possible for the grpc exporter via the headers configuration and and not for the http exporter, but the comment in the description makes me think it's the other way around. Can you confirm this?

Confirmed in local testing: http exporter allows setting user-agent via headers config, grpc does not

* For the `http` client, config headers are set as request headers, which is how a user-agent gets added canonically.

* For the `grpc` client, config headers are set as metadata, whereas a user-agent needs to be set as a dial option.

Thanks for clarifying 👍

config/confighttp/confighttp.go Outdated Show resolved Hide resolved
config/confighttp/confighttp.go Outdated Show resolved Hide resolved
exporter/otlphttpexporter/otlp.go Outdated Show resolved Hide resolved
@github-actions
Copy link
Contributor

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

Copy link
Contributor

@codeboten codeboten left a comment

Choose a reason for hiding this comment

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

PR looks good, please resolve the conflict.

@vreynolds
Copy link
Contributor Author

Merged upstream, and a couple small updates adding a doc comment and parenthesis around (OS/ARCH)

@github-actions
Copy link
Contributor

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

@vreynolds
Copy link
Contributor Author

Didn't get a chance to review the feedback last week, but will do that this week 🙏

@codecov
Copy link

codecov bot commented Oct 6, 2021

Codecov Report

Merging #3970 (a8bd4ee) into main (96a882a) will increase coverage by 0.00%.
The diff coverage is 100.00%.

Impacted file tree graph

@@           Coverage Diff           @@
##             main    #3970   +/-   ##
=======================================
  Coverage   90.77%   90.78%           
=======================================
  Files         179      179           
  Lines       10412    10423   +11     
=======================================
+ Hits         9452     9463   +11     
  Misses        743      743           
  Partials      217      217           
Impacted Files Coverage Δ
exporter/otlpexporter/factory.go 91.30% <100.00%> (ø)
exporter/otlpexporter/otlp.go 74.41% <100.00%> (+1.57%) ⬆️
exporter/otlphttpexporter/factory.go 87.36% <100.00%> (ø)
exporter/otlphttpexporter/otlp.go 82.92% <100.00%> (+0.87%) ⬆️

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 96a882a...a8bd4ee. Read the comment docs.

@vreynolds
Copy link
Contributor Author

@bogdandrutu yes, I plan on updating this today -- are you OK with a custom roundtripper that clones the request and updates the header?

@vreynolds vreynolds changed the title feat: collector-aware user-agent header feat: informative user-agent for otlp exporters Nov 3, 2021
Copy link
Member

@bogdandrutu bogdandrutu left a comment

Choose a reason for hiding this comment

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

few more comments about limiting the public API, and avoid implementing roundtripper if we don't intend that to be used by others.

@@ -232,3 +234,8 @@ func (ts *timeoutSender) send(req request) error {
}
return req.export(ctx)
}

// DefaultUserAgent User-Agent value used by exporters
func DefaultUserAgent(info component.BuildInfo) string {
Copy link
Member

Choose a reason for hiding this comment

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

let's move this to otlpexporter for the moment or an internal package. Prefer to limit the public API.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

✅ Moved to each exporter f5bddaf

@@ -213,3 +218,32 @@ func readResponse(resp *http.Response) *status.Status {

return respStatus
}

type userAgentRoundTripper struct {
Copy link
Member

Choose a reason for hiding this comment

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

Do we really need a roundtripper? Since this is private, we should just simply add a header to the request when creating the request instead of cloning etc., as we need to do for a proper roundtripper.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

I did consider just adding the header when request is created, which is easier but more error-prone (need to remember to add the header again, if there's ever a new codepath that creates requests). That being said, I expect the exporter is fairly stable at this point, so this should be OK? f5bddaf

@vreynolds
Copy link
Contributor Author

@bogdandrutu let me know if there's anything I need to do about the codecov report -- as far as I can tell, coverage is actually up, so I'm not sure what the failure is telling me

@jpkrohling
Copy link
Member

I'm not sure what the failure is telling me

It's not a problem with this PR. It's just telling that the project as a whole is under the target of 90%, which has been the case since we brought the builder here.

@codeboten
Copy link
Contributor

Closing and re-opening to kick the CI

@codeboten codeboten closed this Nov 24, 2021
@codeboten codeboten reopened this Nov 24, 2021
@codeboten
Copy link
Contributor

@open-telemetry/collector-maintainers please merge once CI passes, looks like we have all the approvals needed

@jpkrohling
Copy link
Member

The new release created a conflict for this PR. Sorry about that, but could you rebase the changelog, @vreynolds?

@vreynolds
Copy link
Contributor Author

@jpkrohling conflict resolved ✅

@codeboten codeboten added the ready-to-merge Code review completed; ready to merge by maintainers label Dec 1, 2021
@robbkidd
Copy link
Member

robbkidd commented Dec 3, 2021

So excited! Can't wait!

@codeboten
Copy link
Contributor

@tigrannajaryan @bogdandrutu please merge 😬

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
ready-to-merge Code review completed; ready to merge by maintainers
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Collect OpenTelemetry collector telemetry data for service owners
10 participants