Does Tares need a public URL to receive alerts from Prometheus?

No, Tares does not need a public URL to receive alerts from Prometheus. The prometheus_alerts connector polls Prometheus from the Tares side, so only Tares has to reach Prometheus. Prometheus never has to reach Tares. A public ingest URL matters only for push sources, where the sender calls Tares.

How it works

Tares has two ways to take in events, and the direction of the connection decides whether a public URL matters.

• Pull (poll): the source reaches out. The prometheus_alerts connector polls the /api/v1/alerts endpoint of your Prometheus server every 30 seconds by default. These are the alerts your alerting rules have already fired. The connection starts at Tares and goes to Prometheus, so Tares needs no inbound address.
• Push: the sender reaches in. A push source such as the webhook connector gives you an ingest endpoint, /ingest/<ingest_key>, and the producer posts to it. The sender must be able to reach that URL. On a local tares up it is http://localhost:8787/ingest/<ingest_key>, which only works for senders on the same machine. A sender elsewhere needs an address it can reach, such as the hostname you set up in the deployment guide.

Because the Prometheus alerts connector is a poll source, the only network requirement is that the machine running Tares can reach the Prometheus base URL, for example http://localhost:9090.

Tares tracks state across polls. Each alert fires once and re-emits only when its state changes. When an alert disappears from Prometheus, Tares emits a resolved event instead of repeating a copy on every tick. Each event has the alert name as its event_type, the alert summary as its text, and the alert labels as Tares labels plus a synthetic state of firing, pending or resolved.

You need no Alertmanager and no PromQL. Prometheus decides what counts as an alert, and Tares correlates it and can dispatch it to an agent.

Set it up

1. Start Tares on a machine that can reach your Prometheus server:

   tares up

   The console opens at http://127.0.0.1:8787. No tunnel or public hostname is involved.

2. Add the source. In the console, go to Sources → Add source → Prometheus alerts, enter the url (plus any auth) and click Discover. Discover lists the configured alerting rules and the severities present. If you prefer, ask a connected agent: “Use tares to ingest the firing alerts from the Prometheus at localhost:9090.” The agent runs discover_source and then create_source.

3. Choose what to ingest. Set severities to a comma-separated list such as critical,warning, or leave it blank for all. Turn on include_pending if you also want alerts that are still waiting out their for: duration.

4. If Prometheus sits behind auth, add bearer_token, or username and password. These are credentials Tares sends when it polls.

5. Save the source. This is the equivalent YAML, which you can also send with POST /api/sources:

   - name: alerts
     connector: prometheus_alerts
     poll: 30s
     config:
       url: http://localhost:9090
       severities: critical,warning   # blank = all
       labels:
         - { name: severity, field: labels.severity, primary: true }
         - { name: state, field: state }

6. Verify. Open the source and check Recent events, which shows one event per active alert and resolved events as they clear. Then open Fields to see the labels your alerts carry, and promote labels such as namespace or service to correlate on. Discover only proposes severity and state, because an alert’s dynamic labels exist only while it is firing.

What you get

• Prometheus alerts in Tares with no public URL, no inbound firewall rule and no tunnel for this path.
• One event per active alert, one resolved event when it clears, and no duplicate copy on every poll.
• Labels you can correlate on, so an alert can be matched with other signals and dispatched to an agent.
• A setup you can do in the console, through a connected agent, or with a single POST /api/sources.

When something else fits

• Your Alertmanager already routes alerts. Alertmanager can send alerts to a webhook receiver that points at a Tares ingest URL. That is a push path, so Alertmanager must be able to reach Tares. If Tares runs on a server, give it a hostname through the compose file with TLS in the deployment guide.
• Tares cannot reach Prometheus. If your Prometheus sits on a network that Tares cannot get to, polling does not work. Use a push route instead, where the sender can reach the Tares ingest URL.
• Other senders post to Tares. CI systems, cron jobs and your own services use the webhook connector. Their ingest URL must be reachable from wherever they run. On a secured instance they also send an ingest-scoped API key as Authorization: Bearer.
• You want to control polling. The polled source reads at the poll interval you set, 30 seconds by default. For anything that must arrive the moment it fires, a push source delivers on send.

For most Prometheus setups, start with the polled source described on the Prometheus alerts connector page and add a push route only if you need it.

Related