Grafana Cloud
If you use a Grafana Cloud stack, your cluster can forward your applications’ OpenTelemetry traces and metrics to it. Your applications send to an endpoint inside the cluster, and the cluster forwards to Grafana Cloud. The Grafana Cloud tokens stay out of your applications, and you choose which services get forwarded. Your in-cluster Prometheus, Loki, Grafana and Tempo keep running as before; Grafana Cloud is an extra destination, not a replacement.
How it works
Traces and metrics each go through their own Grafana Alloy gateway in the observability namespace:
| Signal | Endpoint in the cluster | Cluster definition |
|---|---|---|
| Traces | alloy.observability.svc.cluster.local | observability.tracing.grafanaCloud |
| Metrics | alloy-metrics.observability.svc.cluster.local | observability.metrics.grafanaCloud |
Both accept OTLP over gRPC on port 4317 and over HTTP on port 4318.
Each gateway only forwards the services you list, matched on the service.name your application reports. Everything else is dropped. An empty list forwards nothing, so turning the feature on sends no data until you add a service. That keeps every new service’s Grafana Cloud cost a deliberate choice.
The separate metrics gateway means a burst of metrics can’t push traces out, and the other way around.
This page covers what your applications push over OpenTelemetry. The cluster’s own metrics from Prometheus go to Grafana Cloud through Prometheus remote write instead; ask us if you need that.
What you need from Grafana Cloud
From your Grafana Cloud stack’s details page:
- For traces: the Tempo instance ID and its OTLP gRPC endpoint (
host:port, for exampletempo-prod-10-prod-eu-west-2.grafana.net:443). - For metrics: the instance ID and the OTLP endpoint from the OpenTelemetry tile (for example
https://otlp-gateway-prod-eu-west-2.grafana.net/otlp). This instance ID is not the Tempo one. - An access policy token per signal: one with the
traces:writescope, one with themetrics:writescope. Separate tokens keep each gateway to the one thing it needs.
Each token goes into the cluster definition as a tokenPayload, KMS-encrypted with the context k8s_stack=secrets, as for other secrets in your cluster definition.
Send traces
spec:
observability:
tracing:
grafanaCloud:
enabled: true
endpoint: tempo-prod-10-prod-eu-west-2.grafana.net:443
username: "123456"
tokenPayload: a-kms-encrypted-payload
services:
- checkout
- paymentsWhen the in-cluster Tempo is on as well, it keeps receiving every span; only the listed services also reach Grafana Cloud.
Send metrics
spec:
observability:
metrics:
grafanaCloud:
enabled: true
endpoint: https://otlp-gateway-prod-eu-west-2.grafana.net/otlp
username: "654321"
tokenPayload: a-kms-encrypted-payload
services:
- checkout
dropMetrics:
- v8js.memory.heap.limitLeave /v1/metrics off the endpoint: the gateway adds it.
dropMetrics removes whole metrics before they leave the cluster, so you don’t pay for metrics you never look at. Use the name your OpenTelemetry SDK emits (http.server.request.duration), not the name Grafana Cloud shows after converting it to Prometheus style (http_server_request_duration_seconds). Dropping single attributes (labels) isn’t possible yet; if one attribute drives your cost, let us know.
Configure your application
Your SDK needs a separate endpoint per signal, since traces and metrics go to different gateways. The standard OpenTelemetry environment variables cover that. With gRPC:
env:
- name: OTEL_SERVICE_NAME
value: checkout
- name: OTEL_EXPORTER_OTLP_PROTOCOL
value: grpc
- name: OTEL_EXPORTER_OTLP_TRACES_ENDPOINT
value: http://alloy.observability.svc.cluster.local:4317
- name: OTEL_EXPORTER_OTLP_METRICS_ENDPOINT
value: http://alloy-metrics.observability.svc.cluster.local:4317With OTLP over HTTP (OTEL_EXPORTER_OTLP_PROTOCOL=http/protobuf), use port 4318 and include the path, because the SDK uses a signal-specific endpoint exactly as given:
- name: OTEL_EXPORTER_OTLP_TRACES_ENDPOINT
value: http://alloy.observability.svc.cluster.local:4318/v1/traces
- name: OTEL_EXPORTER_OTLP_METRICS_ENDPOINT
value: http://alloy-metrics.observability.svc.cluster.local:4318/v1/metricsOTEL_SERVICE_NAME must match an entry in services exactly, including case. The Tempo guide covers instrumenting your application.
Note
The gateways trust the service.name an application reports. Any workload in the cluster that reports a listed name gets its data forwarded and billed to your Grafana Cloud stack. If teams that shouldn’t share a Grafana Cloud stack run in the same cluster, talk to us about restricting who can reach the gateways.
Troubleshooting
Nothing arrives in Grafana Cloud
- Check that the service is listed in
servicesand thatOTEL_SERVICE_NAMEmatches it exactly. - Check that your application sends traces and metrics to the right gateway: metrics sent to
alloyare not forwarded. - Check the token’s scope (
traces:writeormetrics:write) and that the instance ID belongs to the same signal. A wrong token or instance ID makes Grafana Cloud refuse the data. - The Alloy dashboards in your cluster’s Grafana show whether each gateway’s components are healthy.