Prometheus Proxy

Prometheus is an excellent systems monitoring and alerting toolkit, which uses a pull model for collecting metrics. The pull model is problematic when a firewall separates a Prometheus server and its metrics endpoints. Prometheus Proxy enables Prometheus to reach metrics endpoints running behind a firewall and preserves the pull model.

The prometheus-proxy runtime comprises 2 services:

• proxy: runs in the same network domain as Prometheus server (outside the firewall) and proxies calls from Prometheus to the agent behind the firewall.
• agent: runs in the same network domain as all the monitored hosts/services/apps (inside the firewall). It maps the scraping queries coming from the proxy to the actual /metrics scraping endpoints of the hosts/services/apps.

Here's a simplified network diagram of how the deployed proxy and agent work:

Endpoints running behind a firewall require a prometheus-agent (the agent) to be run inside the firewall. An agent can run as a stand-alone server, embedded in another java server, or as a java agent. Agents connect to a prometheus-proxy (the proxy) and register the paths for which they will provide data. One proxy can work one or many agents.

Requirements

Requires Java 11 or newer.

CLI Usage

Download the proxy and agent uber-jars from here.

Start a proxy with:

java -jar prometheus-proxy.jar

Start an agent with:

java -jar prometheus-agent.jar -Dagent.proxy.hostname=mymachine.local --config https://raw.githubusercontent.com/pambrose/prometheus-proxy/master/examples/myapps.conf

If the prometheus-proxy were running on a machine named mymachine.local and the agent.pathConfigs value in the myapps.conf config file had the contents:

agent {
  pathConfigs: [
    {
      name: "App1 metrics"
      path: app1_metrics
      url: "http://app1.local:9100/metrics"
    },
    {
      name: "App2 metrics"
      path: app2_metrics
      url: "http://app2.local:9100/metrics"
    },
    {
      name: "App3 metrics"
      path: app3_metrics
      url: "http://app3.local:9100/metrics"
    }
  ]
}

then the prometheus.yml scrape_config would target the three apps with:

• http://mymachine.local:8080/app1_metrics
• http://mymachine.local:8080/app2_metrics
• http://mymachine.local:8080/app3_metrics

The prometheus.yml file would include:

scrape_configs:
  - job_name: 'app1 metrics'
    metrics_path: '/app1_metrics'
    static_configs:
      - targets: ['mymachine.local:8080']
  - job_name: 'app2 metrics'
    metrics_path: '/app2_metrics'
    static_configs:
      - targets: ['mymachine.local:8080']
  - job_name: 'app3 metrics'
    metrics_path: '/app3_metrics'
    static_configs:
      - targets: ['mymachine.local:8080']

Docker Usage

The docker images are available via:

docker pull pambrose/prometheus-proxy:1.8.8
docker pull pambrose/prometheus-agent:1.8.8

Start a proxy container with:

docker run --rm -p 8082:8082 -p 8092:8092 -p 50051:50051 -p 8080:8080 \
        --env ADMIN_ENABLED=true \
        --env METRICS_ENABLED=true \
        pambrose/prometheus-proxy:1.8.8

Start an agent container with:

docker run --rm -p 8083:8083 -p 8093:8093 \
        --env AGENT_CONFIG='https://raw.githubusercontent.com/pambrose/prometheus-proxy/master/examples/simple.conf' \
        pambrose/prometheus-agent:1.8.8

Using the config file simple.conf, the proxy and the agent metrics would be available from the proxy on localhost at:

• http://localhost:8082/proxy_metrics
• http://localhost:8083/agent_metrics

If you want to use a local config file with a docker container (instead of the above HTTP-served config file), use the docker mount option. Assuming the config file prom-agent.conf is in your current directory, run an agent container with:

docker run --rm -p 8083:8083 -p 8093:8093 \
    --mount type=bind,source="$(pwd)"/prom-agent.conf,target=/app/prom-agent.conf \
    --env AGENT_CONFIG=prom-agent.conf \
    pambrose/prometheus-agent:1.8.8

Note: The WORKDIR of the proxy and agent images is /app, so make sure to use /app as the base directory in the target for --mount options.

Configuration

The proxy and agent use the Typesafe Config library for configuration. Highlights include:

• support for files in three formats: Java properties, JSON, and a human-friendly JSON superset (HOCON)
• config files can be files or urls
• config values can come from CLI options, environment vars, Java system properties, and/or config files.
• config files can reference environment variables

All the proxy and agent properties are described here. The only required argument is an agent config value, which should have an agent.pathConfigs value.

Proxy CLI Options

Agent CLI Options

Misc notes:

• If you want to customize the logging, include the java arg -Dlogback.configurationFile=/path/to/logback.xml
• JSON config files must have a .json suffix
• Java Properties config files must have a .properties or .prop suffix
• HOCON config files must have a .conf suffix
• Option values are evaluated in the order: CLI, environment vars, and finally config file vals
• Property values can be set as a java -D arg to or as a proxy or agent jar -D arg.

Admin Servlets

These admin servlets are available when the admin servlet is enabled:

• /ping
• /threaddump
• /healthcheck
• /version

The admin servlets can be enabled with the ADMIN_ENABLED environment var, the --admin CLI option, or with the proxy.admin.enabled and agent.admin.enabled properties.

The debug servlet can be enabled with the DEBUG_ENABLED env var, --debug CLI option , or with the proxy.admin.debugEnabled and agent.admin.debugEnabled properties. The debug servlet requires that the admin servlets are enabled. The debug servlet is at: /debug on the admin port.

Descriptions of the servlets are here. The path names can be changed in the configuration file. To disable an admin servlet, assign its property path to "".

Adding TLS to Agent-Proxy connections

Agents connect to a proxy using gRPC. gRPC supports TLS with or without mutual authentication. The necessary certificate and key file paths can be specified via CLI args, environment variables and configuration file settings.

The gRPC docs describe how to setup TLS. The repo includes the certificates and keys necessary to test TLS support.

Running TLS without mutual authentication requires these settingss:

• certChainFilePath and privateKeyFilePath on the proxy
• trustCertCollectionFilePath on the agent

Running TLS with mutual authentication requires these settingss:

• certChainFilePath, privateKeyFilePath and trustCertCollectionFilePath on the proxy
• certChainFilePath, privateKeyFilePath and trustCertCollectionFilePath on the agent

Running with TLS

Run a proxy and an agent with TLS (no mutual auth) using the included testing certs and keys with:

java -jar prometheus-proxy.jar --config examples/tls-no-mutual-auth.conf
java -jar prometheus-agent.jar --config examples/tls-no-mutual-auth.conf

Run a proxy and an agent docker container with TLS (no mutual auth) using the included testing certs and keys with:

docker run --rm -p 8082:8082 -p 8092:8092 -p 50440:50440 -p 8080:8080 \
    --mount type=bind,source="$(pwd)"/testing/certs,target=/app/testing/certs \
    --mount type=bind,source="$(pwd)"/examples/tls-no-mutual-auth.conf,target=/app/tls-no-mutual-auth.conf \
    --env PROXY_CONFIG=tls-no-mutual-auth.conf \
    --env ADMIN_ENABLED=true \
    --env METRICS_ENABLED=true \
    pambrose/prometheus-proxy:1.8.8

docker run --rm -p 8083:8083 -p 8093:8093 \
    --mount type=bind,source="$(pwd)"/testing/certs,target=/app/testing/certs \
    --mount type=bind,source="$(pwd)"/examples/tls-no-mutual-auth.conf,target=/app/tls-no-mutual-auth.conf \
    --env AGENT_CONFIG=tls-no-mutual-auth.conf \
    --env PROXY_HOSTNAME=mymachine.lan:50440 \
    --name docker-agent \
    pambrose/prometheus-agent:1.8.8

Note: The WORKDIR of the proxy and agent images is /app, so make sure to use /app as the base directory in the target for --mount options.

Grafana

Grafana dashboards for the proxy and agent are here.

Related Links

• Prometheus.io
• gRPC
• Typesafe Config