Skip to content

Prometheus interop with the Collector

Oriel ingests OTLP metrics only. It has no PromQL, scrape, or remote_write endpoint. To get Prometheus-instrumented services into Oriel, let an OpenTelemetry Collector do the Prometheus-to-OTLP translation and export the result to Oriel over OTLP. Two directions cover most setups: scrape targets directly, or accept remote_write from an existing Prometheus.

  • OpenTelemetry Collector Contrib when using the prometheusremotewrite receiver
  • An Oriel ingest token that permits metrics
  • A plan for high-cardinality labels before export
receivers:
prometheus:
config:
scrape_configs:
[
{
job_name: services,
scrape_interval: 30s,
static_configs: [{ targets: [app-a:9090, app-b:9090] }],
},
]
exporters:
otlp/oriel:
endpoint: oriel.example.com:4317
headers:
Authorization: Bearer ${ORIEL_INGEST_TOKEN}
service:
pipelines:
metrics:
receivers: [prometheus]
exporters: [otlp/oriel]

Point an existing Prometheus remote_write at a Collector running the prometheusremotewrite receiver (OpenTelemetry Collector Contrib):

receivers:
prometheusremotewrite:
endpoint: 0.0.0.0:9091
exporters:
otlp/oriel:
endpoint: oriel.example.com:4317
headers:
Authorization: Bearer ${ORIEL_INGEST_TOKEN}
service:
pipelines:
metrics:
receivers: [prometheusremotewrite]
exporters: [otlp/oriel]

Prometheus metrics are cumulative; Oriel accepts cumulative OTLP metrics and handles the temporality internally, so no cumulativetodelta processor is required. Watch metric cardinality: Prometheus label combinations become OTLP attributes and count against the per-project active-series cap (ORL-1010 when exceeded). Drop or aggregate high-cardinality labels with a metricstransform or filter processor before export.

Open Metrics or Explore and query one scraped metric name:

metrics | where name == "process_cpu_seconds_total" | limit 20

If the metric name differs after translation, list recent metric names:

metrics | stats count() by name | top 50 by count