Configuration | Prometheus

Prometheus is configured via command-line flags and a configuration file. While the command-line flags configure immutable system parameters (such as storage locations, amount of data to keep on disk and in memory, etc.), the configuration file defines everything related to scraping jobs and their instances, as well as which rule files to load.
To view all available command-line flags, run ./prometheus -h.
Prometheus can reload its configuration at runtime. If the new configuration is not well-formed, the changes will not be applied. A configuration reload is triggered by sending a SIGHUP to the Prometheus process or sending a HTTP POST request to the /-/reload endpoint (when the --web.enable-lifecycle flag is enabled). This will also reload any configured rule files.
To specify which configuration file to load, use the --config.file flag.
The file is written in YAML format , defined by the scheme described below. Brackets indicate that a parameter is optional. For non-list parameters the value is set to the specified default.
Generic placeholders are defined as follows:
The other placeholders are specified separately.
A valid example file can be found here .
The global configuration specifies parameters that are valid in all other configuration contexts. They also serve as defaults for other configuration sections.
A scrape_config section specifies a set of targets and parameters describing how to scrape them. In the general case, one scrape configuration specifies a single job. In advanced configurations, this may change.
Targets may be statically configured via the static_configs parameter or dynamically discovered using one of the supported service-discovery mechanisms.
Additionally, relabel_configs allow advanced modifications to any target and its labels before scraping.
Where <job_name> must be unique across all scrape configurations.
A http_config allows configuring HTTP requests.
A tls_config allows configuring TLS connections.
OAuth 2.0 authentication using the client credentials or password grant type. Prometheus fetches an access token from the specified endpoint with the given client access and credentials.
AWS SD configurations allow retrieving scrape targets from AWS services. This is a unified service discovery that supports multiple AWS service types through the role parameter.
One of the following role types can be configured to discover targets:
The ec2 role discovers targets from AWS EC2 instances. The private IP address is used by default, but may be changed to the public IP address with relabeling.
The IAM credentials used must have the ec2:DescribeInstances permission to discover scrape targets, and may optionally have the ec2:DescribeAvailabilityZones permission if you want the availability zone ID available as a label (see below).
The following meta labels are available on targets during relabeling:
The lightsail role discovers targets from AWS Lightsail instances. The private IP address is used by default, but may be changed to the public IP address with relabeling.
The following meta labels are available on targets during relabeling:
The ecs role discovers targets from AWS ECS containers.
ECS service discovery supports all ECS networking modes:
The private IP address is used by default, but may be changed to the public IP address with relabeling.
The IAM credentials used must have the following permissions to discover scrape targets:
The following meta labels are available on targets during relabeling:
The msk role discovers targets from AWS MSK (Managed Streaming for Apache Kafka) provisioned clusters.
Important: This service discovery only works with provisioned clusters. Serverless clusters are not supported as they do not expose individual broker nodes.
Note: ZooKeeper nodes are not discoverable via the MSK API. For monitoring, MSK provides:
The IAM credentials used must have the following permissions to discover scrape targets:
The following meta labels are available on targets during relabeling:
The elasticache role discovers targets from AWS ElastiCache for both serverless caches and cache clusters.
Important: For cache clusters, one target is created per cache node. Each target includes the cluster-level labels (ARN, status, tags, etc.) and node-specific labels (node ID, endpoint, availability zone, etc.). The __address__ label is set to the individual node's endpoint address and port.
For serverless caches, one target is created per serverless cache, with the __address__ label set to the serverless cache endpoint.
The IAM credentials used must have the following permissions to discover scrape targets:
The following meta labels are available on targets during relabeling:
Common labels (available on all targets):
Serverless Cache labels: