Grafana — Querying Google Managed Prometheus
If your applications send metrics to Google Cloud through the OpenTelemetry
Collector, those metrics are stored in Google Managed Prometheus. CTO2B can
add a Google Managed Prometheus datasource to your Grafana so you can query
them with standard PromQL and build your own dashboards.
How to get it enabled
This is not something you can enable yourself — it needs a component deployed
into your environment by CTO2B.
Raise a request naming the environments you want it for. We will confirm
whether your setup already meets the requirements and give you a timeline.
Requirements we will check:
- Your environment runs on Google Cloud
- Your Grafana (observability stack) is deployed
- Your applications already export metrics through the OpenTelemetry Collector
If your applications do not export metrics yet, that part is application-side
work — the platform cannot create metrics your code does not emit.
What you can expect to find in it
Important: Google Managed Prometheus does not contain everything.
| Metric type | Where to find it |
|---|---|
| Your application's own metrics (request rates, JVM/runtime, custom business metrics) | Google Managed Prometheus |
| Kubernetes infrastructure — nodes, pods, containers, CPU and memory of the cluster itself | Prometheus datasource |
| Application logs | Logs datasource |
So you will normally use two datasources side by side: Prometheus for
infrastructure, Google Managed Prometheus for your applications. A dashboard
mixing both is fine.
Only metrics your applications actually export reach Google Managed Prometheus.
If a metric is missing, the usual cause is that the application is not emitting
it, not that the datasource is broken.
Ingestion is billed by volumeMetrics stored in Google Managed Prometheus are billed by Google based on how
much is ingested. If you plan to add a large number of custom metrics,
contact us first so we can review the cost impact together before you turn
them on.
Label names are prefixed where they collide
Where your application sets its own job, instance, namespace, cluster,
location, or project_id labels, those appear prefixed as exported_job,
exported_instance, and so on. The unprefixed labels describe the Kubernetes
resource the metric came from. If you are bringing PromQL over from another
system, this is the most common thing to adjust.
Dashboards move between environments unchanged
The datasource identifier is the same in every environment, so a dashboard
built against your dev environment can be imported into production without
rewiring its queries. Do check any hardcoded namespace or job filters, which do
differ between environments.
Logs and traces
This page covers metrics only. Logs and traces are handled separately — if you
need either surfaced in Grafana, raise a request and we will scope it with you.
Something not working?
If the datasource returns errors, or queries return nothing where you expect
data, raise a request including the environment, the query you ran, and the
time range. Please do not change the datasource configuration yourself — it is
managed by CTO2B and manual edits are overwritten automatically.
Related articles
Updated about 6 hours ago