Help shape the future of the .NET Aspire dashboard extensibility

[drewnoakes]

We are exploring options for extensibility of the Aspire dashboard. Much of the dashboard's value comes from bringing data about all services in a distributed application into one place. We want to build on that integration to enable new capabilities that fit well in your workflow.

We're looking for your input. You can help by sharing:

• What scenario would would you like to see integrated into the dashboard?
• Why would it benefit from being in the Aspire dashboard rather than a standalone UI?

[EmixamZ]

Hey !
I think that the dashboard could be very beneficial if we could "embed" it with a few lines of code into an existing project.

Something like app.AddAspireDashboard.
Not sure if possible but that would be great !

Thanks!

[JamesNK]

Hi. Embedding the dashboard is something that the team has thought about. Making it Just Work as middleware or endpoints on a web app would be useful.

However, there are some challenges with the dashboard running in-process of an existing app:

1. The dashboard has a lot of dependencies. For example, it uses Blazor Server, a Blazor control library, Humaizer, gRPC, and many other libraries.
   • If the dashboard runs in the same process as an existing website, then those dependencies are added to your app. That might not be desirable.
   • There could be version conflicts. Only one dependency can be used which causes NuGet restore issues, or runtime errors. The dashboard might use V1 on the Blazor control library and your app uses V2. The V2 version is used when the app is running and causes the dashboard to break.
   • Configuration conflicts if configuration is shared between your app and the dashboard.
2. The dashboard exposes UI and endpoints for receiving telemetry data. There are currently requirements regarding what versions of HTTP the server exposes. This means configuration of not just the app's middleware and endpoints, but also Kestrel configuration.

[EmixamZ]

Hi James,
Thank you for your response.

Maybe you could distribute this via a NuGet so the dependencies will be listed and if there is any version conflict, we could wait for the next NuGet version of the embed dashboard.

Not sure to understand the second bullet point. You're saying that even if the extensions methods were exposed there would still be configuration on Kestrel side to operate the dashboard correctly, right ? I guess that this can be resolved with a good documentation from the NuGet.

[JamesNK]

Neither of these are insurmountable problems. But they're barriers to creating an experience that consistently works and is easy to set up.

[SaifAqqad]

there are some challenges with the dashboard running in-process of an existing app

What about running the dashboard out-of-process beside an existing app (almost like a sidecar), and have it managed by the app itself?

for the record, I tried making this (AspireRunner) and it works well enough, but it's not a perfect implementation, so it'd be nice if a more robust version was made by the aspire team

[galvesribeiro]

IMHO it really depends on the future of the Dashboard. For example:

1. If the Dashboard become a general purpose metrics/OTEL service which happens to nicely integrate and auto-discover Aspire services but also works without any Aspire services at all;
2. No, it will always be tied and only work with Aspire;
3. Whether or not it will be a development-only tool or if people will be able to use it as an Aspire solution deployed in production.

With that in mind, a lot of scenarios would could be enabled in terms of extensibility:

• Allow persistence of the metrics/logs/traces thru a provider model. (This is only useful if we would have true support of the Dashboard on the production environments (3));
• Allow authentication with OIDC (only useful on 3);
• Decouple OTEL collector/exporter from the UI (also only useful with 3);
• Have a plugin model where people can inject custom Blazor components. This allow for example NATS, RabbitMQ, databases, or any other service to expose their own metrics and runtime information outside of the OTEL traditional traces and metrics. This is useful at development time but even more at production;

In other words, we could have good usage of a native .Net telemetry/monitoring/metrics/logging tool built-in. But to get more into details of what we would want in terms of extensibility, IMHO, we would need to have a more clear view on what are the goals for the future on Aspire overall.

I understand that current release of Aspire aim to tackle the development side of services and not deployment and/or runtime in production. At least not yet. BUT, until we know when or even IF the runtime in production will be a thing, it is very hard to think of extensibility.

[davidfowl]

You want us to build the azure portal for development tools?

[galvesribeiro]

No no, that is the point of my comment. Not everything is on Azure, people still rely a lot on on-premises or private clouds or just they don't use PaaS/SaaS offerings but instead have self-hosted (i.e. deploying queues, databases and whatnot on Kubernetes) deployments. And again, not suggesting the team should build the whole portal, actually nothing at all. Just asking to make a plugin model so people can inject whatever they want on it. I just mentioned examples.

Another case is for specialized frameworks. For example, Orleans. We can surface grain calls as Traces with OTEL just fine. But there are lots of other data from grains which could be surfaced on its own dedicated section inside Aspire Dashboard. Yes, we do have a community driven project that has some of it as its own Orleans Dashboard. Yes, it can be a hyperlink to open it, but still not ideal. We could inject a menu entry on Aspire Dashboard for Orleans and provide detailed information about Orleans specifically. Like grain activations, runtime information, reminders, etc. Again, yes, we could surface traces using Activity so it glue together with the rest of the OTEL metrics but, not ideal for all cases.

Also, that is why I mentioned that "it depends on the future of Aspire and the Dashboard". The way you say "development tools" basically negate all that I asked before, so it is indeed focused on the development time, not production. I got it. So, just ignore what I said so far :)

[drewnoakes]

The Orleans example is interesting. Consider for example navigating from a structured log message to diagnostics particular to that grain in some other UI. That kind of navigation is harder when the content exists outside. Any time you have to copy an identifier in one UI to search in another seems like a place where we could add real value here, beyond just collating a bunch of discrete UIs under one top-level navigation menu.

Interested in any other examples that might highlight this kind of navigation between views.

[galvesribeiro]

Yeah. Orleans has kind of interesting unique features like for example, Streaming. It is extremely difficult to debug streaming when using traditional Traces since the only reference we have is the trace/span ids. Context is not easy to be carried over between the publishers and the subscriber(s).

Someone, several years ago, have built a UI which was essentially a diagram which show live the calls between grains, reminders ticks, and stream messages so visually someone could see the relation between grains, error rates, details about the grain type, etc. That was really nice. Unfortunately the project went down and the guy seems to not be on GitHub anymore.

In other words, I think different systems/frameworks can surface different information that a traditional span/trace can't proper represent. As you said, we could, thru extensions, detect some "hints" from structured logs or traces that could move the user to another detailed view on an extension which correlate with that trace/span/log showing information specifically for that system/framework.

[elfico]

@galvesribeiro

Decouple OTEL collector/exporter from the UI (also only useful with 3);

Would the benefit of this be that one can swap the exporter/collector with a different implementation? I just started with OTEL in a .NET app and used the Aspire standalone dashboard as an exporter/collector.
Will there be a default then if the collector/exporter is decoupled

[razvangoga]

It would be helpful to support surfacing in the dashboard additional urls along side the default one (like tye had with the routes collection).

It will allow the asipre setup to behave as living docs and help with onboarding.

Sometimes there are additional important endpoints like:

• my app defaults to login on localhost:9000 but i also have an admin login on localhost:9000/backend/admin
• my api is accessible under localhost:9000 but my swagger ui page is under localhost:9000/swaggy/index.html
• or surface urls for things like the CosmosDB emulator image
  

[drewnoakes]

How would you want this presented? Perhaps a drop-down on the list of resources with links to various URLs. Based on your other comment it seems like you'd want these to open in new browser tabs.

[razvangoga]

A list instead of the one url we have now for the main endpoint. As i mentioned i see them as living docs / description of the resource so i would show them front and center not hide them behind a dropdown or popup.

Opening in a new tab is ok, inline with the current behaviour of the main endpoint and would let each page do it's thing (instead of forcing it to run in an iframe or popup)

If they were named you could keep the width smaller than with just the url.
.AddExtraEndpoint("hangfire", "/blabla/hangfire/jobs)" would add <a href="localhost:9000/blabla/hangfire/jobs" target=_blank>hangfire</a>"

[anhaehne]

From a local development perspective it would be great i we could integrate existing management tools into the aspire dashboard. This would help new developers explore the applications.

It would be enough to have a new tab in the left sidebar that hosts an iframe to an existing managment ui. For example the hangfire dashboard to manage background jobs.

[razvangoga]

i think this is the same as i suggested above (#4575 (comment)) - minus the "load url in iframe" part

[martinjt]

One idea I had was around using information from traces to populate a separate section of the dashboard with a subset of information in a different visualisation.

An implementation of that would be to take conversational AI interactions and display them with all the relevant information. Specific to Azure that would be an "OpenAI" dashboard that shows the interactions with Azure OpenAI using the telemetry data with the semantic conventions from Openllmetry as the attributes to look for.

This could be similar for messaging (time to process message types), or databases (top queries, slowest queries).

Ultimately I would see that as an ingest processing layer, rather than querying the base data.

[drewnoakes]

using information from traces to populate a separate section of the dashboard with a subset of information

Can you elaborate on how this would differ from what's available in the current filtering options?

[martinjt]

It's a different layout.

Imagine a trace not being the root, but instead, the conversation id, showing just the tokens from each interactions so you can see information based on an AI interaction instead.

It's not about filtering, it's about the display.

That's just one example of how it could be used, the idea is you need to make trace data useful by providing different representations based on usecases.

It could be SQL queries, it's not about filtering to the DB spans, it's about representing those in a way that allows for differing analysis.

[martinjt]

Another idea was allowing for extensions to extend the trace view page, and then use that information to append other information to parts of the trace.

An implementation would be a button to "analyze this trace" where it would send the trace representation to an external service (maybe an AI backed thing, or an OpenAI endpoint with a specific prompt) that could tell you some things about the trace.

Another implementation could be provide a different visualisation of the current trace.

[razvangoga]

More ways to visualize the resources that the standard table aspire has today (take ArgoCDs web ui as inspiration)

• tiles (show more info about the resource than the table row)
  
• hierarchical (see which resource depends on which)
  

bonus : it would be nice to have a way to have the dashboard start directly in one of these view modes

[JamesNK]

@razvangoga Good feedback. We have some experiments in progress here. We want to make it easier to see resources and the relationships between them.

[Kralizek]

I would love to see a map of the system built using the traces