Pelajari mengapa database deret-waktu (TSDB) menjadi dasar metrik, monitoring, dan observabilitas—kueri cepat, kompresi efisien, dukungan kardinalitas tinggi, dan evaluasi peringatan yang andal.
Metrik adalah angka yang menggambarkan apa yang dilakukan sistem Anda—pengukuran yang bisa Anda plot, seperti latensi permintaan, tingkat error, penggunaan CPU, kedalaman antrean, atau pengguna aktif.
Monitoring adalah praktik mengumpulkan pengukuran itu, meletakkannya di dasbor, dan mengatur peringatan saat sesuatu terlihat salah. Jika tingkat error layanan checkout melonjak, monitoring harus memberi tahu Anda dengan cepat dan jelas.
Observabilitas melangkah lebih jauh: ini kemampuan Anda untuk memahami mengapa sesuatu terjadi dengan melihat beberapa sinyal bersama—biasanya metrik, log, dan trace. Metrik memberi tahu apa yang berubah, log memberi tahu apa yang terjadi, dan trace menunjukkan di mana waktu dihabiskan antar layanan.
Data deret-waktu adalah “nilai + cap waktu,” yang berulang terus-menerus.
Komponen waktu itu mengubah bagaimana Anda memakai data:
Database deret-waktu (TSDB) dioptimalkan untuk menerima banyak titik bercap waktu, menyimpannya secara efisien, dan mengkuerinya cepat pada rentang waktu.
TSDB tidak akan secara ajaib memperbaiki instrumentasi yang hilang, SLO yang tidak jelas, atau alert yang berisik. Ia juga tidak menggantikan log dan trace; TSDB melengkapi mereka dengan membuat alur kerja metrik jadi andal dan lebih hemat biaya.
Bayangkan Anda membuat grafik p95 latensi API setiap menit. Pada 10:05 latensi naik dari 180ms menjadi 900ms dan bertahan. Monitoring menaikkan alert; observabilitas membantu Anda mengaitkan lonjakan itu ke region, endpoint, atau deployment tertentu—mulai dari tren metrik dan menggali sinyal pendukung.
Metrik deret-waktu punya bentuk sederhana, tapi volume dan pola aksesnya membuatnya spesial. Setiap titik data biasanya timestamp + label/tag + nilai—misalnya: “2025-12-25 10:04:00Z, service=checkout, instance=i-123, p95_latency_ms=240”. Timestamp menambatkan kejadian dalam waktu, label menjelaskan siapa yang mengirimnya, dan nilai adalah apa yang Anda ukur.
Sistem metrik tidak menulis dalam batch sesekali. Mereka menulis terus-menerus, sering setiap beberapa detik, dari banyak sumber sekaligus. Itu menghasilkan aliran banyak tulis kecil: counter, gauge, histogram, dan summary yang datang tanpa henti.
Lingkungan yang sederhana pun bisa menghasilkan jutaan titik per menit ketika Anda mengalikan interval scrape dengan host, container, endpoint, region, dan feature flag.
Tidak seperti database transaksional di mana Anda mengambil “baris terbaru,” pengguna deret-waktu biasanya menanyakan:
Itu berarti kueri umum adalah pindai rentang, rollup (mis. 1s → rata-rata 1m), dan agregasi seperti persentil, rate, dan jumlah tergrup.
Data deret-waktu berharga karena memperlihatkan pola yang sulit dilihat dari kejadian terisolasi: lonjakan (insiden), musiman (siklus harian/mingguan), dan tren jangka panjang (peningkatan kapasitas, regresi bertahap). Database yang memahami waktu memudahkan penyimpanan aliran ini secara efisien dan kueri cepat untuk dasbor dan alerting.
TSDB adalah database yang dibangun khusus untuk data berurutan waktu—pengukuran yang datang terus menerus dan umumnya dikueri berdasarkan waktu. Dalam monitoring, itu biasanya metrik seperti penggunaan CPU, latensi permintaan, tingkat error, atau kedalaman antrean, masing-masing dicatat dengan timestamp dan satu set label (service, region, instance, dll.).
Tidak seperti database umum yang menyimpan baris untuk banyak pola akses, TSDB mengoptimalkan beban kerja metrik yang paling umum: menulis titik baru saat waktu bergerak maju dan membaca histori terbaru dengan cepat. Data biasanya diatur dalam potongan/blok berbasis waktu sehingga engine dapat memindai “5 menit terakhir” atau “24 jam terakhir” secara efisien tanpa menyentuh data yang tidak terkait.
Metrik sering numerik dan berubah perlahan. TSDB memanfaatkan itu dengan teknik encoding dan kompresi khusus (misalnya, delta antara timestamp berurutan, pola run-length, dan penyimpanan padat untuk set label yang berulang). Hasilnya: Anda bisa menyimpan lebih banyak histori dengan anggaran penyimpanan yang sama, dan kueri membaca lebih sedikit byte dari disk.
Data monitoring sebagian besar append-only: jarang memperbarui titik lama; Anda menambah yang baru. TSDB memanfaatkan pola ini dengan penulisan sekuensial dan ingest batch. Itu mengurangi I/O acak, menurunkan amplifikasi tulis, dan menjaga ingest stabil meskipun banyak metrik tiba sekaligus.
Kebanyakan TSDB menyediakan primitif kueri yang disesuaikan untuk monitoring dan dasbor:
Walau sintaks berbeda antar produk, pola-pola ini adalah fondasi untuk membangun dasbor dan evaluasi alert yang andal.
Monitoring adalah aliran fakta kecil yang tak pernah berhenti: tick CPU setiap beberapa detik, jumlah permintaan setiap menit, kedalaman antrean seharian. TSDB dibangun untuk pola itu—ingest kontinu plus pertanyaan “apa yang terjadi baru-baru ini?”—sehingga ia cenderung terasa lebih cepat dan lebih dapat diprediksi dibanding database umum saat digunakan untuk metrik.
Sebagian besar pertanyaan operasional adalah kueri rentang: "tunjukkan 5 menit terakhir", "bandingkan 24 jam terakhir", "apa yang berubah sejak deploy?" Penyimpanan dan pengindeksan TSDB dioptimalkan untuk memindai rentang waktu secara efisien, menjaga panel tetap responsif bahkan saat dataset berkembang.
Dasbor dan monitoring SRE mengandalkan agregasi lebih dari poin mentah. TSDB biasanya membuat operasi metrik umum menjadi efisien:
Operasi ini esensial untuk mengubah sampel berisik menjadi sinyal yang dapat diperingatkan.
Dasbor jarang membutuhkan setiap titik mentah selamanya. TSDB sering mendukung time bucketing dan rollup, sehingga Anda dapat menyimpan data resolusi tinggi untuk periode terbaru dan mengagregasi data lama untuk tren jangka panjang. Itu menjaga kueri cepat dan membantu mengendalikan penyimpanan tanpa kehilangan gambaran besar.
Metrik tidak datang dalam batch; mereka datang terus-menerus. TSDB dirancang agar beban tulis berat tidak menurunkan performa baca dengan cepat, membantu memastikan kueri "apakah sesuatu rusak sekarang?" tetap andal saat lonjakan trafik dan badai insiden.
Metrik menjadi kuat saat Anda bisa memotongnya berdasarkan label (juga disebut tag atau dimensi). Satu metrik seperti http_requests_total mungkin dicatat dengan dimensi seperti service, region, instance, dan endpoint—sehingga Anda bisa menjawab pertanyaan seperti "Apakah EU lebih lambat dari US?" atau "Apakah satu instance bermasalah?"
Kardinalitas adalah jumlah seri waktu unik yang dihasilkan metrik Anda. Setiap kombinasi nilai label adalah seri berbeda.
Contoh: jika Anda melacak satu metrik dengan:
…Anda sudah punya 20 × 5 × 200 × 50 = 1.000.000 seri waktu untuk satu metrik itu. Tambahkan beberapa label lagi (status code, method, tipe user) dan bisa melampaui kapasitas penyimpanan dan mesin kueri Anda.
Kardinalitas tinggi biasanya tidak gagal secara anggun. Titik sakit pertama cenderung:
Itu sebabnya toleransi kardinalitas tinggi menjadi pembeda kunci TSDB: beberapa sistem didesain untuk menanganinya; lainnya cepat menjadi tidak stabil atau mahal.
Aturan bagus: gunakan label yang terbatas dan bervariabilitas rendah-sedang, dan hindari label yang secara efektif tak terbatas.
Lebih baik:
service, region, cluster, environmentinstance (jika ukuran fleet dikendalikan)endpoint itu template route ternormalisasi (mis. , bukan )Hindari:
Jika Anda membutuhkan detil itu, simpan di log atau trace dan tautkan dari metrik lewat label yang stabil. Dengan begitu TSDB Anda tetap cepat, dasbor tetap dapat dipakai, dan alert tetap on-time.
Menyimpan metrik “selamanya” terdengar menarik—hingga tagihan penyimpanan membengkak dan kueri melambat. TSDB membantu Anda menyimpan data yang diperlukan, dengan detail yang diperlukan, untuk waktu yang diperlukan.
Metrik secara alami repetitif (seri sama, interval sampling tetap, perubahan kecil antar titik). TSDB memanfaatkan hal ini dengan kompresi khusus, sering menyimpan histori panjang dengan sebagian kecil dari ukuran mentah. Itu berarti Anda bisa mempertahankan lebih banyak data untuk analisis tren—perencanaan kapasitas, pola musiman, dan “apa yang berubah sejak kuartal lalu?”—tanpa bayar untuk disk sebesar itu.
Retensi hanyalah aturan berapa lama data disimpan.
Kebanyakan tim memecah retensi menjadi dua lapis:
Pendekatan ini mencegah data resolusi ultra-tinggi dari kemarin menjadi arsip mahal tahun depan.
Downsampling (atau rollup) menggantikan banyak titik mentah dengan lebih sedikit titik yang dirangkum—biasanya avg/min/max/count per bucket waktu. Terapkan saat:
Beberapa tim melakukan downsample otomatis setelah jendela raw berakhir; lainnya menyimpan raw lebih lama untuk layanan “hot” dan menurunkan resolusi lebih cepat untuk metrik berisik atau bernilai rendah.
Downsampling menghemat penyimpanan dan mempercepat kueri jangka panjang, tetapi Anda kehilangan detail. Misalnya, lonjakan CPU singkat mungkin hilang dalam rata-rata 1-jam, sementara rollup min/max dapat mempertahankan indikasi "ada sesuatu" tanpa menyimpan kapan tepatnya atau seberapa sering.
Aturan praktis: simpan raw cukup lama untuk debugging insiden terbaru, dan simpan rollup cukup lama untuk menjawab pertanyaan produk dan kapasitas.
Alert hanya sebaik kueri yang menopangnya. Jika sistem monitoring Anda tidak bisa cepat dan konsisten menjawab “apakah layanan ini tidak sehat sekarang?”, Anda akan melewatkan insiden atau menerima halaman karena noise.
Sebagian besar aturan alert menyusut ke pola kueri berikut:
rate() atas counter.TSDB penting di sini karena kueri-kueri ini harus memindai data terbaru cepat, menerapkan agregasi dengan benar, dan mengembalikan hasil sesuai jadwal.
Alert dievaluasi atas jendela (mis. “5 menit terakhir”). Masalah timing kecil bisa mengubah hasil:
Alert berisik sering berasal dari data hilang, sampling tak merata, atau ambang yang terlalu sensitif. Flapping—berganti cepat antara firing dan resolved—biasanya berarti aturan terlalu dekat dengan varians normal atau jendelanya terlalu pendek.
Tanggapi “no data” secara eksplisit (apakah itu masalah, atau hanya layanan menganggur?), dan utamakan alert berbasis rate/ratio daripada hitungan mentah bila trafik bervariasi.
Setiap alert harus menautkan ke dasbor dan runbook singkat: apa yang diperiksa pertama, seperti apa kondisi “baik”, dan bagaimana meredam. Bahkan /runbooks/service-5xx dan tautan dasbor sederhana bisa memangkas waktu respons secara drastis.
Observabilitas biasanya menggabungkan tiga tipe sinyal: metrik, log, dan trace. TSDB adalah penyimpan spesialis untuk metrik—titik data yang diindeks menurut waktu—karena ia dioptimalkan untuk agregasi cepat, rollup, dan pertanyaan “apa yang berubah dalam 5 menit terakhir?”.
Metrik adalah garis depan terbaik. Mereka ringkas, murah untuk dikueri pada skala, dan ideal untuk dasbor serta alerting. Dengan ini tim melacak SLO seperti "99.9% permintaan di bawah 300ms" atau "tingkat error di bawah 1%".
TSDB biasanya menopang:
Metrik memberi tahu bahwa ada masalah, tetapi tidak selalu mengapa.
Dalam praktiknya, TSDB berada di pusat monitoring sinyal cepat, sementara sistem log dan trace adalah bukti detail yang Anda konsultasikan setelah metrik menunjukkan kemana harus melihat.
Data monitoring paling berharga selama insiden—tepat saat sistem berada di bawah tekanan dan dasbor mendapat banyak permintaan. TSDB harus terus menerima dan menjawab kueri meski bagian infrastruktur menurun; jika tidak, Anda kehilangan timeline yang dibutuhkan untuk diagnosis dan pemulihan.
Kebanyakan TSDB skala secara horizontal dengan sharding data ke beberapa node (sering berdasarkan rentang waktu, nama metrik, atau hash label). Ini menyebar beban tulis dan memungkinkan menambah kapasitas tanpa mengubah arsitektur monitoring.
Untuk tetap tersedia saat node gagal, TSDB mengandalkan replikasi: menulis salinan data ke beberapa node atau zona. Jika satu replika tidak tersedia, baca dan tulis dapat berlanjut di replika sehat. Sistem yang baik juga mendukung failover sehingga pipeline ingest dan router kueri otomatis mengalihkan lalu lintas dengan gap minimal.
Lalu lintas metrik bersifat bursty—deploy, autoscaling, atau outage bisa menggandakan sampel. TSDB dan collector biasanya menggunakan buffer ingest (antrian, WAL, atau spooling disk lokal) untuk menyerap lonjakan singkat.
Saat TSDB tidak bisa mengejar, backpressure penting. Alih-alih menjatuhkan data tanpa pemberitahuan, sistem harus memberi sinyal ke klien untuk melambat, memprioritaskan metrik kritikal, atau menurunkan ingestion non-esensial secara terkendali.
Di organisasi besar, satu TSDB sering melayani banyak tim dan environment (prod, staging). Fitur multi-tenant—namespace, kuota per-tenant, dan batas kueri—membantu mencegah satu dashboard berisik atau job salah konfigurasi memengaruhi semua orang. Isolasi jelas juga menyederhanakan chargeback dan kontrol akses saat program monitoring Anda tumbuh.
Metrik sering terasa “non-sensitif” karena berupa angka, tetapi label dan metadata dapat mengungkap banyak: identifier pelanggan, hostname internal, bahkan petunjuk insiden. Setup TSDB yang baik memperlakukan data metrik seperti dataset produksi lainnya.
Mulailah dengan dasar: enkripsi lalu lintas dari agen/collector ke TSDB menggunakan TLS, dan autentikasi setiap penulis. Kebanyakan tim mengandalkan token, API key, atau kredensial jangka pendek yang dikeluarkan per-service atau environment.
Aturan praktis: jika token bocor, radius kerusakan harus kecil. Gunakan kredensial tulis terpisah per tim, per cluster, atau per namespace—sehingga Anda bisa mencabut akses tanpa merusak seluruh sistem.
Membaca metrik bisa sama sensitifnya dengan menulisnya. TSDB Anda harus mendukung kontrol akses yang sejajar dengan cara organisasi bekerja:
Cari kontrol berbasis peran dan skoping menurut project, tenant, atau namespace. Ini mengurangi ekspos data tak sengaja dan menjaga dasbor serta alerting selaras dengan kepemilikan.
Banyak "kebocoran metrik" terjadi melalui label: user_email, customer_id, URL lengkap, atau fragmen payload. Hindari memasukkan data pribadi atau identifier unik ke label metrik. Jika butuh debugging level-user, pakai log atau trace dengan kontrol lebih ketat dan retensi lebih pendek.
Untuk kepatuhan, Anda mungkin perlu menjawab: siapa mengakses metrik apa dan kapan? Pilih TSDB (dan gateway di sekitarnya) yang menghasilkan log audit untuk autentikasi, perubahan konfigurasi, dan akses baca—sehingga investigasi dan review berdasarkan bukti.
Memilih TSDB lebih tentang mencocokkan produk dengan realitas metrik Anda: berapa banyak data yang Anda hasilkan, bagaimana Anda mengkuerinya, dan apa yang dibutuhkan tim on-call pukul 2 pagi.
Sebelum membandingkan vendor atau opsi open-source, tuliskan jawaban untuk:
TSDB terkelola mengurangi pemeliharaan (upgrade, scaling, backup), sering dengan SLA yang bisa diprediksi. Trade-off: biaya, kontrol lebih sedikit atas internals, dan kadang keterbatasan fitur kueri atau egress data.
TSDB self-hosted bisa lebih murah pada skala dan memberi fleksibilitas, tetapi Anda bertanggung jawab atas capacity planning, tuning, dan respons insiden untuk databasenya.
TSDB jarang berdiri sendiri. Pastikan kompatibilitas dengan:
Batasi waktu PoC (1–2 minggu) dan definisikan kriteria lulus/gagal:
"TSDB terbaik" adalah yang memenuhi kebutuhan kardinalitas dan kueri Anda sambil menjaga biaya dan beban operasional dapat diterima.
TSDB penting untuk observabilitas karena membuat metrik berguna: kueri cepat untuk dasbor, evaluasi alert yang dapat diprediksi, dan kemampuan menangani banyak data berlabel (termasuk beban kerja kardinalitas lebih tinggi) tanpa mengubah setiap label baru menjadi kejutan biaya dan performa.
Mulai kecil dan buat kemajuan terlihat:
Jika Anda mengembangkan dan merilis layanan cepat memakai workflow vibe-coding (mis. membuat React app + backend Go dengan PostgreSQL), layak menjadikan observabilitas bagian dari jalur delivery—bukan pemikiran belakangan. Platform seperti Koder.ai membantu tim iterasi cepat, tetapi Anda tetap ingin nama metrik konsisten, label stabil, dan paket dasbor/alert standar supaya fitur baru tidak muncul “gelap” di produksi.
Tulis panduan satu halaman yang mudah diikuti:
service_component_metric (mis. checkout_api_request_duration_seconds).Instrumen jalur permintaan kunci dan job background dulu, lalu perluas cakupan. Setelah dasbor baseline ada, jalankan review observabilitas singkat di tiap tim: apakah grafik menjawab "apa yang berubah?" dan "siapa yang terpengaruh?" Jika tidak, perbaiki label dan tambahkan sejumlah kecil metrik bernilai tinggi daripada meningkatkan volume secara membabi buta.
Metrik adalah pengukuran numerik (latensi, tingkat error, CPU, kedalaman antrean). Monitoring adalah pengumpulan metrik tersebut, memvisualisasikannya, dan memberikan peringatan saat terlihat bermasalah. Observabilitas adalah kemampuan menjelaskan mengapa metrik itu bermasalah dengan menggabungkan metrik dengan log (apa yang terjadi) dan trace (di mana waktu dihabiskan antar layanan).
Data deret-waktu adalah data kontinu nilai + cap waktu, sehingga pertanyaan yang umum adalah rentang waktu (15 menit terakhir, sebelum/setelah deploy) dan operasi yang sering dipakai adalah agregasi (avg, p95, rate) daripada mengambil baris individual. Itu membuat tata letak penyimpanan, kompresi, dan performa pemindaian rentang jauh lebih penting dibanding beban kerja transaksional biasa.
TSDB dioptimalkan untuk beban kerja metrik: tingkat tulis tinggi, umumnya append-only, dan kueri rentang-waktu cepat dengan fungsi monitoring umum (bucketing, rollup, rate, persentil, group-by label). Dirancang agar dasbor dan evaluasi alert tetap responsif saat volume data tumbuh.
Tidak otomatis. TSDB memperbaiki mekanika penyimpanan dan kueri metrik, tetapi Anda tetap membutuhkan:
Tanpa itu, Anda bisa saja punya dasbor cepat yang tidak membantu mengambil tindakan.
Metrik memberikan deteksi cepat dan pelacakan tren, tapi detailnya terbatas. Gunakan:
Gunakan metrik untuk mendeteksi dan mempersempit, lalu pivot ke log/trace untuk bukti detail.
Kardinalitas adalah jumlah seri unik yang dibuat oleh kombinasi label. Ia meledak ketika Anda menambahkan dimensi seperti instance, endpoint, status code, atau—yang terburuk—ID tanpa batas. Kardinalitas tinggi biasanya menyebabkan:
Seringkali ini adalah penyebab pertama sistem metrik menjadi mahal atau tidak stabil.
Pilih label yang nilainya terbatas dan bermakna:
service, , , , yang ternormalisasi (route template)Retensi mengontrol biaya dan kecepatan kueri. Setup umum:
Downsampling menukar presisi dengan penyimpanan lebih murah dan kueri lebih cepat; menyimpan min/max bersama rata-rata dapat mempertahankan sinyal "ada sesuatu".
Kebanyakan aturan alert berbasis rentang dan agregasi (threshold, rate/ratio, perbandingan anomali). Jika kueri lambat atau ingest terlambat, Anda dapat mengalami flapping, insiden terlewat, atau paging tertunda. Langkah praktis:
rate/ratio daripada hitungan mentah saat trafik bervariasiValidasi kecocokan dengan rollout kecil dan terukur:
PoC singkat dengan dasbor nyata dan kueri alert sering lebih bernilai daripada daftar fitur.
/users/:id/users/12345regionclusterenvironmentendpointinstance jika fleetnya sering bergantiSimpan identifikasi detail di log/trace dan biarkan label metrik fokus pada pengelompokan dan triase.
/runbooks/service-5xx)