Proxy Status dashboard (product feature)

[samsp-msft]

What should we add or change to make your life better?

Dashboard for proxy status and monitoring configuration

Why is this important to you?

Web front end so that people can understand and monitor the state of the proxy without having to go manually parse logs etc.

Should depend on #124 ( REST / gRPC endpoint). Ideally this could be built and run independently from the proxy process.
In larger sites, there can be multiple instances of the proxy server, so the dashboard would ideally be able to pull data from each individual proxy without having to have multiple instances of the dashboard.
It could be delivered as an independent project, that just depends on a well known API endpoint.

(Came as part of scenario discussion with @Kahbazi )

[davidni]

We're planning to build a poor man's dashboard using Razor pages. @samsp-msft when are you expecting this might start getting traction over here? Sure would be nice to collaborate on this too.

[samsp-msft]

What feature set are you thinking of? I was thinking of it being a site that is independent from the proxy, that can aggregate info from multiple servers that should be "clustered" together from a monitoring perspective, and individual from a config examination. Each proxy would expose a Rest/gRPC endpoint for pulling the data.

What info would you want to show - then lets back track that to an API that can be used by the dashboard or other apps. What is the overlap between the dashboard and log or event counter monitoring?

[davidni]

P0 for us is exploring the active configuration of the proxy. Recall that we do dynamic service discovery from Service Fabric in a multi-tenant setup where multiple teams are hosted behind our gateway through annotations in their service manifests. We want to provide a self-serve experience where teams can quickly see the Gateway's view of their service.
This means pretty much dumping the RuntimeModel classes in a friendly UX, including Backends, Routes, Endpoints, concurrency counters, and assessed health per endpoint and backend.

[thompson-tomo]

Dashboard should be factored into Aspire.

[brenthompson2]

We have been using Traefik as a load balancer for our ServiceFabric clusters. We would love to move to the Yarp version for ServiceFabric, but we love Traefik's dashboard showing frontends on one side and backend on the other side. It is super nice to know when a backend is down, or to know which paths are exposed by which frontends

[rkargMsft]

For a multiple LB scenario, there is a challenge of knowing what the members of the cluster are, as there's not a built-in concept of cluster membership.

We currently don't solve that with our setup (scaling clusters of YARPs) and instead have a page served in-process from each instance and you hit one of the instances however the L4 in front of the YARPs decides to route you.

Generally, this is perfectly fine as the information would be the same (other than Outstanding Calls) from any of the instances. But it doesn't show you if there's a difference between different instances because of some problem.

We do also have Telemetry messages (think well-structured logs) for Route/Cluster status that gets published from each instance to do troubleshooting when necessary. The web page is just a convenient way to get to the information in 99% of cases.