Documentationbreadcrumb arrow Grafana Pyroscopebreadcrumb arrow Configure the serverbreadcrumb arrow Configure storagebreadcrumb arrow Configure object storage
Open source

Configure object storage backend

Grafana Pyroscope can use different object storage services to persist blocks containing the profiles data. Blocks are flushed by ingesters on disk first then are uploaded to the object store.

The supported backends are:

Internally, Pyroscope uses Thanos’ object store client library, so their stated limitations apply.

Dedicated storage for asynchronous queries

The experimental asynchronous query path uses the primary storage bucket by default. To store query metadata, request specifications, and results in a dedicated bucket, configure frontend.async_queries.storage on every query frontend:

YAML 
frontend:
  async_queries:
    enabled: true
    storage:
      backend: s3
      s3:
        bucket_name: pyroscope-async-queries
        region: eu-west-2
        endpoint: s3.eu-west-2.amazonaws.com

This configuration supports the same backend settings as storage, with independent credentials and an optional prefix. The corresponding CLI flags start with -query-frontend.async-queries.storage.. When backend is none (the default), the primary bucket is used. Objects are stored under async-queries/ within the configured prefix. All query frontends must use the same bucket and prefix to poll results and recover queries from another frontend.

Enable asynchronous queries with -query-frontend.async-queries.enabled=true. The legacy -query-frontend.async-queries-enabled flag remains supported, but logs a deprecation warning when used. If both flags are supplied, the last one takes effect.

Changing the bucket does not migrate existing asynchronous queries. Let in-flight queries finish before switching buckets.

Amazon S3

To use an AWS S3 or S3-compatible bucket for long term storage, you can find Pyroscope’s configuration parameters in the reference config. Apart from those parameters, it is also possible to supply configuration parameters using the well-known environment variables of the AWS SDK.

At a minimum, you will need to provide values for the bucket_name, endpoint, access_key_id, and secret_access_key keys.

Example using an AWS Bucket

This how one would configure a bucket in the AWS region eu-west-2:

YAML 
storage:
  backend: s3
  s3:
    bucket_name: #REPLACE_WITH_BUCKET_NAME
    region: eu-west-2
    endpoint: s3.eu-west-2.amazonaws.com
    access_key_id: #REPLACE_WITH_ACCESS_KEY
    secret_access_key: #REPLACE_WITH_SECRET_KEY

Example using a S3 compatible Bucket

This how one would configure a bucket on a locally running instance of MinIO:

YAML 
storage:
  backend: s3
  s3:
    bucket_name: grafana-pyroscope-data
    endpoint: localhost:9000
    insecure: true
    access_key_id: grafana-pyroscope-data
    secret_access_key: grafana-pyroscope-data

Using AWS SDK auth

Set native_aws_auth_enabled: true to use the AWS SDK default credential chain.

YAML 
storage:
  backend: s3
  s3:
    bucket_name: your-bucket
    region: eu-west-2
    endpoint: s3.eu-west-2.amazonaws.com
    native_aws_auth_enabled: true

Google Cloud Storage

To use a Google Cloud Storage (GCS) bucket for long term storage, you can find Pyroscope’s configuration parameters in the reference config.

At a minimum, you will need to provide a values for the bucket_name and a service account. To supply the service account there are two ways:

  • Use the GOOGLE_APPLICATION_CREDENTIALS environment variable to locate your application credentials.
  • Provide the content the service account key within the service_account parameter.

Example using a Google Cloud Storage bucket

This how one would configure a GCS bucket using the service_account parameter:

YAML 
storage:
  backend: gcs
  gcs:
    bucket_name: grafana-pyroscope-data
    service_account: |
      {
        "type": "service_account",
        "project_id": "PROJECT_ID",
        "private_key_id": "KEY_ID",
        "private_key": "-----BEGIN PRIVATE KEY-----\nPRIVATE_KEY\n-----END PRIVATE KEY-----\n",
        "client_email": "SERVICE_ACCOUNT_EMAIL",
        "client_id": "CLIENT_ID",
        "auth_uri": "https://accounts.google.com/o/oauth2/auth",
        "token_uri": "https://accounts.google.com/o/oauth2/token",
        "auth_provider_x509_cert_url": "https://www.googleapis.com/oauth2/v1/certs",
        "client_x509_cert_url": "https://www.googleapis.com/robot/v1/metadata/x509/SERVICE_ACCOUNT_EMAIL"
      }

Azure Blob Storage

To use an Azure Blob Storage bucket for long term storage, you can find Pyroscope’s configuration parameters in the reference config.

If user_assigned_id is used, authentication is done via user-assigned managed identity.

Swift (OpenStack Object Storage)

To use a Swift (OpenStack Object Storage) bucket for long term storage, you can find Pyroscope’s configuration parameters in the reference config.

If the name of a user, project or tenant is used one must also specify its domain by ID or name. Various examples for OpenStack authentication can be found in the official documentation.