Scrape Prometheus Metrics into InfluxDB with the Native Scraper (2026)

Prometheus metrics can be scraped directly into InfluxDB using its native scraping capabilities, eliminating the need for an intermediate Prometheus server and simplifying your monitoring stack.

Let’s see this in action. Imagine you have a simple Go application exposing metrics on port 9091 at the /metrics endpoint.

package main

import (
	"fmt"
	"net/http"

	"github.com/prometheus/client_golang/prometheus"
	"github.com/prometheus/client_golang/prometheus/promauto"
	"github.com/prometheus/client_golang/prometheus/promhttp"
)

var (
	httpRequestsTotal = promauto.NewCounter(prometheus.CounterOpts{
		Name: "myapp_http_requests_total",
		Help: "Total number of HTTP requests received.",
	})
)

func main() {
	http.Handle("/metrics", promhttp.Handler())
	http.HandleFunc("/", func(w http.ResponseWriter, r *http.Request) {
		httpRequestsTotal.Inc()
		fmt.Fprintf(w, "Hello, World!")
	})

	fmt.Println("Starting server on :9091")
	http.ListenAndServe(":9091", nil)
}

When you run this application and send a few requests to http://localhost:9091, the /metrics endpoint will serve data like this:

# HELP myapp_http_requests_total Total number of HTTP requests received.
# TYPE myapp_http_requests_total counter
myapp_http_requests_total 3

Now, the goal is to get these metrics into InfluxDB. We’ll configure InfluxDB to act as the scraper.

The core of this setup is InfluxDB’s "Scraper" configuration. This tells InfluxDB where to find metrics endpoints (like our Go app’s /metrics) and how to scrape them. You define these scrapers within InfluxDB itself, typically via its API or UI.

Here’s a sample InfluxDB scraper configuration, which you’d POST to your InfluxDB instance’s /api/v2/scrapers endpoint:

{
  "name": "my-app-scraper",
  "taskID": "0000000000000000",
  "organization": "my-org",
  "bucket": "metrics-bucket",
  "sources": {
    "prometheus": {
      "urls": ["http://localhost:9091/metrics"],
      "auth": null,
      "tlsConfig": null,
      "metricRelabelConfigs": [],
      "metricLabelAllowlist": [],
      "metricLabelBlocklist": []
    }
  },
  "schedule": "@every 1m"
}

Let’s break this down:

• name: A human-readable name for this scraper.
• organization: The InfluxDB organization where the metrics will be stored.
• bucket: The InfluxDB bucket to write the scraped metrics into.
• sources.prometheus.urls: This is the crucial part – the list of Prometheus-compatible endpoints to scrape. In our case, it’s http://localhost:9091/metrics.
• schedule: How often InfluxDB should perform the scrape. @every 1m means every minute.

Once this scraper is active, InfluxDB will periodically fetch the /metrics data from your application, parse it according to Prometheus exposition format, and write it into the specified metrics-bucket with the my-org organization. The data will appear as InfluxDB line protocol, ready for querying.

The schedule parameter uses a cron-like syntax. You can use @every 1m, @hourly, @daily, or specific cron expressions like 0 * * * * for hourly. The actual scraping interval is governed by this schedule, not by the scrape_interval Prometheus might otherwise use.

If your Prometheus endpoints require authentication, you can configure auth within the sources.prometheus block. This would typically involve basicAuth with username and password. For TLS, tlsConfig would be used.

The metricRelabelConfigs, metricLabelAllowlist, and metricLabelBlocklist provide powerful ways to filter and transform the metrics before they are written to InfluxDB. For example, you could use metricRelabelConfigs to drop certain metrics or add labels based on existing ones, much like you would in Prometheus itself.

The real magic here is that InfluxDB’s scraping engine is built to understand the Prometheus exposition format. It handles the HTTP requests, parses the # HELP and # TYPE directives, and translates the metrics into InfluxDB’s time-series data model. This means you don’t need to run a separate Prometheus server just to collect metrics from targets that expose them in the Prometheus format.

A common pitfall is assuming the scrape interval is dictated by the target application. InfluxDB’s scraper defines the frequency. If your InfluxDB scraper is set to @every 5m but your application’s metrics only update every minute, you’re effectively polling less often than possible. Conversely, if your scraper is @every 10s and your application’s metrics don’t change that rapidly, you’re just making redundant requests.

The next logical step is to explore how to visualize these scraped metrics using InfluxDB’s built-in dashboards or Grafana, connecting to your InfluxDB data source.