# Menskalakan Storage Prometheus dengan Grafana Mimir > Cara saya mengirim metrik Prometheus ke Grafana Mimir lewat remote_write untuk storage jangka panjang yang skalabel horizontal, multi-tenant, dan cepat di-query. URL: https://www.matthewswong.com/id/blog/prometheus-remote-write-mimir-scaling/ - Author: Matthews Wong (https://www.matthewswong.com/id/about/) - Published: 2026-07-11 - Updated: 2026-07-11 - Category: DevOps > **Key takeaway:** 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: 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. > 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: 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. > 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. ## Sources - Grafana Mimir architecture — official documentation - Grafana Mimir store-gateway component - Prometheus Remote-Write specification ## Source links - https://grafana.com/docs/mimir/latest/get-started/about-grafana-mimir-architecture/ - https://grafana.com/docs/mimir/latest/references/architecture/components/store-gateway/ - https://prometheus.io/docs/specs/prw/remote_write_spec/ ## FAQ ### Grafana Mimir digunakan untuk apa? Grafana Mimir adalah backend storage jangka panjang open-source yang skalabel horizontal untuk metrik Prometheus. Ia menerima data lewat protokol remote_write Prometheus, menyimpannya sebagai block TSDB di object storage seperti S3, GCS, atau Azure Blob, dan melayani query PromQL. Ia juga menambahkan multi-tenancy dan high availability yang tidak dimiliki satu Prometheus. ### Bagaimana cara mengirim metrik Prometheus ke Mimir? Tambahkan blok remote_write di prometheus.yml yang mengarah ke endpoint push Mimir di /api/v1/push. Anda wajib menyertakan header X-Scope-OrgID yang menyebut tenant, karena Mimir menolak tulisan tanpa itu. Prometheus lalu mengalirkan sampel secara asinkron dari write-ahead log-nya sambil tetap scraping dan melayani query lokal. ### Apakah remote_write menggantikan storage Prometheus lokal? Tidak. remote_write bersifat aditif — Prometheus tetap memakai TSDB lokalnya dan meneruskan salinan setiap sampel ke endpoint remote. Pertahankan retensi lokal beberapa jam atau hari agar Anda punya fallback cepat untuk data terkini dan buffer yang me-replay jika Mimir sementara tidak terjangkau. ### Bagaimana Mimir menangani banyak tenant? Setiap request tulis dan baca membawa header X-Scope-OrgID yang mengidentifikasi tenant. Mimir menyimpan block tiap tenant secara terpisah di object storage dan menegakkan limit per-tenant seperti ingestion rate, max series, dan periode retensi. Ini memungkinkan satu cluster melayani beberapa tim atau proyek tanpa data atau pemakaian resource mereka bertabrakan. ### Kenapa query jangka panjang saya di Mimir lambat? Biasanya compactor tidak berjalan atau tidak ada query cache. Compactor menggabungkan ribuan block dua jam kecil menjadi block yang lebih besar, tuas terbesar untuk latensi baca. Menambahkan results cache ke query-frontend dan store-gateway, serta memantau kardinalitas series yang liar, menyelesaikan sebagian besar perlambatan. --- - HTML version: https://www.matthewswong.com/id/blog/prometheus-remote-write-mimir-scaling/ - English: https://www.matthewswong.com/en/blog/prometheus-remote-write-mimir-scaling/ - Site index for agents: https://www.matthewswong.com/llms.txt - Sitemap: https://www.matthewswong.com/sitemap.xml - API description (OpenAPI): https://www.matthewswong.com/openapi.json