OTLP appmodel component

[samsp-msft]

trafficstars

Is there an existing issue for this?

• [X] I have searched the existing issues

Is your feature request related to a problem? Please describe the problem.

In watching the session yesterday on DataDog and how you need to configure Aspire to be able to tweak the OTLP settings, I am thinking that we should probably have an OTLP app model component. Today if you want to send data elsewhere than the dashboard, you need to go add new environment variables to each application. Its kind of ugly.

Describe the solution you'd like

We emit a whole bunch of OTLP vars today, but you don't get any control over them. I wonder if we should have an explicit component that you can add to the app model that is something like:

builder.AddTelemetrySettings("otel")
    .UseDefaults(false)
    .Endpoint("http://localhost:4317")
    .ServiceName("AspireApp17")
    .ResourceProperty("MyName", "MyValue");

That you can then reference from each project/ app/ container that you want to reference. It would have the logic for all the attributes that we spit today, together with API endpoints over them, and other common settings. If you disable the defaults then it will no longer spit those.

It would make it easier if you were going to have an OTel collector component, as you can now point one of these at that.

Additional context

No response

[samsp-msft]

@JamesNK, @mitchdenny

[mitchdenny]

Whilst subbing out the otel endpoint is painful (you've got to do it on each resource) it seems like the dashboard is what we want to optimize for right?

I'm thinking if APM provides what to provide an optimal experience here they can ship an AddDataDog(...) API and a custom WithReference(...) overload which splats the environment variables.

The proposal above makes it easy to substitute in a generic Otel endpoint but I think we want to encourage a rich API experience and just use the dashboard by default?

My loosely held opinion ;)