How do I get Prometheus metrics into Tares?

Tares polls your Prometheus server for the metrics you pick by name or by label, with no PromQL to write. Each series becomes a metric event on every poll tick. If your metrics come from OpenTelemetry, you push them to the Tares OTLP endpoint instead.

How it works

Tares has two routes for metrics, and you choose by where the metrics live.

• Prometheus connector (poll). Tares reads from a reachable Prometheus server on an interval. You choose which metrics to ingest, and Tares builds the selector for you. Each series becomes a metric event on every poll tick, joinable with logs, deploys and alerts on the same key. See the Prometheus connector page for every field.
• OTLP connector (push). Your app or OpenTelemetry Collector exports metrics to Tares over OTLP/HTTP, or over OTLP/gRPC if you install the otlp-grpc extra. Resource attributes such as service.name become labels, so one source covers every service. See the OpenTelemetry connector page.

With the Prometheus connector you pick metrics in one of two ways:

• By name. Type a metric name or a prefix_* pattern and tick the matches.
• By label. Pick a label, see the metrics that carry it, and tick the ones you want.

Given a url, the connector lists the server’s metrics and labels for you to pick from. Tares then proposes the entity key and labels from a sample. The metric value is stored as a number-typed value label, so a trigger can take its max, avg or sum.

Set it up

Poll a Prometheus server

1. Make sure you have a reachable Prometheus server and know its base URL, for example http://localhost:9090.
2. Ask a connected agent, for example: “Use tares to ingest the pg_* metrics from the Prometheus at localhost:9090.” The agent lists the metrics and labels, samples your picks, runs one test poll and creates the source. You name the metrics, and it never writes PromQL.
3. Or use the console. Go to Sources → Add source → Prometheus, enter the url and any auth, select Discover, then pick metrics by name or by label and confirm.
4. If your server needs auth, set bearer_token, or username and password, on the source.
5. 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

6. Open the source. Recent events shows one event per series per poll, and Fields shows the labels and the numeric value.

You can also send the same object to POST /api/sources.

Push OpenTelemetry metrics

1. Go to Sources → Add source → otlp. No config is required. Use the service label, taken from service.name, as the natural key.

- name: otel
  connector: otlp
  config:
    labels:
      - { name: service, field: service, primary: true }

2. Point your exporter at Tares:

OTEL_EXPORTER_OTLP_ENDPOINT=http://localhost:8787   # OTLP/HTTP → /v1/{logs,traces,metrics}
# or gRPC (otlp-grpc extra): OTEL_EXPORTER_OTLP_ENDPOINT=http://localhost:4317

3. On a secured instance, exporters send an ingest-scoped API key as a Bearer token in the Authorization header.
4. Open Recent events to see metric points as they arrive, and Explore to list services under the service key.

What you get

• Metrics from Prometheus without writing a query. You pick names or labels, and Tares compiles your picks into a single selector.
• One event per series per poll, each named by its own metric name, so you can tell metrics apart.
• A number-typed value label that triggers can aggregate. Filter a trigger to one metric by event_type, then aggregate value.
• Metrics that correlate with logs, deploys and alerts on the same entity key.
• OpenTelemetry metrics, logs and traces from every service through one OTLP source, correlated by service with no per-service setup.
• A way to confirm that data is flowing: Recent events and Fields on the source, and Explore to watch a metric move.

When something else fits

Pick the route that matches where your metrics already live.

• You run Prometheus. Use the Prometheus connector and poll it. It suits metrics you already scrape and want to pick by name or label.
• Your services export OpenTelemetry. Use the OTLP connector and push. You get logs and traces on the same source, and Prometheus does not need to be in the path.
• You want a derived metric. A rate or a histogram_quantile p99 is a computed series. A queries row in the Prometheus connector can hold a single PromQL expression with an explicit event_type and field. This is the advanced option. The pick-metrics flow covers raw ingestion without any PromQL.
• You need gRPC. Install the otlp-grpc extra with pip install 'tares[otlp-grpc]'. The receiver then listens on port 4317.

Related