Add OpenTelemetry Support

[shikokuchuo]

Implement a basic layer of OpenTelemtery so that users can get tracing 'for free' if they have this enabled.

Ideally we can leverage the existing gargle_debug() internal function to avoid duplication.

[jennybc]

Do we have some high-level explanation and framing of the OpenTelemetry efforts?

[shikokuchuo]

The initiative is to put this into all the packages that people rely on the most, where observability could be of benefit. Then all they have to do is set the required env vars, and they get it across the board without needing to change any code.

The plan is for each package that implements otel to tell the story, so there's currently no big announcement to point to. Shiny (in the process of being released) will be helpful in getting people familiar with the concept. Also httr2, ellmer and plumber2 in a first phase.

mirai was the first to feature it in a release: https://tidyverse.org/blog/2025/09/mirai-2-5-0/#opentelemetry-integration and the package has an OpenTelemetry vignette, but only as it's important for the package. For Gargle, a news item should suffice I'd think.

[jennybc]

What will the difference be for a gargle user using otel vs. not?

I'm guessing this affects where the messages show up?

[shikokuchuo]

If otel isn't enabled then the otel functions don't do anything (they're all guarded by early returns).

Otherwise the messages are sent to a collector (this could be something you've set up locally, or an online service like Pydantic Logfire) but you'd need to set the env vars for this. These collectors will typically have web UIs that let you visualize and query the traces.

There are a couple of slides in this presentation which give an overview: https://shikokuchuo.net/sip2025/#/opentelemetry
In gargle's case, it'd be useful primarily to identify points of failure.