Requests instrumentation http semantic convention migration

[lzchen]

Part of: #2453

Does not support redirect/retries. Tracking issue

Opt-in mechanism for certain attributes for new semconvs don't exist yet and will be implemented in the future. (ie. url_scheme)

Tracking issue for updating semconv package to 1.23.X: open-telemetry/opentelemetry-python#3538

Sample below:

import os
import requests
from opentelemetry import trace
from opentelemetry.instrumentation.requests import RequestsInstrumentor
from opentelemetry.sdk.trace import TracerProvider
from opentelemetry.sdk.trace.export import BatchSpanProcessor, ConsoleSpanExporter

# Specify "http", "http/dup" or ""
os.environ["OTEL_SEMCONV_STABILITY_OPT_IN"] = "http/dup"

# Enable instrumentation in the requests library.
RequestsInstrumentor().instrument()

trace.set_tracer_provider(TracerProvider())
tracer = trace.get_tracer(__name__)
exporter = ConsoleSpanExporter()
span_processor = BatchSpanProcessor(exporter)
trace.get_tracer_provider().add_span_processor(span_processor)

with tracer.start_as_current_span("parent"):
    response = requests.get("https://example.com/", timeout=5)

input()

Old semconv with envvar set to "default" or "":

    "attributes": {
        "http.method": "GET",
        "http.url": "https://example.com/",
        "http.status_code": 200
    },

New semconv with envvar set to "http":

    "attributes": {
        "http.request.method": "GET",
        "url.full": "https://example.com/",
        "server.address": "example.com",
        "network.peer.address": "example.com",
        "http.response.status_code": 200,
        "net.protocol.version": "1.1"
    },

Both semconv with envvar set to "http/dup":

    "attributes": {
        "http.method": "GET",
        "http.request.method": "GET",
        "http.url": "https://example.com/",
        "url.full": "https://example.com/",
        "http.host": "example.com",
        "server.address": "example.com",
        "network.peer.address": "example.com",
        "http.status_code": 200,
        "http.response.status_code": 200,
        "http.flavor": "1.1",
        "net.protocol.version": "1.1"
    },

[lzchen]

@trask

Marking as draft for prototyping reasons.

[lmolkova]

Thanks a lot @lzchen!

A few follow-up questions:

• no retry tracking: how hard do you think this would be? Any blockers you envision?
• can we add prototype for error.type as well?
• span names were changed

[lzchen]

Thanks a lot @lzchen!

A few follow-up questions:

• no retry tracking: how hard do you think this would be? Any blockers you envision?
• can we add prototype for error.type as well?
• span names were changed

@lmolkova

1. Are there other cases in which we expect retries to happen automatically with the underlying instrumented library besides redirects? The requests library handles redirects automatically by default.
   • What do we expect to happen here? The count being stamped on one span or multiple spans created for the initial call and then the redirect?
   • For cases like 503 where the library does not handle this automatically, are multiple spans expected to be created by the instrumentation library or by the user?
     If we are just stamping the one span, I don't think it will be that difficult to implement. Just needs clarification on behavior.
2. Done in recent commits
3. Are you referring to the change of "HTTP {METHOD NAME} to just {METHOD NAME}" ?

[lmolkova]

LGTM!