feat: publish tracer metadata upon global init

[yannham]

What does this PR do?

This PR hooks up store_tracer_metadata from libdd-library-config into tracer initialization. Without changing the API or anything else, this will automatically publish tracer metadata as resource attributes both through a pre-existing Datadog-specific protocol, and through the OTel process context.

Motivation

This is a required step toward supporting ePBF profiling in dd-trace-rs.

Additional Notes

• I couldn't find attributes for hostname, process_tags and container_id in the config. Happy to be pointed at which value we should use for those (or just let them initialized by default)
• While it's not really expected that people set up multiple tracers in a single app, it's permitted by the dd-trace-rs API. The process context is global to the whole process, hence we can ask when should we set or update this context. The answer of this PR is to do it automatically when a tracer is set globally through init(), which should be the common way of doing things, but do not do it for local initialization through init_local. This is somehow arbitrary and can be debated.

[bantonsson]

Looks good. Only minor comments.

[bantonsson]

Should there be a ticket to track this?

[yannham]

Actually, I hope to answer the question before merging the PR 😅 do you know what should go there? Or if I should just omit it for Rust?

[bantonsson]

https://github.com/DataDog/libdatadog/blob/main/libdd-common/src/entity_id/unix/container_id.rs

[ivoanjo]

This is cool + was way less than I was expecting! :)

I guess other than maybe adding some of the keys that are missing the non-trivial bit is to decide what to do with the legacy file descriptor thing.

[ivoanjo]

Ah, quick question -- the way we're wiring it up means it's always on, right? That's exactly what I think we should be doing (and that's most other implementations are doing, at least when they can), just wanted to confirm to mark it on our library support matrix.

[yannham]

Ah, quick question -- the way we're wiring it up means it's always on, right? That's exactly what I think we should be doing (and that's most other implementations are doing, at least when they can), just wanted to confirm to mark it on our library support matrix.

Yes, but with a gotcha. There are several ways to initialize a tracer in dd-trace-rs. The "natural" way is to use init(), which registers a global tracer, and this is where the context publication is hooked up - in this case, this is indeed always on.

There's also an init_local() API, that returns an SdkTracerProvider. This one could or could not be globally set later, I believe and I think it could be set through OTel directly, so we might not even be able to intercept the switch (please correct me if I'm wrong, @bantonsson). It's not really clear what to do in this case, so for now we only install the context in the standard, default workflow.

[bantonsson]

There's also an init_local() API, that returns an SdkTracerProvider. This one could or could not be globally set later, I believe and I think it could be set through OTel directly, so we might not even be able to intercept the switch.

Yeah, the only way around that would be to wrap the SdkTracerProvider and intercept its use I guess, ie publish on first use of the TracerProvider.

[yannham]

Yeah, the only way around that would be to wrap the SdkTracerProvider and intercept its use I guess, ie publish on first use of the TracerProvider.

Got it. IMHO, it's a bit too much magic and doesn't look like it's worth the trouble, especially if the assumption that people should do init() in the vast majority of cases holds true. We should just document the behavior very clearly (maybe what's missing here is another comment to init_local() that also mentions the difference; currently it's only in init()). If really needed we can always add a manual way to publish the context for people who use init_local() AND need the context.

[ivoanjo]

I think supporting only init() is fine -- it looks like the intention is that the init_local() is the "I want full + fine control, let me drive and I'll make all the decisions" mode so not doing it by default seems to match with the intention of that API -- it's one more thing you'll have to opt into.