Prometheus Metrics
Bahriya can scrape a Prometheus-compatible metrics endpoint from your container and display the collected metrics in the console. This works for both HTTP containers and worker containers — any container that exposes a /metrics endpoint (or similar) can use this feature.
How it works
If your application already exposes Prometheus metrics — most frameworks and runtimes have a library or sidecar for this — you tell Bahriya which port and path to scrape. Bahriya then collects those metrics from every running replica, across every region, and surfaces them in the Prometheus tab on the container's detail page in the console.
You don't need to set up a separate Prometheus server, configure scrape targets, or manage a time-series database. Bahriya handles collection and visualisation. Your only job is to expose the endpoint inside your container.
Configuration
Two fields control Prometheus scraping. Both are in the Observability section of the container form.
| Field | Description |
|---|
| Prometheus port | The port inside your container that serves Prometheus metrics. This must be a valid port number (1–65535). |
| Prometheus path | The HTTP path to scrape. Defaults to /metrics if left blank. |
The port you specify does not need to be the same as your container's main service port. Many applications serve metrics on a separate port (e.g. 9090, 9113, 2019) to keep metrics traffic off the main request path.
When to set a separate port
- PHP / FrankenPHP / Laravel — FrankenPHP exposes Prometheus metrics on port
2019 by default at /metrics.
- Go applications — it's common to run a separate HTTP listener for
/metrics on 9090 or similar.
- Node.js — libraries like
prom-client can serve on any port you choose.
- Sidecars — if you're running a metrics exporter alongside your main process, configure the exporter's port.
If your application serves metrics on its main port (e.g. your API has a /metrics route on port 8080), set the prometheus port to the same value as your container port.
Viewing metrics
Once a container has a prometheus port configured and is deployed, a Prometheus tab appears on the container's detail page in the console. The tab shows all metric contexts that Bahriya collected, with a chart per metric, broken down by region.
Metrics are collected from all running replicas and aggregated. You can filter by region and adjust the time range.
If the tab shows no data:
- Verify your application is actually serving metrics on the configured port and path. You can test locally:
curl http://localhost:{port}{path}.
- Check that the port is correct — a mismatch means the scraper can't reach the endpoint.
- Wait a few minutes after deployment for the first scrape cycle to complete.
Reis CLI
In YAML mode, the prometheus fields live under the observability: group:
observability:
prometheus_port: 9090
prometheus_path: /metrics
These map to the prometheusport and prometheuspath API fields. See YAML Mode for the full field reference.
What this does not replace
Bahriya's built-in Prometheus integration gives you visibility into your application's custom metrics without any infrastructure setup. It is designed for quick observability — seeing what your application is doing, spotting trends, and debugging performance issues.
It is not a replacement for a full monitoring stack with alerting, long-term retention, or complex queries. If you need those capabilities, you can still run your own Prometheus or Grafana setup and scrape your containers directly using their region hostnames or internal networking.
Billing
There is no additional charge for Prometheus metrics collection. It is included with every container that has a prometheus port configured.
