Skip to content

feat: Rack semantic stability opt in #1594

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

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

Conversation

hannahramadan
Copy link
Contributor

This PR is intended to assist in the transition from the old to new HTTP semantic conventions. Per the HTTP semantic convention stability migration spec, users should be able to set the environment variable OTEL_SEMCONV_STABILITY_OPT_IN to:

  • http to emit stable conventions only
  • http/dup to emit both old and the stable conventions
  • a blank env var will emit old conventions only
  • Span names have also changed. Spans will now be named based on only their method. For example, what used to be HTTP GET is now just GET - spec

The agent is required to maintain this bridge for 6 months and may drop the environment variable in the next major version and emit only the stable HTTP and networking conventions.

This approach was approved in #1547

Copy link
Contributor

@kaylareopelle kaylareopelle left a comment

Choose a reason for hiding this comment

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

Whew! This one covers a lot of ground. Great work catching the changes needed in the other instrumentations. Thanks for taking this on.

I think the PR description may need a little tweaking for the HTTP server spans that Rack produces.

HTTP server span names SHOULD be {method} {http.route} if there is a (low-cardinality) http.route available (see below for the exact definition of the {method} placeholder).

If there is no (low-cardinality) http.route available, HTTP server span names SHOULD be {method}.

Happy to go over any of the comments if you have questions. Mostly, I was consulting the server span parts of this doc: https://opentelemetry.io/docs/specs/semconv/non-normative/http-migration/#http-server-span-attributes

Comment on lines 44 to 54
stability_opt_in = ENV.fetch('OTEL_SEMCONV_STABILITY_OPT_IN', '')
values = stability_opt_in.split(',').map(&:strip)

if values.include?('http/dup')
use(*OpenTelemetry::Instrumentation::Rack::Instrumentation.instance.middleware_args_dup)
elsif values.include?('http')
use(*OpenTelemetry::Instrumentation::Rack::Instrumentation.instance.middleware_args_stable)
else
use(*OpenTelemetry::Instrumentation::Rack::Instrumentation.instance.middleware_args_old)
end

Copy link
Contributor

@kaylareopelle kaylareopelle Jul 18, 2025

Choose a reason for hiding this comment

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

Since this is a test_helper, does it make sense to update the grape appraisal to use the different env vars?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

@kaylareopelle I decided it might be best to revert changes to this test suite, and instead rely on the original method call, middleware_args, which is now aliased to middleware_args_old. It seemed like a lot of testing of the same idea: that the correct middleware is installed and correct attribute names are used. We test both in Rack and Sinatra ◡̈ This PR is so heavy I'm nervous to keep adding!

def middleware_args
if config.fetch(:use_rack_events, false) == true && defined?(OpenTelemetry::Instrumentation::Rack::Middlewares::EventHandler)
[::Rack::Events, [OpenTelemetry::Instrumentation::Rack::Middlewares::EventHandler.new]]
def middleware_args_old
Copy link
Contributor

Choose a reason for hiding this comment

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

Would this break existing monkey patches of the rack instrumentation, as this is not private? Is that a reasonable concern? I understand we are not 1.x here yet so it's not technically a semver question, but just trying to be mindful around touching rack instrumentation as it's probably got a rather large install base at this point.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Fantastic call out - it probably would break some stuff! I've aliased the new and old method definitions, as well as added a test 7290822

Copy link
Contributor

@ericmustin ericmustin left a comment

Choose a reason for hiding this comment

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

I had one open question otherwise lgtm pending rubocop fixes

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.

3 participants