Mendekode Log Kesalahan MongoDB

Terkadang mendekode log kesalahan MongoDB bisa rumit dan dapat menghabiskan banyak waktu berharga Anda. Dalam artikel ini, kita akan mempelajari cara memeriksa log kesalahan MongoDB dengan membedah setiap bagian dari pesan log.

Format Umum untuk Baris Log MongoDB

Berikut adalah pola baris log untuk versi 3.0 ke atas...

<timestamp> <severity> <component> [<context>] <message>

Pola baris log untuk versi MongoDB sebelumnya hanya menyertakan:

<timestamp> [<context>] <message>

Mari kita lihat masing-masing tag.

Stempel waktu

Bidang stempel waktu pesan log menyimpan waktu yang tepat ketika pesan log dimasukkan ke dalam file log. Ada 4 jenis cap waktu yang didukung oleh MongoDB. Format defaultnya adalah:iso8601-local. Anda dapat mengubahnya menggunakan parameter --timeStampFormat.

Keparahan

Tabel berikut menjelaskan arti dari semua kemungkinan tingkat keparahan.

Komponen

Setelah versi 3.0, pesan log sekarang menyertakan "komponen" untuk memberikan kategorisasi fungsional dari pesan. Ini memungkinkan Anda mempersempit pencarian dengan mudah dengan melihat komponen tertentu.

Konteks

Bagian konteks dari pesan kesalahan umumnya berisi utas atau id koneksi. Nilai lain bisa initandlisten. Bagian ini dikelilingi oleh tanda kurung siku. Pesan log dari koneksi baru apa pun ke MongoDB akan memiliki nilai konteks sebagai initandlisten, untuk semua pesan log lainnya, itu akan berupa id utas atau id koneksi. Misalnya

2018-05-29T19:06:29.731+0000 [initandlisten] connection accepted from 127.0.0.1:27017 #1000 (13 connections now open)
2018-05-29T19:06:35.770+0000 [conn1000] end connection 127.0.0.1:27017 (12 connections now open)

Pesan

Berisi pesan log yang sebenarnya.

Lokasi File Log

Lokasi default di server adalah:/var/log/mongodb/mongodb.log

Jika file log tidak ada di lokasi ini maka Anda dapat memeriksa di file konfigurasi MongoDB. Anda dapat menemukan file konfigurasi MongoDB di salah satu dari dua lokasi ini.

/etc/mongod.conf or /yourMongoDBpath/mongod.conf

Setelah Anda membuka file konfigurasi, cari opsi logpath di dalamnya. opsi logpath memberi tahu MongoDB tempat untuk mencatat semua pesan.

Menganalisis Pesan Log Sederhana

Berikut adalah contoh pesan kesalahan khas MongoDB...

2014-11-03T18:28:32.450-0500 I NETWORK [initandlisten] waiting for connections on port 27017

Timestamp:2014-11-03T18:28:32.450-0500
Keparahan:I
Komponen:NETWORK
Konteks:[initandlisten]
Pesan:menunggu koneksi pada port 27017

Bagian terpenting dari kesalahan ini adalah bagian pesan. Dalam sebagian besar kasus, Anda dapat mengetahui kesalahan dengan melihat bidang ini. Terkadang jika pesannya tidak jelas bagi Anda, maka Anda dapat menggunakan bagian komponen. Untuk pesan ini, nilai Komponen adalah Jaringan yang berarti pesan log terkait dengan masalah jaringan.

Jika Anda tidak dapat mengatasi kesalahan Anda, Anda dapat memeriksa tingkat keparahan pesan log yang mengatakan bahwa pesan ini untuk tujuan informasi. Selanjutnya, Anda juga dapat memeriksa bagian lain dari pesan log seperti stempel waktu atau konteks untuk menemukan akar penyebab lengkapnya.

Mendekode Pesan Log Kesalahan Umum

1. Pesan:

   2018-05-10T21:19:46.942 I CONTROL  [initandlisten] ** WARNING: Access control is not enabled for the database.

   Resolusi: Buat pengguna admin di database otentikasi

2. Pesan:

   2018-05-10T21:19:46.942 E COMMAND  [initandlisten] ** ERROR: getMore command failed. Cursor not found

   Resolusi: Hapus batas waktu dari kursor atau tambah ukuran kumpulan kursor.

3. Pesan:

   2018-05-10T21:19:46.942 E INDEX  [initandlisten] ** ERROR:E11000 duplicate key error index: test.collection.$a.b_1 dup key: { : null }

   Resolusi: Pelanggaran batasan kunci unik. Coba masukkan dokumen dengan kunci yang berbeda.

4. Pesan:

   2018-05-10T21:19:46.942 E NETWORK  [initandlisten] ** ERROR:Timed out connecting to localhost:27017.

   Resolusi: Latensi antara pengemudi dan server terlalu besar, pengemudi mungkin menyerah. Anda dapat mengubah pengaturan dengan menambahkan opsi connectionTimeout di connection string.

5. Pesan:

   2018-05-10T21:19:46.942 E WRITE  [initandlisten] ** ERROR: A write operation resulted in an error. E11000 duplicate key error index: test.people.$_id_ dup key: { : 0 }

   Resolusi: Hapus duplikasi nilai bidang _id dari dokumen yang bentrok.

6. Pesan:

   2018-05-10T21:19:46.942 E NETWORK  [initandlisten] ** ERROR: No connection could be made because the target machine actively refused it 127.0.0.1:27017 at System.Net.Sockets.Socket.EndConnect

   Resolusi: Server tidak berjalan pada port 27017 atau mencoba me-restart server dengan host dan port yang benar.

Alat Manajemen Log

MongoDB 3.0 telah memperbarui fitur logging untuk memberikan wawasan yang lebih baik untuk semua aktivitas database. Ada banyak alat manajemen log yang tersedia di pasar seperti MongoDB Ops Manager, entri log, mtools, dll.

Kesimpulan

Logging sama pentingnya dengan Replication atau Sharding untuk pengelolaan database yang baik dan benar. Untuk manajemen basis data yang lebih baik, seseorang harus dapat memecahkan kode log dengan mudah untuk memperbaiki pengecualian/kesalahan dengan cepat. Saya harap setelah membaca tutorial ini, Anda akan merasa lebih nyaman saat menganalisis log MongoDB yang kompleks.