Collecting Metrics#
Metrics reach materialize-monitoring by the paths in the following table, and most deployments use more than one.
| Path | Use it when | Direction |
|---|---|---|
| Prometheus Operator | An application in the cluster ships — or can be given — a ServiceMonitor or PodMonitor | The gateway pulls |
| Prometheus Remote Write | You already run Prometheus and want it to ship into this stack | Something pushes |
| OpenTelemetry Endpoint | You run an OpenTelemetry Collector, or an application that emits OTLP directly | Something pushes |
| Prometheus Scraper | You run your own Prometheus and this stack is not in the path at all | Your Prometheus pulls |
| Cloud Provider Metrics | The metadata database or the buckets are managed by AWS, Google Cloud or Azure, and their CPU, storage or burst headroom is wanted beside the rest | The gateway pulls from the provider’s API |
| PostgreSQL exporter | The metadata database or Grafana’s database is PostgreSQL, and what it reports about itself is wanted: connections, transaction-ID age, vacuum, and the size of every database on the instance | The gateway pulls from an exporter the chart runs |
Everything but the Prometheus Scraper lands in the same place: the alloy-gateway pipeline, which processes and enriches everything uniformly before writing it to storage.
How it got in makes no difference downstream.
The gateway’s ingress ports#
Three listeners, on the alloy-gateway Service:
| Port | Component | Accepts |
|---|---|---|
4317 | otelcol.receiver.otlp | OTLP over gRPC — metrics and logs |
4318 | otelcol.receiver.otlp | OTLP over HTTP — metrics and logs |
9090 | prometheus.receive_http | Prometheus remote-write |
(A fourth, 3100, takes Loki-format log pushes — see Logs & Events > Collecting.)
None of these ports authenticate their callers, and they are reachable from the whole cluster by default, because usually something in it legitimately pushes telemetry. NetworkPolicy is the only access control here. Narrow the ingest ports if nothing in your cluster needs them — see Securing.
Serving TLS on them#
The listeners are split across the two pipeline trees, and securing one does not secure the other:
| Listener | Governed by |
|---|---|
loki.source.api (3100), otelcol.receiver.otlp (4317/4318) | pipeline.logging.gateway.server.tls |
prometheus.receive_http (9090) | pipeline.metrics.gateway.server.tls |
The OTLP listeners carry metrics as well as logs but are governed by the logging tree, because the listener belongs to that tree even when the payload does not. Set both if you want every ingress port on TLS. See Securing.