Server yang sehat adalah hasil kebiasaan, bukan keberuntungan: pemeriksaan kecil yang dijalankan rutin akan menangkap masalah saat masih murah — sebelum disk penuh, sebelum backup diam-diam gagal berbulan-bulan, sebelum koneksi bocor pelan-pelan. Chapter penutup section ini merangkum seluruh chapter sebelumnya menjadi tiga daftar periksa bernama: harian, mingguan, dan bulanan, lalu ditutup dengan pola runbook untuk skenario yang berulang. Angka-angkanya nyata dari server latihan kita, dan setiap baris menunjuk chapter tempat topiknya dibahas tuntas.
Peta materi chapter ini:
- Daftar periksa harian, mingguan, dan bulanan.
- Skrip pemeriksaan pagi dari mongosh.
- Pola runbook untuk skenario umum.
Pemeriksaan Harian #
Harian menitikberatkan deteksi dini: semuanya read-only, cepat, dan bisa dijalankan sambil menyesap kopi. Satu blok mongosh sudah menampung empat pemeriksaan pertama sekaligus:
const ss = db.serverStatus()
[ db.hello().isWritablePrimary, ss.uptime, ss.connections.current, ss.connections.available ]Output yang Dihasilkan:
[ true, 26016, 5, 404 ]Empat jawaban itu: primary siap menerima tulisan (true), proses sudah hidup 26.016 detik tanpa restart, ada 5 koneksi terbuka, dan masih tersedia 404 slot. Nilai uptime dan koneksi berubah antar pemeriksaan — yang dibaca adalah trennya dari hari ke hari. Daftar lengkapnya:
| # | Pemeriksaan | Cara cepat | Rujukan |
|---|---|---|---|
| 1 | Primary menerima tulisan | db.hello().isWritablePrimary | Status Replica Set |
| 2 | Tidak ada restart mendadak | ss.uptime — bandingkan dengan kemarin | Proses Server Database |
| 3 | Koneksi wajar, tidak bocor | ss.connections — tren naik terus? | Resource Utilization |
| 4 | Tidak ada error/fatal baru | grep -c '"s":"E"' mongod.log | Database Logs |
| 5 | Backup semalam sukses | status job backup + log verifikasi | Backup dan Recovery |
| 6 | Metrik tidak anomali | dasbor serverStatus deret waktu | Monitoring Performa |
Baris 4 dan 5 biasanya otomatis lewat alerting — daftar harian tetap memastikannya karena alert yang gagal kirim adalah kegagalan yang paling jarang disadari.
Pemeriksaan Mingguan #
Mingguan memberi waktu untuk menelaah tren yang tidak terlihat dalam satu hari:
| # | Pemeriksaan | Fokus | Rujukan |
|---|---|---|---|
| 7 | Tren slow query | Operasi baru yang lolos ambang 100 ms | Slow Query Analysis |
| 8 | Index tak terpakai | $indexStats — index dengan ops: 0 | Index Usage Analysis |
| 9 | Jendela oplog cukup | rs.printReplicationInfo() vs rencana maintenance terpanjang | Status Replica Set |
| 10 | Konfigurasi tidak bergeser | getCmdLineOpts dibandingkan dengan berkas resmi | Konfigurasi Server |
| 11 | Patch keamanan tersedia | cek rilis patch major Anda (mis. 9.0.x) | Upgrade MongoDB |
| 12 | Review log warning | baca semua "s":"W" sepekan | Database Logs |
Dua baris pertama sering menemukan akar masalah minggu depan: query yang berubah pelan biasanya mulai dari index yang tidak lagi cocok dengan pola akses terbaru.
Pemeriksaan Bulanan #
Bulanan mendedikasikan waktu untuk pekerjaan yang butuh jendela dan persiapan. Mulai dari angka kapasitas:
use latihan_ops
db.dropDatabase()
db.ping.insertOne({ ok: true })Output yang Dihasilkan:
switched to db latihan_ops
{ ok: 1, dropped: 'latihan_ops' }
{
acknowledged: true,
insertedId: ObjectId('6ad3d8326bb4dd9c2b1e6a76')
}Lalu hitung rasio pemakaian disk tempat dbPath berada:
const d = db.stats()
[ d.db, d.objects, (100 * d.fsUsedSize / d.fsTotalSize).toFixed(1) ]Output yang Dihasilkan:
[ 'latihan_ops', Long('1'), '25.3' ]Disk terpakai 25,3% — zona aman. Patokan umum: di bawah 70% aman, 70–85% saatnya merencanakan penambahan kapasitas atau pembersihan (compact, review TTL), di atas 85% tindakan segera karena WiredTiger butuh ruang gerak untuk checkpoint dan journal. Lanjutan daftar bulanan:
| # | Pemeriksaan | Fokus | Rujukan |
|---|---|---|---|
| 13 | Kapasitas disk dan tren dataSize | proyeksi kapan menyentuh 70% | Storage Management |
| 14 | validate collection kritis | integritas data dan index | Database Maintenance |
| 15 | Evaluasi compact | file bytes available for reuse yang membesar | Database Maintenance |
| 16 | Audit user dan role | akun tidak terpakai, privilege berlebih | Database Users, Least Privilege |
| 17 | Uji pemulihan backup nyata | restore ke lingkungan terpisah, ukur waktunya | Restore Testing |
| 18 | Rencana upgrade driver/server | jadwal dan prasyaratnya | Upgrade MongoDB |
| 19 | Review ulimit dan cache | konfigurasi masih cocok dengan beban kini | Proses Server Database |
Menyusun Runbook #
Checklist menjawab “apa yang diperiksa”; runbook menjawab “apa yang dilakukan ketika pemeriksaan itu gagal”. Format yang terbukti praktis: satu skenario per halaman, berisi gejala, langkah diagnosis, perintah, dan kriteria eskalasi. Kerangka lima skenario paling sering:
| Skenario | Langkah pertama | Rujukan |
|---|---|---|
| Disk menyentuh 85% | Cek fsUsedSize vs storageSize — pilih compact atau tambah kapasitas | Storage Management |
| Koneksi menipis | currentOp → temukan pemilik koneksi → perbaiki pool aplikasi | Monitoring Server, Connection Pooling |
| Secondary tertinggal | Baca optimeDate tiap anggota → cari hambatan jaringan/disk | Status Replica Set, Replication Lag |
| Proses mati mendadak | Baca log shutdown → nyalakan → pantau recovery journal | Database Logs, Proses Server Database |
| Query tiba-tiba lambat | currentOp + explain → index hilang atau data tumbuh? | Slow Query Analysis |
Rangkuman #
- Harian: primary siap, uptime stabil, koneksi wajar, log bersih, backup sukses — semuanya read-only dan cepat.
- Mingguan: tren slow query, index tak terpakai, jendela oplog, drift konfigurasi, patch keamanan.
- Bulanan: kapasitas disk (patokan 70/85%),
validate, evaluasicompact, audit user, uji restore nyata, rencana upgrade. - Runbook melengkapi checklist dengan langkah tindakan per skenario — dan wajib diuji berkala agar tetap bisa dipercaya.