Teams using Prometheus may still need measurements collected by Google Cloud’s monitoring services. Stackdriver Exporter retrieves selected time series from the Cloud Monitoring API and presents them for Prometheus to scrape, allowing shared queries and alerts. This direction of data flow matters: it brings Google monitoring data into Prometheus rather than sending application traces or Prometheus data to Google. Source sampling delays, project permissions and API quotas affect how current and complete the resulting measurements will be.
Current guidance
The historical chart metadata identifies frodenas/stackdriver_exporter, now documented in prometheus-community as a Google Cloud Monitoring metrics exporter. It requests metric time series from the Monitoring API when Prometheus scrapes it. This corrects a mismatch in the recovered body: it is not an application tracing agent or the Stackdriver Trace service.
The current upstream README points to a prometheus-community chart and documents Google Application Default Credentials and monitoring read permissions. Use an appropriate workload identity mechanism where available and scope access to the projects that must be observed. Avoid treating long-lived downloaded service-account keys as the only authentication option.
Before migrating, inventory metric prefixes, project selection, label mapping, scrape interval and API quotas. Cloud metric sampling and ingestion delay can differ from Prometheus scrape timing, so validate alert windows and missing-data behavior with actual metrics. Compare a bounded set of queries and recording rules before switching exporters. Keep this direction of data flow clear: collecting Cloud Monitoring metrics into Prometheus is different from sending Prometheus metrics to Google’s managed monitoring service.
Historical upstream link check · 2026-10-09
The recorded upstream address responded successfully (HTTP 200) on 2026-10-09. GitHub confirms that helm/charts is archived: this is a historical chart distribution, not evidence that the application itself is retired. Link availability does not certify the historical installation instructions or current security support.
Website availability is separate from project, chart and image support. Use the current guidance and primary sources on this page to assess the distribution.
Historical Kubedex content
Preserved for context. Commands, versions, prices and results below reflect the original research.
Stackdriver Trace is a distributed tracing system that collects latency data from your applications and displays it in the Google Cloud Platform Console.
You can track how requests propagate through your application and receive detailed near real-time performance insights. Stackdriver Trace automatically analyzes all of your application’s traces to generate in-depth latency reports to surface performance degradations and can capture traces from all of your VMs, containers, or Google App Engine projects.
Stackdriver Monitoring provides visibility into the performance, uptime, and overall health of cloud-powered applications. Stackdriver collects metrics, events, and metadata from Google Cloud Platform, Amazon Web Services, hosted uptime probes, application instrumentation, and a variety of common application components including Cassandra, Nginx, Apache Web Server, Elasticsearch, and many others.
Stackdriver ingests that data and generates insights via dashboards, charts, and alerts. Stackdriver alerting helps you collaborate by integrating with Slack, PagerDuty, HipChat, Campfire, and more.
OpenCensus Go has support for this exporter available through the package.Prometheus exporter for Stackdriver, allowing for Google Cloud metrics. You must have appropriate IAM permissions for this exporter to work. If you are passing in an IAM key then you must have:
- monitoring.metricDescriptors.list
- monitoring.timeSeries.list
This chart creates a Stackdriver-Exporter deployment on a Kubernetes cluster using the Helm package manager.
Prerequisites
- Kubernetes 1.8+ with Beta APIs enabled
Overview of Logs Exports
You can export copies of some or all of your logs outside of Stackdriver Logging. You might want to export logs for the following reasons:
To store logs for extended periods. Logging typically holds logs for weeks, not years. For more information, see the Quota Policy.
- To use big-data analysis tools on your logs.
- To stream your logs to other applications, other repositories, or third parties.
Overview of exports
Exporting involves writing a filter that selects the log entries you want to export, and choosing a destination in Cloud Storage, BigQuery, or Cloud Pub/Sub. The filter and destination are held in an object called a sink. Sinks can be created in projects, organizations, folders, and billing accounts.
There are no costs or limitations in Logging for exporting logs, but the export destinations charge for storing or transmitting the log data.
Sink properties and terminology
Sinks have the following properties:
Sink identifier: A name for the sink. For example, “my-vm-error-sink”.
Parent resource: The resource in which you create the sink. The parent is most often a project, but it can be any of the following:
“projects/[PROJECT_ID]”
“folders/[FOLDER_ID]”
“billingAccounts/[BILLINGACCOUNT_ID]”
“organizations/[ORGANIZATION_ID]”
The sink can only export logs that belong to its parent resource. For the one exception to this rule, see the following Aggregated Exports property.
How sinks work
Every time a log entry arrives in a project, folder, billing account, or organization resource, Logging compares the log entry to the sinks in that resource. Each sink whose filter matches the log entry writes a copy of the log entry to the sink’s export destination.
Since exporting happens for new log entries only, you cannot export log entries that Logging received before your sink was created.
Access control
To create or modify a sink, you must have the IAM roles Owner or Logging/Logs Configuration Writer in the sink’s parent resource. To view existing sinks, you must have the IAM roles Viewer or Logging/Logs Viewer in the sink’s parent resource. For more information, see Access Control.
To export logs to a destination, the sink’s writer service account must be permitted to write to the destination. For more information about writer identities, see the preceding section, Sink properties.
To secure exported logs from unauthorized access, you must use the access control features of your export destination. Sinks can export any log entries, including private Data Access audit logs.
Sources & further reading
Spotted something that needs another look?
Help improve this page →