My adventure with URLs in a Grafana that's behind a reverse proxy
I was oblique in yesterday's entry,
but today I'm going to talk about the concrete issue I'm seeing
because it makes a good illustration of how modern web environments
can be rather complicated. We run Grafana behind a reverse proxy as
part of a website, with all of Grafana under the /grafana/ path.
One of the things you can add to a Grafana dashboard is links,
either to other dashboards or to URLs. I want all of our dashboards
to have a link to the front page of our overall metrics site. The
obvious way to configure this is to tell Grafana that you want a
link to '
/', which as a raw link in HTML is an absolute path to
the root of the current web server in the current scheme.
When I actually do this, the link is actually rendered (in the
resulting HTML) as a link to '/grafana/', which is the root of the
Grafana portion of the website. Grafana is partially configured so
that it knows what this is, in that on the one hand it knows what
the web server's root URL for it is, but on the other hand its own
post-proxy root is '/' (in Apache terminology, we do a ProxyPass
of '/grafana/' to 'localhost:3000/'). This happens in both Firefox
and Chrome, and I've used Firefox's developer tools to verify that
href' of the link in the HTML is '/grafana/' (as opposed
you hover or click on it).
What I take from all of this is that a modern web application is a complicated thing and putting it behind a reverse proxy makes it more so, at least if it's sharing your web server with anything else. Of course, neither of these two things are exactly news. Now that I know a little bit more about how much 'rehydration' Grafana does to render dashboards, I'm a bit more amazed at how seamlessly it works behind our Apache reverse proxy.
PS: Configuring the link value in Grafana to be 'https:/' defeats
whatever rewriting is going on. The HTML winds up with that literal
text as the '
href' value, and then the pragmatics of how browsers
interpret this take over.