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

[WhitWaldo]

Chiming in here - as Aspire is centered around improving the developer experience, and the dashboard plays a key role in delivering that experience across IDEs - I'd like to advocate for enabling extensibility within the dashboard. Specifically, it would be valuable to allow integration developers to contribute their own sets of views for the resources deployed via Aspire.

I'm the .NET SDK maintainer for the Dapr project, and I've been exploring ways to streamline Dapr development in .NET. IDE extensions like Dapr for Visual Studio Code are helpful because they let developers visualize their applications, access logs from their app and the Dapr runtime, and interact with the runtime's HTTP APIs to test pub/sub flows and other features. It's a powerful tool - but it's tied to VS Code and overlaps with many of the capabilities Aspire already provides.

If Aspire's dashboard supported pluggable or extensible views, we could deliver a Dapr-specific visualization layer that's IDE agnostic and is aligned with Aspire's broader goals. This would not only enhance the developer experience for .NET users, but also support the growing number of Dapr users working in Python and Node.js. More importantly, it would unlock those capabilities transitionally confined to IDE plugins - such as real-time insights into runtime behavior - within a unified, cross-platform and cross-IDE dashboard.

For example, tapping into the telemetry data already available via the OpenTelemetry collector could allow developers to observe how Dapr interacts with other Aspire-launched resources, while also surfacing internal Dapr metrics and traces and in a more visualized capacity. This sort of integration would be a big step in making Aspire a central and extensible hub for modern development workflows and I'd be really eager to work with the Aspire team to realize the idea.

[Kralizek]

I forgot about this thread. Just today, I was wondering how cool it would be if the aspire dashboard would work also when the AppHost is stopped.

I'm not sure what it means from a technical or implementation point of view. But today it happened few times that I spun up the system, threw few requests, found an error, stopped the system to attempt to fix it, realized there was some valuable information in a resource logs just to find out I couldn't access it because now the apphost wasn't running anymore.

[mikolaj-milewski]

I am developing a workflow framework (www.stateflows.net) and the biggest challenge for my users is debugging of more complex models. I use standalone Aspire Dashboard as traces collector and visualizer (it's very handy except of lack of "Clear" button 😉) and it would be great to link traces of specific model execution steps (transition from state to state, passing data tokens between actions, action failures etc.) with elements in graphical representation of state machine/activity model.

To put it simply, I'd like to be able to register a plugin in dashboard that can render custom details content for logs and traces, if such content is available. Details pane can have tabs to enable that without adding new panes.

[SaifAqqad]

They actually added a clear button