Missing `TraceEnricher` instance scope information in `OpenTelemetry.Extensions.Enrichment` documentation

[julealgon]

I just saw the release information for this new OpenTelemetry.Extensions.Enrichment package today and it seems super useful for some use cases that we have.

I went to check the main README.md on the project to learn more about how it works, and one thing that immediately jumped to me as lacking was information about when/how the TraceEnricher class is created. Is a single instance of the enricher created per application (singleton), is it scoped, or is it created for each individual Activity?

This is important to be able to know the types of dependencies we can inject in the implementations. I would like to be able to inject things that are naturally scoped, for instance.

Can the docs be updated to add detail about the lifetime of the TraceEnricher instances when DI is used?

@evgenyfedorov2

[evgenyfedorov2]

TraceEnricher is an abstract class, so user code is expected to have one or more concrete implementations. Each implementation type will be registered with singleton lifetime. So basically you can create your implementation whose instance will be created only once (singleton) and expect its Enrich() method will be called on every Activity.

If we speak about things like IHttpContextAccessor, it can be injected and will work, but I know that it is not very convenient because there is no access to HttpRequestMessage /HttpResponseMessage from it. Please also consider this functionality.

[julealgon]

Each implementation type will be registered with singleton lifetime.

Can you add this to the documentation? I believe this is a very important point that should be exposed there.

So basically you can create your implementation whose instance will be created only once (singleton) and expect its Enrich() method will be called on every Activity.

This makes it less usable for us in particular. I wonder if you could reconsider this design? Would it be possible to change it to be a scoped registration instead?

If we speak about things like IHttpContextAccessor, it can be injected and will work, but I know that it is not very convenient because there is no access to HttpRequestMessage /HttpResponseMessage from it. Please also consider this functionality.

Yeah, I'm already familiar with this and we are currently leveraging it, thanks.