Menskalakan Storage Prometheus dengan Grafana Mimir

Satu Prometheus adalah hal yang luar biasa sampai Anda memintanya untuk mengingat. Retensi TSDB lokal diukur dalam hari atau minggu, penskalaan berarti mesin yang lebih besar, dan begitu Anda menjalankan lebih dari satu Prometheus, tidak ada satu tempat untuk men-query semuanya. Pada monitoring stack yang saya jalankan, saya menabrak ketiga tembok itu sekaligus: disk penuh, query melambat, dan saya punya tiga server Prometheus yang tidak bisa melihat data satu sama lain.

Grafana Mimir adalah jawaban yang saya pilih. Ini adalah store jangka panjang open-source yang skalabel horizontal, berbicara protokol remote_write Prometheus di sisi tulis dan PromQL di sisi baca. Prometheus tetap melakukan apa yang dikuasainya (scraping dan query lokal jangka pendek) dan meneruskan setiap sampel ke Mimir, yang mempersistensikannya ke object storage. Tulisan ini adalah bagaimana potongan-potongan ini menyatu dan konfigurasi yang benar-benar saya pakai.

Mengapa remote_write ketimbang sekadar Prometheus yang lebih besar

Menskalakan Prometheus secara vertikal menabrak plafon keras: TSDB-nya single-node, dan tidak ada replikasi atau clustering bawaan. remote_write menembus plafon itu dengan memisahkan ingestion dari storage. Prometheus mem-buffer sampel di write-ahead log dan mengalirkannya secara asinkron ke endpoint remote, sehingga tetap scraping dan melayani query lokal bahkan sambil meneruskan. Jika endpoint remote sempat mati, WAL menyerap backlog dan me-replay-nya. Pilihan desain tunggal itulah yang memungkinkan Anda menyalurkan banyak server Prometheus ke satu store terpusat yang tereplikasi.

Konfigurasi remote_write minimal

Di sisi Prometheus Anda menambahkan blok remote_write yang mengarah ke endpoint push Mimir. Path-nya adalah /api/v1/push, dan satu hal yang sering terlewat adalah header X-Scope-OrgID — Mimir menolak tulisan yang tidak menyebut tenant. Berikut blok yang saya pakai, dengan penyetelan queue yang masuk akal untuk konfigurasi scrape yang sibuk:

# prometheus.yml
remote_write:
  - url: http://mimir:8080/api/v1/push
    headers:
      X-Scope-OrgID: team-platform      # the tenant ID — required by Mimir
    queue_config:
      capacity: 10000                   # samples buffered per shard
      max_shards: 50                    # upper bound on parallel senders
      min_shards: 1
      max_samples_per_send: 2000
      batch_send_deadline: 5s
    metadata_config:
      send: true                        # forward metric metadata (help/type)

Mimir tidak melakukan autentikasi sendiri — dokumentasinya eksplisit bahwa auth diharapkan berada di depannya, biasanya nginx atau gateway mimir yang memvalidasi token dan menyuntikkan header X-Scope-OrgID. Di jaringan internal yang tepercaya Anda bisa menjalankannya dengan header disetel langsung, tetapi jangan pernah mengekspos endpoint push mentah ke internet.

Apa yang terjadi pada sampel setelah tiba

Memahami jalur tulis Mimir-lah yang membuat jaminan durabilitas masuk akal. Mimir adalah sekumpulan microservice yang skalabel horizontal, masing-masing melakukan satu tugas, dan sebuah sampel mengalir melewatinya secara berurutan:

1. Distributor menerima request remote_write, memvalidasinya, dan membagi series ke seluruh ingester menggunakan hash ring.
2. Setiap series ditulis sebanyak replication factor (tiga secara default), sehingga kehilangan satu ingester tidak pernah menghilangkan data.
3. Ingester menambahkan sampel ke TSDB per-tenant di disk lokal dan, setiap dua jam, memotong sebuah block dan mengunggahnya ke object storage.
4. Compactor menggabungkan block-block dua jam kecil itu menjadi block yang lebih besar dan ter-dedup, mengecilkan storage dan mempercepat pembacaan.
5. Store-gateway melayani query terhadap block jangka panjang itu, memakai shuffle-sharding dan cache untuk menekan panggilan object storage.

Tenant: satu cluster, banyak dunia terisolasi

Header X-Scope-OrgID bukan formalitas — itu adalah batas tenancy Mimir. Setiap tenant mendapat set block TSDB-nya sendiri di object storage, series-nya sendiri, dan limit yang dapat dikonfigurasi sendiri. Beginilah saya menjalankan satu cluster Mimir untuk beberapa proyek tanpa metrik mereka bertabrakan atau satu tim berisik membuat tim lain kelaparan. Limit disetel per tenant dan ditegakkan saat ingestion:

# mimir runtime overrides — per-tenant limits
overrides:
  team-platform:
    ingestion_rate: 150000            # samples/sec accepted
    ingestion_burst_size: 1500000
    max_global_series_per_user: 1500000
    compactor_blocks_retention_period: 1y
  team-billing:
    ingestion_rate: 25000
    max_global_series_per_user: 200000
    compactor_blocks_retention_period: 90d

Perhatikan retensi juga per tenant. Data tim billing kedaluwarsa setelah sembilan puluh hari; tim platform menyimpan satu tahun penuh. Di sisi query, Grafana meneruskan X-Scope-OrgID yang sama sehingga sebuah datasource hanya pernah melihat tenant-nya sendiri. Jika Anda perlu membaca lintas tenant, Anda bisa mengaktifkan query multi-tenant dengan mengirim daftar tenant ID dipisah pipa, tetapi saya membiarkannya mati secara default demi menjaga isolasi.

Menjaga query tetap cepat pada skala jangka panjang

Object storage murah dan tahan lama tetapi lambat per request, jadi desain naif akan membuat query rentang PromQL satu tahun merangkak. Mimir menghindari ini di beberapa sisi. Query-frontend memecah rentang waktu yang lebar menjadi sub-query paralel yang lebih kecil dan meng-cache hasil, sehingga menjalankan ulang dashboard kemarin nyaris gratis. Store-gateway men-shard block ke seluruh instance dan meng-cache index block serta chunk, memangkas jumlah round trip object storage. Dan seluruh tugas compactor adalah mengubah ribuan block mungil menjadi segelintir block besar, yang merupakan tuas terbesar untuk latensi baca.

• Jalankan compactor. Tanpanya, block menumpuk dan baik latensi query maupun biaya storage naik terus.
• Beri store-gateway dan query-frontend sebuah results cache (memcached atau Redis) — ini penyetelan berdampak tertinggi untuk dashboard.
• Pantau jumlah series per tenant; kardinalitas yang liar, bukan volume sampel mentah, yang biasanya merusak cluster Mimir.

Kapan Mimir berlebihan

Jujurlah soal skala. Jika Anda menjalankan satu Prometheus dan butuh riwayat tiga puluh hari, cukup naikkan retensi lokal atau pasang Thanos sidecar — permukaan operasional Mimir (object storage, hash ring, beberapa komponen stateful) tidak gratis. Saya memilih Mimir ketika ada lebih dari satu Prometheus untuk disatukan, ketika retensi perlu membentang kuartal atau tahun, atau ketika tim terpisah butuh tenancy yang terisolasi dan ter-rate-limit di infrastruktur bersama. Di bawah ambang itu, alat yang lebih sederhana menang.