1--- 2title: Configuration 3sort_rank: 1 4--- 5 6# Configuration 7 8Prometheus is configured via command-line flags and a configuration file. While 9the command-line flags configure immutable system parameters (such as storage 10locations, amount of data to keep on disk and in memory, etc.), the 11configuration file defines everything related to scraping [jobs and their 12instances](https://prometheus.io/docs/concepts/jobs_instances/), as well as 13which [rule files to load](recording_rules.md#configuring-rules). 14 15To view all available command-line flags, run `./prometheus -h`. 16 17Prometheus can reload its configuration at runtime. If the new configuration 18is not well-formed, the changes will not be applied. 19A configuration reload is triggered by sending a `SIGHUP` to the Prometheus process or 20sending a HTTP POST request to the `/-/reload` endpoint (when the `--web.enable-lifecycle` flag is enabled). 21This will also reload any configured rule files. 22 23## Configuration file 24 25To specify which configuration file to load, use the `--config.file` flag. 26 27The file is written in [YAML format](http://en.wikipedia.org/wiki/YAML), 28defined by the scheme described below. 29Brackets indicate that a parameter is optional. For non-list parameters the 30value is set to the specified default. 31 32Generic placeholders are defined as follows: 33 34* `<boolean>`: a boolean that can take the values `true` or `false` 35* `<duration>`: a duration matching the regular expression `[0-9]+(ms|[smhdwy])` 36* `<labelname>`: a string matching the regular expression `[a-zA-Z_][a-zA-Z0-9_]*` 37* `<labelvalue>`: a string of unicode characters 38* `<filename>`: a valid path in the current working directory 39* `<host>`: a valid string consisting of a hostname or IP followed by an optional port number 40* `<path>`: a valid URL path 41* `<scheme>`: a string that can take the values `http` or `https` 42* `<string>`: a regular string 43* `<secret>`: a regular string that is a secret, such as a password 44* `<tmpl_string>`: a string which is template-expanded before usage 45 46The other placeholders are specified separately. 47 48A valid example file can be found [here](/config/testdata/conf.good.yml). 49 50The global configuration specifies parameters that are valid in all other configuration 51contexts. They also serve as defaults for other configuration sections. 52 53```yaml 54global: 55 # How frequently to scrape targets by default. 56 [ scrape_interval: <duration> | default = 1m ] 57 58 # How long until a scrape request times out. 59 [ scrape_timeout: <duration> | default = 10s ] 60 61 # How frequently to evaluate rules. 62 [ evaluation_interval: <duration> | default = 1m ] 63 64 # The labels to add to any time series or alerts when communicating with 65 # external systems (federation, remote storage, Alertmanager). 66 external_labels: 67 [ <labelname>: <labelvalue> ... ] 68 69# Rule files specifies a list of globs. Rules and alerts are read from 70# all matching files. 71rule_files: 72 [ - <filepath_glob> ... ] 73 74# A list of scrape configurations. 75scrape_configs: 76 [ - <scrape_config> ... ] 77 78# Alerting specifies settings related to the Alertmanager. 79alerting: 80 alert_relabel_configs: 81 [ - <relabel_config> ... ] 82 alertmanagers: 83 [ - <alertmanager_config> ... ] 84 85# Settings related to the remote write feature. 86remote_write: 87 [ - <remote_write> ... ] 88 89# Settings related to the remote read feature. 90remote_read: 91 [ - <remote_read> ... ] 92``` 93 94### `<scrape_config>` 95 96A `scrape_config` section specifies a set of targets and parameters describing how 97to scrape them. In the general case, one scrape configuration specifies a single 98job. In advanced configurations, this may change. 99 100Targets may be statically configured via the `static_configs` parameter or 101dynamically discovered using one of the supported service-discovery mechanisms. 102 103Additionally, `relabel_configs` allow advanced modifications to any 104target and its labels before scraping. 105 106```yaml 107# The job name assigned to scraped metrics by default. 108job_name: <job_name> 109 110# How frequently to scrape targets from this job. 111[ scrape_interval: <duration> | default = <global_config.scrape_interval> ] 112 113# Per-scrape timeout when scraping this job. 114[ scrape_timeout: <duration> | default = <global_config.scrape_timeout> ] 115 116# The HTTP resource path on which to fetch metrics from targets. 117[ metrics_path: <path> | default = /metrics ] 118 119# honor_labels controls how Prometheus handles conflicts between labels that are 120# already present in scraped data and labels that Prometheus would attach 121# server-side ("job" and "instance" labels, manually configured target 122# labels, and labels generated by service discovery implementations). 123# 124# If honor_labels is set to "true", label conflicts are resolved by keeping label 125# values from the scraped data and ignoring the conflicting server-side labels. 126# 127# If honor_labels is set to "false", label conflicts are resolved by renaming 128# conflicting labels in the scraped data to "exported_<original-label>" (for 129# example "exported_instance", "exported_job") and then attaching server-side 130# labels. This is useful for use cases such as federation, where all labels 131# specified in the target should be preserved. 132# 133# Note that any globally configured "external_labels" are unaffected by this 134# setting. In communication with external systems, they are always applied only 135# when a time series does not have a given label yet and are ignored otherwise. 136[ honor_labels: <boolean> | default = false ] 137 138# Configures the protocol scheme used for requests. 139[ scheme: <scheme> | default = http ] 140 141# Optional HTTP URL parameters. 142params: 143 [ <string>: [<string>, ...] ] 144 145# Sets the `Authorization` header on every scrape request with the 146# configured username and password. 147# password and password_file are mutually exclusive. 148basic_auth: 149 [ username: <string> ] 150 [ password: <secret> ] 151 [ password_file: <string> ] 152 153# Sets the `Authorization` header on every scrape request with 154# the configured bearer token. It is mutually exclusive with `bearer_token_file`. 155[ bearer_token: <secret> ] 156 157# Sets the `Authorization` header on every scrape request with the bearer token 158# read from the configured file. It is mutually exclusive with `bearer_token`. 159[ bearer_token_file: /path/to/bearer/token/file ] 160 161# Configures the scrape request's TLS settings. 162tls_config: 163 [ <tls_config> ] 164 165# Optional proxy URL. 166[ proxy_url: <string> ] 167 168# List of Azure service discovery configurations. 169azure_sd_configs: 170 [ - <azure_sd_config> ... ] 171 172# List of Consul service discovery configurations. 173consul_sd_configs: 174 [ - <consul_sd_config> ... ] 175 176# List of DNS service discovery configurations. 177dns_sd_configs: 178 [ - <dns_sd_config> ... ] 179 180# List of EC2 service discovery configurations. 181ec2_sd_configs: 182 [ - <ec2_sd_config> ... ] 183 184# List of OpenStack service discovery configurations. 185openstack_sd_configs: 186 [ - <openstack_sd_config> ... ] 187 188# List of file service discovery configurations. 189file_sd_configs: 190 [ - <file_sd_config> ... ] 191 192# List of GCE service discovery configurations. 193gce_sd_configs: 194 [ - <gce_sd_config> ... ] 195 196# List of Kubernetes service discovery configurations. 197kubernetes_sd_configs: 198 [ - <kubernetes_sd_config> ... ] 199 200# List of Marathon service discovery configurations. 201marathon_sd_configs: 202 [ - <marathon_sd_config> ... ] 203 204# List of AirBnB's Nerve service discovery configurations. 205nerve_sd_configs: 206 [ - <nerve_sd_config> ... ] 207 208# List of Zookeeper Serverset service discovery configurations. 209serverset_sd_configs: 210 [ - <serverset_sd_config> ... ] 211 212# List of Triton service discovery configurations. 213triton_sd_configs: 214 [ - <triton_sd_config> ... ] 215 216# List of labeled statically configured targets for this job. 217static_configs: 218 [ - <static_config> ... ] 219 220# List of target relabel configurations. 221relabel_configs: 222 [ - <relabel_config> ... ] 223 224# List of metric relabel configurations. 225metric_relabel_configs: 226 [ - <relabel_config> ... ] 227 228# Per-scrape limit on number of scraped samples that will be accepted. 229# If more than this number of samples are present after metric relabelling 230# the entire scrape will be treated as failed. 0 means no limit. 231[ sample_limit: <int> | default = 0 ] 232``` 233 234Where `<job_name>` must be unique across all scrape configurations. 235 236### `<tls_config>` 237 238A `tls_config` allows configuring TLS connections. 239 240```yaml 241# CA certificate to validate API server certificate with. 242[ ca_file: <filename> ] 243 244# Certificate and key files for client cert authentication to the server. 245[ cert_file: <filename> ] 246[ key_file: <filename> ] 247 248# ServerName extension to indicate the name of the server. 249# http://tools.ietf.org/html/rfc4366#section-3.1 250[ server_name: <string> ] 251 252# Disable validation of the server certificate. 253[ insecure_skip_verify: <boolean> ] 254``` 255 256### `<azure_sd_config>` 257 258Azure SD configurations allow retrieving scrape targets from Azure VMs. 259 260The following meta labels are available on targets during relabeling: 261 262* `__meta_azure_machine_id`: the machine ID 263* `__meta_azure_machine_location`: the location the machine runs in 264* `__meta_azure_machine_name`: the machine name 265* `__meta_azure_machine_os_type`: the machine operating system 266* `__meta_azure_machine_private_ip`: the machine's private IP 267* `__meta_azure_machine_resource_group`: the machine's resource group 268* `__meta_azure_machine_tag_<tagname>`: each tag value of the machine 269* `__meta_azure_machine_scale_set`: the name of the scale set which the vm is part of (this value is only set if you are using a [scale set](https://docs.microsoft.com/en-us/azure/virtual-machine-scale-sets/)) 270 271See below for the configuration options for Azure discovery: 272 273```yaml 274# The information to access the Azure API. 275# The Azure environment. 276[ environment: <string> | default = AzurePublicCloud ] 277# The subscription ID. 278subscription_id: <string> 279# The tenant ID. 280tenant_id: <string> 281# The client ID. 282client_id: <string> 283# The client secret. 284client_secret: <secret> 285 286# Refresh interval to re-read the instance list. 287[ refresh_interval: <duration> | default = 300s ] 288 289# The port to scrape metrics from. If using the public IP address, this must 290# instead be specified in the relabeling rule. 291[ port: <int> | default = 80 ] 292``` 293 294### `<consul_sd_config>` 295 296Consul SD configurations allow retrieving scrape targets from [Consul's](https://www.consul.io) 297Catalog API. 298 299The following meta labels are available on targets during [relabeling](#relabel_config): 300 301* `__meta_consul_address`: the address of the target 302* `__meta_consul_dc`: the datacenter name for the target 303* `__meta_consul_metadata_<key>`: each node metadata key value of the target 304* `__meta_consul_node`: the node name defined for the target 305* `__meta_consul_service_address`: the service address of the target 306* `__meta_consul_service_id`: the service ID of the target 307* `__meta_consul_service_metadata_<key>`: each service metadata key value of the target 308* `__meta_consul_service_port`: the service port of the target 309* `__meta_consul_service`: the name of the service the target belongs to 310* `__meta_consul_tags`: the list of tags of the target joined by the tag separator 311 312```yaml 313# The information to access the Consul API. It is to be defined 314# as the Consul documentation requires. 315[ server: <host> | default = "localhost:8500" ] 316[ token: <secret> ] 317[ datacenter: <string> ] 318[ scheme: <string> | default = "http" ] 319[ username: <string> ] 320[ password: <secret> ] 321 322tls_config: 323 [ <tls_config> ] 324 325# A list of services for which targets are retrieved. If omitted, all services 326# are scraped. 327services: 328 [ - <string> ] 329 330# See https://www.consul.io/api/catalog.html#list-nodes-for-service to know more 331# about the possible filters that can be used. 332 333# An optional tag used to filter nodes for a given service. 334[ tag: <string> ] 335 336# Node metadata used to filter nodes for a given service. 337[ node_meta: 338 [ <name>: <value> ... ] ] 339 340# The string by which Consul tags are joined into the tag label. 341[ tag_separator: <string> | default = , ] 342 343# Allow stale Consul results (see https://www.consul.io/api/index.html#consistency-modes). Will reduce load on Consul. 344[ allow_stale: <bool> ] 345 346# The time after which the provided names are refreshed. 347# On large setup it might be a good idea to increase this value because the catalog will change all the time. 348[ refresh_interval: <duration> | default = 30s ] 349``` 350 351Note that the IP number and port used to scrape the targets is assembled as 352`<__meta_consul_address>:<__meta_consul_service_port>`. However, in some 353Consul setups, the relevant address is in `__meta_consul_service_address`. 354In those cases, you can use the [relabel](#relabel_config) 355feature to replace the special `__address__` label. 356 357The [relabeling phase](#relabel_config) is the preferred and more powerful 358way to filter services or nodes for a service based on arbitrary labels. For 359users with thousands of services it can be more efficient to use the Consul API 360directly which has basic support for filtering nodes (currently by node 361metadata and a single tag). 362 363### `<dns_sd_config>` 364 365A DNS-based service discovery configuration allows specifying a set of DNS 366domain names which are periodically queried to discover a list of targets. The 367DNS servers to be contacted are read from `/etc/resolv.conf`. 368 369This service discovery method only supports basic DNS A, AAAA and SRV record 370queries, but not the advanced DNS-SD approach specified in 371[RFC6763](https://tools.ietf.org/html/rfc6763). 372 373During the [relabeling phase](#relabel_config), the meta label 374`__meta_dns_name` is available on each target and is set to the 375record name that produced the discovered target. 376 377```yaml 378# A list of DNS domain names to be queried. 379names: 380 [ - <domain_name> ] 381 382# The type of DNS query to perform. 383[ type: <query_type> | default = 'SRV' ] 384 385# The port number used if the query type is not SRV. 386[ port: <number>] 387 388# The time after which the provided names are refreshed. 389[ refresh_interval: <duration> | default = 30s ] 390``` 391 392Where `<domain_name>` is a valid DNS domain name. 393Where `<query_type>` is `SRV`, `A`, or `AAAA`. 394 395### `<ec2_sd_config>` 396 397EC2 SD configurations allow retrieving scrape targets from AWS EC2 398instances. The private IP address is used by default, but may be changed to 399the public IP address with relabeling. 400 401The following meta labels are available on targets during [relabeling](#relabel_config): 402 403* `__meta_ec2_availability_zone`: the availability zone in which the instance is running 404* `__meta_ec2_instance_id`: the EC2 instance ID 405* `__meta_ec2_instance_state`: the state of the EC2 instance 406* `__meta_ec2_instance_type`: the type of the EC2 instance 407* `__meta_ec2_owner_id`: the ID of the AWS account that owns the EC2 instance 408* `__meta_ec2_platform`: the Operating System platform, set to 'windows' on Windows servers, absent otherwise 409* `__meta_ec2_primary_subnet_id`: the subnet ID of the primary network interface, if available 410* `__meta_ec2_private_dns_name`: the private DNS name of the instance, if available 411* `__meta_ec2_private_ip`: the private IP address of the instance, if present 412* `__meta_ec2_public_dns_name`: the public DNS name of the instance, if available 413* `__meta_ec2_public_ip`: the public IP address of the instance, if available 414* `__meta_ec2_subnet_id`: comma separated list of subnets IDs in which the instance is running, if available 415* `__meta_ec2_tag_<tagkey>`: each tag value of the instance 416* `__meta_ec2_vpc_id`: the ID of the VPC in which the instance is running, if available 417 418See below for the configuration options for EC2 discovery: 419 420```yaml 421# The information to access the EC2 API. 422 423# The AWS Region. 424region: <string> 425 426# Custom endpoint to be used. 427[ endpoint: <string> ] 428 429# The AWS API keys. If blank, the environment variables `AWS_ACCESS_KEY_ID` 430# and `AWS_SECRET_ACCESS_KEY` are used. 431[ access_key: <string> ] 432[ secret_key: <secret> ] 433# Named AWS profile used to connect to the API. 434[ profile: <string> ] 435 436# AWS Role ARN, an alternative to using AWS API keys. 437[ role_arn: <string> ] 438 439# Refresh interval to re-read the instance list. 440[ refresh_interval: <duration> | default = 60s ] 441 442# The port to scrape metrics from. If using the public IP address, this must 443# instead be specified in the relabeling rule. 444[ port: <int> | default = 80 ] 445 446# Filters can be used optionally to filter the instance list by other criteria. 447# Available filter criteria can be found here: 448# https://docs.aws.amazon.com/AWSEC2/latest/APIReference/API_DescribeInstances.html 449# Filter API documentation: https://docs.aws.amazon.com/AWSEC2/latest/APIReference/API_Filter.html 450filters: 451 [ - name: <string> 452 values: <string>, [...] ] 453``` 454 455The [relabeling phase](#relabel_config) is the preferred and more powerful 456way to filter targets based on arbitrary labels. For users with thousands of 457instances it can be more efficient to use the EC2 API directly which has 458support for filtering instances. 459 460### `<openstack_sd_config>` 461 462OpenStack SD configurations allow retrieving scrape targets from OpenStack Nova 463instances. 464 465One of the following `<openstack_role>` types can be configured to discover targets: 466 467#### `hypervisor` 468 469The `hypervisor` role discovers one target per Nova hypervisor node. The target 470address defaults to the `host_ip` attribute of the hypervisor. 471 472The following meta labels are available on targets during [relabeling](#relabel_config): 473 474* `__meta_openstack_hypervisor_host_ip`: the hypervisor node's IP address. 475* `__meta_openstack_hypervisor_name`: the hypervisor node's name. 476* `__meta_openstack_hypervisor_state`: the hypervisor node's state. 477* `__meta_openstack_hypervisor_status`: the hypervisor node's status. 478* `__meta_openstack_hypervisor_type`: the hypervisor node's type. 479 480#### `instance` 481 482The `instance` role discovers one target per network interface of Nova 483instance. The target address defaults to the private IP address of the network 484interface. 485 486The following meta labels are available on targets during [relabeling](#relabel_config): 487 488* `__meta_openstack_instance_id`: the OpenStack instance ID. 489* `__meta_openstack_instance_name`: the OpenStack instance name. 490* `__meta_openstack_instance_status`: the status of the OpenStack instance. 491* `__meta_openstack_instance_flavor`: the flavor of the OpenStack instance. 492* `__meta_openstack_public_ip`: the public IP of the OpenStack instance. 493* `__meta_openstack_private_ip`: the private IP of the OpenStack instance. 494* `__meta_openstack_address_pool`: the pool of the private IP. 495* `__meta_openstack_tag_<tagkey>`: each tag value of the instance. 496 497See below for the configuration options for OpenStack discovery: 498 499```yaml 500# The information to access the OpenStack API. 501 502# The OpenStack role of entities that should be discovered. 503role: <openstack_role> 504 505# The OpenStack Region. 506region: <string> 507 508# identity_endpoint specifies the HTTP endpoint that is required to work with 509# the Identity API of the appropriate version. While it's ultimately needed by 510# all of the identity services, it will often be populated by a provider-level 511# function. 512[ identity_endpoint: <string> ] 513 514# username is required if using Identity V2 API. Consult with your provider's 515# control panel to discover your account's username. In Identity V3, either 516# userid or a combination of username and domain_id or domain_name are needed. 517[ username: <string> ] 518[ userid: <string> ] 519 520# password for the Identity V2 and V3 APIs. Consult with your provider's 521# control panel to discover your account's preferred method of authentication. 522[ password: <secret> ] 523 524# At most one of domain_id and domain_name must be provided if using username 525# with Identity V3. Otherwise, either are optional. 526[ domain_name: <string> ] 527[ domain_id: <string> ] 528 529# The project_id and project_name fields are optional for the Identity V2 API. 530# Some providers allow you to specify a project_name instead of the project_id. 531# Some require both. Your provider's authentication policies will determine 532# how these fields influence authentication. 533[ project_name: <string> ] 534[ project_id: <string> ] 535 536# Whether the service discovery should list all instances for all projects. 537# It is only relevant for the 'instance' role and usually requires admin permissions. 538[ all_tenants: <boolean> | default: false ] 539 540# Refresh interval to re-read the instance list. 541[ refresh_interval: <duration> | default = 60s ] 542 543# The port to scrape metrics from. If using the public IP address, this must 544# instead be specified in the relabeling rule. 545[ port: <int> | default = 80 ] 546 547# TLS configuration. 548tls_config: 549 [ <tls_config> ] 550``` 551 552### `<file_sd_config>` 553 554File-based service discovery provides a more generic way to configure static targets 555and serves as an interface to plug in custom service discovery mechanisms. 556 557It reads a set of files containing a list of zero or more 558`<static_config>`s. Changes to all defined files are detected via disk watches 559and applied immediately. Files may be provided in YAML or JSON format. Only 560changes resulting in well-formed target groups are applied. 561 562The JSON file must contain a list of static configs, using this format: 563 564```yaml 565[ 566 { 567 "targets": [ "<host>", ... ], 568 "labels": { 569 "<labelname>": "<labelvalue>", ... 570 } 571 }, 572 ... 573] 574``` 575 576As a fallback, the file contents are also re-read periodically at the specified 577refresh interval. 578 579Each target has a meta label `__meta_filepath` during the 580[relabeling phase](#relabel_config). Its value is set to the 581filepath from which the target was extracted. 582 583There is a list of 584[integrations](https://prometheus.io/docs/operating/integrations/#file-service-discovery) with this 585discovery mechanism. 586 587```yaml 588# Patterns for files from which target groups are extracted. 589files: 590 [ - <filename_pattern> ... ] 591 592# Refresh interval to re-read the files. 593[ refresh_interval: <duration> | default = 5m ] 594``` 595 596Where `<filename_pattern>` may be a path ending in `.json`, `.yml` or `.yaml`. The last path segment 597may contain a single `*` that matches any character sequence, e.g. `my/path/tg_*.json`. 598 599### `<gce_sd_config>` 600 601[GCE](https://cloud.google.com/compute/) SD configurations allow retrieving scrape targets from GCP GCE instances. 602The private IP address is used by default, but may be changed to the public IP 603address with relabeling. 604 605The following meta labels are available on targets during [relabeling](#relabel_config): 606 607* `__meta_gce_instance_id`: the numeric id of the instance 608* `__meta_gce_instance_name`: the name of the instance 609* `__meta_gce_label_<name>`: each GCE label of the instance 610* `__meta_gce_machine_type`: full or partial URL of the machine type of the instance 611* `__meta_gce_metadata_<name>`: each metadata item of the instance 612* `__meta_gce_network`: the network URL of the instance 613* `__meta_gce_private_ip`: the private IP address of the instance 614* `__meta_gce_project`: the GCP project in which the instance is running 615* `__meta_gce_public_ip`: the public IP address of the instance, if present 616* `__meta_gce_subnetwork`: the subnetwork URL of the instance 617* `__meta_gce_tags`: comma separated list of instance tags 618* `__meta_gce_zone`: the GCE zone URL in which the instance is running 619 620See below for the configuration options for GCE discovery: 621 622```yaml 623# The information to access the GCE API. 624 625# The GCP Project 626project: <string> 627 628# The zone of the scrape targets. If you need multiple zones use multiple 629# gce_sd_configs. 630zone: <string> 631 632# Filter can be used optionally to filter the instance list by other criteria 633# Syntax of this filter string is described here in the filter query parameter section: 634# https://cloud.google.com/compute/docs/reference/latest/instances/list 635[ filter: <string> ] 636 637# Refresh interval to re-read the instance list 638[ refresh_interval: <duration> | default = 60s ] 639 640# The port to scrape metrics from. If using the public IP address, this must 641# instead be specified in the relabeling rule. 642[ port: <int> | default = 80 ] 643 644# The tag separator is used to separate the tags on concatenation 645[ tag_separator: <string> | default = , ] 646``` 647 648Credentials are discovered by the Google Cloud SDK default client by looking 649in the following places, preferring the first location found: 650 6511. a JSON file specified by the `GOOGLE_APPLICATION_CREDENTIALS` environment variable 6522. a JSON file in the well-known path `$HOME/.config/gcloud/application_default_credentials.json` 6533. fetched from the GCE metadata server 654 655If Prometheus is running within GCE, the service account associated with the 656instance it is running on should have at least read-only permissions to the 657compute resources. If running outside of GCE make sure to create an appropriate 658service account and place the credential file in one of the expected locations. 659 660### `<kubernetes_sd_config>` 661 662Kubernetes SD configurations allow retrieving scrape targets from 663[Kubernetes'](http://kubernetes.io/) REST API and always staying synchronized with 664the cluster state. 665 666One of the following `role` types can be configured to discover targets: 667 668#### `node` 669 670The `node` role discovers one target per cluster node with the address defaulting 671to the Kubelet's HTTP port. 672The target address defaults to the first existing address of the Kubernetes 673node object in the address type order of `NodeInternalIP`, `NodeExternalIP`, 674`NodeLegacyHostIP`, and `NodeHostName`. 675 676Available meta labels: 677 678* `__meta_kubernetes_node_name`: The name of the node object. 679* `__meta_kubernetes_node_label_<labelname>`: Each label from the node object. 680* `__meta_kubernetes_node_annotation_<annotationname>`: Each annotation from the node object. 681* `__meta_kubernetes_node_address_<address_type>`: The first address for each node address type, if it exists. 682 683In addition, the `instance` label for the node will be set to the node name 684as retrieved from the API server. 685 686#### `service` 687 688The `service` role discovers a target for each service port for each service. 689This is generally useful for blackbox monitoring of a service. 690The address will be set to the Kubernetes DNS name of the service and respective 691service port. 692 693Available meta labels: 694 695* `__meta_kubernetes_namespace`: The namespace of the service object. 696* `__meta_kubernetes_service_name`: The name of the service object. 697* `__meta_kubernetes_service_label_<labelname>`: The label of the service object. 698* `__meta_kubernetes_service_annotation_<annotationname>`: The annotation of the service object. 699* `__meta_kubernetes_service_port_name`: Name of the service port for the target. 700* `__meta_kubernetes_service_port_number`: Number of the service port for the target. 701* `__meta_kubernetes_service_port_protocol`: Protocol of the service port for the target. 702 703#### `pod` 704 705The `pod` role discovers all pods and exposes their containers as targets. For each declared 706port of a container, a single target is generated. If a container has no specified ports, 707a port-free target per container is created for manually adding a port via relabeling. 708 709Available meta labels: 710 711* `__meta_kubernetes_namespace`: The namespace of the pod object. 712* `__meta_kubernetes_pod_name`: The name of the pod object. 713* `__meta_kubernetes_pod_ip`: The pod IP of the pod object. 714* `__meta_kubernetes_pod_label_<labelname>`: The label of the pod object. 715* `__meta_kubernetes_pod_annotation_<annotationname>`: The annotation of the pod object. 716* `__meta_kubernetes_pod_container_name`: Name of the container the target address points to. 717* `__meta_kubernetes_pod_container_port_name`: Name of the container port. 718* `__meta_kubernetes_pod_container_port_number`: Number of the container port. 719* `__meta_kubernetes_pod_container_port_protocol`: Protocol of the container port. 720* `__meta_kubernetes_pod_ready`: Set to `true` or `false` for the pod's ready state. 721* `__meta_kubernetes_pod_phase`: Set to `Pending`, `Running`, `Succeeded`, `Failed` or `Unknown` 722 in the [lifecycle](https://kubernetes.io/docs/concepts/workloads/pods/pod-lifecycle/#pod-phase). 723* `__meta_kubernetes_pod_node_name`: The name of the node the pod is scheduled onto. 724* `__meta_kubernetes_pod_host_ip`: The current host IP of the pod object. 725* `__meta_kubernetes_pod_uid`: The UID of the pod object. 726* `__meta_kubernetes_pod_controller_kind`: Object kind of the pod controller. 727* `__meta_kubernetes_pod_controller_name`: Name of the pod controller. 728 729#### `endpoints` 730 731The `endpoints` role discovers targets from listed endpoints of a service. For each endpoint 732address one target is discovered per port. If the endpoint is backed by a pod, all 733additional container ports of the pod, not bound to an endpoint port, are discovered as targets as well. 734 735Available meta labels: 736 737* `__meta_kubernetes_namespace`: The namespace of the endpoints object. 738* `__meta_kubernetes_endpoints_name`: The names of the endpoints object. 739* For all targets discovered directly from the endpoints list (those not additionally inferred 740 from underlying pods), the following labels are attached: 741 * `__meta_kubernetes_endpoint_ready`: Set to `true` or `false` for the endpoint's ready state. 742 * `__meta_kubernetes_endpoint_port_name`: Name of the endpoint port. 743 * `__meta_kubernetes_endpoint_port_protocol`: Protocol of the endpoint port. 744 * `__meta_kubernetes_endpoint_address_target_kind`: Kind of the endpoint address target. 745 * `__meta_kubernetes_endpoint_address_target_name`: Name of the endpoint address target. 746* If the endpoints belong to a service, all labels of the `role: service` discovery are attached. 747* For all targets backed by a pod, all labels of the `role: pod` discovery are attached. 748 749#### `ingress` 750 751The `ingress` role discovers a target for each path of each ingress. 752This is generally useful for blackbox monitoring of an ingress. 753The address will be set to the host specified in the ingress spec. 754 755Available meta labels: 756 757* `__meta_kubernetes_namespace`: The namespace of the ingress object. 758* `__meta_kubernetes_ingress_name`: The name of the ingress object. 759* `__meta_kubernetes_ingress_label_<labelname>`: The label of the ingress object. 760* `__meta_kubernetes_ingress_annotation_<annotationname>`: The annotation of the ingress object. 761* `__meta_kubernetes_ingress_scheme`: Protocol scheme of ingress, `https` if TLS 762 config is set. Defaults to `http`. 763* `__meta_kubernetes_ingress_path`: Path from ingress spec. Defaults to `/`. 764 765See below for the configuration options for Kubernetes discovery: 766 767```yaml 768# The information to access the Kubernetes API. 769 770# The API server addresses. If left empty, Prometheus is assumed to run inside 771# of the cluster and will discover API servers automatically and use the pod's 772# CA certificate and bearer token file at /var/run/secrets/kubernetes.io/serviceaccount/. 773[ api_server: <host> ] 774 775# The Kubernetes role of entities that should be discovered. 776role: <role> 777 778# Optional authentication information used to authenticate to the API server. 779# Note that `basic_auth`, `bearer_token` and `bearer_token_file` options are 780# mutually exclusive. 781# password and password_file are mutually exclusive. 782 783# Optional HTTP basic authentication information. 784basic_auth: 785 [ username: <string> ] 786 [ password: <secret> ] 787 [ password_file: <string> ] 788 789# Optional bearer token authentication information. 790[ bearer_token: <secret> ] 791 792# Optional bearer token file authentication information. 793[ bearer_token_file: <filename> ] 794 795# TLS configuration. 796tls_config: 797 [ <tls_config> ] 798 799# Optional namespace discovery. If omitted, all namespaces are used. 800namespaces: 801 names: 802 [ - <string> ] 803``` 804 805Where `<role>` must be `endpoints`, `service`, `pod`, `node`, or 806`ingress`. 807 808See [this example Prometheus configuration file](/documentation/examples/prometheus-kubernetes.yml) 809for a detailed example of configuring Prometheus for Kubernetes. 810 811You may wish to check out the 3rd party [Prometheus Operator](https://github.com/coreos/prometheus-operator), 812which automates the Prometheus setup on top of Kubernetes. 813 814### `<marathon_sd_config>` 815 816Marathon SD configurations allow retrieving scrape targets using the 817[Marathon](https://mesosphere.github.io/marathon/) REST API. Prometheus 818will periodically check the REST endpoint for currently running tasks and 819create a target group for every app that has at least one healthy task. 820 821The following meta labels are available on targets during [relabeling](#relabel_config): 822 823* `__meta_marathon_app`: the name of the app (with slashes replaced by dashes) 824* `__meta_marathon_image`: the name of the Docker image used (if available) 825* `__meta_marathon_task`: the ID of the Mesos task 826* `__meta_marathon_app_label_<labelname>`: any Marathon labels attached to the app 827* `__meta_marathon_port_definition_label_<labelname>`: the port definition labels 828* `__meta_marathon_port_mapping_label_<labelname>`: the port mapping labels 829* `__meta_marathon_port_index`: the port index number (e.g. `1` for `PORT1`) 830 831See below for the configuration options for Marathon discovery: 832 833```yaml 834# List of URLs to be used to contact Marathon servers. 835# You need to provide at least one server URL. 836servers: 837 - <string> 838 839# Polling interval 840[ refresh_interval: <duration> | default = 30s ] 841 842# Optional authentication information for token-based authentication 843# https://docs.mesosphere.com/1.11/security/ent/iam-api/#passing-an-authentication-token 844# It is mutually exclusive with `auth_token_file` and other authentication mechanisms. 845[ auth_token: <secret> ] 846 847# Optional authentication information for token-based authentication 848# https://docs.mesosphere.com/1.11/security/ent/iam-api/#passing-an-authentication-token 849# It is mutually exclusive with `auth_token` and other authentication mechanisms. 850[ auth_token_file: <filename> ] 851 852# Sets the `Authorization` header on every request with the 853# configured username and password. 854# This is mutually exclusive with other authentication mechanisms. 855# password and password_file are mutually exclusive. 856basic_auth: 857 [ username: <string> ] 858 [ password: <string> ] 859 [ password_file: <string> ] 860 861# Sets the `Authorization` header on every request with 862# the configured bearer token. It is mutually exclusive with `bearer_token_file` and other authentication mechanisms. 863# NOTE: The current version of DC/OS marathon (v1.11.0) does not support standard Bearer token authentication. Use `auth_token` instead. 864[ bearer_token: <string> ] 865 866# Sets the `Authorization` header on every request with the bearer token 867# read from the configured file. It is mutually exclusive with `bearer_token` and other authentication mechanisms. 868# NOTE: The current version of DC/OS marathon (v1.11.0) does not support standard Bearer token authentication. Use `auth_token_file` instead. 869[ bearer_token_file: /path/to/bearer/token/file ] 870 871# TLS configuration for connecting to marathon servers 872tls_config: 873 [ <tls_config> ] 874 875# Optional proxy URL. 876[ proxy_url: <string> ] 877``` 878 879By default every app listed in Marathon will be scraped by Prometheus. If not all 880of your services provide Prometheus metrics, you can use a Marathon label and 881Prometheus relabeling to control which instances will actually be scraped. 882See [the Prometheus marathon-sd configuration file](/documentation/examples/prometheus-marathon.yml) 883for a practical example on how to set up your Marathon app and your Prometheus 884configuration. 885 886By default, all apps will show up as a single job in Prometheus (the one specified 887in the configuration file), which can also be changed using relabeling. 888 889### `<nerve_sd_config>` 890 891Nerve SD configurations allow retrieving scrape targets from [AirBnB's Nerve] 892(https://github.com/airbnb/nerve) which are stored in 893[Zookeeper](https://zookeeper.apache.org/). 894 895The following meta labels are available on targets during [relabeling](#relabel_config): 896 897* `__meta_nerve_path`: the full path to the endpoint node in Zookeeper 898* `__meta_nerve_endpoint_host`: the host of the endpoint 899* `__meta_nerve_endpoint_port`: the port of the endpoint 900* `__meta_nerve_endpoint_name`: the name of the endpoint 901 902```yaml 903# The Zookeeper servers. 904servers: 905 - <host> 906# Paths can point to a single service, or the root of a tree of services. 907paths: 908 - <string> 909[ timeout: <duration> | default = 10s ] 910``` 911 912### `<serverset_sd_config>` 913 914Serverset SD configurations allow retrieving scrape targets from [Serversets] 915(https://github.com/twitter/finagle/tree/master/finagle-serversets) which are 916stored in [Zookeeper](https://zookeeper.apache.org/). Serversets are commonly 917used by [Finagle](https://twitter.github.io/finagle/) and 918[Aurora](http://aurora.apache.org/). 919 920The following meta labels are available on targets during relabeling: 921 922* `__meta_serverset_path`: the full path to the serverset member node in Zookeeper 923* `__meta_serverset_endpoint_host`: the host of the default endpoint 924* `__meta_serverset_endpoint_port`: the port of the default endpoint 925* `__meta_serverset_endpoint_host_<endpoint>`: the host of the given endpoint 926* `__meta_serverset_endpoint_port_<endpoint>`: the port of the given endpoint 927* `__meta_serverset_shard`: the shard number of the member 928* `__meta_serverset_status`: the status of the member 929 930```yaml 931# The Zookeeper servers. 932servers: 933 - <host> 934# Paths can point to a single serverset, or the root of a tree of serversets. 935paths: 936 - <string> 937[ timeout: <duration> | default = 10s ] 938``` 939 940Serverset data must be in the JSON format, the Thrift format is not currently supported. 941 942### `<triton_sd_config>` 943 944[Triton](https://github.com/joyent/triton) SD configurations allow retrieving 945scrape targets from [Container Monitor](https://github.com/joyent/rfd/blob/master/rfd/0027/README.md) 946discovery endpoints. 947 948The following meta labels are available on targets during relabeling: 949 950* `__meta_triton_groups`: the list of groups belonging to the target joined by a comma separator 951* `__meta_triton_machine_alias`: the alias of the target container 952* `__meta_triton_machine_brand`: the brand of the target container 953* `__meta_triton_machine_id`: the UUID of the target container 954* `__meta_triton_machine_image`: the target containers image type 955* `__meta_triton_server_id`: the server UUID for the target container 956 957```yaml 958# The information to access the Triton discovery API. 959 960# The account to use for discovering new target containers. 961account: <string> 962 963# The DNS suffix which should be applied to target containers. 964dns_suffix: <string> 965 966# The Triton discovery endpoint (e.g. 'cmon.us-east-3b.triton.zone'). This is 967# often the same value as dns_suffix. 968endpoint: <string> 969 970# A list of groups for which targets are retrieved. If omitted, all containers 971# available to the requesting account are scraped. 972groups: 973 [ - <string> ... ] 974 975# The port to use for discovery and metric scraping. 976[ port: <int> | default = 9163 ] 977 978# The interval which should should be used for refreshing target containers. 979[ refresh_interval: <duration> | default = 60s ] 980 981# The Triton discovery API version. 982[ version: <int> | default = 1 ] 983 984# TLS configuration. 985tls_config: 986 [ <tls_config> ] 987``` 988 989### `<static_config>` 990 991A `static_config` allows specifying a list of targets and a common label set 992for them. It is the canonical way to specify static targets in a scrape 993configuration. 994 995```yaml 996# The targets specified by the static config. 997targets: 998 [ - '<host>' ] 999 1000# Labels assigned to all metrics scraped from the targets. 1001labels: 1002 [ <labelname>: <labelvalue> ... ] 1003``` 1004 1005### `<relabel_config>` 1006 1007Relabeling is a powerful tool to dynamically rewrite the label set of a target before 1008it gets scraped. Multiple relabeling steps can be configured per scrape configuration. 1009They are applied to the label set of each target in order of their appearance 1010in the configuration file. 1011 1012Initially, aside from the configured per-target labels, a target's `job` 1013label is set to the `job_name` value of the respective scrape configuration. 1014The `__address__` label is set to the `<host>:<port>` address of the target. 1015After relabeling, the `instance` label is set to the value of `__address__` by default if 1016it was not set during relabeling. The `__scheme__` and `__metrics_path__` labels 1017are set to the scheme and metrics path of the target respectively. The `__param_<name>` 1018label is set to the value of the first passed URL parameter called `<name>`. 1019 1020Additional labels prefixed with `__meta_` may be available during the 1021relabeling phase. They are set by the service discovery mechanism that provided 1022the target and vary between mechanisms. 1023 1024Labels starting with `__` will be removed from the label set after relabeling is completed. 1025 1026If a relabeling step needs to store a label value only temporarily (as the 1027input to a subsequent relabeling step), use the `__tmp` label name prefix. This 1028prefix is guaranteed to never be used by Prometheus itself. 1029 1030```yaml 1031# The source labels select values from existing labels. Their content is concatenated 1032# using the configured separator and matched against the configured regular expression 1033# for the replace, keep, and drop actions. 1034[ source_labels: '[' <labelname> [, ...] ']' ] 1035 1036# Separator placed between concatenated source label values. 1037[ separator: <string> | default = ; ] 1038 1039# Label to which the resulting value is written in a replace action. 1040# It is mandatory for replace actions. Regex capture groups are available. 1041[ target_label: <labelname> ] 1042 1043# Regular expression against which the extracted value is matched. 1044[ regex: <regex> | default = (.*) ] 1045 1046# Modulus to take of the hash of the source label values. 1047[ modulus: <uint64> ] 1048 1049# Replacement value against which a regex replace is performed if the 1050# regular expression matches. Regex capture groups are available. 1051[ replacement: <string> | default = $1 ] 1052 1053# Action to perform based on regex matching. 1054[ action: <relabel_action> | default = replace ] 1055``` 1056 1057`<regex>` is any valid 1058[RE2 regular expression](https://github.com/google/re2/wiki/Syntax). It is 1059required for the `replace`, `keep`, `drop`, `labelmap`,`labeldrop` and `labelkeep` actions. The regex is 1060anchored on both ends. To un-anchor the regex, use `.*<regex>.*`. 1061 1062`<relabel_action>` determines the relabeling action to take: 1063 1064* `replace`: Match `regex` against the concatenated `source_labels`. Then, set 1065 `target_label` to `replacement`, with match group references 1066 (`${1}`, `${2}`, ...) in `replacement` substituted by their value. If `regex` 1067 does not match, no replacement takes place. 1068* `keep`: Drop targets for which `regex` does not match the concatenated `source_labels`. 1069* `drop`: Drop targets for which `regex` matches the concatenated `source_labels`. 1070* `hashmod`: Set `target_label` to the `modulus` of a hash of the concatenated `source_labels`. 1071* `labelmap`: Match `regex` against all label names. Then copy the values of the matching labels 1072 to label names given by `replacement` with match group references 1073 (`${1}`, `${2}`, ...) in `replacement` substituted by their value. 1074* `labeldrop`: Match `regex` against all label names. Any label that matches will be 1075 removed from the set of labels. 1076* `labelkeep`: Match `regex` against all label names. Any label that does not match will be 1077 removed from the set of labels. 1078 1079Care must be taken with `labeldrop` and `labelkeep` to ensure that metrics are still uniquely labeled 1080once the labels are removed. 1081 1082### `<metric_relabel_configs>` 1083 1084Metric relabeling is applied to samples as the last step before ingestion. It 1085has the same configuration format and actions as target relabeling. Metric 1086relabeling does not apply to automatically generated timeseries such as `up`. 1087 1088One use for this is to blacklist time series that are too expensive to ingest. 1089 1090### `<alert_relabel_configs>` 1091 1092Alert relabeling is applied to alerts before they are sent to the Alertmanager. 1093It has the same configuration format and actions as target relabeling. Alert 1094relabeling is applied after external labels. 1095 1096One use for this is ensuring a HA pair of Prometheus servers with different 1097external labels send identical alerts. 1098 1099### `<alertmanager_config>` 1100 1101An `alertmanager_config` section specifies Alertmanager instances the Prometheus server sends 1102alerts to. It also provides parameters to configure how to communicate with these Alertmanagers. 1103 1104Alertmanagers may be statically configured via the `static_configs` parameter or 1105dynamically discovered using one of the supported service-discovery mechanisms. 1106 1107Additionally, `relabel_configs` allow selecting Alertmanagers from discovered 1108entities and provide advanced modifications to the used API path, which is exposed 1109through the `__alerts_path__` label. 1110 1111```yaml 1112# Per-target Alertmanager timeout when pushing alerts. 1113[ timeout: <duration> | default = 10s ] 1114 1115# Prefix for the HTTP path alerts are pushed to. 1116[ path_prefix: <path> | default = / ] 1117 1118# Configures the protocol scheme used for requests. 1119[ scheme: <scheme> | default = http ] 1120 1121# Sets the `Authorization` header on every request with the 1122# configured username and password. 1123# password and password_file are mutually exclusive. 1124basic_auth: 1125 [ username: <string> ] 1126 [ password: <string> ] 1127 [ password_file: <string> ] 1128 1129# Sets the `Authorization` header on every request with 1130# the configured bearer token. It is mutually exclusive with `bearer_token_file`. 1131[ bearer_token: <string> ] 1132 1133# Sets the `Authorization` header on every request with the bearer token 1134# read from the configured file. It is mutually exclusive with `bearer_token`. 1135[ bearer_token_file: /path/to/bearer/token/file ] 1136 1137# Configures the scrape request's TLS settings. 1138tls_config: 1139 [ <tls_config> ] 1140 1141# Optional proxy URL. 1142[ proxy_url: <string> ] 1143 1144# List of Azure service discovery configurations. 1145azure_sd_configs: 1146 [ - <azure_sd_config> ... ] 1147 1148# List of Consul service discovery configurations. 1149consul_sd_configs: 1150 [ - <consul_sd_config> ... ] 1151 1152# List of DNS service discovery configurations. 1153dns_sd_configs: 1154 [ - <dns_sd_config> ... ] 1155 1156# List of EC2 service discovery configurations. 1157ec2_sd_configs: 1158 [ - <ec2_sd_config> ... ] 1159 1160# List of file service discovery configurations. 1161file_sd_configs: 1162 [ - <file_sd_config> ... ] 1163 1164# List of GCE service discovery configurations. 1165gce_sd_configs: 1166 [ - <gce_sd_config> ... ] 1167 1168# List of Kubernetes service discovery configurations. 1169kubernetes_sd_configs: 1170 [ - <kubernetes_sd_config> ... ] 1171 1172# List of Marathon service discovery configurations. 1173marathon_sd_configs: 1174 [ - <marathon_sd_config> ... ] 1175 1176# List of AirBnB's Nerve service discovery configurations. 1177nerve_sd_configs: 1178 [ - <nerve_sd_config> ... ] 1179 1180# List of Zookeeper Serverset service discovery configurations. 1181serverset_sd_configs: 1182 [ - <serverset_sd_config> ... ] 1183 1184# List of Triton service discovery configurations. 1185triton_sd_configs: 1186 [ - <triton_sd_config> ... ] 1187 1188# List of labeled statically configured Alertmanagers. 1189static_configs: 1190 [ - <static_config> ... ] 1191 1192# List of Alertmanager relabel configurations. 1193relabel_configs: 1194 [ - <relabel_config> ... ] 1195``` 1196 1197### `<remote_write>` 1198 1199`write_relabel_configs` is relabeling applied to samples before sending them 1200to the remote endpoint. Write relabeling is applied after external labels. This 1201could be used to limit which samples are sent. 1202 1203There is a [small demo](/documentation/examples/remote_storage) of how to use 1204this functionality. 1205 1206```yaml 1207# The URL of the endpoint to send samples to. 1208url: <string> 1209 1210# Timeout for requests to the remote write endpoint. 1211[ remote_timeout: <duration> | default = 30s ] 1212 1213# List of remote write relabel configurations. 1214write_relabel_configs: 1215 [ - <relabel_config> ... ] 1216 1217# Sets the `Authorization` header on every remote write request with the 1218# configured username and password. 1219# password and password_file are mutually exclusive. 1220basic_auth: 1221 [ username: <string> ] 1222 [ password: <string> ] 1223 [ password_file: <string> ] 1224 1225# Sets the `Authorization` header on every remote write request with 1226# the configured bearer token. It is mutually exclusive with `bearer_token_file`. 1227[ bearer_token: <string> ] 1228 1229# Sets the `Authorization` header on every remote write request with the bearer token 1230# read from the configured file. It is mutually exclusive with `bearer_token`. 1231[ bearer_token_file: /path/to/bearer/token/file ] 1232 1233# Configures the remote write request's TLS settings. 1234tls_config: 1235 [ <tls_config> ] 1236 1237# Optional proxy URL. 1238[ proxy_url: <string> ] 1239 1240# Configures the queue used to write to remote storage. 1241queue_config: 1242 # Number of samples to buffer per shard before we start dropping them. 1243 [ capacity: <int> | default = 10000 ] 1244 # Maximum number of shards, i.e. amount of concurrency. 1245 [ max_shards: <int> | default = 1000 ] 1246 # Minimum number of shards, i.e. amount of concurrency. 1247 [ min_shards: <int> | default = 1 ] 1248 # Maximum number of samples per send. 1249 [ max_samples_per_send: <int> | default = 100] 1250 # Maximum time a sample will wait in buffer. 1251 [ batch_send_deadline: <duration> | default = 5s ] 1252 # Maximum number of times to retry a batch on recoverable errors. 1253 [ max_retries: <int> | default = 3 ] 1254 # Initial retry delay. Gets doubled for every retry. 1255 [ min_backoff: <duration> | default = 30ms ] 1256 # Maximum retry delay. 1257 [ max_backoff: <duration> | default = 100ms ] 1258 1259``` 1260 1261There is a list of 1262[integrations](https://prometheus.io/docs/operating/integrations/#remote-endpoints-and-storage) 1263with this feature. 1264 1265### `<remote_read>` 1266 1267```yaml 1268# The URL of the endpoint to query from. 1269url: <string> 1270 1271# An optional list of equality matchers which have to be 1272# present in a selector to query the remote read endpoint. 1273required_matchers: 1274 [ <labelname>: <labelvalue> ... ] 1275 1276# Timeout for requests to the remote read endpoint. 1277[ remote_timeout: <duration> | default = 1m ] 1278 1279# Whether reads should be made for queries for time ranges that 1280# the local storage should have complete data for. 1281[ read_recent: <boolean> | default = false ] 1282 1283# Sets the `Authorization` header on every remote read request with the 1284# configured username and password. 1285# password and password_file are mutually exclusive. 1286basic_auth: 1287 [ username: <string> ] 1288 [ password: <string> ] 1289 [ password_file: <string> ] 1290 1291# Sets the `Authorization` header on every remote read request with 1292# the configured bearer token. It is mutually exclusive with `bearer_token_file`. 1293[ bearer_token: <string> ] 1294 1295# Sets the `Authorization` header on every remote read request with the bearer token 1296# read from the configured file. It is mutually exclusive with `bearer_token`. 1297[ bearer_token_file: /path/to/bearer/token/file ] 1298 1299# Configures the remote read request's TLS settings. 1300tls_config: 1301 [ <tls_config> ] 1302 1303# Optional proxy URL. 1304[ proxy_url: <string> ] 1305``` 1306 1307There is a list of 1308[integrations](https://prometheus.io/docs/operating/integrations/#remote-endpoints-and-storage) 1309with this feature. 1310