Ikuti satu permintaan lambat sebelum mengubah ukuran

Pilih permintaan dengan hasil yang diharapkan yang jelas

Untuk endpoint laporan ilustratif, catat pola rute, perkiraan ukuran data, konteks autentikasi, dan apakah itu menciptakan pekerjaan latar belakang. Gunakan akun uji dan data tersanitasi yang representatif. Jangan salin token, pengenal pelanggan, atau badan permintaan lengkap ke dalam catatan insiden.

Pisahkan biaya startup permintaan pertama dari perilaku steady-state berulang. Catat jendela UTC dan revisi rilis. Tentukan apakah semua rute lambat, hanya laporan besar yang terpengaruh, atau penundaan mengikuti satu dependensi eksternal. Perbedaan ini membuat pengukuran berikutnya lebih berguna daripada kumpulan metrik tak terkait yang luas.

Bangun timeline tanpa menghitung ganda

Trace OpenTelemetry menghubungkan span terkait melalui konteks yang dipropagasi melintasi batas layanan. Mencocokkan stempel waktu saja tidak cukup. Span sinkron bersarang dan panggilan paralel dapat tumpang tindih. Anak asinkron dapat hidup lebih lama dari induknya, sehingga menambahkan setiap durasi span dapat menghitung ganda waktu yang berlalu. Ikuti operasi yang menentukan kapan permintaan selesai.

Referensi teknis: Trace OpenTelemetry · Perilaku akhir span OpenTelemetry.

Interval terbesar menunjukkan tempat untuk diperiksa, bukan akar penyebabnya. Interval basis data yang diukur di API dapat mencakup menunggu koneksi sebelum kueri mencapai basis data. Telemetri yang hilang juga tidak membuktikan bahwa tidak ada pekerjaan yang terjadi; periksa sampling dan cakupan instrumentasi.

Korelasikan pengamatan aplikasi dan host

Kumpulkan waktu permintaan, error, penggunaan koneksi basis data, usia antrean, CPU, memori, dan tekanan disk untuk jendela yang sama. Catat backup, migrasi, atau rilis yang berjalan bersamaan. Satu tangkapan layar utilisasi dapat melewatkan lonjakan yang memengaruhi permintaan.

Gunakan ID korelasi dan stempel waktu dalam log yang disunting dengan retensi dan kontrol akses yang sesuai. Hindari rahasia mentah, payload pelanggan, dan label metrik tak terbatas. Instrumentasikan batas yang diperlukan untuk hipotesis dan tinjau overhead-nya. Agen tracing baru itu sendiri adalah perubahan yang layak diamati.

Periksa kueri tanpa menyebabkan insiden lain

Identifikasi bentuk kueri, karakteristik ukuran input, dan tunggu koneksi atau lock terlebih dahulu. PostgreSQL EXPLAIN menjelaskan rencana; EXPLAIN ANALYZE benar-benar mengeksekusi pernyataan dan menambahkan overhead instrumentasi. Penulisan dapat mengubah data, sementara pembacaan yang mahal tetap menciptakan beban. Gunakan basis data representatif yang terisolasi untuk investigasi awal.

Biaya planner bukanlah milidetik yang berlalu. Tabel uji yang sangat kecil dapat menghasilkan rencana yang berbeda dari kumpulan data aplikasi yang lebih besar. Tinjau statistik, indeks, dan distribusi, serta bandingkan bentuk kueri yang sama setelah mengubahnya. Jangan pernah menempelkan penulisan yang tidak diketahui ke dalam perintah analisis di produksi hanya untuk mendapatkan pengaturan waktu.

Referensi teknis: PostgreSQL EXPLAIN.

Prediksi apa yang seharusnya ditingkatkan oleh satu perubahan

Jika tunggu pool mendominasi, periksa koneksi worker atau permintaan yang menahan koneksi tanpa perlu. Jika eksekusi kueri mendominasi, periksa rencana dan baris yang diminta. Jika API eksternal mendominasi, tinjau timeout, percobaan ulang, dan apakah pekerjaan tersebut harus sinkron. Saturasi CPU selama serialisasi menunjuk ke eksperimen yang berbeda.

Tulis prediksi: mengurangi konkurensi ekspor harus mengurangi tunggu pool API sementara ekspor memakan waktu lebih lama. Ini mengungkap tradeoff-nya. Ulangi campuran permintaan yang sama, bandingkan latensi dan error, serta periksa bahwa peningkatan tersebut tidak sekadar memindahkan kegagalan ke antrean yang terus bertambah.

Simpan hasil dan ketidakpastiannya

Catat pengamatan awal, perubahan yang diuji, metode perbandingan, dan ketidakpastian yang tersisa. Jika bukti bertentangan dengan hipotesis, batalkan perubahan terisolasi tersebut jika sesuai dan selidiki batas lain. Hindari menumpuk perubahan penyetelan permanen tanpa penjelasan.

Ubah ukuran ketika pengukuran mengidentifikasi kendala sumber daya yang dapat diatasi oleh alokasi tambahan. Gunakan anggaran beban kerja dan tangkap regresi rilis di ringkasan insiden. Hasilnya adalah diagnosis yang beralasan, bukan latensi yang dijanjikan atau tolok ukur penyedia.