Brendan Gregg adalah salah satu suara paling berpengaruh dalam kinerja sistem, terutama di dunia Linux. Ia menulis buku yang banyak dipakai, membuat tooling praktis, dan—yang terpenting—membagikan metode jelas untuk menyelidiki masalah produksi nyata. Tim mengadopsi pendekatannya karena metode itu bekerja di bawah tekanan: ketika latensi melonjak dan semua orang ingin jawaban, Anda butuh cara untuk bergerak dari “mungkin ini X” ke “ini pasti Y” dengan drama seminimal mungkin.
Apa arti sebenarnya “metodologi kinerja”
Metodologi kinerja bukanlah satu alat tunggal atau perintah pintar. Ini adalah cara yang dapat diulang untuk menyelidiki: daftar periksa tentang apa yang dilihat pertama, bagaimana menafsirkan temuan, dan bagaimana memutuskan langkah berikutnya.
Pengulangan itulah yang mengurangi tebakan. Alih-alih bergantung pada siapa yang paling berintuisi (atau berpendapat paling keras), Anda mengikuti proses konsisten yang:
mempersempit masalah ke sumber daya, layanan, atau jalur kode spesifik
mengukur apa yang terjadi pada jendela waktu yang sama dengan insiden
mengonfirmasi hambatan dengan bukti sebelum melakukan perubahan
Mode kegagalan umum: memperbaiki sebelum mengukur
Banyak investigasi latensi gagal dalam lima menit pertama. Orang langsung lompat ke perbaikan: “tambahi CPU,” “restart service,” “tingkatkan cache,” “tune GC,” “pasti jaringan.” Kadang tindakan itu membantu—seringkali mereka menyamarkan sinyal, membuang waktu, atau memperkenalkan risiko baru.
Metode Gregg mendorong Anda menunda “solusi” sampai Anda dapat menjawab pertanyaan sederhana: Apa yang jenuh? Apa yang error? Apa yang melambat—throughput, antrean, atau operasi individual?
Apa yang dibantu panduan ini lakukan
Panduan ini membantu Anda mempersempit lingkup, mengukur sinyal yang tepat, dan mengonfirmasi hambatan sebelum mengoptimalkan. Tujuannya adalah workflow terstruktur untuk menyelidiki masalah latensi dan profiling di produksi sehingga hasilnya tidak bergantung pada keberuntungan.
Dasar-dasar latensi: apa yang diukur sebelum tuning
Latensi adalah sebuah gejala: pengguna menunggu lebih lama sampai pekerjaan selesai. Penyebab biasanya berada di tempat lain—kontensi CPU, menunggu disk atau jaringan, kontensi lock, garbage collection, antrean, atau keterlambatan dependensi jarak jauh. Mengukur latensi saja memberitahu Anda bahwa rasa sakit itu ada, bukan dari mana ia berasal.
Throughput, latensi, dan error bergerak bersama
Ketiga sinyal ini saling terkait:
Throughput (permintaan/detik) yang naik dapat meningkatkan antrean, yang menaikkan latensi.
Error bisa mengurangi latensi yang teramati (gagal cepat) atau meningkatkannya (retry dan timeout).
Membatasi throughput (rate limits, backpressure) bisa memperbaiki tail latency sambil membuat lebih sedikit permintaan berhasil.
Sebelum tuning, tangkap ketiganya untuk jendela waktu yang sama. Kalau tidak, Anda mungkin “memperbaiki” latensi dengan menurunkan kerja atau gagal lebih cepat.
Jangan percaya rata-rata: persentil dan tail latency
Rata-rata latency menyembunyikan lonjakan yang diingat pengguna. Layanan dengan rata-rata 50 ms bisa saja sering mengalami jeda 2 s.
Lacak persentil:
p50: pengalaman pengguna tipikal
p95/p99: tail latency (tempat sebagian besar rasa sakit insiden berada)
Perhatikan juga bentuk latensi: p50 yang stabil dengan p99 yang naik sering mengindikasikan stall intermittent (mis. kontensi lock, hiccup I/O, jeda stop-the-world) daripada perlambatan umum.
Anggaran latensi: ke mana waktu boleh dihabiskan
Anggaran latensi adalah model akuntansi sederhana: “Jika permintaan harus selesai dalam 300 ms, bagaimana waktu itu boleh dibagi?” Pecah menjadi bucket seperti:
waktu di layanan Anda (komputasi + menunggu)
waktu di layanan downstream
waktu di database/cache
transit jaringan dan TLS
waktu yang dihabiskan dalam antrean (thread, connection pool, load balancer)
Anggaran ini membingkai tugas pengukuran pertama: identifikasi bucket mana yang tumbuh selama spike, lalu selidiki area itu daripada melakukan tuning buta.
Mulai dengan pertanyaan dan lingkup yang jelas
Pekerjaan latensi melenceng ketika “masalah” digambarkan sebagai sistem lambat. Metode Gregg mulai lebih awal: paksa masalah menjadi pertanyaan yang spesifik dan dapat diuji.
Definisikan apa itu “lambat” (dan untuk siapa)
Tuliskan dua kalimat sebelum Anda menyentuh alat apapun:
Apa yang lambat? (muatan halaman, endpoint API, job batch, login, checkout, query SQL tertentu)
Di mana pengamatan lambat terjadi? (browser pelanggan, aplikasi mobile, satu region, satu pod, satu host, layanan internal)
Ini mencegah Anda mengoptimalkan lapisan yang salah—mis. CPU host—padahal rasa sakit terisolasi pada satu endpoint atau dependensi downstream.
Pilih jendela waktu dan lingkup
Pilih jendela yang cocok dengan keluhan dan sertakan periode perbandingan “baik” jika mungkin.
Rinci lingkup investigasi Anda secara eksplisit:
Host vs service vs endpoint: “Satu node Kubernetes” berbeda dengan “satu route API.”
Irisan trafik mana: region, tier pelanggan, hanya request error, atau semua request.
Sinyal apa yang memicu laporan: p95 latency, timeout, kedalaman antrean, atau user timing.
Ketepatan di sini membuat langkah selanjutnya (USE, RED, profiling) lebih cepat karena Anda tahu data apa yang seharusnya berubah jika hipotesis benar.
Perlakukan perubahan terbaru sebagai hipotesis, bukan jawaban
Catat deploys, perubahan konfigurasi, pergeseran trafik, dan event infra—tetapi jangan anggap kausalitas. Tuliskan sebagai “Jika X, maka kita akan berharap Y,” sehingga Anda bisa mengonfirmasi atau menolak dengan cepat.
Simpan log investigasi ringan
Log kecil mencegah duplikasi kerja antar rekan dan mempermudah handoff.
Time | Question | Scope | Data checked | Result | Next step
Bahkan lima baris seperti ini bisa mengubah insiden yang menegangkan jadi proses yang bisa diulang.
Metode USE: inventaris cepat bottleneck sumber daya
Metode USE (Utilization, Saturation, Errors) adalah daftar periksa cepat Gregg untuk memindai empat sumber daya utama—CPU, memori, disk (storage), dan jaringan—supaya Anda berhenti menebak dan mulai mempersempit masalah.
Apa itu: daftar periksa per-sumber daya
Alih-alih menatap puluhan dashboard, tanyakan tiga pertanyaan yang sama untuk tiap sumber daya:
Utilization: Seberapa sibuk saat ini?
Saturation: Apakah kerja menumpuk (antrean, waktu tunggu), bahkan jika utilizasi belum penuh?
Errors: Apakah gagal atau melakukan retry dengan cara yang menimbulkan delay?
Diterapkan konsisten, ini menjadi inventaris cepat tentang di mana “tekanan” ada.
Cara menerapkannya dalam praktik
Untuk CPU, utilization adalah persentase sibuk CPU, saturation tampak sebagai pressure run-queue atau thread yang menunggu untuk dijalankan, dan errors bisa termasuk throttling (di container) atau interrupt yang bermasalah.
Untuk memori, utilization adalah memori yang terpakai, saturation sering muncul sebagai paging atau garbage collection yang sering, dan errors meliputi kegagalan alokasi atau OOM.
Untuk disk, utilization adalah device busy time, saturation adalah kedalaman antrean dan read/write wait time, dan errors adalah error I/O atau timeout.
Untuk jaringan, utilization adalah throughput, saturation adalah drops/queues/latency, dan errors adalah retransmit, reset, atau packet loss.
Sinyal paling berguna selama insiden latensi
Saat pengguna melaporkan kelambatan, sinyal saturation sering paling mengungkapkan: antrean, waktu tunggu, dan kontensi cenderung berkorelasi lebih langsung dengan latensi dibandingkan utilisasi mentah.
USE melengkapi metrik service (bukan menggantikan)
Metrik level-service (seperti latency request dan error rate) memberi tahu Anda dampak. USE memberi tahu Anda ke mana harus melihat selanjutnya dengan mengidentifikasi sumber daya yang tertekan.
Loop praktis:
Konfirmasi dampak pengguna (Duration/Errors)
Jalankan inventaris USE
Zoom ke resource yang mencurigakan dengan tooling lebih dalam (profil, trace, stat kernel)
Metode RED: sinyal berorientasi layanan yang menunjuk ke dampak
Metode RED menjaga Anda tetap berfokus pada pengalaman pengguna sebelum menyelam ke grafik host.
Rate: berapa request per detik yang dilayani layanan atau endpoint Anda
Errors: berapa banyak request yang gagal (dan apa arti “gagal” untuk aplikasi Anda)
Duration: berapa lama request sukses berlangsung (lacak sebagai persentil, bukan rata-rata)
Mengapa RED membantu memprioritaskan
RED mencegah Anda mengejar metrik sistem yang “menarik” tapi tak berdampak pada pengguna. Ini memaksa loop yang lebih ketat: endpoint mana yang lambat, untuk siapa, dan sejak kapan? Jika Duration hanya melonjak pada satu route sementara keseluruhan CPU datar, Anda sudah punya titik awal yang lebih tajam.
Kebiasaan berguna: pertahankan RED terurai menurut service dan endpoint teratas (atau RPC penting). Itu memudahkan membedakan degradasi luas dari regresi lokal.
Memetakan gejala RED ke pemeriksaan USE
RED memberi tahu Anda di mana rasa sakit, USE membantu menguji sumber daya mana yang bertanggung jawab.
Contoh:
Duration naik + Rate stabil → periksa saturation/queueing: run queue CPU, latensi storage, pool koneksi DB.
Errors naik + Duration naik → periksa timeout dan retry: downstream kewalahan, pool thread, drop jaringan.
Overview RED: Rate, Errors, dan p50/p95/p99 Duration untuk service.
Endpoint teratas: sinyal RED yang sama per endpoint, diurutkan menurut trafik atau p95 terburuk.
Dependensi: panel bergaya RED untuk downstream utama (DB, cache, API eksternal).
Satu baris korelasi: sekumpulan kecil metrik sistem (CPU, tekanan memori, latensi I/O disk, retransmit jaringan) untuk mempercepat lompatan dari view service ke pengujian akar penyebab.
Jika Anda ingin workflow insiden konsisten, padukan bagian ini dengan inventaris USE di /blog/use-method-overview sehingga Anda dapat bergerak dari “pengguna merasakannya” ke “resource ini yang menjadi kendala” dengan lebih sedikit kebingungan.
Prioritisasi: pilih pertanyaan terbaik berikutnya untuk diajukan
Investigasi kinerja bisa meledak menjadi puluhan grafik dan hipotesis dalam hitungan menit. Pola pikir Gregg adalah mempertahankannya sempit: tugas Anda bukan “mengumpulkan lebih banyak data,” melainkan menanyakan pertanyaan berikutnya yang paling cepat menghilangkan ketidakpastian.
Aturan 80/20 untuk bottleneck
Sebagian besar masalah latensi didominasi oleh satu biaya (atau pasangan kecil): satu lock panas, satu dependensi lambat, satu disk ter-unggul, pola jeda GC. Prioritisasi berarti berburu biaya dominan itu terlebih dulu, karena memangkas 5% di lima tempat berbeda jarang menggerakkan latensi yang terlihat pengguna.
Tes praktis: “Apa yang bisa menjelaskan sebagian besar perubahan latensi yang kita lihat?” Jika sebuah hipotesis hanya bisa menjelaskan sebagian kecil, itu prioritas rendah.
Top-down vs. bottom-up: dari mana memulai
Gunakan top-down ketika Anda menjawab “Apakah pengguna terdampak?” Mulai dari endpoint (sinyal bergaya RED): latensi, throughput, error. Ini membantu Anda menghindari mengoptimalkan sesuatu yang tidak berada di jalur kritis.
Gunakan bottom-up ketika host jelas sakit (gejala bergaya USE): saturasi CPU, tekanan memori yang tak terkendali, I/O wait. Jika sebuah node terpegged, Anda akan buang waktu melihat persentil endpoint tanpa memahami kendala.
Pohon keputusan sederhana yang mencegah thrash
Ketika sebuah alert muncul, pilih cabang dan tetap di situ sampai terkonfirmasi atau dipalsukan:
Lonjakan latensi + lonjakan error → “Apakah ini event dependensi atau kapasitas?” (timeout, kehabisan pool koneksi, downstream 5xx)
Lonjakan latensi + lonjakan CPU → “Apakah CPU melakukan kerja berguna atau terjebak?” (on-CPU vs off-CPU time)
Lonjakan latensi + I/O wait tinggi → “Perangkat atau filesystem mana yang menumpuk?”
Lonjakan latensi tanpa lonjakan resource → “Di mana waktu dihabiskan menunggu?” (lock, scheduler, jaringan, panggilan jarak jauh)
Hindari kelebihan metrik, tetap sistematis
Batasi diri pada set sinyal awal kecil, lalu telusuri turun hanya ketika sesuatu bergerak. Jika Anda butuh daftar periksa untuk tetap fokus, tautkan langkah Anda ke runbook seperti /blog/performance-incident-workflow sehingga setiap metrik baru punya tujuan: menjawab pertanyaan spesifik.
Profiling di produksi tanpa menjatuhkan sistem
Profiling produksi bisa terasa berisiko karena menyentuh sistem hidup—tetapi seringkali ini cara tercepat untuk menggantikan perdebatan dengan bukti. Log dan dashboard dapat memberitahu Anda bahwa sesuatu melambat. Profiling memberitahu Anda ke mana waktu pergi: fungsi mana yang berjalan panas, thread mana yang menunggu, dan jalur kode apa yang mendominasi selama insiden.
Apa yang sebenarnya dijawab profiling
Profiling adalah alat “anggaran waktu”. Alih-alih memperdebatkan teori (“db” vs “GC”), Anda mendapatkan bukti seperti “45% sampel CPU ada di parsing JSON” atau “kebanyakan request diblok pada mutex”. Itu mempersempit langkah berikutnya menjadi satu atau dua perbaikan konkret.
Jenis umum yang bisa digunakan di produksi
CPU profiling: menunjukkan kode apa yang dieksekusi on-CPU.
Off-CPU (wait) profiling: menunjukkan di mana thread menghabiskan waktu terblokir (I/O wait, scheduler delay, sleep, jaringan, disk).
Lock profiling: menunjukkan kontensi—waktu hilang menunggu lock, mutex, dan latch baca/tulis.
Setiap jenis menjawab pertanyaan berbeda. Latensi tinggi dengan CPU rendah sering mengarah ke off-CPU atau waktu lock daripada hotspot CPU.
Always-on vs on-demand
Always-on profiling (kontinu, overhead rendah) membantu misteri “terjadi jam 3 pagi” karena Anda bisa melihat ke belakang.
On-demand profiling adalah capture terarah saat spike. Lebih mudah diadopsi, tetapi Anda harus siap memicunya cepat.
Banyak tim mulai on-demand, lalu pindah ke always-on setelah mempercayai keamanan dan melihat isu berulang.
Keamanan: overhead, sampling, dan jendela singkat
Profiling aman untuk produksi adalah soal mengendalikan biaya. Pilih sampling (bukan melacak setiap event), jaga jendela capture pendek (mis. 10–30 detik), dan ukur overhead di canary dulu. Kalau ragu, mulai dengan sampling frekuensi rendah dan naikkan hanya jika sinyal terlalu berisik.
Flame graphs: cara membacanya dan menghindari kesimpulan keliru
Flame graphs memvisualisasikan ke mana waktu sampel pergi selama jendela profiling. Setiap “kotak” adalah fungsi (atau frame stack), dan setiap stack menunjukkan bagaimana eksekusi mencapai fungsi itu. Mereka sangat baik untuk menemukan pola cepat—tetapi tidak otomatis memberi tahu “bug ada di sini.”
Apa yang ditunjukkan flame graph (dan apa yang tidak)
Flame graph biasanya merepresentasikan sampel on-CPU: waktu program benar-benar berjalan di core CPU. Ini dapat menyoroti jalur kode yang berat CPU, parsing yang tidak efisien, serialisasi berlebih, atau hotspot yang benar-benar membakar CPU.
Ia tidak** langsung** menunjukkan menunggu disk, jaringan, scheduler delay, atau waktu terblok pada mutex (itu adalah waktu off-CPU dan butuh profiling berbeda). Ia juga tidak membuktikan kausalitas untuk latensi yang terlihat pengguna kecuali Anda mengikatnya ke gejala yang discoped.
Membaca lebar dan kedalaman stack
Lebar: seberapa sering frame itu muncul dalam sampel. Lebih lebar biasanya berarti “lebih banyak waktu CPU,” tetapi hanya dalam jendela waktu yang dipilih.
Kedalaman stack: kedalaman panggilan. Stack yang dalam tidak buruk sendiri; yang penting adalah jalur mana yang mendominasi dan apakah mereka cocok dengan kerja yang Anda pedulikan.
Perangkap umum yang harus dihindari
Kotak paling lebar menggoda untuk disalahkan, tetapi tanyakan: apakah itu hotspot yang bisa Anda ubah, atau sekadar “waktu dihabiskan di malloc, GC, atau logging” karena isu sebenarnya ada di upstream? Juga awasi konteks yang hilang (JIT, inlining, simbol) yang bisa membuat sebuah kotak tampak seperti biang keladi padahal hanya perantara.
Padukan flame graphs dengan pertanyaan yang presisi
Anggap flame graph sebagai jawaban terhadap pertanyaan yang discoped: endpoint mana, jendela waktu mana, host mana, dan apa yang berubah. Bandingkan flame graph “sebelum vs sesudah” (atau “sehat vs terdegradasi”) untuk jalur request yang sama agar menghindari noise profiling.
Off-CPU time: sumber tersembunyi latensi
Saat latensi melonjak, banyak tim melihat persen CPU dulu. Itu wajar—tetapi sering menyesatkan. Layanan bisa “hanya 20% CPU” dan tetap sangat lambat jika thread menghabiskan sebagian besar waktunya tidak berjalan.
Mengapa CPU% saja menyesatkan
CPU% menjawab “seberapa sibuk prosesor?” Ia tidak menjawab “ke mana waktu permintaan saya pergi?” Permintaan bisa terhenti sementara thread menunggu, terblok, atau diparkir oleh scheduler.
Ide kunci: waktu wall-clock sebuah request mencakup kerja on-CPU dan menunggu off-CPU.
Penyebab off-CPU umum
Waktu off-CPU biasanya bersembunyi di balik dependensi dan kontensi:
Disk I/O: baca/tulis sinkron, fsync, storage lambat, cache halaman miss.
Antrean: menunggu di thread pool, connection pool, atau antrean kerja internal.
Gejala yang layak diwaspadai
Beberapa sinyal sering berkorelasi dengan bottleneck off-CPU:
naiknya queue time (permintaan menunggu sebelum mulai dieksekusi)
meningkatnya runnable threads (lebih banyak kompetisi untuk CPU)
naiknya I/O wait dan latensi disk/jaringan yang lebih panjang
Sinyal-sinyal ini memberitahu Anda “kita menunggu,” tetapi tidak apa yang ditunggu.
Bagaimana profiling off-CPU menunjukkan “ke mana waktu pergi”
Profiling off-CPU mengatribusikan waktu ke alasan Anda tidak berjalan: terblok di syscall, menunggu lock, sleep, atau dideschedule. Itu kuat untuk kerja latensi karena mengubah perlambatan samar menjadi kategori yang bisa ditindaklanjuti: “terblok pada mutex X,” “menunggu read() dari disk,” atau “stuck in connect() ke upstream.” Setelah Anda bisa memberi nama tunggu itu, Anda bisa mengukurnya, mengonfirmasinya, dan memperbaikinya.
Konfirmasi hambatan dengan bukti, bukan intuisi
Pekerjaan kinerja sering gagal pada momen yang sama: seseorang melihat metrik mencurigakan, menyatakannya “masalahnya,” dan mulai tuning. Metode Gregg mendorong Anda melambat dan membuktikan apa yang membatasi sistem sebelum Anda mengubah apapun.
Bottleneck, hot spot, dan noise
Sebuah bottleneck adalah resource atau komponen yang saat ini membatasi throughput atau mendorong latensi. Jika Anda meredakannya, pengguna akan melihat perbaikan.
Sebuah hot spot adalah tempat waktu dihabiskan (mis., fungsi yang sering muncul di profile). Hot spot bisa jadi bottleneck nyata—atau sekadar pekerjaan sibuk yang tidak mempengaruhi slow path.
Noise adalah semua yang tampak bermakna tapi bukan: job latar, lonjakan satu-kali, artefak sampling, efek caching, atau “top talkers” yang tidak berkorelasi dengan masalah yang terlihat pengguna.
Buktikan dengan perbandingan dan perubahan terkontrol
Mulai dengan menangkap snapshot sebelum yang bersih: gejala yang terlihat pengguna (latency atau error rate) dan sinyal kandidat teratas (saturasi CPU, kedalaman antrean, I/O disk, kontensi lock, dll). Lalu terapkan perubahan terkontrol yang seharusnya hanya memengaruhi dugaan penyebab.
Contoh tes kausal:
Tambah kapasitas ke resource yang dicurigai (satu worker lagi, lebih banyak CPU share, pool koneksi lebih tinggi) dan periksa apakah latency membaik.
Sementara kurangi beban (batasi endpoint yang berisik, replay workload lebih kecil) dan lihat apakah kendala yang dicurigai melonggar.
Korelasi adalah petunjuk, bukan vonis. Jika “CPU naik saat latensi naik,” verifikasi dengan mengubah ketersediaan CPU atau mengurangi kerja CPU dan mengamati apakah latensi mengikuti.
Dokumentasikan apa yang Anda buktikan
Tuliskan: apa yang diukur, perubahan tepat yang dibuat, hasil sebelum/sesudah, dan perbaikan yang diamati. Ini mengubah kemenangan sekali pakai menjadi playbook yang bisa dipakai di insiden selanjutnya—dan mencegah “intuisi” menulis ulang sejarah nanti.
Bangun workflow yang dapat diulang untuk insiden kinerja
Insiden kinerja terasa mendesak, dan itulah saat tebakan masuk. Workflow ringan yang dapat diulang membantu Anda bergerak dari “ada yang lambat” ke “kita tahu apa yang berubah” tanpa banyak thrash.
Loop insiden: detect → triage → measure → fix
Detect: alert berdasarkan latensi dan error yang terlihat pengguna, bukan hanya CPU. Paging ketika p95/p99 latency melewati ambang untuk jendela yang berkelanjutan.
Triage: jawab segera tiga pertanyaan: apa yang lambat, kapan mulai, dan siapa yang terdampak? Jika Anda tidak bisa menyebut lingkup (service, endpoint, region, cohort), Anda belum siap mengoptimalkan.
Measure: kumpulkan bukti yang mempersempit bottleneck. Pilih capture berbatas waktu (mis., 60–180 detik) sehingga Anda bisa membandingkan “buruk” vs “baik.”
Fix: ubah satu hal pada satu waktu, lalu ukur ulang sinyal yang sama untuk mengonfirmasi perbaikan dan menyingkirkan placebo.
Standarkan sekumpulan grafik kecil
Pertahankan dashboard bersama yang dipakai semua orang saat insiden. Buat ia membosankan dan konsisten:
Latency: p50 / p95 / p99 (per endpoint kritis)
Sinyal RED: Rate, Errors, Duration (view berorientasi service)
Beberapa metrik USE: utilization, saturation, errors untuk CPU, disk, dan network
Tujuannya bukan memvisualisasikan semuanya; melainkan mempersingkat waktu-ke-fakta-pertama.
Definisikan “golden signals” per endpoint kritis
Instrumentasikan endpoint yang paling penting (checkout, login, search), bukan setiap endpoint. Untuk masing-masing, sepakati: p95 yang diharapkan, batas error maksimum, dan dependensi kunci (DB, cache, pihak ketiga).
Putuskan apa yang ditangkap selama insiden
Sebelum outage berikutnya, sepakati kit capture:
Profil (CPU dan off-CPU), plus flame graphs
Trace untuk endpoint yang lambat
Log untuk error/timeout (sampled)
Dokumentasikan dalam runbook singkat (mis., /runbooks/latency), termasuk siapa yang boleh menjalankan capture dan di mana artefak disimpan.
Di mana Koder.ai cocok dalam workflow ala Gregg
Metodologi Gregg pada dasarnya tentang perubahan terkontrol dan verifikasi cepat. Jika tim Anda membangun layanan menggunakan Koder.ai (platform chat-driven untuk menghasilkan dan mengiterasi web, backend, dan aplikasi mobile), dua fitur cocok dengan pola ini:
Planning Mode membantu Anda mengubah “mungkin ini X” menjadi hipotesis eksplisit dan set perubahan kecil yang dapat diuji sebelum menyentuh produksi.
Snapshots and rollback mendukung eksperimen aman satu-variabel: lakukan satu perubahan, ukur ulang sinyal RED/USE, dan rollback cepat jika bukti mengatakan “tidak.”
Bahkan jika Anda tidak menghasilkan kode baru saat insiden, kebiasaan itu—diff kecil, hasil yang terukur, dan reversibilitas cepat—adalah kebiasaan yang sama yang Gregg promosikan.
Walkthrough praktis: dari lonjakan latensi ke perbaikan terverifikasi
Skenario: p99 melonjak saat puncak trafik
Pukul 10:15 pagi dashboard menunjukkan p99 latency API naik dari ~120ms ke ~900ms saat puncak trafik. Error rate stabil, tetapi pelanggan melaporkan request “lambat.”
Langkah 1 — Mulai dengan RED untuk menemukan dampak pengguna
Mulai berorientasi layanan: Rate, Errors, Duration.
Anda memecah Duration berdasarkan endpoint dan melihat satu route mendominasi p99: POST /checkout. Rate naik 2×, error normal, tetapi Duration melonjak khususnya saat concurrency meningkat. Itu mengarah ke antrean atau kontensi, bukan kegagalan total.
Selanjutnya, periksa apakah latensi adalah waktu komputasi atau menunggu: bandingkan “handler time” aplikasi vs total request time (atau upstream vs downstream spans jika ada tracing). Handler time rendah, total time tinggi—permintaan sedang menunggu.
Langkah 2 — Terapkan USE pada host yang dicurigai
Inventarisasi bottleneck kemungkinan: Utilization, Saturation, Errors untuk CPU, memori, disk, dan jaringan.
Utilisasi CPU hanya ~35%, tetapi run queue CPU dan context switches naik. Disk dan jaringan terlihat stabil. Ketidaksesuaian ini (CPU% rendah, banyak waiting) adalah petunjuk klasik: thread tidak membakar CPU—mereka diblokir.
Langkah 3 — Pilih profiling berdasarkan gejala
Kalau CPU tinggi: gunakan CPU profiling (on-CPU flame graph) untuk melihat ke mana waktu pergi.
Kalau request menunggu: gunakan off-CPU profiling untuk melihat apa yang membuat thread terblokir (lock, I/O, scheduler).
Anda menangkap profile off-CPU selama spike dan menemukan banyak waktu terbuang pada mutex di sekitar cache "promotion validation" bersama.
Langkah 4 — Perbaiki, lalu verifikasi
Anda mengganti lock global dengan lock per-key (atau jalur baca tanpa lock), deploy, dan mengamati p99 kembali ke baseline sementara Rate tetap tinggi.
Checklist pasca-insiden:
Catat gejala RED tepat dan endpoint yang dipersempit.
Simpan profile dan jendela waktunya.
Tambahkan alert untuk sinyal saturasi spesifik (mis., waktu tunggu lock / run queue).
Tuliskan “pertanyaan berikutnya” jika terjadi lagi.
