Database Logs

Saat server berperilaku aneh — koneksi ditolak, query melambat, atau replica set memilih primary baru — kisah lengkapnya hampir selalu tercatat di log. MongoDB sejak versi 3.0 menulis log dalam format JSON yang bisa dipilah mesin, bukan teks bebas, sehingga mencari kejadian tertentu cukup dengan filter sederhana. Chapter ini membedah struktur satu baris log, arti severity dan komponen, teknik penyaringan untuk investigasi insiden, serta cara menaikkan verbosity sementara saat kita butuh detail lebih banyak.

Peta materi chapter ini:

• Struktur JSON log: t, s, c, id, ctx, msg, attr.
• Severity F/E/W/I/D dan komponen seperti NETWORK serta COMMAND.
• Menyaring log dengan grep untuk investigasi.
• db.setLogLevel() untuk menyetel verbosity per komponen.

Anatomi Satu Baris Log #

Server latihan kita menyimpan log di /home/z/my-project/mongo-data/mongod.log (di instalasi paket biasanya /var/log/mongodb/mongod.log). Berikut satu baris asli dari log itu, diformat ulang agar muat:

{"t":{"$date":"2026-10-17T12:47:32.230+00:00"},"s":"I",  "c":"NETWORK",  "id":22943,   "ctx":"listener","msg":"Connection accepted","attr":{"remote":"127.0.0.1:38282","isLoadBalanced":false,"isProxyUnixSock":false,"isPriority":false,"uuid":{"uuid":{"$uuid":"b095e932-8100-4c77-be3c-d60d942bdd02"}},"connectionId":1,"local":"127.0.0.1:27017","connectionCount":1}}

Setiap baris log adalah satu document JSON dengan field tetap:

Dua field inilah kunci pemilahan cepat: s untuk menyaring berdasarkan tingkat urgensi, dan attr untuk menyaring berdasarkan isi. Nomor id berguna saat Anda mencari arti pesan di dokumentasi resmi — setiap id memiliki halaman penjelasan sendiri.

Severity dan Komponen #

Nilai s memiliki lima tingkat yang wajib dihafal:

Sebagai gambaran nyata, log server latihan kita saat ini berisi 82.274 baris: 82.118 ber-s:"I", 149 ber-s:"W", dan nol E/F — pola sehat yang wajar untuk server tanpa masalah. Komponen c yang paling sering muncul:

Menyaring Log untuk Investigasi #

Karena formatnya JSON satu baris, grep sederhana sudah menjadi alat investigasi yang kuat. Tiga pola yang paling sering dipakai — pertama, menghitung ada berapa baris error:

grep -c '"s":"E"' /home/z/my-project/mongo-data/mongod.log

Output yang Dihasilkan:

0

Kedua, melihat semua warning — ingat kembali strukturnya, "s":"W" cocok sebagai string karena field severity selalu berformat itu:

grep '"s":"W"' /home/z/my-project/mongo-data/mongod.log | head -n 2

Output yang Dihasilkan:

{"t":{"$date":"2026-10-17T12:47:25.941+00:00"},"s":"W",  "c":"CONTROL",  "id":20720,   "ctx":"initandlisten","msg":"Memory available to mongo process is less than total system memory","attr":{"availableMemSizeMB":4096,"systemMemSizeMB":4159}}
{"t":{"$date":"2026-10-17T12:47:25.972+00:00"},"s":"W",  "c":"CONTROL",  "id":22120,   "ctx":"initandlisten","msg":"Access control is not enabled for the database. Read and write access to data and configuration is unrestricted","tags":["startupWarnings"]}

Kedua warning di atas terjadi saat startup: yang pertama hanya informasi pembagian memori di mesin virtual, sedangkan yang kedua adalah peringatan klasik server tanpa autentikasi — di produksi, baris ini wajib membuat Anda bertindak. Ketiga, mengais durasi semua slow query:

grep '"msg":"Slow query"' /home/z/my-project/mongo-data/mongod.log \
  | grep -o '"durationMillis":[0-9]*' | tail -n 3

Output yang Dihasilkan:

"durationMillis":4
"durationMillis":0
"durationMillis":0

Pola dua tahap ini layak dihafal: tahap pertama memilih baris Slow query (server menandai operasi yang melewati ambang 100 ms secara bawaan), tahap kedua mengeluarkan hanya angka durasinya. Saat menyelidiki keluhan “aplikasi lambat tadi siang”, gabungkan filter "t" untuk rentang jam dengan filter jenis kejadian seperti ini.

Menyetel Verbosity per Komponen #

Tingkat detail log bisa dinaikkan sementara untuk komponen tertentu lewat db.setLogLevel(level, komponen). Level bergerak dari 0 (normal) sampai 5 (paling rinci). Mari kita nyalakan level 1 untuk komponen query, lihat hasilnya, lalu kembalikan:

db.setLogLevel(1, "query").was.query.verbosity

Output yang Dihasilkan:

-1

Nilai kembalian was menunjukkan level sebelumnya — -1 berarti komponen query semula hanya mewarisi level global. Verifikasi bahwa pengaturan baru sudah aktif:

db.adminCommand({ getParameter: 1, logComponentVerbosity: 1 }).logComponentVerbosity.query

Output yang Dihasilkan:

{
  verbosity: 1,
  optimizer: { verbosity: -1 },
  ce: { verbosity: -1 },
  rejected: { verbosity: -1 }
}

Sekarang verbosity bernilai 1, sementara sub-komponen seperti optimizer masih -1 — artinya mewarisi induknya. Mengembalikan ke keadaan semula cukup set nilai -1:

db.setLogLevel(-1, "query").was.query.verbosity

Output yang Dihasilkan:

1

Angka 1 yang dikembalikan adalah level sebelum pemulihan — bukti perintah pemulihan menimpa level 1 tadi. Setelah blok ini, komponen query kembali mewarisi level global.

Rotasi dan Volume Log #

File log tumbuh tanpa henti, sehingga perlu dirotasi. Perintah logRotate membuat mongod menutup file aktif dan membuka file baru:

// mdtest: skip
db.adminCommand({ logRotate: 1 })

Rotasi juga bisa dipicu dari luar dengan kill -USR1 <pid>. Pada instalasi paket, pekerjaan ini biasanya diserahkan ke logrotate milik sistem operasi yang menjalankan perintah tersebut secara terjadwal. Opsi logAppend: true yang kita pakai memastikan rotasi tidak menimpa log lama, sedangkan systemLog.quiet: true bisa dipakai untuk meredam pesan rutin — gunakan hanya bila volume benar-benar bermasalah, karena kemampuan diagnosis ikut berkurang.

Rangkuman #

• Log MongoDB berformat JSON per baris dengan field tetap: t, s, c, id, ctx, msg, attr.
• Severity F/E/W/I/D dan komponen seperti NETWORK/COMMAND/REPL adalah dua sumbu penyaringan utama.
• grep pada pola "s":"E", "s":"W", dan "msg":"Slow query" sudah cukup untuk sebagian besar investigasi insiden.
• db.setLogLevel(level, komponen) menaikkan detail untuk komponen tertentu; selalu pulihkan dengan -1 setelah selesai.
• Rotasi log lewat logRotate atau SIGUSR1 menjaga ukuran file tetap terkelola.