Documentation

Prometheus Output Plugin

This plugin starts a Prometheus client and exposes the written metrics on a /metrics endpoint by default. This endpoint can then be polled by a Prometheus server.

Introduced in: Telegraf v0.2.1 Tags: applications OS support: all

Use this plugin for Prometheus scraping

When Prometheus scrapes your Telegraf instance, use this plugin. It exposes a /metrics endpoint that Prometheus can poll directly.

For other Prometheus output scenarios, see the comparison table:

Use CaseRecommended Approach
Prometheus scrapes Telegrafprometheus_client output plugin
Counters and gauges to file/HTTPPrometheus serializer + file or http output
Histograms and summariesprometheus_client output plugin
Remote write to Prometheus-compatible endpointhttp output + prometheusremotewrite serializer

Use this plugin for histograms and summaries

Histogram and summary metrics accumulate observations over time. The prometheus serializer processes each batch independently and cannot maintain this state. When metric data spans multiple batches, the serializer produces incomplete output.

This plugin keeps metrics in memory until they expire or are scraped, ensuring complete and correct histogram buckets and summary quantiles.

For counters and gauges, you can use either this plugin or the prometheus serializer with an output plugin like file or http.

Global configuration options

Plugins support additional global and plugin configuration settings for tasks such as modifying metrics, tags, and fields, creating aliases, and configuring plugin ordering. See CONFIGURATION.md for more details.

Secret-store support

This plugin supports secrets from secret-stores for the basic_password option. See the secret-store documentation for more details on how to use them.

Configuration

# Configuration for the Prometheus client to spawn
[[outputs.prometheus_client]]
  ## Address to listen on.
  ##   ex:
  ##     listen = ":9273"
  ##     listen = "vsock://:9273"
  listen = ":9273"

  ## Maximum duration before timing out read of the request
  # read_timeout = "10s"
  ## Maximum duration before timing out write of the response
  # write_timeout = "10s"

  ## Metric version controls the mapping from Prometheus metrics into Telegraf metrics.
  ## See "Metric Format Configuration" in plugins/inputs/prometheus/README.md for details.
  ## Valid options: 1, 2
  # metric_version = 1

  ## Use HTTP Basic Authentication.
  # basic_username = "Foo"
  # basic_password = "Bar"

  ## If set, the IP Ranges which are allowed to access metrics.
  ##   ex: ip_range = ["192.168.0.0/24", "192.168.1.0/30"]
  # ip_range = []

  ## Path to publish the metrics on.
  # path = "/metrics"

  ## Expiration interval for each metric. 0 == no expiration
  # expiration_interval = "60s"

  ## Collectors to enable, valid entries are "gocollector" and "process".
  ## If unset, both are enabled.
  # collectors_exclude = ["gocollector", "process"]

  ## Send string metrics as Prometheus labels.
  ## Unless set to false all string metrics will be sent as labels.
  # string_as_label = true

  ## If set, enable TLS with the given certificate.
  # tls_cert = "/etc/ssl/telegraf.crt"
  # tls_key = "/etc/ssl/telegraf.key"

  ## Set one or more allowed client CA certificate file names to
  ## enable mutually authenticated TLS connections
  # tls_allowed_cacerts = ["/etc/telegraf/clientca.pem"]

  ## Export metric collection time.
  # export_timestamp = false

  ## Set custom headers for HTTP responses.
  # http_headers = {"X-Special-Header" = "Special-Value"}

  ## Specify the metric type explicitly.
  ## This overrides the metric-type of the Telegraf metric. Globbing is allowed.
  # [outputs.prometheus_client.metric_types]
  #   counter = []
  #   gauge = []

Metrics

Prometheus metrics are produced in the same manner as the prometheus serializer.


Was this page helpful?

Thank you for your feedback!


New in InfluxDB 3.8

Key enhancements in InfluxDB 3.8 and the InfluxDB 3 Explorer 1.6.

See the Blog Post

InfluxDB 3.8 is now available for both Core and Enterprise, alongside the 1.6 release of the InfluxDB 3 Explorer UI. This release is focused on operational maturity and making InfluxDB easier to deploy, manage, and run reliably in production.

For more information, check out:

InfluxDB Docker latest tag changing to InfluxDB 3 Core

On February 3, 2026, the latest tag for InfluxDB Docker images will point to InfluxDB 3 Core. To avoid unexpected upgrades, use specific version tags in your Docker deployments.

If using Docker to install and run InfluxDB, the latest tag will point to InfluxDB 3 Core. To avoid unexpected upgrades, use specific version tags in your Docker deployments. For example, if using Docker to run InfluxDB v2, replace the latest version tag with a specific version tag in your Docker pull command–for example:

docker pull influxdb:2