Pagi itu semua service berjalan normal. Website aktif, API merespons, dan tidak ada alert masuk. Namun, menjelang siang, akses ke beberapa container mulai terasa lambat. Karena kondisi ini sering muncul di server produksi, saya langsung mulai pengecekan tanpa menebak-nebak penyebabnya. Daripada menyalahkan Docker sejak awal, saya memilih menelusuri masalah dari sisi server. Dengan pendekatan ini, saya bisa menemukan sumber masalah lebih cepat dan menghindari downtime berkepanjangan.
Gejala Awal yang Biasanya Muncul
Pertama, respon aplikasi di dalam container terasa delay meski status container masih running. Selain itu, proses restart container memakan waktu lebih lama dari biasanya. Bahkan, beberapa service terlihat hidup, tetapi responnya tidak konsisten. Karena itu, saya tidak langsung masuk ke konfigurasi Docker. Sebaliknya, saya mulai dari kondisi host server secara keseluruhan.
Cek Kondisi Server Sebelum Menyentuh Docker
Langkah awal selalu saya mulai dari resource server. Dengan cara ini, saya bisa memastikan apakah masalah muncul karena beban sistem atau hanya berasal dari satu container.
htop
Dari tampilan ini, saya langsung bisa melihat lonjakan CPU dan penggunaan RAM. Jika grafik terlihat tidak stabil, maka masalah hampir pasti berasal dari beban server. Selanjutnya, saya juga mengecek kapasitas disk karena Docker sangat sensitif terhadap kondisi disk penuh.
df -h
Jika partisi root mendekati penuh, performa container biasanya langsung turun walaupun CPU masih aman.
Analisa Resource per Container
Setelah memastikan kondisi server, saya lanjut mengecek masing-masing container. Di tahap ini, saya tidak memakai Grafana atau dashboard tambahan agar server tetap ringan.
docker stats --no-stream
Dari output ini, saya bisa langsung mengetahui container mana yang paling boros CPU dan RAM. Dengan informasi tersebut, saya fokus ke satu container tanpa mengganggu service lain.
Log Docker yang Diam-Diam Membesar
Dalam beberapa kasus sebelumnya, performa server turun bukan karena aplikasi berat. Sebaliknya, file log container tumbuh tanpa kontrol hingga memenuhi disk.
Karena itu, saya selalu mengecek ukuran log Docker secara manual.
du -sh /var/lib/docker/containers/*
Jika salah satu container memiliki ukuran log tidak wajar, maka saya langsung melakukan pembatasan log.
Membatasi Log Agar Masalah Tidak Terulang
Pada server produksi, saya hampir selalu menerapkan batas log sejak awal. Dengan cara ini, saya bisa menjaga performa server tetap stabil dalam jangka panjang.
{
"log-driver": "json-file",
"log-opts": {
"max-size": "10m",
"max-file": "3"
}
}
Setelah konfigurasi selesai, saya restart Docker agar pengaturan langsung aktif.
systemctl restart docker
Cek Ulang Setelah Perbaikan
Setelah Docker berjalan kembali, saya ulangi pengecekan resource server dan container. Pada tahap ini, respon aplikasi biasanya sudah kembali normal. Selain itu, saya juga memastikan tidak ada lonjakan log baru yang bisa memicu masalah serupa di kemudian hari.
Baca Juga:
Kenapa Cara Ini Cocok untuk Server Produksi Kecil
Pendekatan ini tidak membutuhkan tool tambahan. Selain itu, semua proses berjalan langsung dari sistem yang sudah tersedia di server. Karena itulah, metode ini sangat cocok untuk VPS kecil, server rumahan, maupun server produksi dengan resource terbatas.
Kesimpulan
Container Docker yang tiba-tiba lambat jarang disebabkan oleh Docker itu sendiri. Dalam banyak kasus, resource server, disk hampir penuh, atau log yang tidak terkontrol justru menjadi penyebab utama. Dengan alur pengecekan sederhana ini, saya bisa menemukan masalah lebih cepat dan menjaga stabilitas server setiap hari.
