metrics

The metrics core microservice provides a single endpoint that lets Prometheus scrape metrics from all microservices at once. Prometheus pulls metrics from the metrics core microservice, which in turn pulls and aggregates metrics from all microservices it can reach on the messaging bus.

The endpoint to obtain metrics from the metrics microservice is https://localhost:8080/metrics.core/collect. An optional argument service can be used to obtain the metrics of an individual service.

Metrics can also be obtained from a microservice directly at https://localhost:8080/hello.example:888/metrics.

The metrics core microservice is unnecessary if metrics are pushed to an OpenTelemetry collector, rather than pulled. Pushing is the recommended path: a scrape aggregation transiently holds every replica’s metrics output in memory, a cost that grows with the mesh, while push spreads the same data over time and connections. This microservice does nothing unless explicitly added to the app, so its cost and attack surface are opt-in.

Authenticating the Scrape

Pass the secret key in an Authorization: Bearer header. It is mandatory outside local development and testing, and must match the SecretKey config or the request is denied.

# prometheus.yml
scrape_configs:
  - job_name: microbus
    authorization:
      type: Bearer
      credentials_file: /etc/prometheus/microbus-metrics-key
    static_configs:
      - targets: ['localhost:8080']
    metrics_path: /metrics.core/collect

The header is preferred over the legacy secretKey query argument because URLs land verbatim in access logs, proxy logs and monitoring UIs, while headers conventionally do not. The query argument still works — dropping it would be a silent breakage an operator could not detect until metrics went dark — but new scrape configs should use the header. Grafana Alloy and other Prometheus-compatible scrapers express it the same way.

An incorrect key returns 404 rather than 401, so the endpoint’s existence is not confirmed to a prober. Keys are compared in constant time over their SHA-256 digests, so neither the key’s content nor its length leaks through response timing.

How Collection Works

Collect publishes a single multicast to every replica’s :888/metrics control endpoint and streams the responses into its output as they arrive, keeping the concatenated series distinct by each replica’s id label. One request wave covers the whole mesh; a service query argument narrows it to one host.

Concurrency is deliberately uncapped. A worker pool would serialize the scrape and stretch its wall time past Prometheus’s scrape timeout on a large mesh, which is a worse failure than the transient memory of holding the responses.

Prometheus metric collection must be explicitly enabled by setting the MICROBUS_PROMETHEUS_EXPORTER environment variable.