Design Realtime Monitoring

Prompt latihan

1. Problem Statement, Functional Requirements, and Scale Assumptions

   Tentukan ruang lingkup sistem monitoring real-time: layanan memancarkan metrik (counter, gauge, histogram), sistem menyimpan metrik sebagai time series, operator men-query metrik via dashboard, aturan alert memicu notifikasi saat ambang batas dilampaui, dan data historis di-downsample serta diretensi dalam tier. Kecualikan secara eksplisit: agregasi log (gaya ELK), distributed tracing (Jaeger/Zipkin), alur manajemen insiden, dan APM (application performance monitoring) dengan profiling level-kode. Nyatakan asumsi skala: data point metrik yang di-ingest per detik, jumlah time series unik (kardinalitas), penonton dashboard bersamaan, jumlah aturan alert aktif, dan tier retensi metrik (raw, agregat 5-menit, agregat 1-jam).

2. Non-Functional Requirements

   Tentukan NFR utama: latensi ingestion metrik (waktu dari layanan memancarkan metrik hingga dapat di-query, target < 30 detik untuk dashboard real-time), latensi query dashboard (dashboard dengan 20 panel harus dimuat dalam < 5 detik, pra-agregasi apa yang dibutuhkan?), latensi pemicu alert (waktu dari pelanggaran ambang hingga notifikasi, target < 60 detik untuk alert kritis), durabilitas metrik (kehilangan metrik saat ingest dapat diterima untuk dashboarding; tidak dapat diterima untuk metrik billing/SLA), dan pengelolaan kardinalitas-tinggi (metrik dengan label user_id menghasilkan satu time series per pengguna, pada 10 juta pengguna ini menciptakan 10 juta time series; bagaimana kardinalitas dikelola?).

3. Quantitative Analysis

   Estimasikan: data point metrik yang di-ingest per detik (1 juta layanan × 100 metrik/layanan × 1 sample/10s = 10 juta data point/detik, memerlukan sharding TSDB horizontal), storage per time series per tier (10 juta data point/s × 16 byte/data point × 86400s = 13,8TB/hari raw, downsampling ke agregat 5-menit mengurangi 300×), throughput evaluasi aturan alert (100 ribu aturan alert × 1 eval/30s = ~3 ribu eval/detik, distribusikan ke beberapa evaluator), fan-out query dashboard (20 panel/dashboard × 100 penonton bersamaan × 1 query TSDB masing-masing = 2.000 query TSDB simultan, memerlukan caching query atau pra-agregasi), dan kardinalitas: 10 juta time series unik × 64 byte metadata label = 640MB indeks, dapat dikelola di memori.

4. API Design

   Tentukan operasi API untuk: ingestion metrik (POST /metrics/batch, menerima batch [{metric_name, labels: {key:value}, value, timestamp}]; 202 Accepted), query metrik (GET /query?expr=sum(rate(http_requests[5m]))&start=&end=&step=, ekspresi mirip-PromQL, mengembalikan time series), pemuatan dashboard (GET /dashboards/{id}/data, data panel pra-agregat untuk latensi rendah), manajemen aturan alert (POST /alerts/rules, {name, expr, threshold, severity, notification_channels}), dan status alert (GET /alerts/active, mengembalikan alert yang sedang menyala dengan pengelompokan). Bahas trade-off ingestion push vs. pull dan bagaimana ingestion metrik batch mengurangi overhead per-request.

5. High-Level Design

   Usulkan komponen utama: metric ingestion gateway (menerima batch metrik, memvalidasi, merutekan ke shard TSDB), time series database (TSDB, menyimpan data time series terkompresi; di-shard berdasarkan hash nama metrik; menggunakan storage LSM-tree untuk ingest write-optimized), query engine (memproses query PromQL, fan-out ke shard TSDB, mengagregasi hasil), dashboard service (menyajikan data panel pra-agregat dari lapisan caching), alert evaluator (mengevaluasi aturan alert terhadap TSDB terjadwal; mem-publish alert ke notification service), notification service (merutekan alert ke PagerDuty, Slack, email), dan downsampling pipeline (me-roll up data raw ke agregat 5-menit dan 1-jam, mengelola tier retensi). Jelaskan bagaimana query dashboard untuk 1 jam terakhir disajikan dari data pra-agregat alih-alih time series raw.

6. Additional High-Level Design Prompts

   Bahas tiga area lanjutan: (1) Ingestion metrik push vs. pull, push: layanan memanggil POST /metrics/batch; latensi rendah, layanan mengontrol timing, tetapi layanan harus tahu endpoint-nya; pull (gaya Prometheus): sistem monitoring mem-scrape metrik dari endpoint /metrics layanan terjadwal; lebih terkontrol (tidak ada burst dari semua layanan sekaligus), tetapi memerlukan service discovery; untuk desain ini, push lebih sederhana dan latensi lebih rendah, pilih push dengan batching; (2) Pra-agregasi vs. agregasi saat-query, saat-query: semua kalkulasi berjalan saat query terhadap TSDB raw; fleksibel (dimensi apa pun), tetapi mahal pada skala besar; pra-agregasi: pra-komputasi agregasi umum (per layanan, per region, rollup 5-menit) saat ingest; query dashboard mengenai store pra-agregat; trade-off: dimensi agregasi tetap kehilangan fleksibilitas untuk query ad-hoc; strategi: pra-agregasi untuk panel dashboard yang diketahui, izinkan saat-query untuk eksplorasi ad-hoc dengan batas kardinalitas; (3) Isolasi multi-tenancy, pada platform monitoring SaaS, tenant tidak boleh melihat metrik satu sama lain; strategi: namespace metrik berdasarkan tenant_id saat ingestion; shard TSDB ditugaskan per-tenant atau dibagikan dengan filtering label tenant; query engine menegakkan filter tenant_id pada setiap query; aturan alert dicakup ke tenant_id.

7. Deep Dives

   Deep dive ke tiga area: (1) Supresi alert fatigue, masalah: satu root cause tunggal (mis. overload database) dapat memicu ratusan alert dari layanan dependen secara bersamaan, membanjiri engineer on-call; solusi: (a) pengelompokan alert, kelompokkan alert dengan label yang sama (service, region) menjadi satu notifikasi; kirim notifikasi grup hanya sekali; (b) aturan inhibisi, jika alert severity-tinggi menyala (mis. database_down), inhibisi alert severity-lebih-rendah yang secara kausal di hilir (mis. api_error_rate_high); (c) rantai eskalasi, alert menuju on-call L1 dulu; jika tidak di-acknowledge dalam N menit, eskalasi ke L2; (d) ambang adaptif, alih-alih ambang statis (error_rate > 1%), alert saat error_rate N standar deviasi di atas baseline mingguan untuk waktu-hari ini (mencegah false positive selama pola trafik yang diharapkan); (2) Kardinalitas metrik, masalah: satu metrik dengan label user_id pada 10 juta pengguna menciptakan 10 juta time series; indeks TSDB tumbuh menjadi 640MB, tekanan kompaksi meningkat, kecepatan ingest menurun; solusi: (a) batas kardinalitas saat ingestion, tolak tulis metrik jika kombinasi label unik metrik melebihi batas yang dikonfigurasi; (b) relabeling pipeline, ganti nilai label kardinalitas-tinggi dengan 'other' (mis. user_id → cohort ter-bucket); (c) agregasi di sumber, layanan mengagregasi metrik per-pengguna menjadi per-tim atau per-plan tier sebelum memancarkan; (d) analisis biaya storage, label kardinalitas tinggi meningkatkan selektivitas query (dapat memfilter ke satu pengguna) tetapi biayanya storage O(pengguna × window_waktu); (3) Dashboarding pada skala besar, masalah: 100 penonton bersamaan × 20 panel/dashboard × 1 query TSDB masing-masing = 2.000 query simultan; solusi: (a) tier pra-agregasi, dashboard service pra-komputasi data panel untuk 1 jam dan 24 jam terakhir dan meng-cache di Redis; query panel mengenai cache alih-alih TSDB; TTL: 30 detik; (b) refresh inkremental, saat cache kedaluwarsa, hanya query ulang 30s data terakhir dan merge dengan historis yang di-cache; (c) berbagi hasil query, jika dua penonton membuka dashboard yang sama, backend men-deduplikasi query TSDB (satu query melayani semua penonton); (d) penjaga kardinalitas pada query ad-hoc, query PromQL yang akan menghasilkan > 10 ribu time series ditolak dengan error yang menyarankan filtering dimensi.

8. Final Review Handoff Readiness

   Ringkas keputusan desain utama: ingestion push dengan batching, TSDB LSM-tree ter-shard, tier pra-agregasi dengan caching Redis untuk dashboard, pengelompokan dan inhibisi alert untuk supresi fatigue, batas kardinalitas saat ingestion dengan relabeling pipeline, dan downsampling bertingkat (raw → 5-menit → 1-jam). Soroti dua pertanyaan terbuka terbesar yang tersisa (algoritma ambang adaptif, bagaimana mendeteksi musiman dalam pola trafik mingguan untuk kalkulasi baseline yang akurat, dan tekanan kompaksi TSDB, pada 10 juta data point/s, kompaksi LSM dapat tertinggal saat burst ingestion kardinalitas-tinggi, menyebabkan read amplification) dan usulkan rollout bertahap: ingestion metrik + alert ambang dasar dulu, lalu pra-agregasi dashboard, lalu penegakan kardinalitas, lalu ambang adaptif.

Preview solusi

Solusi: Merancang Realtime Monitoring Framing Problem Sebuah sistem real-time monitoring meng-ingest metric data point dari service, menyimpannya sebagai time series, melayani query dashboard, memicu alert saat pelanggaran threshold, dan mengelola retensi data dengan downsampling. Dalam scope: Ingestion metric, storage time series (TSDB), query dashboard, th…