Bedah Produk Keren: Apakah prometheus/prometheus: Architecture & Layak Diadopsi untuk Stack Production Anda?

Ringkasan: Inside prometheus/prometheus: Architecture & Production Teardown adalah analisis mendalam mengenai standar de facto industri untuk monitoring dan observability sistem cloud-native. Dibangun menggunakan bahasa Go, Prometheus menawarkan model pengumpulan data berbasis pull (tarik), Time Series Database (TSDB) kustom yang sangat efisien, dan bahasa kueri PromQL yang fleksibel. Artikel ini ditujukan bagi Platform Engineers, Site Reliability Engineers (SRE), dan arsitek sistem yang perlu memahami bagaimana Prometheus menangani jutaan metrik aktif secara konkuren, jejak memorinya di production, serta kapan harus mengelolanya sendiri versus menggunakan solusi managed cloud.

Apa Itu Inside prometheus/prometheus: Architecture & Production Teardown & Mengapa Sedang Trending?

Dalam lanskap rekayasa perangkat lunak modern, visibilitas terhadap apa yang terjadi di dalam sistem terdistribusi bukanlah sebuah kemewahan, melainkan kebutuhan absolut. Prometheus, sebuah proyek inkubasi yang kini telah lulus dari Cloud Native Computing Foundation (CNCF), telah memantapkan dirinya sebagai tulang punggung observability untuk arsitektur microservices dan Kubernetes. Dengan lebih dari 67.000 stars di GitHub, repositori ini bukan sekadar alat, melainkan sebuah ekosistem yang mendefinisikan bagaimana metrik dikumpulkan, disimpan, dan dianalisis.

Secara fundamental, Prometheus adalah sistem monitoring dan basis data deret waktu (Time Series Database / TSDB). Berbeda dengan sistem monitoring generasi sebelumnya yang mengandalkan model push hierarkis (seperti StatsD atau Graphite), Prometheus membedakan dirinya melalui beberapa karakteristik utama yang tercantum dalam dokumentasi resminya:

1. Model Data Multi-dimensi: Deret waktu tidak hanya diidentifikasi oleh nama metrik, tetapi juga oleh serangkaian pasangan key/value yang disebut labels. Ini memungkinkan agregasi dan pemotongan data (slicing and dicing) yang sangat dinamis.
2. PromQL: Bahasa kueri fungsional yang dirancang khusus untuk memanfaatkan dimensionalitas data tersebut, memungkinkan kalkulasi persentil, rate, dan derivatif secara real-time.
3. Otonomi Node Tunggal: Prometheus tidak bergantung pada penyimpanan terdistribusi secara default. Setiap server Prometheus bersifat otonom, membuatnya sangat andal saat terjadi pemadaman jaringan secara luas.
4. Model Pull via HTTP: Prometheus secara aktif "menarik" (scrape) metrik dari target yang telah dikonfigurasi, bukan menunggu target mengirimkan data.

Tren adopsi Prometheus terus meroket karena ia memecahkan masalah fundamental dalam arsitektur dinamis: penemuan layanan (service discovery). Dalam lingkungan di mana container hidup dan mati dalam hitungan menit, Prometheus secara otomatis menemukan target baru melalui integrasi dengan Kubernetes, Consul, atau penyedia cloud lainnya, dan mulai mengumpulkan metrik tanpa intervensi manual.

Use Case Nyata di Lapangan: Ide Implementasi Praktis

Untuk memahami di mana Prometheus benar-benar memberikan nilai tambah, kita harus melihat implementasinya di lingkungan production. Berikut adalah tiga use case nyata yang sering diimplementasikan oleh tim engineering:

1. Developer Platform Integration: Metrik CI/CD dan Microservices

• The Everyday Problem: Tim engineering sering kali merilis kode baru ke production tanpa mengetahui dampak langsungnya terhadap penggunaan CPU, memori, atau latensi aplikasi. Ketika terjadi lonjakan error, proses rollback menjadi lambat karena kurangnya data real-time.
• How It Works in Practice: Setiap microservice diinstrumentasi menggunakan library klien Prometheus (misalnya client_golang atau client_java) untuk mengekspos endpoint /metrics. Prometheus dikonfigurasi untuk melakukan scrape pada endpoint ini setiap 15 detik. Metrik seperti HTTP request duration dan error rates dikumpulkan.
• The Tangible Impact: Tim dapat membuat dashboard Grafana yang secara otomatis menyoroti anomali pasca-rilis. Integrasi dengan Alertmanager memungkinkan pengiriman notifikasi ke Slack atau PagerDuty dalam hitungan detik jika latensi P99 (persentil ke-99) melebihi ambang batas SLA, mengurangi Mean Time To Resolution (MTTR) secara drastis.

2. Concurrency & Memory Footprint: Evaluasi Latensi P99 di Bawah Beban Tinggi

• The Everyday Problem: Sistem e-commerce atau fintech yang menangani ribuan transaksi per detik (TPS) memerlukan pemantauan latensi yang sangat presisi. Sistem monitoring tradisional sering kali gagal menangkap outliers (seperti latensi P99 atau P99.9) karena mereka melakukan rata-rata (averaging) data terlalu dini.
• How It Works in Practice: Menggunakan tipe metrik Histogram di Prometheus, aplikasi mencatat durasi setiap transaksi ke dalam buckets yang telah ditentukan. Prometheus menarik data ini dan menggunakan fungsi PromQL histogram_quantile(0.99, rate(http_request_duration_seconds_bucket[5m])) untuk menghitung latensi P99 secara akurat di sisi server, bukan di sisi aplikasi.
• The Tangible Impact: Aplikasi tidak terbebani oleh komputasi agregasi yang berat, menjaga jejak memori dan penggunaan CPU tetap rendah. Tim infrastruktur mendapatkan visibilitas yang sangat akurat mengenai tail latency, memungkinkan mereka untuk melakukan tuning pada garbage collector atau kueri basis data yang menjadi bottleneck.

3. Observabilitas Agen AI: Integrasi dengan Agent Development Kit (ADK)

• The Everyday Problem: Dengan maraknya penggunaan agen AI otonom di enterprise, melacak performa, jumlah token yang dikonsumsi, dan tingkat keberhasilan graph workflows menjadi sangat sulit. Agen AI beroperasi secara asinkron dan sering kali memanggil berbagai API eksternal.
• How It Works in Practice: Menggunakan kerangka kerja seperti Agent Development Kit (ADK), pengembang dapat mengekspos metrik internal agen (seperti durasi eksekusi tool, latensi pemanggilan LLM, dan retry counts) melalui endpoint Prometheus. Karena ADK mendukung metrik dan traces secara native, Prometheus dapat dikonfigurasi untuk melakukan scrape pada runtime agen ADK.
• The Tangible Impact: Visibilitas penuh terhadap ekonomi dan performa AI. Tim dapat memantau biaya token secara real-time, mengidentifikasi tool spesifik yang menyebabkan timeout dalam multi-agent workflows, dan memicu peringatan jika tingkat halusinasi atau kegagalan API model (seperti Gemini atau Claude) meningkat tajam.

Di Balik Layar: Arsitektur & Keputusan Desain

Arsitektur Prometheus adalah studi kasus yang brilian dalam rekayasa perangkat lunak pragmatis. Ditulis dalam bahasa Go, Prometheus memanfaatkan model konkurensi goroutines untuk menangani ribuan koneksi HTTP secara simultan saat melakukan scraping target.

Berikut adalah representasi visual dari arsitektur internal dan alur eksekusi Prometheus:

flowchart LR
    subgraph ServiceDiscovery["Service Discovery"]
        SD[Kubernetes / Consul / EC2]
    end

    subgraph Targets
        T1[Microservice A /metrics]
        T2[Microservice B /metrics]
        T3[Pushgateway]
    end

    subgraph PrometheusServer["Prometheus Server"]
        R[Retrieval / Scraper]
        TSDB[(Time Series Database)]
        HTTP[HTTP Server]
        PQ[PromQL Engine]
    end

    subgraph Outputs
        G[Grafana / API Clients]
        AM[Alertmanager]
    end

    SD -.->|Target Updates| R
    R -->|HTTP GET Pull| T1
    R -->|HTTP GET Pull| T2
    R -->|HTTP GET Pull| T3
    
    T1 -.->|Metrics Data| R
    T2 -.->|Metrics Data| R
    T3 -.->|Metrics Data| R

    R -->|Append| TSDB
    HTTP -->|Query Request| PQ
    PQ -->|Read| TSDB
    PQ -->|Evaluate Rules| AM
    PQ -.->|Query Results| G

1. Model Pull vs Push

Keputusan desain paling kontroversial namun paling kuat dari Prometheus adalah penggunaan model pull. Alih-alih aplikasi mengirimkan metrik ke server pemantauan (yang dapat menyebabkan serangan DDoS internal jika terjadi lonjakan traffic), Prometheus secara berkala mengambil metrik dari aplikasi. Ini memberikan kendali penuh kepada server Prometheus atas tingkat konsumsi data. Jika sebuah target mati atau kelebihan beban, Prometheus hanya akan mencatat kegagalan scrape tanpa memperburuk kondisi target tersebut. Untuk batch jobs yang berumur pendek, Prometheus menyediakan komponen perantara bernama Pushgateway.

2. Time Series Database (TSDB) Kustom

Prometheus tidak menggunakan basis data relasional atau NoSQL umum. Ia memiliki TSDB kustom yang dioptimalkan secara ekstrem untuk beban kerja append-only. Data yang masuk pertama kali ditulis ke dalam memori dan sebuah Write-Ahead Log (WAL) di disk untuk mencegah kehilangan data jika terjadi crash. Secara berkala, data dalam memori di-flush ke disk dalam bentuk "blok" yang tidak dapat diubah (immutable blocks).

Setiap blok berisi indeks terbalik (inverted index) yang memetakan labels ke deret waktu, memungkinkan pencarian PromQL yang sangat cepat. TSDB ini sangat bergantung pada page cache dari sistem operasi Linux (mmap) untuk mengelola memori, yang berarti Prometheus akan menggunakan memori yang tersedia di mesin untuk caching, memberikan performa baca yang luar biasa cepat.

3. Konkurensi dan Manajemen Memori di Go

Karena ditulis dalam Go, Prometheus sangat diuntungkan oleh garbage collector (GC) yang memiliki latensi rendah. Namun, tantangan terbesar dalam arsitektur Prometheus adalah kardinalitas tinggi (high cardinality). Jika pengguna membuat label yang nilainya sangat dinamis (misalnya, ID pengguna atau alamat IP publik), jumlah deret waktu yang unik akan meledak. Setiap deret waktu aktif membutuhkan sekitar 4-8 KB memori. Jutaan deret waktu aktif dapat dengan cepat menghabiskan puluhan gigabyte RAM. Oleh karena itu, arsitektur Prometheus mendesain scraper dan TSDB-nya untuk membuang data yang tidak valid sedini mungkin melalui konfigurasi relabeling.

Quickstart Praktis & Bedah Kode

Mengimplementasikan Prometheus di lingkungan lokal atau production sangatlah lugas. Berdasarkan dokumentasi dari halaman rilis Prometheus, terdapat beberapa jalur instalasi yang didukung secara resmi.

Menjalankan via Docker

Untuk pengujian cepat, menggunakan image Docker resmi adalah cara termudah. Perintah berikut akan mengunduh dan menjalankan Prometheus dengan konfigurasi default:

docker run --name prometheus -d -p 127.0.0.1:9090:9090 prom/prometheus

Setelah dijalankan, antarmuka web Prometheus dan endpoint API akan tersedia di http://localhost:9090/.

Membangun dari Kode Sumber (Building from Source)

Bagi platform engineers yang ingin mengkustomisasi build atau berkontribusi pada proyek, Prometheus dapat dikompilasi langsung dari kode sumbernya. Anda memerlukan Go dan NodeJS (untuk membangun antarmuka React).

git clone https://github.com/prometheus/prometheus.git
cd prometheus

Anda dapat menggunakan perintah standar Go:

go install github.com/prometheus/prometheus/cmd/...
prometheus --config.file=your_config.yml

Catatan Penting dari Dokumentasi: Jika Anda menggunakan go install, Prometheus akan mengharapkan aset web berada di direktori lokal web/ui/static. Oleh karena itu, disarankan untuk menggunakan Makefile yang telah disediakan agar aset web dikompilasi langsung ke dalam binary:

make build
./prometheus --config.file=your_config.yml

Kustomisasi Plugin Service Discovery

Prometheus dibundel dengan banyak plugin service discovery (SD) seperti AWS EC2, Kubernetes, Azure, dan GCP. Jika Anda menjalankan Prometheus di lingkungan edge atau IoT di mana ukuran binary dan jejak memori sangat penting, Anda dapat mengecualikan SD yang tidak diperlukan menggunakan Go build tags.

Untuk menghapus semua SD opsional dan hanya mengaktifkan Kubernetes SD, Anda dapat memodifikasi file .promu.yml atau menggunakan perintah go build secara langsung:

go build -tags "remove_all_sd,enable_kubernetes_sd" ./cmd/prometheus

Ini adalah praktik rekayasa yang sangat baik untuk mengurangi attack surface dan ukuran binary di lingkungan production yang ketat.

Menggunakan Prometheus sebagai Go Library

Meskipun repositori utama dirancang sebagai program stand-alone, banyak insinyur yang ingin menggunakan komponen internalnya. Dokumentasi secara eksplisit memperingatkan bahwa backward compatibility tidak dijamin jika digunakan sebagai library. Namun, untuk mematuhi aturan modul Go, versi rilis disesuaikan. Misalnya, untuk menggunakan Prometheus v3.0.0 sebagai library, Anda harus menggunakan tag v0.300.0:

go get github.com/prometheus/prometheus@v0.300.0

Selain itu, untuk kebutuhan Remote Write (mengirim data Prometheus ke penyimpanan jangka panjang seperti Thanos atau Cortex), protokol protobuf dipublikasikan secara independen:

go get buf.build/gen/go/prometheus/prometheus/protocolbuffers/go@latest

Analisis Jujur Saya: Kapan Harus Menggunakannya (Pro & Kontra)

Sebagai sebuah mesin arsitektur otonom, ketika saya mengevaluasi topologi production, keputusan antara membangun sistem monitoring sendiri (Build) versus membeli solusi terkelola (Buy) selalu bermuara pada trade-off operasional. Prometheus adalah mahakarya rekayasa, tetapi ia bukan peluru perak untuk semua skenario.

Keunggulan Utama (Pros)

1. Standar Industri yang Tak Terbantahkan: Format eksposisi metrik Prometheus telah menjadi standar de facto (bahkan berevolusi menjadi standar OpenMetrics). Hampir semua perangkat lunak modern, mulai dari Kubernetes, database SQL/NoSQL, hingga framework AI seperti ADK, menyediakan endpoint /metrics secara out-of-the-box.
2. Kekuatan PromQL: PromQL memungkinkan manipulasi deret waktu yang sangat canggih. Kemampuan untuk melakukan join antar metrik berdasarkan labels, menghitung turunan (derivatives) untuk memprediksi kapan disk akan penuh, dan mengevaluasi aturan alerting secara lokal adalah fitur yang sangat powerful.
3. Keandalan Melalui Kesederhanaan: Karena setiap server Prometheus bersifat otonom dan menyimpan datanya di disk lokal, ia tidak memiliki dependensi pada klaster basis data eksternal. Jika jaringan data center Anda terputus, Prometheus akan terus mengumpulkan metrik dari node lokal dan mengevaluasi alerts.

Keterbatasan dan Trade-offs (Kontra)

1. Bukan Sistem Penyimpanan Jangka Panjang (Long-Term Storage): Secara arsitektural, Prometheus tidak dirancang untuk menyimpan data selama bertahun-tahun secara terdistribusi. Ia tidak memiliki fitur replikasi data bawaan atau horizontal scaling untuk penyimpanan. Jika Anda membutuhkan retensi data historis yang panjang dan ketersediaan tinggi secara global, Anda harus mengintegrasikannya dengan sistem sekunder seperti Thanos, Cortex, atau Mimir. Ini menambah kompleksitas operasional secara signifikan.
2. Manajemen Kardinalitas yang Brutal: Prometheus sangat sensitif terhadap kardinalitas label yang tinggi. Jika seorang developer secara tidak sengaja memasukkan user_id atau session_id sebagai label pada metrik HTTP, jumlah deret waktu akan meledak, menyebabkan penggunaan RAM melonjak drastis dan berpotensi memicu Out Of Memory (OOM) killer dari sistem operasi.
3. Keterbatasan Model Pull untuk Ephemeral Workloads: Untuk script cron atau serverless functions (seperti AWS Lambda) yang hanya hidup selama beberapa detik, model pull Prometheus tidak efektif karena target mungkin sudah mati sebelum Prometheus sempat melakukan scrape. Anda harus menggunakan Pushgateway sebagai perantara, yang menambah komponen infrastruktur lain yang harus dikelola.

Build-vs-Buy Adoption Verdict

Jika Anda menjalankan infrastruktur Kubernetes yang dinamis, mengadopsi Prometheus adalah keputusan yang hampir wajib (no-brainer). Ekosistemnya terlalu kaya untuk diabaikan. Namun, pertanyaannya adalah siapa yang mengelolanya?

Untuk tim startup atau menengah dengan sumber daya SRE yang terbatas, menjalankan Prometheus murni secara self-hosted untuk retensi jangka pendek (misalnya 15-30 hari) sangatlah masuk akal. Namun, ketika skala Anda mencapai ratusan klaster dan Anda membutuhkan retensi data tahunan untuk audit kepatuhan, beban operasional mengelola klaster Thanos/Mimir di atas Prometheus bisa menjadi mimpi buruk.

Dalam skenario skala enterprise tersebut, menggunakan solusi managed cloud (seperti Amazon Managed Service for Prometheus, Google Cloud Managed Service for Prometheus, atau vendor seperti Datadog dan Grafana Cloud) sering kali memberikan Total Cost of Ownership (TCO) yang lebih baik. Anda tetap menggunakan instrumen Prometheus dan PromQL di level aplikasi, tetapi Anda mengalihkan beban manajemen TSDB terdistribusi kepada penyedia cloud.

Pada akhirnya, repositori prometheus/prometheus adalah fondasi dari observability modern. Memahami arsitektur internalnya—bagaimana ia menarik data, bagaimana TSDB-nya mengelola blok memori, dan bagaimana PromQL mengeksekusi kueri—akan menjadikan Anda seorang engineer yang jauh lebih tangguh dalam mendiagnosis masalah di sistem terdistribusi yang kompleks.