Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Customize URL prefix on alerts #805

Closed
bluecmd opened this issue Jun 13, 2015 · 4 comments · Fixed by #864
Closed

Customize URL prefix on alerts #805

bluecmd opened this issue Jun 13, 2015 · 4 comments · Fixed by #864

Comments

@bluecmd
Copy link
Contributor

bluecmd commented Jun 13, 2015

While -web.hostname allows to set the hostname part of http://$host:$port, the scheme and $port is not settable per se.

The problem I'm having is that for the operator the Prometheus frontend is behind a proxy and needs to be accessed through this proxy. Currently the url is http://host:9090/prefix while I need it to be https://my.longer.hostname/prefix/
@juliusv
Copy link
Member

juliusv commented Jun 30, 2015

This is how parts of the externally exposed URL are configured right now:

  • the hostname is a flag
  • the path prefix is a flag
  • the port is derived from the listening address, but the externally
    reachable port could actually be different (load-balancer or port forwarding)
  • the scheme is hardcoded to http

The last two points are problematic and need to be configurable. Now I started a PR to be able to configure the scheme, but then noticed the thing about the port as well. I thought it might be better to just allow setting the entire Prometheus URL externally as one string. We would still need the hostname and path prefix flags though, as the former is used to substitute localhost in target links on the status page, and the latter is used for self-links throughout the web UI. Adding a separate flag for the entire URL would introduce partial redundancy (path prefix and hostname information would be repeated and possibly inconsistent). Maybe add two new flags, for scheme and external port (if external port flag is empty, it would default to the listening port)?

/cc @fabxc

@brian-brazil
Copy link
Contributor

For me the hostname I'd display is different (and a lot shorter) than the full hostname that you need to get to the prometheus server. If anything I'd like to be able to determine links automagically from the labels for all targets (in my case it's a simple concatenation), maybe we need a __display target label?

@juliusv
Copy link
Member

juliusv commented Jun 30, 2015

For that, you'd still need to be able to configure what the default externally visible hostname is, so this sounds like an orthogonal issue. Granted, just configuring the hostname might not be enough, as the external scheme, port, and endpoint of targets (if they are reachable through an LB at all) could be all different as well. That would then have to be configurable via some display relabeling options, but I see that as an orthogonal issue (and maybe too much feature bloat to put it into Prometheus TBH).

@juliusv juliusv mentioned this issue Jun 30, 2015
Merged
juliusv added a commit that referenced this issue Jul 3, 2015
@juliusv
Consolidate external reachability flags into one.
fcff35b 
Besides fixing #805 by
making the entire externally reachable server URL configurable, this
adds tests for the "globalURL" template function and makes it easier to
test other such functions in the future.

This breaks the `web.Hostname` flag (and introduces `web.external-url`).
This flag is likely only used by few users, so I hope that's
justifiable.

Fixes #805
simonpasquier pushed a commit to simonpasquier/prometheus that referenced this issue Oct 12, 2017
@mkm85 @brian-brazil
clarify gce sd config when meta data is returning urls as values (pro…
8861c6d 
…metheus#805)

* clarify gce sd config when meta data is returning urls as values

* examples has been removed
@lock
Copy link

lock bot commented Mar 24, 2019

This thread has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.

@lock lock bot locked and limited conversation to collaborators Mar 24, 2019
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

Successfully merging a pull request may close this issue.

Consolidate external reachability flags into one. prometheus/prometheus
3 participants
@bluecmd @juliusv @brian-brazil