Decouple the dashboard from the Aspire.Hosting during development

[davidfowl]

We want to treat the dashboard like it's just another orchestrated process in your application.

We want to do 2 things to move this forward:

1. Make the dashboard run as an orchestrated resource. It's no longer special code running in process in the app host, it's out of process.
2. Define an HTTP API that the dashboard talks to get information. Aspire.Hosting will expose this API in development.

To make 1. work, we would make a dotnet tools package for the dashboard. The app model would define a new "tools package resource" that would install the dotnet tool and then run it as an orchestrated process. This would mean the dashboard and its dependencies would be fully isolated and it would run like tool (this has other benefits as well). It would be configured with the HTTP end point to get information from (the running app host itself). It also means we would update the templates to have an AddAspireDashboard call on the IDistributedApplicationBuilder. No call, no dashboard.

For the secod, we need to define an HTTP API to enable the dashboard to get data about the model. We also need to take versioning into consideration. Right now, we're using the k8s API talking to DCP directly, and augmenting it with additional data from the DistributedApplicationModel. The API is a contract for the dashboard, not DCP or Aspire.Hosting and it should be modeled as such.

[niltor]

I'm using otel/loki/tempo/grafana to summarize and view telemetry information.

After the dashboard is detached, can I remove my existing scheme and send the telemetry data directly to the dashboard through some extension method?

In addition, if it exists as a dotnet tool and is defined as a tools package resource, then when publishing, you need to consider how to control the publishing behavior of this type of resource.

[davidfowl]

I'm using otel/loki/tempo/grafana to summarize and view telemetry information.

I think you want to keep doing that unless there's a reason not to.

After the dashboard is detached, can I remove my existing scheme and send the telemetry data directly to the dashboard through some extension method?

I'd suggest sending it to both places.

In addition, if it exists as a dotnet tool and is defined as a tools package resource, then when publishing, you need to consider how to control the publishing behavior of this type of resource.

Yes, I have another issue in progress about deploying the dashboard

[josephaw1022]

Are there playwright tests in place for the ui dashboard?

[davidfowl]

No there isn't. Test coverage for the dashboard is manual at this point

[smitpatel]

In the decoupled world the dashboard will run out of process from AppHost. The dashboard will act as a client/receiver will which receive data about resources in the aspire and display them in UI on dashboard (including OTel data). Since dashboard also update data about resources in realtime, it will need data regarding resource being pushed to it once the connection is established rather than polling mechanism. Initial plan is to explore grpc as an option through which dashboard will talk to "server" and receive data regarding resources.
The "server" is supposed to provide data to dashboard regarding all the resources. In local development environment it will be endpoint exposed by Hosting project. This will also allow dashboard to be integrated with anything which can provide information e.g. in deployment environment.
The communication contract between dashboard and server will be responsible for providing all basic details about resources (including custom resources), their current execution status, logs associated with resources. While server may not provide data regarding OTel configuration but it will provide endpoints to get that data from individual app (similar to current setup).

[niltor]

In the decoupled world the dashboard will run out of process from AppHost. The dashboard will act as a client/receiver will which receive data about resources in the aspire and display them in UI on dashboard (including OTel data). Since dashboard also update data about resources in realtime, it will need data regarding resource being pushed to it once the connection is established rather than polling mechanism. Initial plan is to explore grpc as an option through which dashboard will talk to "server" and receive data regarding resources. The "server" is supposed to provide data to dashboard regarding all the resources. In local development environment it will be endpoint exposed by Hosting project. This will also allow dashboard to be integrated with anything which can provide information e.g. in deployment environment. The communication contract between dashboard and server will be responsible for providing all basic details about resources (including custom resources), their current execution status, logs associated with resources. While server may not provide data regarding OTel configuration but it will provide endpoints to get that data from individual app (similar to current setup).

It sounds good! I hope I can use it freely because monitoring is a common requirement for programs. Currently, using solutions like OTLP/loki/tempo/grafana or ELK can be relatively cumbersome to use and deploy.

When OpenTelemetry is used as the infrastructure, it should make everything easier. Many times, I don't need Grafana's ability to connect to various data sources. I just need the ability to monitor my applications and services.

With this approach, even if I'm not using the Aspire workload, I can still integrate into the Dashboard in my existing programs (through a library, a line of code, and configuring the connection string). I will have no burden and will be more willing to use it.

For production environments, additional requirements are basic role authorization verification and user management capabilities.

[davidfowl]

For production environments, additional requirements are basic role authorization verification and user management capabilities.

This is one thing we don’t have plans to solve yet. Nor long term storage of telemetry information.