Allow the dashboard to be added to an existing project

[martinjt]

While the whole project is amazing (seriously, kudos), the Dashboard on it's own is pretty good, and reminds me of Glimpse back in the day.

What would be great is if users of existing applications that aren't considered an "Aspire App" could add the dashboard when running locally.

If there was an extension like:

var builder = WebApplication.CreateBuilder(args);

builder.Services.AddAspireDashboard();

var app = builder.Build();

Everyone could benefit.

What I'd see that doing is.

• Add an OTLP exporter for http://localhost:18889
• Add that exporter for Logs, Metrics and Traces
• Add the Dashboard as a hosted service

We could add configuration for ports, and also disable some UI elements that aren't relevant. It would also be great if you could tail the logs too (too many people don't know how to find the log tail in Visual studio and it's useful).

I've mocked it up, and will push a nuget to my Github feed, happy to take suggestions on whether you'd want to take the dashboard in this direction. It's really hacky right now to get around some limitations on internal classes, but it does the job.

My biggest concern with this is that people see it as something they can deploy to prod, and it becomes a security risk, however, if it's limited to Web, we could force it to not work when the environment is production to help people into that pit of success.

https://github.com/martinjt/aspire-app-extension

[DamianEdwards]

Thanks for the kudos! Yep this is something we're interested in looking at. Lots of folks ask about running the dashboard outside of the AppHost project when they see it. We can use this issue to track this work.

[martinjt]

Once the conf stuff has died down a bit, do let me know if you want outside help.

[davidfowl]

I would recommend forking the code at the moment because we need to re-do some of this dashboard to make it run in other environments. It's not that this wouldn't be nice, it's just low priority and would be expedited if you did it for the scenario you are trying to enable.

[martinjt]

At the moment, I'm not sure that a Fork is required at this stage, it can mostly be done as a project in the solution without making changes to the dashboard at all. As I say, I can do the work, it's just the review time really, unless you're talking about the new coupling work that's in PR will break this?

[davidfowl]

As long as you can do it in way that isn't disruptive, we'll take it!

[martinjt]

Awesome, I'll take a crack at a small PR soon.

[samsp-msft]

@martinjt - why do you want/need to run the dashboard in-proc to the application that is being monitored. For OpenTelemetry, the dashboard is implementing OTLP to collect the traces/metrics/logs. It doesn't need to be in the same process as the app - in fact running in the app will likely skew the results as it will be tracking its own usage too.

If it were reading the data directly from ActivitySource, Meter, & ILogger, then it would make more sense to be in-proc, but it's not.

It can be easily started as its own process - either running directly or as a container.

It could then be questioned as to why use it, rather than jaeger, grafana etc? I think it has a couple of benefits:

• It's all in one - most OSS tools only deal with one aspect of telemetry
• It has zero configuration, only the port to listen on
• It's designed for developers rather than ops - this is subtle, but key - it shows what is emitted/collected automatically. Unlike a grafana dashboard, there is no pre-setup required. If a metric is exported, its automatically shown, it doesn't need to be searched for etc.
• Its light weight - there is no storage for records, no query language. It uses a circular buffer so data is expired when the limits are reached,

[martinjt]

The main reason is that engineers don't want to run extra things. This is a trait I've found more prevalent in the .NET ecosystem.

While running a docker container isn't hard, and when you're in a cloud native world, it's pretty natural, not all users are comfortable with that.

Allow this to be an extension to an existing site will help normalise using tracing inside monoliths, and even help push people to structured logging.

Right now, the biggest objection I hear for logs over tracing is to do with how easy it is to use locally. Once viewing traces is as easy viewing logs, that barrier becomes a non-issue. So making this a 1 line change inside an existing application will make things easy for non-cloud-native engineers to adopt.

You can also see from the twitter messages and the chat from the day that there were a lot of asks for it.

I can understand that there are challenges to get the dashboard metrics separated, traces should be easy, logs is probably fine too. However, the question is more about whether this is a useful item, and how useful it is rather than the work involved. In my opinion, and based on public feedback and questions on twitter/mastodon, this is something engineers want.

If I'm going to use something locally, and spin up containers, I'm going to recommend Jaeger or the otel-desktop-viewer. The lack of a persistent store, and tightly coupling to log sources, and the dashboard view model classes makes it a lot less appealing.

If I'm using something like Tilt to build a monorepo, then I'm likely to use something more k8s native.

The niche for this is quick and easy viewing of telemetry in smaller apps, and doing that from a hosted service inside an app is a nice way to do that and increase adoption.

[KSemenenko]

In mean time can I deploy Dashboard into azure as new container like part of AppHost?
Or it's only for local development?

[DamianEdwards]

@KSemenenko see #888

[senioroman4uk]

Hey, was trying to plug this in to one of the existing project my team owns, then realized that it only works in a standalone container. Is this up for grabs? I would like contribute

[adamint]

@senioroman4uk you are welcome to contribute. Let me know if you want it assigned to you

[vgallegob]

I would love to have this inside my app, we can't use containers unfortunately