Best practices regarding configuring open telemetry in ServiceDefaults when using multiple projects with different meters.

[Expecho]

So we have started adopting Aspire for some of our applications. We have a solution containing multiple projects like a frontend, backend api and some supporting api services. Since we now have a ServiceDefaults project we can make sure all projects use the same configuration when it comes to OTEL, health checks etc, basically what Aspire is also created for.

However, each project has its own custom sources and meters to listen to. We could change the ConfigureOpenTelemetry method to cater for this situation by adding a collection parameter of meter names to add for example. Is that considered best practice or should we leave the whole OTEL configuration to the individual projects to implement in this case?

.. Or should we use WithEnvironment in our AppHost and specify the custom meter names and source names using environment variables?

[davidfowl]

This is an interesting question and there's no wrong answer here. Aspire has service defaults for ASP.NET and .NET's counters. It's not wrong to add more counters there but the intent is that the things that go into service defaults are "mostly shared", meaning a majority of the applications that use it are using those telemetry sources.

.. Or should we use WithEnvironment in our AppHost and specify the custom meter names and source names using environment variables?

I like this pattern. It lets you share the logic for reading sources from configuration

PS: This was our original plan for configuring more telemetry sources. This is how logging and meters work today in .NET but we don't yet have this story for metrics.

cc @samsp-msft for thoughts.