How self-hosted Grafana reads Google Cloud Monitoring metrics
Google Cloud Monitoring is a core Grafana data source in the metrics and time series category, so an operations team running self-hosted Grafana can connect to it with the built-in data source rather than a third-party plugin or custom code. That matters for planning: the integration is part of the Grafana install you already operate, and the decisions you make here concern identity, project scope and where the query traffic leaves your network, not which plugin to maintain. Confirm the data source's current configuration fields and supported authentication methods in the Grafana data sources documentation for the Grafana version you run.
In practice, the integration reads metrics that already exist in Cloud Monitoring and returns them to Grafana queries, so panels and alert rules can use GCP series next to Prometheus, database or other on-premises sources. It does not collect metrics from your Google Cloud resources, install agents on your virtual machines, or copy data into your Grafana database. Your Grafana server makes authenticated API calls to Google Cloud on each query, which means the metrics you chart are only as available as the Cloud Monitoring API and the permissions behind it. Plan for that dependency when you design dashboards that operators rely on during an incident.
The rest of this page follows the order in which decisions are made. It covers how Grafana authenticates to Google Cloud, with service account keys compared against workload identity, then how project scope limits what each data source can read, then the setup steps and the checks that show the panels return the expected series. The goal is a working connection that a second engineer can audit, rotate and rebuild without guessing which identity or project it used.
What a Google Cloud Monitoring integration needs before setup
Five things need to be in place before the Google Cloud Monitoring data source can return anything useful: a supported Grafana release, a production configuration database, a Google Cloud project that is already sending metrics, an identity with the right permissions, and a network path to Google APIs. Confirm each one with the team that owns it, because a gap in any of them shows up later as an empty panel or a failed login.
Supported Grafana minor release
Confirm that the self-hosted instance runs a minor release that is still inside its support window. Grafana's upgrade guidance says each minor release is supported for 9 months, and patch releases arrive at least monthly, so an instance that has fallen behind will miss fixes for the data source plugins as well as the core. Check the running version with the platform team and compare it against the upgrade guidance before you install anything new. If the instance is behind, plan the upgrade first so the integration is not built on a release that is about to lose support.
Production configuration database
Confirm that Grafana stores its configuration in MySQL 8.0 or later, or PostgreSQL 12 or later. SQLite is not suitable for production, and the data source settings you create in this integration, including the saved credentials and dashboard definitions, live in that database. Ask the database owner whether backups cover it, who can restore it, and whether a high availability setup is planned. Changing the database after dashboards exist is possible but adds a migration step to the project plan.
Cloud Monitoring enabled with metrics flowing
Confirm with the Google Cloud project owner that Cloud Monitoring is enabled on the target project and that the metrics you intend to chart are already arriving. Check the specific resource types, such as Compute Engine instances, Kubernetes containers or a custom metric, in the Cloud Monitoring console. A project with no data yields empty panels that look like a connection fault. Record the project IDs now, because they become the scope for the data source and for any dashboard variables.
Identity and IAM permissions
Decide which identity Grafana will use to call the Cloud Monitoring API, then ask the Google Cloud administrator to grant it read access to monitoring data in the agreed projects. Keep the role to read-only monitoring access and avoid project-wide editor roles. Confirm whether the security team accepts a service account key, which is a long-lived secret that must be stored and rotated, or a keyless approach that uses the identity of the host Grafana runs on. The choice affects who approves the setup and how the credential is audited.
Outbound access to Google APIs
Confirm with the network team that the Grafana server can reach Google's monitoring endpoints over HTTPS, either directly or through an approved proxy. Ask whether the proxy performs TLS inspection, since that can break certificate validation, and whether the firewall rules allow the destination the team has approved. Test the path from the Grafana host itself, not from a laptop, because the server is the component that will make the calls. Record any proxy settings so they are applied consistently across the Grafana service and any plugin installation.
Service account keys or workload identity for Grafana
When Grafana runs on a virtual machine or an on-premises host, a service account key is usually the most direct credential for the Google Cloud Monitoring data source. You create a service account in the project that holds the metrics, grant it read access to Cloud Monitoring, generate a key file and add that key to the data source configuration. Whoever creates the key owns its lifecycle, and nothing in Grafana rotates it on your behalf.
- Lifecycle: The key is created in Google Cloud, copied into Grafana and stays valid until someone disables or deletes it.
- Who rotates: Your platform team should name an owner and schedule rotation, because Grafana will not remind anyone.
- Where the secret sits: The key file is a credential. Keep it out of exported dashboards and Git repositories, and inject it from a secrets store at provisioning time.
- What breaks on rotation: Panels and alert rules that query Cloud Monitoring return authentication errors until the new key is loaded. Confirm whether your provisioning method needs a restart or only a data source update.
- Key sprawl: Each Grafana instance tends to receive its own key, so keep an inventory of keys, owners and the projects each one reads.
Before you choose this path, check which credential types the data source supports in the Grafana data sources documentation and confirm current key guidance with Google.
When Grafana runs in a Kubernetes cluster, workload identity may remove the stored key file. The pod authenticates with its Kubernetes identity, which is mapped to a Google identity through IAM policy, so Google issues short-lived credentials instead of a long-lived key. For Google Kubernetes Engine, confirm the mapping steps in Google's current workload identity guidance. For clusters outside Google, confirm whether the Grafana data source accepts federated credentials in your version before you plan around it.
- Lifecycle: Credentials are issued at runtime and expire on their own, so there is no key to copy into a secret.
- Who rotates: The cluster operator maintains the trust configuration, and Google handles the short-lived tokens.
- Where the secret sits: The chart values hold no key material. The binding lives in the cluster configuration and the IAM policy.
- What breaks on rotation: Usually the mapping. A renamed Kubernetes service account, a changed namespace or an altered trust attribute can remove access without any change to Grafana. Check the Grafana pod logs for permission errors after cluster changes.
- Scope: Give the mapped identity read access only to the projects Grafana needs, since every pod using that identity inherits the same access.
Before you commit, confirm with the Grafana data sources documentation that your data source version supports the federated flow you intend to use.
When Grafana runs on Google Cloud compute, such as a Compute Engine instance, the instance can carry an attached service account. Google supplies the credentials to the workload and refreshes them, so no key file needs to be written to disk. Whether the data source picks up these attached credentials automatically is a detail to confirm for your Grafana version and installation method, because some setups still ask for an explicit credential type.
- Lifecycle: Google issues and refreshes the credentials for the attached account, so your team does not handle a secret.
- Who rotates: Google manages credential refresh. Your team manages role grants and any change to the attached account.
- Where the secret sits: No key file sits on the disk. Access follows the instance's service account and its IAM roles.
- What breaks: Replacing the instance's service account or narrowing its access scopes stops queries. A copied machine image can carry a stale account assignment into a new environment.
- Shared access: Every process on the instance can use the attached account, so keep that account limited to read roles on the monitoring projects Grafana uses.
Confirm the exact supported credential behavior against the Grafana data sources documentation and Google's current guidance before you rely on it.
Grafana's Google OAuth option signs users in to Grafana. It controls who can open the Grafana interface and, with role mapping, what they can do inside it. It does not give the Cloud Monitoring data source permission to read metrics. The data source needs its own credential, configured separately, so a user's Google login and the data source's access are two different controls.
- What it covers: Who can log in, and optionally which Google accounts map to which Grafana roles.
- What it does not cover: The data source credential. Removing a user's Google sign-in does not revoke the data source's access to Cloud Monitoring, and changing the data source credential does not affect who can log in.
- Lifecycle: User sessions follow the identity provider, while the data source credential follows its own lifecycle.
- Ownership: The identity team configures sign-in, and the monitoring team owns the data source credential. Document both in the runbook.
- Exposure: A dashboard viewer can see any data the data source credential can read, so a Google login is not a substitute for limiting the service account's projects and roles.
Confirm the sign-in setup and the data source credential in separate reviews, using the Grafana authentication documentation for sign-in and the data sources documentation for the credential.
Configuring the Cloud Monitoring data source in order
This sequence connects a self-hosted Grafana instance to Google Cloud Monitoring with a least-privilege identity, a scoped project list and a verified query path, so teams can build panels and alerts on GCP metrics from the start.
Create or select the identity in the target project
The cloud administrator for the target project creates or selects a dedicated service account that Grafana will use to read metrics, or confirms that the workload identity your Grafana host already runs under can be used instead. Choose a workload identity where your hosting platform supports it, because it avoids storing a long-lived key file on the Grafana server. Record which identity you chose and which project it belongs to. Done means the identity exists, is named for Grafana and appears in the project's IAM view, and the owning team has agreed who holds the key or binding.
Grant only the monitoring read roles needed
Attach the Cloud Monitoring read roles that the data source needs to the identity, and nothing broader. Confirm the exact role names in Google's Cloud Monitoring documentation before you grant them, since names and their permissions change over time. If you plan to read logs or resource metadata through other Google Cloud data paths, add those roles separately and review them on their own. Done means the IAM policy shows only read-level monitoring roles for this identity, and a reviewer has checked the list against the panels you intend to build.
Install or confirm the core data source
Open the Grafana instance as an administrator and confirm that the Google Cloud Monitoring data source is present under connections. Google Cloud Monitoring is a core data source in the metrics and time series category, so no third-party plugin should be needed, but check the version of your Grafana release against the data source documentation. Done means the data source type appears in the add-data-source list and can be created without installing a plugin.
Enter the credential and default project
Create a new data source instance and select the authentication method that matches step one: the workload identity option or an uploaded service account key. If you use a key, store the file with restricted filesystem permissions or in your secrets manager, and do not paste it into shared dashboards or version control. Set the default project to the project that most dashboards will query. Done means the form saves without validation errors and the stored credential is not displayed back in plain text.
Set the scope for queryable projects
Define which projects this data source instance can query, using the project scope options in the data source settings. Limit the list to projects that the identity can already read and that your dashboard owners need. Where you run separate Grafana instances for different teams, give each instance its own identity and scope so one team cannot query another team's projects. Done means the scope lists only the intended projects, and a test query against a project outside the list fails as expected.
Save and test the connection
Select save and test in the data source settings and read the result. A successful test confirms that Grafana can authenticate and reach the Cloud Monitoring API with the identity you configured. If the test fails, check the identity's roles, the project ID spelling, and whether the Grafana host can reach Google's APIs through your network path. Done means the page reports a successful connection and the test does not depend on a manual retry.
Run a panel query against a known metric
Create a test dashboard, add a panel that uses the Cloud Monitoring data source, and query a metric whose value you already know, such as a metric for a resource you can see in the Google Cloud console. Compare the series in the panel with the console chart for the same time range and resource. Done means the panel returns a series that matches the known value within the expected sampling interval, and you have saved the query as the reference for later checks.
Run an alert test against the same metric
Create a test alert rule that uses the same query and a threshold you can cross deliberately, then confirm that the rule evaluates and reaches the firing state. Route the notification to a non-production contact point so that the test does not wake on-call staff. Done means the rule evaluates on schedule, changes state when the threshold is crossed, and the test notification arrives at the contact point you selected. Remove or disable the test rule once the check is complete.
How Cloud Monitoring projects, resources and labels map into Grafana
This table maps each Cloud Monitoring element your team configures to what it controls in Grafana, who should own the value, and where it is set. Use it to decide which settings belong in the data source configuration and which belong to individual queries or dashboards. Confirm exact field names against the Grafana data sources documentation for your version before writing provisioning files.
| Element | What it controls | Who owns the value | Where it is set |
|---|---|---|---|
| Default project | The Google Cloud project that queries use when no other project is chosen | Cloud team | Data source settings |
| Per-query project | Overrides the default project for a single panel when one dashboard spans several projects | Application owner | Query editor |
| Authentication method | Whether the data source uses a service account key or workload identity, and which identity Grafana presents to Google Cloud | Platform team | Data source settings |
| Metric type | The Cloud Monitoring metric queried, such as a specific resource or service metric | Application owner | Query editor |
| Resource labels and filters | Narrows series by resource type and label values such as instance or cluster | Application owner | Query editor |
| Aligner and reducer | How raw points are aligned over time and combined across series for display | Application owner | Query editor |
| Folder or team access | Which Grafana users and teams can open dashboards and panels that use this data source | Platform team | Grafana folder and team permissions |
| Provisioned defaults | Versioned default project, auth type and data source name loaded at startup | Platform team | Provisioning file |
Putting GCP and on-premises metrics on one dashboard
A single Grafana dashboard can hold panels from Cloud Monitoring and from an on-premises store such as a Prometheus-compatible server, because each panel picks its own data source. The hard part is agreeing on the rules before anyone builds a panel. Settle three things first: a common time range, consistent units, and one naming scheme for hosts or services that appear in both places. Without a shared time range, a panel comparing a GCP instance's CPU with the same host's CPU on-premises can show two different windows and look like a fault. Without agreed units, a value reported in bytes in one source and megabytes in the other will be misread. Without shared names, the join you expect in your head will not exist in the query, so a host label in Prometheus and an instance name in Cloud Monitoring need an explicit mapping. Write these conventions down and confirm them with the people who own each source.
The operational trade-off is that every source on a page is a dependency of that page. Grafana sends each panel's query to its own data source, and a panel waiting on a slow or throttled source holds up the dashboard as a whole, so one slow Cloud Monitoring query can make a page of on-premises panels feel broken. Cross-source comparisons add a second constraint: the series must share aligned intervals. Cloud Monitoring and a Prometheus-compatible store can return samples at different resolutions and with different alignment, so a ratio or overlay panel may need the intervals set explicitly so that both series line up. Where the comparison matters for an alert or a capacity decision, keep the mixed panel to a small number of queries and put heavier views on separate dashboards.
Confirm behavior for each panel type you plan to use, because the core data sources do not all support the same transformations, mixed-source expressions and alerting. Build a test dashboard with one panel of every type you need (time series, stat, table, gauge, and any panel that combines results), point each at the real GCP project and on-premises store, and check the displayed values against the source consoles for a known window. Check the Cloud Monitoring data source's documentation in your installed version for which panels and query options are supported before you commit a layout. Then record the results, so the team knows which combinations work and which need a separate panel or dashboard.
Least-privilege access and credential handling for the integration
The Google Cloud Monitoring data source is only as safe as the identity behind it. The controls below cover who holds the credential, what it can read, how it is stored and rotated, and who can change the connection. Together they keep a dashboard convenience from becoming a standing route into your cloud projects.
Dedicated service identity per instance
Create a separate Google Cloud service account for each Grafana instance or environment, so production, staging and test dashboards never share a credential. If one instance is retired or compromised, only its identity needs to be disabled. Confirm with your cloud team how service accounts are named and labeled so that owners can be identified from the console.
Read-only monitoring roles scoped to projects
Grant the service account only read access to Cloud Monitoring in the projects that the dashboards actually need. Avoid bundling it with logging or resource-management roles unless a specific panel requires them. Check the role bindings at the project level, and review whether folder or organization-level inheritance gives the account more reach than intended.
No broad project-owner grants
Project owner, editor or other broad basic roles are a common shortcut during setup and should not reach a Grafana service account. A compromised dashboard credential with those rights could change infrastructure, not just read metrics. Ask for a role inventory of the account as part of acceptance testing, and record the exceptions with an owner and a review date.
Workload identity over long-lived keys
Where the Grafana host runs on Google Cloud or can federate with Google identity, prefer workload identity or attached service identity over downloaded JSON keys. Keys are static secrets that can be copied out of a host. If a key is unavoidable, record its creation date, its owner and the procedure for rotating and revoking it.
Keep secrets out of files and dashboards
Provisioning files should reference the credential from an environment variable or a secret store, not contain its text. The same applies to dashboard JSON exports and version control, where a pasted key remains in history even after deletion. Ask whether your provisioning pipeline scans commits for key material and whether exported dashboards are reviewed before they are shared.
Limit who can edit the data source
Restrict edit rights on the Google Cloud Monitoring data source to platform administrators. Dashboard editors can build panels on an existing connection without being able to change its credential or project. Review the audit trail for changes to the data source configuration, and confirm that the instance is set to record administrative actions and that those logs leave the Grafana host.
Why Cloud Monitoring panels show no data or fail to save
This table lists the failures teams most often hit when connecting self-hosted Grafana to Google Cloud Monitoring, with the likely cause and the first diagnostic step for each. Work down the rows in order, since a failed connection test or missing permission explains many of the empty panels that follow. Confirm each control against the current Google Cloud and Grafana documentation for your versions.
| Symptom | Likely cause | First diagnostic step |
|---|---|---|
| Save and test fails on the data source | The service account key is wrong, expired, or was pasted with extra formatting | Confirm the key file is valid JSON for the intended service account, check whether the key has been disabled or rotated, and retest from the Grafana server |
| Connection test passes but panels show no data | The service account lacks read access to the selected project | Check the IAM roles granted to the identity on the target project and confirm the Monitoring viewer role is included |
| Panels are empty on one dashboard but not another | The data source default project differs from the project the query expects | Open the query editor and confirm the project field, then compare it with the project on the working dashboard |
| Query returns no series | Metric type or label filter does not match the monitored resource | Run the metric explorer in Google Cloud Monitoring with the same metric type and filters, and compare resource labels |
| Older time ranges show gaps or nothing | The requested range exceeds how long the metric retains data at its granularity | Check the metric's retention in Google Cloud documentation and narrow the dashboard time range to test |
| Timeouts or connection errors from the Grafana server | A proxy or firewall blocks outbound calls to Google APIs from the Grafana host | Test outbound HTTPS from the Grafana server to Google endpoints and review the proxy settings in the Grafana configuration |
| Alert rules fire on different data than the dashboard | The alert rule runs against a different data source instance or project than the panel | Compare the data source UID and project in the rule with the panel, and confirm the rule's query matches the dashboard query |
| Provisioned data source breaks after an upgrade | The provisioning file uses settings that changed or were deprecated in the new Grafana version | Review the release notes for the target version, validate the provisioning YAML, and check the Grafana startup log for provisioning errors |
Questions teams ask before connecting Grafana to Cloud Monitoring
How much does connecting Grafana to Cloud Monitoring cost?
The cost has three parts: the Grafana edition, Google Cloud Monitoring usage, and the engineering effort to set it up. Open-source Grafana is licensed under AGPLv3 after the April 20, 2021 relicensing, so the software itself carries no license fee for most teams, while Grafana Enterprise is a separate commercial option. Google Cloud Monitoring charges depend on the metrics and API calls your team chooses to query and retain, so dashboard count, refresh rates and query scope all move the bill. Engineering effort is the largest variable and is one-time for the initial build, then recurs as dashboards and projects change. Ask any quote to itemize the build, the identity setup, the number of projects in scope and the post-handover support, and confirm current Cloud Monitoring pricing with Google.
How long does a Grafana and Cloud Monitoring setup take?
Duration depends on how many Google Cloud projects are in scope, which identity model you choose, how the network path is designed, and how many dashboards must be rebuilt or validated. A single project with a working Grafana instance and an agreed identity pattern is a short task. Each additional project adds IAM bindings, scoping decisions and verification, and a multi-project estate with several teams adds approval steps and change windows. The network path matters when Grafana runs on premises, because outbound access to Google APIs must be allowed and tested. No duration is fixed here; the written scope from a partner or your own plan should give a timeline tied to these drivers.
Can our internal team set this up without a partner?
Yes, for a narrow scope. A team that already runs a production Grafana, has one Google Cloud project to query, and has an identity owner willing to grant a read-only role can usually complete the core data source setup internally. It becomes harder with many projects, strict credential policies that rule out long-lived service account keys, and dashboards that mix GCP and on-premises sources with alerting. In those cases the risk lies in configuration drift, over-broad roles and undocumented credentials. Check whether your team has someone who can own IAM bindings, a Grafana administrator who can manage data sources, and time to test failure cases before handing the dashboards to users.
What do we need to provide before the work starts?
The work needs four things from your side. First, access to the Google Cloud projects in scope, with someone who can review the monitoring read roles that will be granted. Second, an IAM owner who approves the identity model, whether that is a service account key or workload identity, and who can create the bindings. Third, a Grafana administrator who can install or change the core Google Cloud Monitoring data source and manage folders, permissions and provisioning. Fourth, change windows for the Grafana server and any network rules. Confirm these owners and windows in the written scope before work begins, since missing approvals are a common cause of delay.
Service account keys or workload identity: which should we choose?
The choice depends on where Grafana runs and what your credential policy allows. Service account keys are portable and work for a Grafana server outside Google Cloud, but they are long-lived secrets that need storage, rotation and revocation. Workload identity avoids stored keys when Grafana runs on Google Cloud infrastructure that supports it, though it needs a clear mapping between the workload and the service account. For on-premises Grafana, the decision usually centers on whether a federated identity path is approved by your security team. Document the choice, the owner of each credential and the rotation procedure, and confirm the exact configuration options for your Grafana version in the data source documentation.
Does the integration give us compliance evidence?
It gives monitoring visibility that can support evidence, but it does not replace the auditor's review. A Grafana dashboard that shows Cloud Monitoring metrics can show that systems are observed and that thresholds are tracked, which supports monitoring and capacity controls. Auditors still need to examine the design of the control, the access model, change records and the period over which evidence was produced. DeployOpen prepares systems, controls and evidence for compliance assessments, but it does not issue audit reports, attestations or certifications; independent auditors and certification bodies do. Ask your auditor early which evidence they will accept from this integration.
Which Grafana features do we need for mixed GCP and on-premises dashboards?
The Google Cloud Monitoring data source is a core Grafana data source in the metrics and time series category, so it sits alongside other core data sources in one instance. Mixed dashboards depend on consistent time ranges, shared variables and a clear naming scheme so that panels from different sources can be read together. Confirm your Grafana version supports the panel features you plan to use, and check the data source documentation for query editor options. Also plan for query cost and refresh rates, since panels that poll many projects consume more Cloud Monitoring usage than a single summary panel.
How DeployOpen scopes and delivers a Grafana and Google Cloud Monitoring integration
DeployOpen plans, implements, hardens, documents and supports self-hosted open-source platforms inside your own infrastructure, including the Grafana instance and its connection to Google Cloud Monitoring. Engagements are fixed-scope, so the data sources, projects, identity method and dashboards are agreed in writing before any build work starts.
How we scope
- We list the Google Cloud projects, metrics and dashboards that the Grafana instance must read.
- We record whether access uses a service account key or workload identity, and who owns that decision.
- We agree the written scope, deliverables and timeline with you before any build work starts.
How we build
- We configure the core Google Cloud Monitoring data source in your self-hosted Grafana, provisioned as code where your setup allows.
- We set up least-privilege roles on each project in scope and confirm that queries return only the data intended.
- We build combined dashboards that place Google Cloud metrics beside your on-premises data sources, then test them with your team.
How we hand over
- We document the data source configuration, identity setup, project scoping and dashboard ownership for your operators.
- We walk your platform and security staff through the access model, credential rotation steps and recovery procedure.
- We deliver the configuration files and runbook in your repositories so your team can rebuild the integration without us.
How we support
- Ongoing support, Grafana upgrades and continuous testing are available as retainers after handover.
- A retainer can cover checks after each Grafana minor or patch release that could affect the data source plugin.
- Your team keeps ownership of the Google Cloud projects, identities and dashboards, and we work within the access you grant.
