The historical prometheus-to-sd package bridged components exposing Prometheus-format measurements to Google’s monitoring service, formerly called Stackdriver. It scraped selected endpoints and forwarded their metrics. Its upstream now explicitly limits the component’s intended role to Google’s internal Kubernetes system-service monitoring, so it is not an appropriate general-purpose starting point for a new application pipeline. Teams replacing a user-installed bridge should choose a supported collection path and preserve metric identities and alert behavior during the move.
Current guidance
The historical chart exposed prometheus-to-sd as a general bridge from Prometheus text metrics to Stackdriver. Its own current README is more restrictive: the component exists for Google’s Kubernetes system-service metrics and is not intended for end users. That scope warning matters more than whether an old image still runs.
For application monitoring, evaluate Google Cloud’s supported Prometheus collection paths instead. Managed Service for Prometheus separates collection, storage/querying and rule evaluation, with options for managed collectors, self-deployed collectors and OpenTelemetry. Choose the model that fits your Kubernetes environment and operational ownership; it is not a transparent image replacement for the old bridge.
Inventory metric names, monitored-resource labels, project identity, IAM permissions and alert queries before changing collection. Run a small parallel comparison, account for duplicate ingestion and cost, and check missing/delayed samples. Do not remove a Google-managed system component just because a similarly named chart is obsolete. This recommendation concerns user-installed application pipelines; no GKE control-plane or production telemetry migration was performed here.
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.
Prometheus-to-sd is a simple component that can scrape metrics stored in prometheus text format from one or multiple components and push them to the Stackdriver. Main requirement: k8s cluster should run on GCE or GKE.
Usage
For scraping metrics from the component it’s name, host, port and metrics should passed through the flag source in the next format: component-name:http://host:port?whitelisted=a,b,c. If whitelisted part is omitted, then all metrics that are scraped from the component will be pushed to the Stackdriver.
Metrics autodiscovery
If metric descriptors already exist on the Stackdriver (created manually or by different component) then autodiscovery feature could be used. In such case prometheus-to-sd will push metrics for which metric descriptors are available on the Stackdriver. To use this feature a flag auto-whitelist-metrics=true has to be passed.
Scrape interval vs. export interval
There are two flags: scrape-interval and export-interval that allow specifying how often metrics are read from the sources and how often they are exported to Stackdriver, respectively. By default both are set to 1m. The scrapes can be more frequent than exports, however, to achieve grater precision for metrics being exported. For example, if metrics are exported once every minute and a container dies between scrapes, up to 1 minutes of metrics can be lost. Frequent scrapes mitigate that, at the cost of elevated resource usage.
Sources & further reading
Spotted something that needs another look?
Help improve this page →