Important: This documentation is about an older version. It's relevant only to the release noted, many of the features and functions have been updated or replaced. Please view the current version.
Pyroscope configuration parameters
You can configure Pyroscope by using a YAML file or via command-line flags
that represent configuration parameters.
To specify the YAML file, use the -config.file command-line option.
If you specify both the command-line flags and YAML configuration parameters,
the command-line flags take precedence over values in a YAML file.
To see the current configuration of any component,
go to the /config HTTP API endpoint.
Passwords are filtered out of this endpoint.
Parameters are written in YAML format, and brackets indicate that a parameter is optional.
Generic placeholders
<boolean>: a boolean that can take the valuestrueorfalse<int>: any integer matching the regular expression[1-9]+[0-9]*<duration>: a duration matching the regular expression[0-9]+(ns|us|µs|ms|s|m|h|d|w|y)where y = 365 days<string>: a string<url>: a URL<filepath>: a string containing an absolute or relative path and filename to a file on disk<prefix>: a CLI flag prefix based on the context (look at the parent configuration block to see which CLI flags prefix should be used)<relabel_config>: a Prometheus relabeling configuration<time>: a timestamp, with available formats:2006-01-20(midnight, local timezone)2006-01-20T15:04(local timezone)- RFC 3339 formats:
2006-01-20T15:04:05Z(UTC) or2006-01-20T15:04:05+07:00(explicit timezone)
Use environment variables in the configuration
You can use environment variable references in the YAML configuration file
to set values that need to be configurable during deployment.
To do this, pass -config.expand-env=true on the command line and use
${VAR},
where VAR is the name of the environment variable.
Each variable reference is replaced at startup by the value of the environment variable. The replacement is case-sensitive and occurs before the YAML file is parsed. References to undefined variables are replaced by empty strings unless you specify a default value or custom error text.
To specify a default value, use ${VAR:default_value},
where default_value is the value to use if the environment variable is undefined.
Configuration parameters
server
The server block configures the HTTP and gRPC server of the launched service(s).
distributor
The distributor block configures the distributor.
# Timeout when pushing data to ingester.
# CLI flag: -distributor.push.timeout
[pushtimeout: <duration> | default = 5s]
pool_config:
# How frequently to clean up clients for ingesters that have gone away.
# CLI flag: -distributor.client-cleanup-period
[client_cleanup_period: <duration> | default = 15s]
# Run a health check on each ingester client during periodic cleanup.
# CLI flag: -distributor.health-check-ingesters
[health_check_ingesters: <boolean> | default = true]
# Timeout for ingester client healthcheck RPCs.
# CLI flag: -distributor.health-check-timeout
[remote_timeout: <duration> | default = 5s]ingester
The ingester block configures the ingester.
querier
The querier block configures the querier.
pool_config:
# How frequently to clean up clients for ingesters that have gone away.
# CLI flag: -querier.client-cleanup-period
[client_cleanup_period: <duration> | default = 15s]
# Run a health check on each ingester client during periodic cleanup.
# CLI flag: -querier.health-check-ingesters
[health_check_ingesters: <boolean> | default = true]
# Timeout for ingester client healthcheck RPCs.
# CLI flag: -querier.health-check-timeout
[remote_timeout: <duration> | default = 5s]
# The time after which a metric should be queried from storage and not just
# ingesters. 0 means all queries are sent to store. If this option is enabled,
# the time range of the query sent to the store-gateway will be manipulated to
# ensure the query end is not more recent than 'now - query-store-after'.
# CLI flag: -querier.query-store-after
[query_store_after: <duration> | default = 4h]query_frontend
The query_frontend block configures the query-frontend.
# Number of concurrent workers forwarding queries to single query-scheduler.
# CLI flag: -query-frontend.scheduler-worker-concurrency
[scheduler_worker_concurrency: <int> | default = 5]
# Configures the gRPC client used to communicate between the query-frontends and
# the query-schedulers.
# The CLI flags prefix for this block configuration is:
# query-frontend.grpc-client-config
[grpc_client_config: <grpc_client>]
# List of network interface names to look up when finding the instance IP
# address. This address is sent to query-scheduler and querier, which uses it to
# send the query response back to query-frontend.
# CLI flag: -query-frontend.instance-interface-names
[instance_interface_names: <list of strings> | default = [<private network interfaces>]]
# IP address to advertise to the querier (via scheduler) (default is
# auto-detected from network interfaces).
# CLI flag: -query-frontend.instance-addr
[address: <string> | default = ""]frontend_worker
The frontend_worker block configures the frontend-worker.
# Querier ID, sent to the query-frontend to identify requests from the same
# querier. Defaults to hostname.
# CLI flag: -querier.id
[id: <string> | default = ""]
# Configures the gRPC client used to communicate between the queriers and the
# query-frontends / query-schedulers.
# The CLI flags prefix for this block configuration is: querier.frontend-client
[grpc_client_config: <grpc_client>]
# The maximum number of concurrent queries allowed.
# CLI flag: -querier.max-concurrent
[max_concurrent: <int> | default = 4]query_scheduler
The query_scheduler block configures the query-scheduler.
# Maximum number of outstanding requests per tenant per query-scheduler.
# In-flight requests above this limit will fail with HTTP response status code
# 429.
# CLI flag: -query-scheduler.max-outstanding-requests-per-tenant
[max_outstanding_requests_per_tenant: <int> | default = 100]
# If a querier disconnects without sending notification about graceful shutdown,
# the query-scheduler will keep the querier in the tenant's shard until the
# forget delay has passed. This feature is useful to reduce the blast radius
# when shuffle-sharding is enabled.
# CLI flag: -query-scheduler.querier-forget-delay
[querier_forget_delay: <duration> | default = 0s]
# This configures the gRPC client used to report errors back to the
# query-frontend.
# The CLI flags prefix for this block configuration is:
# query-scheduler.grpc-client-config
[grpc_client_config: <grpc_client>]
# The maximum number of query-scheduler instances to use, regardless how many
# replicas are running. This option can be set only when
# -query-scheduler.service-discovery-mode is set to 'ring'. 0 to use all
# available query-scheduler instances.
# CLI flag: -query-scheduler.max-used-instances
[max_used_instances: <int> | default = 0]grpc_client
The grpc_client block configures the gRPC client used to communicate between two Pyroscope components. The supported CLI flags <prefix> used to reference this configuration block are:
querier.frontend-clientquery-frontend.grpc-client-configquery-scheduler.grpc-client-config
memberlist
The memberlist block configures the Gossip memberlist.
s3_storage_backend
The s3_backend block configures the connection to Amazon S3 object storage backend.
gcs_storage_backend
The gcs_backend block configures the connection to Google Cloud Storage object storage backend.
# GCS bucket name
# CLI flag: -storage.gcs.bucket-name
[bucket_name: <string> | default = ""]
# JSON either from a Google Developers Console client_credentials.json file, or
# a Google Developers service account key. Needs to be valid JSON, not a
# filesystem path. If empty, fallback to Google default logic:
# 1. A JSON file whose path is specified by the GOOGLE_APPLICATION_CREDENTIALS
# environment variable. For workload identity federation, refer to
# https://cloud.google.com/iam/docs/how-to#using-workload-identity-federation on
# how to generate the JSON configuration file for on-prem/non-Google cloud
# platforms.
# 2. A JSON file in a location known to the gcloud command-line tool:
# $HOME/.config/gcloud/application_default_credentials.json.
# 3. On Google Compute Engine it fetches credentials from the metadata server.
# CLI flag: -storage.gcs.service-account
[service_account: <string> | default = ""]azure_storage_backend
The azure_storage_backend block configures the connection to Azure object storage backend.
# Azure storage account name
# CLI flag: -storage.azure.account-name
[account_name: <string> | default = ""]
# Azure storage account key
# CLI flag: -storage.azure.account-key
[account_key: <string> | default = ""]
# Azure storage container name
# CLI flag: -storage.azure.container-name
[container_name: <string> | default = ""]
# Azure storage endpoint suffix without schema. The account name will be
# prefixed to this value to create the FQDN. If set to empty string, default
# endpoint suffix is used.
# CLI flag: -storage.azure.endpoint-suffix
[endpoint_suffix: <string> | default = ""]
# Number of retries for recoverable errors
# CLI flag: -storage.azure.max-retries
[max_retries: <int> | default = 20]
# User assigned identity. If empty, then System assigned identity is used.
# CLI flag: -storage.azure.user-assigned-id
[user_assigned_id: <string> | default = ""]swift_storage_backend
The swift_storage_backend block configures the connection to OpenStack Object Storage (Swift) object storage backend.
filesystem_storage_backend
The filesystem_storage_backend block configures the usage of local file system as object storage backend.
# Local filesystem storage directory.
# CLI flag: -storage.filesystem.dir
[dir: <string> | default = ""]Was this page helpful?
Related resources from Grafana Labs
