Do I need to write PromQL to ingest Prometheus metrics into Tares?

No, Tares does not require PromQL to ingest Prometheus metrics, because you pick metrics by name or by label and Tares builds the selector for you. Your picks compile into a single selector that ingests every metric you chose, and discovery lists the server’s metrics and labels so you can choose from them. PromQL is only for the advanced case of a computed series, such as a derived rate or a histogram_quantile p99.

How it works

The prometheus connector polls a Prometheus server on an interval. Each series becomes a metric event on every poll tick, and you can join it with logs, deploys and alerts on the same key. You choose which metrics to ingest, and Tares does the rest.

• Discovery. Give the connector a url and it lists the server’s metrics and labels for you to pick from.
• Pick by name. Type a metric name or a prefix_* pattern, then tick the matches.
• Pick by label. Choose a label, and Tares lists the metrics that carry it. Tick the ones you want.
• One compiled selector. Your picks become a single selector that ingests every chosen metric. Each event is named by its own metric name, which is what the by_name setting on a generated entry does.
• Numeric value. The metric value is stored as a number-typed value label, so triggers can aggregate it with max, avg or sum. Filter the trigger to one metric by event_type, then aggregate value.

The selector entries under queries are built from your picks, so you don’t author them by hand. You can also drop metrics by name with the exclude key, which takes comma-separated substrings such as _bucket.

The only place PromQL appears is the computed series. A queries row can be a single PromQL expression, for example a derived rate or a histogram_quantile p99. You give it an explicit event_type and field, and you can add a text line to render it. Use this when you want a computed metric instead of a raw one. Raw ingestion never needs it.

Set it up

You need a reachable Prometheus server and its base URL, for example http://localhost:9090. If your server needs authentication, the connector accepts bearer_token, or username with password.

1. Choose your path. Ask a connected agent, or use the console. This guide belongs to the AI SRE workflow, and the agent path fits it well.

2. Ask an agent. Name the metrics you want in plain words:

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

   The agent calls discover_source, which lists the metrics and labels, samples your picks and proposes the config. It then calls test_source for one poll, and create_source to save it. You name the metrics, and the agent never writes PromQL.

3. Or use the console. Go to Sources, then Add source, then Prometheus. Enter the url and any auth, then select Discover.

4. Pick the metrics. Type a metric name or a prefix_* pattern and tick the matches. Or pick a label and tick the metrics that carry it.

5. Confirm. Tares proposes the entity key and the labels from a sample. There is no query language at any step.

6. Review the generated config. You rarely hand-write it, but this is what the picks produce:

- 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

The promql line is generated from your picks, so you never type it. You can also send the same object with POST /api/sources.

7. Verify. Open the source. Recent events shows one event per series per poll, and Fields shows the labels such as metric.service and the numeric value. To watch a metric move, open Explore and pick the entity the series is keyed on.

For every field the connector accepts, see the Prometheus connector page.

What you get

• Raw Prometheus metrics in Tares without writing a query. You choose them by name, by prefix_* pattern or by label.
• A single generated selector that covers every metric you picked, with each event named by its own metric name.
• A number-typed value label that triggers can aggregate with max, avg or sum.
• A proposed entity key and labels from a sample, so series line up with your logs, deploys and alerts on the same key. Series that carry no key label fall back to default_key, which is unknown unless you change it.
• Discovery that shows what the server exposes, so you pick from a list instead of guessing metric names.
• An escape hatch for computed series. You can add a PromQL expression with its own event_type and field when you want a derived rate or a p99.

When something else fits

Write PromQL only when you want a computed metric, such as a derived rate or a histogram_quantile p99. Add it as a queries row with an explicit event_type and field. If you want the alerts that Prometheus rules have fired instead of metric values, the prometheus_alerts connector is the better fit.

Related