Monitoring Performa

Perbedaan antara server yang sehat dan server yang sedang menuju masalah hampir selalu terlihat lebih dulu di angka: antrean koneksi yang memanjang, rasio cache yang menurun, atau operasi tulis yang melambat. Monitoring adalah kebiasaan membaca angka-angka itu secara rutin, bukan hanya saat keluhan datang. Chapter ini memetakan metrik kunci yang tersedia langsung dari server melalui db.serverStatus() dan db.currentOp(), menjelaskan arti masing-masing, lalu menutup dengan peran mongostat dan mongotop dari Database Tools.

Peta materi Chapter ini:

• db.serverStatus(): sumber metrik utama dan bagian-bagiannya.
• Metrik koneksi, opcounters, cache WiredTiger, dan document.
• db.currentOp() untuk melihat operasi yang sedang berjalan.
• mongostat dan mongotop sebagai pemantau laju data.

db.serverStatus(): Pusat Data Operasional #

Perintah serverStatus mengembalikan dokumen besar berisi statistik server sejak proses dinyalakan. Karena bentuknya panjang, kita simpan sekali lalu ambil bagian-bagiannya:

use latihan_perf
const ss = db.serverStatus()
ss.version
ss.uptime
ss.connections

Output yang Dihasilkan:

switched to db latihan_perf

9.0.2
23317
{
  current: 4,
  available: 405,
  totalCreated: 7864,
  rejected: 0,
  active: 1,
  queuedForEstablishment: 0,
  establishmentRateLimit: { rejected: 0, exempted: 0, interruptedDueToClientDisconnect: 0 },
  threaded: 4,
  exhaustIsMaster: Long('0'),
  exhaustHello: Long('0'),
  awaitingTopologyChanges: Long('0'),
  loadBalanced: 0,
  priority: 0
}

Angka-angka di atas diambil dari satu eksekusi — di server Anda nilainya pasti berbeda karena statistik ini bersifat kumulatif sejak proses menyala. Mari kita bedah bagian-bagiannya:

1. ss.version: versi server — berguna memastikan Anda memantau host yang tepat.
2. ss.uptime: umur proses dalam detik. Angka yang tiba-tiba menjadi kecil berarti server baru saja hidup ulang — sinyal untuk menyelidiki.
3. ss.connections: current adalah koneksi terbuka saat ini; available adalah sisa slot hingga batas maxIncomingConnections; totalCreated menghitung total koneksi yang pernah dibuat. Kenaikan current yang terus membesar tanpa turun mengindikasikan kebocoran koneksi di sisi aplikasi. Field seperti queuedForEstablishment dan establishmentRateLimit memantau pembatasan laju koneksi baru yang diterapkan server.

Opcounters: Denyut Operasi #

opcounters menghitung setiap operasi sejak server menyala, dibagi per jenis:

ss.opcounters
ss.opcountersRepl

Output yang Dihasilkan:

{
  insert: Long('10944'),
  query: Long('2221'),
  update: Long('5472'),
  delete: Long('1161'),
  getmore: Long('4'),
  command: Long('26296'),
  aggregate: Long('72308')
}

{
  insert: Long('10'),
  query: Long('0'),
  update: Long('3'),
  delete: Long('2'),
  getmore: Long('0'),
  command: Long('14'),
  aggregate: Long('0')
}

Tujuh penghitung ini adalah denyut harian server. insert, query, update, dan delete masing-masing jelas; getmore bertambah setiap cursor mengambil batch berikutnya; command menghitung semua perintah lain termasuk hello dan panggilan internal driver; dan aggregate — pemisahan yang dimulai pada MongoDB 9.0 — menghitung pipeline aggregation secara khusus sehingga diagnosis beban analitik menjadi lebih ringkas. opcountersRepl memisahkan operasi yang datang dari replikasi anggota secondary; nilainya kecil di server latihan kita karena tidak ada secondary yang sibuk menarik data.

Angka mentah ini baru berguna sebagai deret waktu: simpan sampel tiap menit, lalu bandingkan. Lonjakan query tiga kali lipat pada jam yang sama setiap hari adalah pola beban; lonjakan command tanpa aktivitas aplikasi biasanya sinyal health-check atau polling yang terlalu rapat.

Cache WiredTiger: Tekanan Memori #

Bagian wiredTiger.cache menjelaskan bagaimana storage engine mengelola memori:

ss.wiredTiger.cache["bytes currently in the cache"]
ss.wiredTiger.cache["maximum bytes configured"]
ss.wiredTiger.cache["unmodified pages evicted"]

Output yang Dihasilkan:

61882793
268435456
396

Tiga angka ini membentuk cerita memori. Mari kita tafsirkan:

1. bytes currently in the cache: total data dan index yang sedang berada di memori — pada server latihan kita sekitar 62 MB.
2. maximum bytes configured: batas atas cache yang dikonfigurasi — server latihan sengaja dibatasi 256 MB (cacheSizeGB: 0.25) agar hemat sumber daya; server produksi umumnya mengatur sekitar 50% RAM dikurangi 1 GB.
3. unmodified pages evicted: jumlah halaman bersih yang pernah dilempar keluar dari cache untuk memberi ruang. Angka kecil pada data latihan ini normal; pada produksi, eviksi yang terus membesar bersama waktu respons yang memburuk adalah indikasi klasik working set yang tidak muat.

Metrik Document dan Memori Proses #

Dua blok pelengkap yang sering dirujuk saat diagnosis:

ss.metrics.document
ss.mem

Output yang Dihasilkan:

{
  deleted: Long('647'),
  inserted: Long('10797'),
  returned: Long('6670'),
  updated: Long('909')
}

{
  bits: 64,
  resident: 572,
  virtual: 6325,
  supported: true,
  secureAllocByteCount: 0,
  secureAllocBytesInPages: 4096
}

metrics.document menghitung document yang dimasukkan, dikembalikan, diperbarui, dan dihapus — angka returned adalah kandidat utama audit payload: nilai yang jauh melampaui kebutuhan aplikasi biasanya berarti query tanpa limit atau projection terlalu lebar. mem.resident menunjukkan memori fisik yang dipakai proses dalam MB; angka ini tumbuh mendekati batas cache plus overhead, lalu stabil — pertumbuhan terus-menerus patut dicurigai.

currentOp: Jendela ke Operasi Berjalan #

Ketika server terasa lambat, pertanyaan pertama adalah “apa yang sedang dikerjakan?”. db.currentOp() menjawabnya:

db.currentOp({ active: true, secs_running: { $gte: 1 } })

Output yang Dihasilkan:

{ inprog: [], ok: 1 }

Server latihan sedang tidak mengerjakan apa pun yang berjalan lebih dari satu detik, sehingga inprog kosong. Filter yang umum dipakai: active: true hanya operasi aktif, secs_running: { $gte: N } hanya yang sudah berjalan lama, dan command untuk mencari jenis operasi tertentu. Setiap entri inprog memuat secs_running, command, ns (namespace), dan planSummary — pola COLLSCAN pada entri berdurasi panjang hampir selalu menjadi tersangka utama kelambatan.

mongostat dan mongotop #

Dua alat baris perintah dari MongoDB Database Tools melengkapi gambaran di atas dengan tampilan laju (bukan total kumulatif):

Keduanya mengambil sampel berkala lalu mencetak baris ringkas; --rowcount membatasi jumlah baris agar cocok untuk pemeriksaan singkat. Untuk pemantauan berkelanjutan di produksi, praktik yang lebih umum adalah menyalurkan serverStatus ke sistem metrik (Prometheus, dsb.) dan menaruhnya di dasbor — angka yang sama, hanya digambar menjadi grafik.

Rangkuman #

• db.serverStatus() adalah sumber metrik utama: versi, uptime, koneksi, opcounters, cache WiredTiger, metrik document, dan memori proses.
• Opcounters dan metrics.document adalah angka kumulatif — nilainya muncul dari perbandingan antar sampel waktu; MongoDB 9.0 menghitung aggregate secara terpisah.
• Eviksi halaman cache yang membesar menandakan working set melebihi memori cache yang dikonfigurasi.
• db.currentOp({ active: true, secs_running: { $gte: 1 } }) menampilkan operasi yang sedang berjalan lama beserta rencananya.
• mongostat dan mongotop menyajikan laju operasi dan waktu per collection sebagai pelengkap pemantauan berkala.