How do I connect to a Prometheus behind an auth proxy or on Grafana Cloud?

Tares connects to a Prometheus behind an auth proxy or on Grafana Cloud with the optional bearer_token field or with HTTP basic auth through username and password. You set the credentials next to the Prometheus url, and Tares stores the token and the password as secrets. Series that carry no key label fall under the entity key you set in default_key.

How it works

The Prometheus connector polls a Prometheus server on an interval and turns each series into a metric event. Authentication is part of the connector config, next to the base URL. You have two options:

• Bearer token. Set bearer_token to send an Authorization: Bearer token. Use it for managed Prometheus or for an auth proxy in front of your server.
• HTTP basic auth. Set username and password. For Grafana Cloud, the username is your instance id and the password is an API token.

Both bearer_token and password are secret fields, so Tares stores them as secrets. username is a plain string. All auth fields are optional, so a Prometheus without auth needs only the url.

The same credentials apply when you discover metrics. Given a url and your auth, Tares lists the server’s metrics and labels so you can pick from them. You never write PromQL. Your picks compile to a single selector that ingests every chosen metric.

The default_key field sets the entity key for series that carry no key label. If you leave it out, those series use unknown. Setting it to a meaningful name keeps those series joinable with logs, deploys and alerts on the same key, which is how Tares correlates in an AI SRE setup.

Set it up

1. Collect the base URL of your Prometheus, for example http://localhost:9090, or the Prometheus endpoint of your Grafana Cloud stack.
2. Collect the credential. Use a bearer token for an auth proxy or managed Prometheus. Use the instance id as username and an API token as password for Grafana Cloud.
3. Add the source in the console under Sources → Add source → Prometheus. Enter the url and your auth, then select Discover.
4. Pick the metrics. Choose By name and type a metric name or a prefix_* pattern, or choose By label and tick the metrics that carry the label you pick. Confirm, and Tares proposes the entity key and labels from a sample.
5. Or ask a connected agent, and it runs discovery, a test poll and the creation for you:

Use tares to ingest the pg_* metrics from the Prometheus at localhost:9090.

6. Check the generated config. The console and agent write it for you, and it looks like this:

- name: metrics
  connector: prometheus
  poll: 10s
  config:
    url: http://localhost:9090
    queries:
      - promql: '{__name__=~"(pg_stat_database_xact_commit|pg_up)"}'   # generated from your picks
        by_name: true
    labels:
      - { name: service, field: metric.service, primary: true }
      - { name: value, field: value, type: number }   # the metric value, aggregate it in triggers

7. Add your auth fields under config, next to url. Use bearer_token alone, or username together with password. Add default_key if you want a name other than unknown for series without a key label. You can also send the same object with POST /api/sources.
8. Verify. Open the source and check Recent events for one event per series per poll. Then check Fields for the labels such as metric.service and the numeric value.

What you get

• Metrics from a protected Prometheus, whether it sits behind an auth proxy, runs as managed Prometheus or lives on Grafana Cloud, arrive as events on every poll tick.
• The token and the password are stored as secrets.
• The numeric value is stored as a number-typed value label, so triggers can use max, avg or sum on it. Filter a trigger to one metric by event_type, then aggregate value.
• Series without a key label still land under one entity key you choose with default_key, so they stay joinable with your other sources.
• Discovery works against the protected server, so you pick metrics from a list instead of writing queries.

When something else fits

• If you want Prometheus rules that already fired, firing and resolved, the alerts connector fits better than raw metrics. If Alertmanager routes your alerts, point a webhook receiver at a Tares ingest URL instead.
• If you need a derived rate or a histogram_quantile p99, add a computed series, a queries row with a single PromQL expression, an explicit event_type and a field.

Related