Ringkasan Utama
Prometheus tidak pernah dirancang menyimpan metrik bertahun-tahun. Arahkan remote_write-nya ke Grafana Mimir dan sampel mengalir ke blocks storage yang skalabel horizontal dan didukung object storage seperti S3. Mimir menambahkan multi-tenancy lewat header X-Scope-OrgID dan menjaga query PromQL tetap cepat melalui store-gateway ter-shard dan compactor.
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.
Jangan hapus retensi lokal saat Anda mengadopsi remote_write. Pertahankan beberapa jam hingga beberapa hari di mesin Prometheus: ini memberi fallback lokal yang cepat untuk data terkini dan buffer jika Mimir tidak terjangkau. remote_write bersifat aditif, bukan pengganti TSDB lokal.
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:
- Distributor menerima request remote_write, memvalidasinya, dan membagi series ke seluruh ingester menggunakan hash ring.
- Setiap series ditulis sebanyak replication factor (tiga secara default), sehingga kehilangan satu ingester tidak pernah menghilangkan data.
- Ingester menambahkan sampel ke TSDB per-tenant di disk lokal dan, setiap dua jam, memotong sebuah block dan mengunggahnya ke object storage.
- Compactor menggabungkan block-block dua jam kecil itu menjadi block yang lebih besar dan ter-dedup, mengecilkan storage dan mempercepat pembacaan.
- Store-gateway melayani query terhadap block jangka panjang itu, memakai shuffle-sharding dan cache untuk menekan panggilan object storage.
Ingester menyimpan hingga dua jam data yang belum di-flush di disk lokal. Jika Anda menjalankan replication factor 1 untuk menghemat memori dan sebuah ingester mati sebelum mengunggah block-nya, jendela itu hilang permanen. Pertahankan replication factor default tiga di lingkungan apa pun yang Anda pedulikan.
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: 90dPerhatikan 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.
Untuk setup kecil Anda tidak butuh deployment microservices penuh. Mimir menyediakan mode monolitik yang menjalankan setiap komponen dalam satu binary dengan satu file config — sempurna untuk satu VPS dengan object storage kompatibel S3 di belakangnya. Mulai dari sana, pisahkan menjadi microservices hanya ketika satu komponen menjadi bottleneck.
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.