[BUG] Paths that depend on a subdomain don't get resolved correctly when wildcard routes are involved

[begleynk]

Describe the bug
This is admittedly a bit of a niche bug, but I think I've figured out the root cause here.

Basically, I was surprised to see that all my Phoenix dashboard paths looked something like this:

Looking at /metrics, I saw that regardless of what path I visited, the phoenix metrics would have a controller of Phoenix.LiveView.Plug and this wildcard path of /*path.

Now, my app works like this: there's a dashboard subdomain which is sort of an "admin" interface, and any other subdomain routes to a particular user's project. The path that routes to a user's project accepts a wildcard path, since they are generated dynamically. The dashboard routes use the :host option in their scope to match only this subdomain.

So it seems like even though I'm visiting dashboard.myapp.com/foo, instead of being counted as a visit to the /foo path under the dashboard subdomain, the wildcard route handling all other subdomains catches it. Actual navigation in the app works just fine - just the metrics paths are being resolved incorrectly.

So, the root cause:

In the Phoenix plugin, there's a call to Phoenix.Router.route_info (https://github.com/akoutmos/prom_ex/blob/master/lib/prom_ex/plugins/phoenix.ex#L404). In order for these cases where the routing is based on a subdomain to be resolved, you have to pass the host to the function too. Currently just an empty string is passed.

I've tested this locally by calling route_info directly, and this reproduces the issue I'm seeing.

I'm happy to create a PR with this change since the host information is available directly in the conn, although I'm not sure if there are other implications.

To Reproduce

• Have an endpoint with a scope that matches only a particular subdomain
• Have another scope that matches all subdomain with a wildcard path
• Visit a path under the first scope

Expected behavior

The correct path is used in Phoenix metrics even with wildcard and subdomain based routing.

Environment

• Elixir version: 1.13.4-otp-25
• Erlang/OTP version: 25.0
• Grafana version: 9.0.3
• Prometheus version: 2.37.0

Additional context

Thanks for all the great work building this library 🚀 It was super easy to get up and running.

[feld]

I believe this affects me too. I have a similar situation for several apps at work.

[feld]

Does this explain why I have these routes that show up but are always 0ms? Is it because the API call was a relative path when on a subdomain?

[akoutmos]

Apologies @begleynk. I didn't see this issue until a reply was posted. If you want to work on the fix @begleynk that sounds good to me. I'll merge that in before the 1.8 release which I am trying to put together.

@feld What do the graphs look like if you don't mind posting them? The Grafana current field is sometimes unreliable and may report things that are a little off especially if traffic is sparse and there are scattered data points.

[feld]

I think I was mistaken. I believe prom_ex's phoenix plugin is always going to be exporting data for every known phoenix route (as seen above) and if there was no recent activity captured for those endpoints the grafana panel is still listing them but with 0ms for max/current. We're not hitting a lot of these endpoints as frequently as I expected either.