The company group an end-to-end containerized test environment, located under different sub-paths, proxied by Nginx: * For example, user A is under
- For example, user A is under
- For example, user B under
The effect you want to achieve, in addition to the above distinction between different subpaths, requires that there is no such distinction inside the container: i.e., the container can be accessed directly inside
prometheus:9090 to request Prometheus.
TLDR: If you also have such a need. If you think the article is too long and don’t want to read it, you can skip directly to the final summary.
Prometheus’ path and route configuration
From the command line parameters of Prometheus, you can see that it provides the following two options to control the path and route configuration.
The URL under which Prometheus is externally reachable (for example, if Prometheus is served via a reverse proxy). Used for generating relative and absolute links back to Prometheus itself. If the URL has a path portion, it will be used to prefix all HTTP endpoints served by Prometheus. If omitted, relevant URL components will be derived automatically.
This is the address (URL) that is externally reachable by Prometheus (after reverse proxy).
Used to generate relative or absolute links (on a page or in a request).
Prefix for the internal routes of web endpoints. Defaults to path of –web.external-url.
Route prefix for Prometheus internal web requests.
Defaults to the path in
Direct access test
In order to have direct access to Prometheus’ API inside the container,
--web.route-prefix should be configured as
--web.external-url, since it controls the externally accessible path and relative link generation in the page. So this address should be configured to the path mentioned at the beginning of the article (in the case of user A):
Here’s a real test to see.
Note: For illustration purposes,
prometheus are used below to represent the two services respectively.
The API is accessible.
The home page is redirected to the path with the prefix when you visit it.
However, if you try to access this redirected address, it will report an error that it cannot be found.
Isn’t it quite strange? If I directly request the path without the prefix, it is found.
So that’s what
--web.external-url=<URL> means when it says “deeper”: This option is used to control the path before the reflection proxy, which Prometheus itself doesn’t need, and you should rewrite the path in nginx to remove it.
Tested by nginx proxy
Tried to access it, and as expected it didn’t work because the path hadn’t been rewritten yet.
Try to rewrite the path.
rewrite rule above means roughly: the request
/a/prometheus/xxx is rewritten to
/xxx and then passed to the proxied server.
So, Prometheus receives the request without the prefix. And, it was found to work.
After consulting the
proxy_pass documentation for nginx, we found that
proxy_passis not followed by a URL, the original URL received by nginx is passed directly to the proxied server unchanged.
proxy_passis followed by a URL, the prefix in
locationis removed and appended to the URL before it is proxied.
In this way, the above nginx configuration can be simplified to look like the following.
Note that there is a
/ at the end.
The configuration of Prometheus.
In addition, PushGateway and Prometheus have exactly similar configurations.