Wawancara Desain Sistem: Bagaimana Anda Mendesain Sistem Pemantauan Metrik dan Peringatan?

Masalah dan Skenario yang Berlaku

Rancang sistem pemantauan metrik dan peringatan yang digunakan bersama oleh beberapa tim rekayasa. Sistem ini memantau 50.000 instans layanan, masing-masing mengekspos 200 time series aktif, dan mengumpulkan data setiap 15 detik. Sistem ini mendukung counter, gauge, dan histogram; pemfilteran dan agregasi berdasarkan label; dasbor; serta peringatan berbasis aturan. Kegagalan baru harus masuk ke perutean notifikasi dalam waktu 60 detik pada p99. Kueri dasbor umum selama enam jam terakhir harus selesai dalam waktu dua detik pada p95. Sampel mentah disimpan selama tujuh hari, rollup satu menit selama 90 hari, dan rollup satu jam selama 13 bulan.

Asumsikan satu wilayah dengan tiga availability zone dan autentikasi tepercaya sebagai sumber identitas penyewa. Penyedia email, obrolan, dan telepon yang ada dapat mengirimkan notifikasi; desain ini harus menghasilkan, mendeduplikasi, mengelompokkan, dan merutekannya secara andal. Log dan trace berada di luar cakupan utama. Wawancara harus fokus pada label berkardinalitas tinggi, sampel duplikat dan terlambat, data yang hilang, status peringatan, isolasi kueri, dan deteksi kegagalan pada platform pemantauan itu sendiri.

Materi bahasa Inggris dan Mandarin saat ini dari tahun 2026 menyajikan pemantauan metrik dan peringatan sebagai masalah wawancara desain sistem langsung yang melibatkan penyerapan (ingestion) time-series, kueri, peringatan, dan ketersediaan tinggi. Dokumentasi Prometheus menyediakan semantik utama untuk identitas deret, pengumpulan tarik (pull), WAL, peringatan pending dan firing, pengelompokan, serta inhibisi. Google SRE menyediakan prinsip-prinsip untuk peringatan rendah derau (low-noise) dan pemantauan kotak hitam (black-box). Oleh karena itu, pertanyaan ini representatif dan dapat diverifikasi secara teknis saat ini.

Apa yang Sedang Dievaluasi oleh Pewawancara

Pertama, dapatkah kandidat memisahkan throughput sampel dari kardinalitas time-series aktif? Jumlah instans, deret per instans, dan interval pengumpulan menentukan penulisan. Memori, indeks, dan fan-out kueri mungkin gagal terlebih dahulu karena kardinalitas. Menambahkan user_id atau request_id ke label dapat menciptakan deret yang berkali-kali lipat lebih banyak tanpa meningkatkan lalu lintas.

Kedua, apakah penyerapan yang tahan lama (durable), kueri dasbor, dan deteksi kegagalan membentuk jalur yang lengkap? Kolektor yang menerima sampel tidak berarti sampel tersebut sudah tahan lama. Aturan peringatan tidak boleh bergantung pada pool bersama yang dapat dihabiskan oleh kueri ad-hoc yang mahal. Jawaban yang kuat mendefinisikan batas pengakuan (acknowledgement boundary), mencadangkan kapasitas untuk peringatan, dan menentukan semantik untuk data terlambat, duplikat, hilang, dan hasil parsial.

Ketiga, apakah penyimpanan cocok dengan pola akses? Data terbaru ditambahkan dan sering dikueri. Data historis cocok dengan blok yang tidak dapat diubah (immutable), kompresi, indeks, dan penyimpanan objek. Downsampling tidak dapat merata-ratakan nilai rata-rata. Downsampling harus mempertahankan setidaknya sum, count, min, dan max; histogram memerlukan batas bucket yang kompatibel sebelum dapat digabungkan.

Terakhir, sistem peringatan harus mampu bertahan dalam insiden. Suatu insiden dapat meningkatkan metrik kesalahan, kueri, dan notifikasi sekaligus. Kandidat harus mencakup sharding aturan, pemulihan status, deduplikasi notifikasi, badai peringatan (alert storms), penyewa yang berisik (noisy tenants), pemantauan diri sendiri, dan probe keaktifan ujung-ke-ujung di luar domain kegagalan platform.

Pertanyaan Klarifikasi Sebelum Menjawab

• Apakah target pengumpulan stabil? Sebagian besar adalah layanan jangka panjang yang ditemukan oleh platform; tugas singkat dan jaringan terbatas menggunakan push gateway.
• Apakah skala yang disebutkan bersifat global atau regional? Anggap ini sebagai puncak regional. Wilayah tambahan mengumpulkan data secara independen dan mengekspos kueri global yang terkontrol.
• Apa batas pengakuan (acknowledgement boundary)? Write gateway berhasil hanya setelah sampel masuk ke log tahan lama yang direplikasi di seluruh availability zone.
• Apakah sampel duplikat dan di luar urutan (out-of-order) diizinkan? Percobaan ulang jaringan dapat menduplikasi data, dan sampel dapat tiba dalam jendela keterlambatan yang dibatasi. Deret dan stempel waktu yang sama menggunakan aturan konflik deterministik.
• Apakah sampel yang hilang berarti nol? Tidak. Ini mungkin menunjukkan target mati, pengumpulan gagal, atau partisi, yang berbeda dari nilai nol terukur.
• Haruskah setiap kueri selesai dalam dua detik? Tidak. SLO mencakup kueri enam jam umum yang dibatasi. Pemindaian mentah berdurasi sebulan dan berkardinalitas tinggi memiliki kuota atau menggunakan analisis asinkron.
• Bagaimana pemulihan peringatan diputuskan? Aturan mendefinisikan interval evaluasi, durasi penahanan, kebijakan data hilang, dan kondisi pemulihan. Layanan notifikasi tidak menyimpulkannya.
• Bolehkah penyewa membuat label arbitrer? Dalam batas kuota, tunduk pada batas jumlah label, panjang, deret aktif, dan laju deret baru.
• Apakah notifikasi tepat-sekali (exactly-once) diperlukan? Tidak. Pengiriman setidaknya sekali (at-least-once), dengan idempoten berdasarkan sidik jari peringatan dan transisi status.
• Bagaimana hubungan data mentah dan data yang di-rollup? Rollup dapat dihitung ulang saat blok sumber masih disimpan, dan mencatat resolusi serta watermark cakupannya.

Kerangka Jawaban 30 Detik

“Skalanya adalah 10 juta deret aktif, sekitar 667.000 sampel per detik, atau 57,6 miliar sampel per hari. Kolektor ter-shard menarik (pull) target dari penemuan layanan (service discovery), sedangkan tugas singkat menggunakan push gateway. Sampel yang dinormalisasi masuk ke log tahan lama lintas-zona berdasarkan penyewa dan sidik jari deret, lalu ke tingkat data terbaru dan blok waktu yang tidak dapat diubah. Indeks label melayani kueri, dan anggaran kardinalitas membatasi label berbahaya seperti user_id. Mesin aturan yang disediakan secara terpisah mengevaluasi stempel waktu tetap dan menyimpan status inactive, pending, dan firing. Manajer peringatan mendeduplikasi, mengelompokkan, membisukan, menginhibisi, dan merutekan peringatan. Saya akan memverifikasi jalur ini dengan lonjakan deret baru sepuluh kali lipat, sampel duplikat dan terlambat, kegagalan zona, dan canary eksternal.”

Pembahasan Mendalam Langkah demi Langkah

Mulailah dengan enam invarian: label sampel tidak dapat mendeklarasikan identitas penyewa; sampel yang diakui telah masuk ke log tahan lama; satu percobaan ulang tidak dapat menghasilkan hasil yang berbeda; data yang hilang tidak pernah diubah secara diam-diam menjadi nol; beban dasbor tidak dapat membuat sistem peringatan kekurangan sumber daya (starve); dan setiap penolakan, penurunan, penundaan, serta degradasi memiliki hitungan yang dapat diamati.

Langkah pertama: hitung ulang skala dan perlakukan kardinalitas sebagai sumber daya kelas satu.

Perhitungan deret aktif adalah:

50,000 instances × 200 series/instance = 10,000,000 active series
10,000,000 ÷ 15 seconds ≈ 666,667 samples/second
666,667 × 86,400 ≈ 57.6 billion samples/day

Dokumentasi penyimpanan Prometheus memberikan titik awal penyimpanan lokal kasar sebesar satu hingga dua bita per sampel. Pada tingkat tersebut, bongkahan sampel terkompresi akan menempati sekitar 57,6–115,2 GB per hari, atau 172,8–345,6 GB per hari dengan tiga salinan. Estimasi ini tidak termasuk indeks label, WAL, head, metadata objek, batas keamanan di luar replika, dan efek distribusi yang diamati. Ini adalah pemeriksaan kelayakan (sanity check), bukan pengganti tolok ukur (benchmark) dengan metrik yang representatif.

Deret baru lebih berbahaya. Jika user_id tingkat permintaan masuk ke kumpulan label, identitas deret berubah pada setiap nilai. Platform harus membatasi deret aktif, laju pembuatan deret baru, jumlah label, panjang label, dan kunci yang diizinkan per penyewa dan metrik, dengan kebijakan peringatan (warn), karantina, dan penolakan eksplisit.

Langkah kedua: gunakan pengumpulan tarik (pull) secara default dan dorong (push) jika diperlukan.

Penemuan layanan menyediakan kumpulan target. Control plane menetapkan target ke kolektor dengan consistent atau rendezvous hashing. Setiap 15 detik, kolektor menarik melalui HTTP, melampirkan bidang penyewa, kluster, pekerjaan, dan instans tepercaya, serta menghasilkan metrik pengumpulan seperti up, durasi scrape, jumlah sampel, dan kesalahan. Penarikan membuat fakta bahwa “target ada tetapi pengumpulan gagal” dapat terlihat secara langsung dan memungkinkan platform mengontrol laju pengumpulan.

Tugas batch berumur pendek, jaringan tanpa akses masuk, dan lingkungan yang sudah memancarkan OTLP menggunakan gateway regional. Gateway mengotentikasi identitas, membatasi ukuran batch, menormalkan bidang, dan memasuki kontrak penyerapan yang sama. Keberhasilan pengiriman klien bukanlah keberhasilan penyimpanan akhir; keberhasilan gateway berarti platform telah mencapai batas tahan lamanya. Kolektor menggunakan spool lokal yang dibatasi selama pemutusan koneksi dan menolak dengan counter saat ruang habis daripada mengisi disk tanpa batas.

Langkah ketiga: tentukan identitas deret dan kontrak penyerapan.

Suatu deret diidentifikasi secara unik oleh tenant_id + metric_name + canonical_labels. Label diurutkan dan dienkode secara kanonis sebelum di-hash. Tabrakan sidik jari tetap memerlukan perbandingan identitas lengkap; hash saja tidak cukup. Sebuah sampel berisi identitas deret, waktu sumber, waktu pengamatan, nilai atau histogram, tipe data, dan sumber pengumpulan.

WriteBatch {
  tenantId, sourceId, requestId,
  samples: [{ metric, labels, sourceTimestamp, value }]
}

Gateway melakukan autentikasi, normalisasi label, validasi tipe, penganggaran kardinalitas, pemeriksaan rentang waktu, dan batasan batch. Gateway kemudian mempartisi berdasarkan tenant_id + series_fingerprint ke dalam log yang direplikasi lintas-zona. Commit log adalah batas ack. requestId yang sama dapat dicoba lagi dengan aman, dan penyimpanan mendeduplikasi berdasarkan (series_id, source_timestamp). Nilai yang berbeda pada satu deret dan stempel waktu mengikuti kebijakan konflik tetap dan meningkatkan metrik konflik; urutan kedatangan tidak boleh memutuskan secara diam-diam.

Langkah keempat: pisahkan data terbaru, blok historis, dan indeks.

Head yang dapat ditambahkan (appendable) menampung jam-jam terbaru dan mengizinkan perubahan terbatas untuk data yang terlambat. Pekerja latar belakang membekukannya menjadi blok-blok yang tidak dapat diubah dan dipartisi berdasarkan waktu serta shard, menggunakan kompresi delta-stempel-waktu dan nilai, lalu mengunggahnya ke penyimpanan objek. Metadata blok berisi waktu minimum dan maksimum, penyewa, resolusi, checksum, dan watermark cakupan. Pemadatan (compaction) menggabungkan blok-blok kecil dan hanya menghapus blok yang sepenuhnya tercakup oleh pengganti yang tervalidasi.

Indeks terbalik (inverted index) memetakan pasangan kunci/nilai label ke ID deret, yang menemukan blok data. Metadata label dan deret panas dapat di-cache, tetapi identitas penyewa adalah bagian dari setiap kunci cache. Downsampling membuat blok satu menit dan satu jam dengan sum/count/min/max. Counter memerlukan penanganan reset, dan histogram hanya bergabung dengan skema bucket yang kompatibel. Blok mentah bertahan tujuh hari, blok satu menit 90 hari, dan blok satu jam 13 bulan.

Langkah kelima: buat biaya kueri dapat diprediksi.

Koordinator kueri mengurai rentang waktu, pemilih label, agregasi, dan step. Koordinator mengotorisasi terlebih dahulu, menggunakan indeks untuk menemukan deret, dan membaca blok yang relevan secara paralel. Rollup dipilih hanya jika step dan fungsi yang diminta mengizinkannya. Nilai rata-rata dihitung ulang dari sum/count; persentil yang ada tidak dapat di-rollup menjadi persentil lain yang benar. Kueri terbaru menggabungkan head dengan blok yang dipertahankan dan mendeduplikasi pada watermark bersama.

Setiap kueri memiliki batasan untuk deret, titik yang dipindai, konkurensi, memori, dan tenggat waktu. Dasbor umum menggunakan step tetap, pra-agregasi, dan caching hasil singkat untuk menargetkan dua detik pada p95 selama enam jam terakhir. Eksplorasi berkardinalitas tinggi selama sebulan dapat menjadi tugas asinkron. Ketika sebuah shard gagal, API mengembalikan partial=true dan rentang yang hilang. Aturan peringatan menolak hasil parsial secara default.

QueryRange {
  tenantId, expression, start, end, step, maxSeries
}
QueryResult { data, resolution, watermark, partial, warnings }

Langkah enam: pisahkan evaluasi aturan dari perutean notifikasi.

Penjadwal membagi grup aturan berdasarkan penyewa (shard) dan mengevaluasi setiap 15 atau 30 detik pada stempel waktu evaluasi eksplisit. Sebuah instans peringatan memiliki sidik jari stabil yang diturunkan dari aturan dan label hasil, serta bergerak melalui inactive -> pending -> firing. Durasi for menyaring lonjakan sementara. keep_firing_for atau histeresis eksplisit mencegah data hilang yang singkat menyebabkan resolusi berulang. Setiap aturan juga menyatakan apakah data yang hilang itu normal, memicu peringatan, atau tidak diketahui.

Dua evaluator berketersediaan tinggi dapat mengirimkan sidik jari yang sama ke manajer peringatan, yang kemudian mendeduplikasinya. Manajer peringatan merutekan berdasarkan tim, layanan, dan tingkat keparahan; mengelompokkan instans dari satu insiden; menginhibisi peringatan instans hilir ketika kluster tidak dapat dijangkau; dan menerapkan pembisuan yang kedaluwarsa selama pemeliharaan. Status notifikasi berada di penyimpanan yang direplikasi. Pengiriman setidaknya sekali dan menggunakan alert_fingerprint + state_transition + receiver sebagai kunci idempoten. Komputasi aturan, status, dan antrean notifikasi menggunakan kapasitas yang diisolasi dari kueri dasbor ad-hoc.

Langkah tujuh: tangani kegagalan, isolasi penyewa, dan pemantauan mandiri.

Ketika sebuah kolektor mati, sewa target berpindah ke instans yang sehat. Pengumpulan yang tumpang tindih singkat diserap oleh deduplikasi. Ketika log atau penyimpanan menerapkan backpressure, gateway mengurangi batch dan menolak secara eksplisit alih-alih membangun antrean memori tanpa batas. Selama pemadaman penyimpanan objek, log yang direplikasi dan head yang dibatasi terus menerima data dan penghapusan blok berhenti. Di luar watermark yang aman, kuota penyewa melindungi metrik kritis untuk peringatan. Kegagalan kueri tidak boleh menghentikan aturan membaca watermark yang telah dikonfirmasi.

Identitas penyewa berasal dari mTLS atau token yang diterbitkan server, tidak pernah dari label sampel tenant. Batasan terpisah berlaku untuk penyerapan, kueri, dan aturan. RBAC mengontrol dasbor dan konfigurasi peringatan, serta perubahan pada aturan, pembisuan, dan rute diaudit. Platform mengamati latensi penyerapan, backlog log, watermark head, usia blok, titik kueri yang dipindai, penundaan evaluasi aturan, jumlah pending dan firing, serta kegagalan notifikasi.

Pemantauan mandiri berbagi domain kegagalan platform, sehingga canary kotak hitam eksternal terus-menerus menulis metrik yang diketahui dari lingkungan independen, menunggu aturannya aktif dan notifikasinya tiba, lalu menyelesaikannya. Pemeriksaan dead-man eksternal menggunakan jalur notifikasi independen jika heartbeat yang diharapkan berhenti. Ini mendeteksi platform pemantauan yang benar-benar tidak bersuara (silent failure).

Langkah delapan: validasi janji dengan beban dan injeksi kesalahan.

Beban kondisi stabil (steady-state) harus mencapai setidaknya 667.000 sampel per detik, diikuti oleh lonjakan dua kali lipat. Kemudian buat laju deret baru sepuluh kali lipat dan verifikasi bahwa penyewa yang bermasalah diisolasi sementara penyewa lain dan evaluasi aturan tetap memenuhi SLO mereka. Uji kebenaran mencakup batch duplikat, nilai yang bertentangan pada satu stempel waktu, jendela keterlambatan, reset counter, penggabungan histogram, komputasi ulang rollup, dan hasil yang sama sebelum dan sesudah pemadatan blok.

Uji kesalahan mematikan kolektor, replika log satu zona, node head, shard kueri, evaluator aturan, dan penyedia notifikasi. Pengujian ini memverifikasi bahwa sampel yang diakui tetap ada, tumpang tindih sewa dideduplikasi, status aturan pulih, dan percobaan ulang notifikasi tidak dapat tumbuh tanpa batas. Terakhir, ukur latensi canary di seluruh penyerapan, durasi penahanan aturan, tunggu grup, dan pengiriman. Konfirmasikan 60 detik pada p99 atau identifikasi tahapan yang menghabiskan anggarannya.

Contoh Jawaban yang Kuat

“Pertama-tama saya akan mengalikan 50.000 instans dengan 200 deret untuk mendapatkan 10 juta deret aktif. Membaginya dengan 15 detik menghasilkan sekitar 667.000 sampel per detik, atau 57,6 miliar per hari. Perencanaan kapasitas harus mencakup bongkahan sampel dan indeks label. Anggaran deret aktif dan laju deret baru mencegah label seperti user_id menghabiskan sumber daya platform.

Jalur utama menggunakan penemuan layanan dan kolektor tarik ter-shard; tugas singkat menggunakan push gateway. Setelah autentikasi, normalisasi label, dan pemeriksaan kuota, sampel masuk ke log yang direplikasi lintas-zona berdasarkan penyewa dan sidik jari deret. Hanya penulisan log yang telah di-commit yang diakui. Data terbaru masuk ke head, lalu membeku menjadi blok terkompresi yang tidak dapat diubah dan indeks terbalik label di penyimpanan objek. Tugas latar belakang menghasilkan rollup satu menit dan satu jam; nilai rata-rata dibangun kembali dari sum/count.

Koordinator kueri memangkas blok berdasarkan waktu, label, dan resolusi, dengan anggaran untuk deret, titik, memori, dan tenggat waktu. Mesin aturan yang disediakan secara terpisah mengevaluasi stempel waktu tetap dan mempertahankan status inactive, pending, dan firing. Manajer peringatan mendeduplikasi berdasarkan sidik jari, lalu mengelompokkan, menginhibisi, membisukan, dan merutekan. Data yang hilang mengikuti kebijakan aturan eksplisit, dan notifikasi menggunakan pengiriman setidaknya sekali.

Saya akan melakukan uji beban 667.000 sampel per detik, lonjakan dua kali lipat, dan lonjakan deret baru sepuluh kali lipat. Kemudian saya akan menginjeksikan sampel duplikat dan terlambat, kegagalan zona, shard kueri yang gagal, dan penyedia notifikasi yang gagal. Canary di lingkungan independen terus melatih alur penyerapan hingga notifikasi, memverifikasi p99 60 detik dan mendeteksi platform yang hening total.”

Kesalahan Umum

• Hanya menghitung sampel per detik → Indeks label dan deret aktif dapat menghabiskan memori terlebih dahulu → Anggarkan juga 10 juta deret aktif dan laju deret baru.
• Mengizinkan label user_id arbitrer → Setiap nilai membuat deret lain → Terapkan kebijakan label, anggaran kardinalitas, dan karantina.
• Memberikan pengakuan (ack) saat permintaan diterima → Kegagalan proses atau zona dapat menghilangkan data yang telah diakui → Beri ack hanya setelah commit log yang direplikasi.
• Memperlakukan data hilang sebagai nol → Kegagalan pengumpulan terlihat seperti penurunan bisnis menjadi nol → Pertahankan status usang (stale) atau tidak diketahui dan biarkan aturan memilih kebijakan.
• Merata-ratakan nilai rata-rata → Bucket dengan jumlah berbeda menghasilkan hasil yang bias → Pertahankan sum/count dan hitung ulang.
• Menjanjikan setiap kueri selesai dalam dua detik → Label dan rentang waktu tanpa batas memiliki biaya tanpa batas → Batasi cakupan SLO dan tegakkan anggaran kueri serta jalur asinkron.
• Membiarkan aturan peringatan menerima hasil parsial → Satu shard yang hilang mungkin terlihat seperti pemulihan → Wajibkan watermark lengkap atau masuk ke status tidak diketahui.
• Mengirim notifikasi untuk setiap instans → Pemadaman besar menciptakan badai peringatan → Kelompokkan insiden dan gunakan inhibisi, pembisuan, dan pembatasan laju.
• Mengklaim notifikasi tepat-sekali → Batas waktu tidak dapat membuktikan apakah pengiriman telah terjadi → Gunakan pengiriman setidaknya sekali dengan kunci idempoten yang stabil.
• Memantau platform hanya dengan dirinya sendiri → Pemadaman total tidak menghasilkan sinyal → Tambahkan canary kotak hitam independen dan jalur dead-man.

Pertanyaan Lanjutan dan Tanggapan

Pertanyaan Lanjutan 1: Mengapa tidak membiarkan setiap klien melakukan push secara langsung?

Layanan jangka panjang cocok dengan pengumpulan tarik (pull): platform mengetahui kumpulan target dan frekuensi, membedakan nilai terukur dari pengumpulan yang gagal, dan melampirkan label sumber daya tepercaya secara konsisten. Tugas singkat, jaringan terbatas, dan klien OTLP yang ada cocok dengan push. Kedua pintu masuk pada akhirnya menggunakan kontrak validasi dan penyerapan tahan lama yang sama, menghindari dua semantik kueri.

Pertanyaan Lanjutan 2: Bagaimana Anda mengontrol kardinalitas tanpa memblokir beban kerja yang sah?

Ukur stok dan aliran: batasi deret aktif per penyewa dan metrik, serta batasi deret baru per menit. Tawarkan pratinjau kardinalitas sebelum peluncuran. Berikan peringatan mendekati ambang batas, lalu hapus label berbahaya yang dikonfigurasi, karantina metrik, atau tolak deret baru sesuai dengan kebijakan penyewa. Pertahankan hitungan penurunan dan diagnostik representatif, tetapi jangan menyalin label mentah sensitif ke dalam log biasa.

Pertanyaan Lanjutan 3: Bagaimana sampel yang terlambat memengaruhi sistem peringatan?

Aturan membaca watermark yang dikonfirmasi pada stempel waktu evaluasi tetap dan dapat menambahkan sedikit penundaan untuk keterlambatan normal. Sampel lama yang tiba setelah watermark tersebut dapat memperbarui kueri historis, tetapi secara default tidak boleh mencabut notifikasi manusia. Jika produk memerlukan koreksi, pancarkan peristiwa koreksi berversi. Jendela keterlambatan, deviasi jam maksimum, dan aturan konflik harus didokumentasikan dan diuji.

Pertanyaan Lanjutan 4: Mengapa tidak menyimpan persentil secara langsung?

Nilai p95 dari beberapa instans atau bucket waktu tidak dapat dirata-ratakan atau dilewatkan melalui operasi p95 lain untuk mendapatkan p95 global. Simpan bucket histogram atau sketsa yang dapat digabungkan, gabungkan distribusi pada waktu kueri, lalu hitung persentilnya. Batas bucket atau parameter sketsa yang tidak kompatibel memerlukan hasil terpisah atau migrasi eksplisit.

Pertanyaan Lanjutan 5: Bagaimana mesin aturan yang berketersediaan tinggi menghindari notifikasi duplikat?

Kedua evaluator dapat menghitung dan mengirimkan instans peringatan yang sama. Sidik jari instans stabil di seluruh aturan dan label hasil. Manajer peringatan menggunakan status yang direplikasi untuk mendeduplikasi, mengelompokkan, dan merutekan berdasarkan sidik jari, status, dan penerima. Evaluasi tidak perlu menjadi singleton. Partisi mungkin masih menghasilkan duplikat langka, sehingga penerima mempertahankan kunci idempoten yang sama.

Pertanyaan Lanjutan 6: Apa yang terjadi jika penyimpanan objek tidak tersedia?

Lanjutkan menulis sampel baru ke log yang direplikasi dan head yang dibatasi. Jeda pengunggahan blok, penghapusan pemadatan, dan penerimaan di luar watermark yang aman. Lindungi metrik kritis peringatan dengan kuota penyewa. Jika pemulihan tidak dapat terjadi dalam retensi log, tolak penulisan baru secara eksplisit dan beri tahu operator; jangan pernah mengklaim bahwa semua data tetap diterima.

Pertanyaan Lanjutan 7: Bagaimana kueri multi-wilayah global bekerja?

Setiap wilayah mengumpulkan data dan memberikan peringatan secara independen sehingga partisi area luas tidak dapat membungkam peringatan lokal. Koordinator global membaca blok tidak dapat diubah yang diterbitkan atau titik akhir kueri terkontrol dan mengembalikan watermark serta status partial setiap wilayah. Kumpulan kecil metrik peringatan yang benar-benar global diagregasikan secara regional terlebih dahulu, kemudian direplikasi sebagai hasil berkardinalitas rendah ke dalam domain aturan terpisah.

Pertanyaan Lanjutan 8: Bagaimana Anda menemukan tahapan mana yang melanggar target peringatan 60 detik?

Untuk sampel canary, catat waktu sumber, waktu pengamatan, watermark log-commit, waktu evaluasi aturan, interval pending, tunggu pengelompokan, dan penerimaan notifikasi. Urai histogram ujung-ke-ujung berdasarkan tahapan dan verifikasi kedatangan akhir secara eksternal. Klausul lima menit for dari suatu aturan adalah kondisi produk, bukan latensi deteksi platform, jadi laporkan pemrosesan platform dan durasi penahanan yang dikonfigurasi secara terpisah.