-
Notifications
You must be signed in to change notification settings - Fork 79
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] custom user-agent (& expanding OTEL_EXPORTER_OTLP_* env var support) #94
[feat] custom user-agent (& expanding OTEL_EXPORTER_OTLP_* env var support) #94
Conversation
This looks great, thanks @robbkidd 👍🏻 |
ef1bf42
to
3e442b7
Compare
Looks great! I think it is worth adding to this PR the modification of |
I checked out your branch and ran
This would be the reason for the failure. The offsets failure looks more like a network timeout flake |
I was only starting to venture into making changes to the build or release workflows. I'm game to add that, but I'm not quite clear on the source of truth for a particular build's version. Is it the In some of the pipelines I've worked with, we'll determine a build version based on an identifiably-a-release tag or the distance from one (somewhat like the Collector does in its Makefile). Is that a pattern this project would want to adopt? For example, |
😅 Y'all are OK with the creation of the unit test suite†? And that the CI run of unit tests was added to the existing generate job? † … that has only one test that probably needs changing if the source of truth for a version is not the |
Delegating the OTLP env var interpretation to the SDK means the endpoints need to have the protocol scheme included in the URL. (I believe.) Trying that in ab37628.
Update: Yup. Parsed from the ENDPOINT value. Without the scheme present, the SDK defaults to Horray! Now the failure is the resource attribute I added to the code, but not to the test expectations! 🎉 |
After reading the release docs that are currently in-progress (#98), I think this would work for release version in code:
A release build triggered by the tagging event described in the proposed RELEASING process would have the "clean" version tag. I'm happy to include the git-tag-based release version update:
EDIT: I've opened an issue proposing option 2, emphasized above. |
Instead of the Go autoinst agent appearing to telemetry data receivers as only the version of grpc-go against which it was built, this adds an identifier to the User-Agent header via the dial options parameter support within otlptracegrpc. To help troubleshooting data transmission, runtime operating system and CPU architecture is included in the user-agent within a parenthetical comment in accordance with the header's specification.[1] This replaces the low-level build up of a gRPC client connection with a reuse of the OTel Go SDK's grpc trace client constructor. A happy byproduct of using the SDK's constructor is that all of the OTEL_EXPORTER_OTLP_* environment variables related to exporting traces ought to be supported now, obviating the need to maintain code here to retrieve, interpret, and handle them. [1] RFC 7231 https://www.rfc-editor.org/rfc/rfc7231#section-5.5.3 though more readable documentation about this header spec is available at MDN Web Docs: https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/User-Agent
This is an expendable commit if folks don't like it.
Spec and therefore SDK require the URL scheme in ENDPOINT values.
This Go auto-inst adds its version to resource attributes now.
dcbd454
to
6c7f3d6
Compare
Rebased to latest main. If all passes, I believe this is ready for merge with the work to automate the release version lookup during build tracked in another issue. |
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.
Can you add a version.go
similar to this: https://github.com/open-telemetry/opentelemetry-go/blob/86f325839ca329997672fbae8b054e7b6181b4d2/version.go (with a version_test.go
). Our release tooling will update versions found there.
It does? Excellent. I was ready to start wiring up a releaseinfo package and all manner of LDFLAGS shenanigans (#107) to get version wired in. |
The version declared here will get bumped when using the multimod releaser utility. The agent's controller uses this version to include in the User-Agent header and in a resource attribute for outgoing telemetry.
Modeled after the test targets in OpenTelemetry Go. Removes the "maybe use gotestsum if you've got it!" option.
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.
Overall looks good, just minor issues. Thanks for the contribution!
In thinking through this morning about the version number reflected in code, one disadvantage of the multimod-managed hard-coded value is that receivers of telemetry cannot distinguish uses of release builds versus dev builds. That's one benefit of the version being determined at build time, usually with ldflags set to the output of git describe. As a vendor receiving telemetry from thousands of independent customer sources, Honeycomb has found it incredibly useful to be able to see more nuanced version information in user agents. Update: I'm not proposing that ☝🏻 as a blocker to this PR; this PR makes things better! I can open a new issue or PR to consider appending more to the version number when built on a non-release commit and/or from a dirty working copy. |
Co-authored-by: Tyler Yahn <[email protected]>
Always Be Testing. Co-authored-by: Tyler Yahn <[email protected]>
@robbkidd can you sync with |
@MrAlias Certainly! Done. |
Instead of the Go autoinst agent appearing to telemetry data receivers as only the version of grpc-go against which it was built, this adds an identifier to the User-Agent header via the dial options parameter support within otlptracegrpc.
To help troubleshooting data transmission, runtime operating system and CPU architecture is included in the user-agent within a parenthetical comment in accordance with the header's specification.†
This replaces the low-level build up of a gRPC client connection with a reuse of the OTel Go SDK's grpc trace client constructor. A happy byproduct of using the SDK's constructor is that all of the OTEL_EXPORTER_OTLP_* environment variables related to exporting traces ought to be supported now, obviating the need to maintain code here to retrieve, interpret, and handle them.
A unit test to catch the hard-coded releaseVersion was added to cover version mismatches until the build pipeline can be updated to determine the proper version automatically.
Updated the instrumentation fixture output expectations to include the
telemetry.auto.version
attribute.And resolves the following issues recorded in the keyval repo:
TODO:
† RFC 7231 though more readable documentation is available in the MDN Web Docs about the User-Agent header.