Memantau &Mengamankan MongoDB dengan ClusterControl Advisors

Manajemen operasi basis data terdiri dari 80% membaca dan menafsirkan sistem pemantauan Anda. Ratusan metrik dapat ditafsirkan dan digabungkan dalam berbagai cara untuk memberi Anda wawasan mendalam tentang sistem database Anda dan cara mengoptimalkannya. Saat menjalankan beberapa sistem basis data, pemantauan sistem ini dapat menjadi tugas yang cukup berat. Jika interpretasi dan kombinasi metrik membutuhkan banyak waktu, bukankah lebih baik jika ini dapat diotomatisasi dengan cara tertentu?

Inilah sebabnya kami membuat penasihat basis data di ClusterControl:skrip kecil yang dapat menginterpretasikan dan menggabungkan metrik untuk Anda, dan memberi Anda saran bila berlaku. Untuk MySQL, kami telah membuat perpustakaan lengkap dari pemeriksaan pemantauan MySQL yang paling umum digunakan. Tetapi juga untuk MongoDB kami memiliki perpustakaan penasihat yang luas untuk Anda gunakan. Untuk posting blog ini, kami telah memilih sembilan yang paling penting untuk Anda. Kami akan menjelaskannya satu per satu secara mendetail.

Sembilan penasihat MongoDB yang akan kita bahas dalam posting blog ini adalah:

• Pemeriksaan opsi pemasangan disk
• Cek angka
• Persentase kunci koleksi (MMAP)
• Keterlambatan replikasi
• Jendela Replikasi
• Basis data dan koleksi yang tidak di-sharding (khusus cluster yang di-sharding)
• Cek autentikasi diaktifkan
• Pemeriksaan kewarasan otentikasi/otorisasi
• Deteksi kesalahan (penasihat baru)

Penasihat Opsi Pemasangan Disk

Sangat penting untuk memasang disk Anda dengan cara yang paling optimal. Dengan penasihat opsi pemasangan disk ClusterControl, kami melihat lebih dekat pada disk data Anda setiap hari. Dalam penasihat ini, kami menyelidiki sistem file yang digunakan, opsi pemasangan, dan pengaturan penjadwal io dari sistem operasi.

Kami memeriksa apakah disk Anda telah dipasang dengan noatime dan nodiratime. Pengaturan ini akan menurunkan kinerja disk, karena pada setiap akses ke file atau direktori, waktu akses harus ditulis ke disk. Karena ini terjadi terus-menerus pada database, ini adalah pengaturan kinerja yang baik dan juga meningkatkan daya tahan SSD Anda.

Untuk sistem file, kami menyarankan untuk menggunakan sistem file modern seperti xfs, zfs, ext4 atau btrfs. Sistem file ini dibuat dengan mempertimbangkan kinerja. Penjadwal io disarankan untuk berada di noop atau tenggat waktu. Batas waktu telah menjadi default untuk database selama bertahun-tahun, tetapi berkat penyimpanan yang lebih cepat seperti SSD, noop penjadwal sekarang lebih masuk akal.

Penasihat Pemeriksaan Numa

Untuk MongoDB kami mengaktifkan NUMA memeriksa penasihat. Penasihat ini akan memeriksa apakah NUMA (Memori Akses Non-Seragam) telah diaktifkan di sistem Anda, dan jika ini masalahnya, matikan.

Ketika Memori Akses Non-Seragam telah diaktifkan, CPU server hanya dapat menangani memorinya sendiri secara langsung dan bukan CPU lain di mesin. Dengan cara ini CPU hanya dapat mengalokasikan memori dari ruang memorinya sendiri, dan mengalokasikan apa pun yang berlebihan akan menghasilkan penggunaan swap. Arsitektur ini memiliki manfaat kinerja yang kuat pada aplikasi multi-prosesor yang mengalokasikan semua CPU, tetapi karena MongoDB bukan aplikasi multi-prosesor, itu akan sangat menurunkan kinerja dan dapat menyebabkan penggunaan swap yang besar.

Persentase Kunci Koleksi (MMAP)

Sebagai MMAP adalah sistem penyimpanan berbasis file, tidak mendukung penguncian tingkat dokumen seperti yang ditemukan di WiredTiger dan RocksDB. Alih-alih tingkat penguncian terendah untuk MMAP adalah kunci koleksi. Ini berarti setiap penulisan ke koleksi (menyisipkan, memperbarui, atau menghapus) akan mengunci seluruh koleksi. Jika persentase kunci terlalu tinggi, ini menunjukkan Anda memiliki masalah pertengkaran pada koleksi. Jika tidak ditangani dengan benar, hal ini dapat membuat throughput penulisan Anda terhenti. Oleh karena itu, memiliki penasihat yang memperingatkan Anda sebelumnya sangat membantu.

Penasihat Jeda Replikasi MongoDB

Jika Anda meningkatkan MongoDB untuk pembacaan melalui sekunder, jeda replikasi sangat penting untuk diperhatikan. Driver klien MongoDB hanya akan menggunakan sekunder yang tidak ketinggalan terlalu jauh, jika tidak, Anda dapat mengambil risiko menyajikan data basi.

Di dalam MongoDB, primer akan melacak status replikasi sekundernya. Penasihat akan mengambil informasi replikasi dan menjaga jeda replikasi. Jika lag menjadi terlalu tinggi, itu akan mengirimkan peringatan atau pesan status kritis.

Penasihat Jendela Replikasi MongoDB

Di samping jeda replikasi, jendela replikasi adalah metrik penting yang harus diperhatikan. Oplog MongoDB adalah kumpulan tunggal, yang telah dibatasi dalam ukuran (preset). Setelah oplog mencapai akhir dan transaksi baru perlu disimpan, oplog akan mengeluarkan transaksi terlama untuk memberi ruang bagi transaksi baru. Jendela replikasi mencerminkan jumlah detik antara transaksi terlama dan terbaru di oplog.

Metrik ini sangat penting karena Anda perlu mengetahui berapa lama Anda dapat mengambil sekunder dari replicaSet, sebelum tidak lagi dapat mengejar master karena terlalu jauh tertinggal dalam replikasi. Juga jika sekunder mulai tertinggal, akan baik untuk mengetahui berapa lama kita dapat mentolerir ini sebelum sekunder tidak lagi dapat mengejar.

Di shell MongoDB, sebuah fungsi tersedia untuk menghitung jendela replikasi. Penasihat di ClusterControl ini menggunakan fungsi untuk membuat perhitungan yang sama. Manfaatnya adalah Anda sekarang dapat diperingatkan pada jendela replikasi yang terlalu pendek.

MongoDB Un-Sharded Databases and Collections Advisor

Dalam sharded MongoDB cluster, semua database dan koleksi yang tidak di-sharded ditetapkan ke shard primer default oleh router shard MongoDB. Pecahan utama ini dapat bervariasi antara basis data dan koleksi, tetapi secara umum ini adalah pecahan dengan ruang disk paling banyak yang tersedia.

Memiliki database atau koleksi yang tidak di-sharding tidak langsung menimbulkan risiko bagi klaster Anda. Namun jika aplikasi atau pengguna mulai menulis data dalam jumlah besar ke salah satu dari ini, pecahan utama dapat terisi dengan cepat dan membuat pemadaman pada pecahan ini. Karena database atau koleksi tidak di-shard, maka tidak akan dapat menggunakan shard lain.

Karena alasan ini kami telah membuat penasihat yang akan mencegah hal ini terjadi. Penasihat akan memindai semua database dan koleksi, dan memperingatkan Anda jika belum di-sharding.

Otentikasi Diaktifkan Periksa

Tanpa mengaktifkan otentikasi di MongoDB, setiap pengguna yang masuk akan diperlakukan sebagai admin. Ini adalah risiko serius karena tugas admin yang biasanya, seperti membuat pengguna atau membuat cadangan, kini tersedia bagi siapa saja. Ini dikombinasikan dengan server MongoDB yang terbuka, menghasilkan peretasan tebusan MongoDB baru-baru ini, sementara pengaktifan otentikasi sederhana akan mencegah sebagian besar kasus ini.

Kami telah menerapkan penasihat yang memverifikasi apakah server MongoDB Anda mengaktifkan otentikasi. Ini dapat dilakukan secara eksplisit dengan menyetel ini dalam konfigurasi, atau secara implisit dengan mengaktifkan file kunci replikasi. Jika penasihat ini gagal mendeteksi otentikasi telah diaktifkan, Anda harus segera menindaklanjutinya, karena server Anda rentan disusupi.

Pemeriksaan Kewarasan Otentikasi/Otorisasi

Di samping penasihat yang mengaktifkan otentikasi, kami juga telah membangun penasihat yang melakukan pemeriksaan kewarasan untuk otentikasi dan otorisasi di MongoDB.

Di MongoDB otentikasi dan otorisasi tidak ditempatkan di lokasi pusat, tetapi dilakukan dan disimpan di tingkat basis data. Biasanya pengguna akan terhubung ke database, mengautentikasi terhadap database yang ingin mereka gunakan. Namun, dengan hibah yang benar, juga dimungkinkan untuk mengotentikasi terhadap database lain (tidak terkait) dan masih menggunakan database lain. Biasanya ini baik-baik saja, kecuali jika pengguna memiliki hak yang berlebihan (seperti peran admin) atas database lain.

Dalam penasihat ini, kami memverifikasi apakah peran berlebihan ini ada, dan jika mereka dapat menimbulkan ancaman. Kami juga memeriksa kata sandi yang lemah dan mudah ditebak secara bersamaan.

Deteksi Kesalahan (Penasihat baru)

Di MongoDB, setiap kesalahan yang ditemukan akan dihitung atau dicatat. Di dalam MongoDB ada berbagai macam kemungkinan kesalahan:pernyataan pengguna, pernyataan reguler, peringatan, dan bahkan pengecualian server internal. Jika ada tren dalam kesalahan ini, kemungkinan ada kesalahan konfigurasi atau masalah aplikasi.

Penasihat ini akan melihat statistik kesalahan MongoDB (menegaskan) dan memahaminya. Kami menafsirkan tren yang ditemukan dan saran tentang cara mengurangi kesalahan di lingkungan MongoDB Anda!