OpenTelemetry

InfraSigns works with OpenTelemetry-native backends. It is a view + analysis layer over your existing metrics store, not a TSDB — it does not ingest or store OTLP itself. Apps instrumented with OpenTelemetry reach InfraSigns through a backend that ingests OTLP and exposes a Prometheus-compatible query API, which InfraSigns reads read-only (see Sources).

There are two shapes, depending on where your metrics land.

Recipe 1 — OTel → Prometheus (self-hosted) → InfraSigns

Prometheus ≥ 3.x can ingest OTLP directly (its native /api/v1/otlp/v1/metrics endpoint), so an OTel SDK or Collector can push metrics straight into a Prometheus you already run.

┌────────────┐   OTLP    ┌────────────┐   PromQL    ┌────────────┐
│ App + OTel │ ────────▶ │ Prometheus │ ◀────────── │ InfraSigns │
│ SDK/Collctr│           │  (≥ 3.x)   │  /api/v1/*  │            │
└────────────┘           └────────────┘             └────────────┘

1. Enable OTLP ingestion in Prometheus (--web.enable-otlp-receiver) and point your OTel Collector's otlphttp exporter at it.
2. Configure an InfraSigns source at the Prometheus query API — no token needed for a Prometheus you run yourself on a trusted network:

sources:
  - name: production
    url: http://prometheus:9090
    queries:
      - name: http_error_rate
        query: 'sum(rate(http_requests_total{status=~"5.."}[5m]))'
        signal: errors

Recipe 2 — OTel → hosted backend → InfraSigns (authenticated)

Hosted, OTel-native backends — Grafana Cloud, Dash0, Grafana Mimir, VictoriaMetrics Cloud, or Thanos behind an auth proxy — expose an authenticated Prometheus-compatible query API. Send your OTel data to them, then read it back with a bearer token:

┌────────────┐   OTLP    ┌───────────────┐   PromQL + Bearer   ┌────────────┐
│ App + OTel │ ────────▶ │ Dash0 / Grafana│ ◀───────────────── │ InfraSigns │
│ SDK/Collctr│           │ Cloud / Mimir  │  /api/prometheus/… │            │
└────────────┘           └───────────────┘                    └────────────┘

sources:
  - name: grafana-cloud
    # The backend's Prometheus query API base (paths differ per vendor — e.g.
    # Dash0's /api/prometheus, Grafana Cloud's /api/prom, Mimir's /prometheus).
    url: https://prometheus-prod-01.grafana.net/api/prom
    token: '${GRAFANA_TOKEN}'          # Authorization: Bearer <token>
    queries:
      - name: http_error_rate
        query: 'sum(rate(http_requests_total{status=~"5.."}[5m]))'
        signal: errors

The token is optional and is sent as Authorization: Bearer <token> on every query. It is a secret — inject it from the environment, never in the URL — and the endpoint must be https (a bearer over cleartext http to a non-loopback host is refused at config load). See Authenticated Prometheus-compatible backends for the redaction and redirect-scoping guarantees, and Kubernetes for wiring the secret. Both self-hosted configuration and the cloud add-source wizard collect the token (#251); in the wizard, entering a token skips the live probe (it verifies on first collection, like the cloud sources) since the probe is unauthenticated.

A Loki source reads authenticated Grafana Cloud Logs the same way (type: loki, token), running LogQL metric queries and optional log-line capture.

Metric names: OTel → Prometheus normalization

When metrics cross from OTLP into a Prometheus-compatible store, the exporter rewrites names to the Prometheus convention. Your queries (and the add-source wizard's preview) must use the normalized names, not the original OTel instrument names:

OTel	Prometheus-compatible query name
http.server.request.duration (dots)	http_server_request_duration (dots → _)
a monotonic Sum (counter)	gets a _total suffix — requests → requests_total
an instrument with a unit (s, By)	may gain a unit suffix — _seconds, _bytes
a non-alphanumeric character	replaced with _

Notes:

• The exact rules are the OpenTelemetry Prometheus-exporter naming spec; newer backends can disable the _total/unit suffixing (Prometheus's --enable-feature=otlp-deltatocumulative and translation-strategy options). Confirm the real series name in your backend (its metrics explorer) before writing a query — InfraSigns queries whatever name the backend actually stores.
• signal / warn / crit / unit hints attach to the query by its configured name, independent of the metric name — so a _seconds counter can still carry a signal: latency hint and a unit: " s" display suffix.

What InfraSigns does not do

• No OTLP push ingestion / no metric storage. InfraSigns is not a TSDB. Point it at a backend that ingests OTLP; do not send OTLP to InfraSigns.
• No new source type for this — an OTel backend rides the existing prometheus (or loki) source. Genuinely different APIs (CloudWatch, DigitalOcean, Hetzner) are their own source types.