All Products
Search
Document Center

Time Series Database:Prometheus Remote Write configuration

Last Updated:Mar 28, 2026

Each Alibaba Cloud Time Series Database (TSDB) instance has a maximum write throughput limit. Exceeding that limit triggers a throttling rule, causing write failures. Configure Prometheus remote_write settings to match your TSDB instance's capacity so that metrics flow into TSDB smoothly and reliably.

For the full list of remote_write configuration options, see the Prometheus documentation.

How it works

When Prometheus writes to remote storage, it reads from the write-ahead log (WAL) and distributes samples into an in-memory queue managed by shards. Each shard sends batched requests to the configured endpoint:

                 |--> queue (shard_1) --> TSDB endpoint
WAL --> buffer --|--> queue (shard_2) --> TSDB endpoint
                 |--> queue (shard_n) --> TSDB endpoint

The queue_config block controls this pipeline. Two parameters determine the maximum write throughput: max_shards sets the number of concurrent shards, and max_samples_per_send sets the batch size. Together, they cap how fast Prometheus can push data:

Max throughput = max_shards x max_samples_per_send / send_latency

For example, with the default values (max_shards: 1000, max_samples_per_send: 100) and a 100 ms send latency, Prometheus can reach 1,000,000 data points per second — far above most TSDB instance limits.

Queue configuration parameters

The following parameters control how Prometheus buffers and sends data to TSDB:

ParameterDefaultDescription
capacity10,000Samples buffered per shard before the WAL blocks.
max_shards1,000Maximum number of concurrent shards. Controls maximum throughput and memory usage.
min_shards1Minimum number of shards. Supported in Prometheus v2.6.0 and later; has no effect in earlier versions.
max_samples_per_send100Samples per request batch. Higher values improve efficiency but increase per-request size.
batch_send_deadline5sMaximum time a sample waits before the batch is sent, regardless of batch size.
max_retries3Maximum retry attempts on recoverable errors before the batch is dropped.
min_backoff30msInitial retry delay. Doubles on each retry attempt.
max_backoff100msUpper bound for the retry delay.

Reference configuration by TSDB specification

Set max_shards based on your TSDB instance specification. Keep capacity and max_samples_per_send at the values below unless you have specific latency or memory constraints.

TSDB specificationMax write throughput (data points/s)capacitymax_samples_per_sendmax_shards
mlarge5,00010,0005001
large10,00010,0005002
3xlarge30,00010,0005006
4xlarge40,00010,0005008
6xlarge60,00010,00050012
12xlarge120,00010,00050024
24xlarge240,00010,00050048
48xlarge480,00010,00050096
96xlarge960,00010,000500192

Complete configuration example

The following example shows a full Prometheus configuration for an mlarge TSDB instance. Replace the placeholders with your actual values before using it.

PlaceholderDescriptionExample
<tsdb-instance-id>Your TSDB instance IDts-bp1234567890abcdef
# Global settings
global:
  scrape_interval:     15s  # How often to scrape targets
  evaluation_interval: 15s  # How often to evaluate alerting rules

# Alertmanager configuration
alerting:
  alertmanagers:
  - static_configs:
    - targets:
      # - alertmanager:9093

# Alerting rule files
rule_files:
  # - "first_rules.yml"
  # - "second_rules.yml"

# Scrape configuration
scrape_configs:
  - job_name: 'prometheus'
    static_configs:
    - targets: ['localhost:9090']

# Remote write configuration -- sends metrics to TSDB
remote_write:
  - url: "http://<tsdb-instance-id>.hitsdb.rds.aliyuncs.com:3242/api/prom_write"
    queue_config:
      capacity: 10000           # Buffer per shard
      max_shards: 1             # Set based on your TSDB specification
      max_samples_per_send: 500 # Batch size per request

# Remote read configuration -- reads recent metrics from TSDB
remote_read:
  - url: "http://<tsdb-instance-id>.hitsdb.rds.aliyuncs.com:3242/api/prom_read"
    read_recent: true

To use a different TSDB specification, adjust max_shards according to the reference table above and keep the other parameters unchanged.

What's next