status page has absolute links instead of relative paths

[mrwacky42]

I noticed that the /status page in AlertManager has broken CSS. It ended up being because the CSS links are incorrect.
We proxy to /alertmanager with nginx, but I confirmed it also misbehaves talking directly to AlertManager. This happens on at least 0.0.3 and 0.0.4. I don't see anything in the source that would cause /status to be treated differently.

We are running alertmanager -config.file=some_config.conf, not bothering to set any other command-line parameters.

• Relative hrefs for /, /alerts and /silences. CSS loads just fine.

curl -s localhost:9093/ |grep default.css
    <link href="static/css/default.css" media="all" rel="stylesheet" type="text/css" />

curl -s localhost:9093/silences |grep default.css
    <link href="static/css/default.css" media="all" rel="stylesheet" type="text/css" />

• Absolute hrefs, not correct. Links all broken, no CSS styles loaded.

curl -s localhost:9093/status |grep default.css
    <link href="/static/css/default.css" media="all" rel="stylesheet" type="text/css" />

[juliusv]

No proxy here, but the CSS loads correctly for me on all pages, including /status. The paths are absolute in all of them. This is both when building from HEAD as well as when trying out the 0.0.4 tarball.

curl -s localhost:9093/ |grep default.css
    <link href="/static/css/default.css" media="all" rel="stylesheet" type="text/css" />
curl -s localhost:9093/silences |grep default.css
    <link href="/static/css/default.css" media="all" rel="stylesheet" type="text/css" />
curl -s localhost:9093/status |grep default.css
    <link href="/static/css/default.css" media="all" rel="stylesheet" type="text/css" />

You said it also misbehaves without a proxy?

[mrwacky42]

My examples above all were without a proxy, using the release from github, built on your thinkpad! 😀

Build Information

branch  master
date    20150909-17:20:43
go_version  1.4.2
revision    e00f5b1
user    julius@julius-thinkpad
version 0.0.4

I'll try building 0.0.4 myself and see what happens.

[juliusv]

Ok, that's very strange, as with that exact binary I'm not getting the problem you're seeing. It's a static binary, so we should be getting the same results.

Are you sure that your curl doesn't use a proxy (via environment variable http_proxy or in ~/.curlrc) that does something weird?

[mrwacky42]

I just compiled 0.0.4 in a Vagrant VM, and tested again. Same results. I even zapped web/files/blob.go.
And, no, no funky curl configs.

vagrant@vagrant-ubuntu-trusty-64:/tmp/alertmanager$ cd /tmp
vagrant@vagrant-ubuntu-trusty-64:/tmp$ rm -fr /tmp/alertmanager/
vagrant@vagrant-ubuntu-trusty-64:/tmp$ git clone https://github.com/prometheus/alertmanager.git
Cloning into 'alertmanager'...
[SNIP]
Checking connectivity... done.
vagrant@vagrant-ubuntu-trusty-64:/tmp$ cd alertmanager/
vagrant@vagrant-ubuntu-trusty-64:/tmp/alertmanager$ git co -b 0.0.4 tags/0.0.4
Switched to a new branch '0.0.4'
vagrant@vagrant-ubuntu-trusty-64:/tmp/alertmanager$ make dependencies-stamp
Go version 1.4.2 required but not found in PATH.
About to download and install go1.4.2 to /tmp/alertmanager/.build/go1.4.2
[SNIP]
touch dependencies-stamp
vagrant@vagrant-ubuntu-trusty-64:/tmp/alertmanager$ rm web/blob/files.go
vagrant@vagrant-ubuntu-trusty-64:/tmp/alertmanager$ make web
./web/blob/embed-static.sh web/static web/templates | /tmp/alertmanager/.build/go1.4.2/bin/gofmt > web/blob/files.go
vagrant@vagrant-ubuntu-trusty-64:/tmp/alertmanager$ make
GOROOT=/tmp/alertmanager/.build/go1.4.2 GOPATH=/tmp/alertmanager/.build/gopath /tmp/alertmanager/.build/go1.4.2/bin/go get -d
touch dependencies-stamp
GOROOT=/tmp/alertmanager/.build/go1.4.2 GOPATH=/tmp/alertmanager/.build/gopath /tmp/alertmanager/.build/go1.4.2/bin/go build  -o alertmanager
vagrant@vagrant-ubuntu-trusty-64:/tmp/alertmanager$ touch alertmanager.conf
vagrant@vagrant-ubuntu-trusty-64:/tmp/alertmanager$ ./alertmanager &
[1] 3961
vagrant@vagrant-ubuntu-trusty-64:/tmp/alertmanager$ alertmanager, version  ()
  build user:
  build date:
  go version:
WARN[0000] Couldn't load silences, starting up with empty silence list: open silences.json: no such file or directory  file=main.go line=76
INFO[0000] Replacing aggregator rules (old: 0, new: 0)...  file=manager.go line=246
INFO[0000] Running notification dispatcher...            file=main.go line=151
INFO[0000] listening on :9093                            file=web.go line=76
INFO[0001] Recomputing notification outputs (active alerts have changed, inhibit rules have changed)  file=manager.go line=398

vagrant@vagrant-ubuntu-trusty-64:/tmp/alertmanager$ curl -s 0:9093/status  |grep default.css
    <link href="/static/css/default.css" media="all" rel="stylesheet" type="text/css" />
vagrant@vagrant-ubuntu-trusty-64:/tmp/alertmanager$ curl -s 0:9093/silences  |grep default.css
    <link href="static/css/default.css" media="all" rel="stylesheet" type="text/css" />

[juliusv]

What the...

Now I'm getting the same (that is, relative paths on everything except /status), although the CSS still loads correctly with both path variants since it's correct both as a relative and absolute path. I have no idea why I didn't get this before, maybe I did something really wrong, even during the copy&paste of the output. Strange.

Looking more.

[juliusv]

Aha! In HEAD it's all absolute paths. I noticed that Alertmanager doesn't shut down when it cannot acquire it's port (ugh), so I must've still been running a HEAD Alertmanager in another terminal and didn't notice that the 0.0.4 one didn't start up correctly because it doesn't indicate that properly.

Ok, so something evidently changed between 0.0.4 and HEAD there. Have you given HEAD a try?

[juliusv]

Also in general, this current experimental Alertmanager is being replaced by a complete rewrite, of which an Alpha is now out: https://groups.google.com/forum/#!topic/prometheus-developers/AmGnO_Sj7xI

You might already want to use the new one. The old one is experimental and a horrible proof-of-concept codebase, but has seen more practical use. The new one doesn't have as many miles yet, but will be the shape of things to come and is more future-proof and properly built.

[mrwacky42]

Yep, HEAD behaves correctly.
I'll try to have a look at the alpha.

It looks like this ab93482, insofar as it fixed /silences and /alerts by causing the pathPrefix to now be set.

So, presently, /status is the only path that is working "correctly".

[mrwacky42]

Just to wrap this up, with 0.0.4, if I set -web.external-url and -web.path-prefix everything is working.
Although, it's still the wonky behavior of not always having PathPrefix set:

$ curl -s 0:9093/alertmanager/status|grep default.css
    <link href="/alertmanager/static/css/default.css" media="all" rel="stylesheet" type="text/css" />

$ curl -s 0:9093/alertmanager/|grep default.css
    <link href="static/css/default.css" media="all" rel="stylesheet" type="text/css" />

$ curl -s 0:9093/alertmanager/silences|grep default.css
    <link href="static/css/default.css" media="all" rel="stylesheet" type="text/css" />