Docker Loglari Diskni To'ldirganda: Case Study va Yechim
Muallif: Javohir Abdullayev · · Server va DevOps

Kirish: Kutilmagan Server Inqirozi
Tasavvur qiling: dam olish kuni tunda mijozdan yoki monitoring tizimidan shoshilinch xabar keldi. Sayt ochilmayapti, API 500 yoki 502 xatosini qaytarmoqda, ma'lumotlar bazasi esa so'rovlarni qabul qilmayapti. SSH orqali VPS serverga kirasiz va birinchi ko'rgan narsangiz: No space left on device. Disk 100% to'lgan.
Serverda atigi bitta Django veb-ilovasi, PostgreSQL va Celery konteynerlari ishlab turgan edi. Foydalanuvchilar soni keskin oshmagan, katta media fayllar esa tashqi S3 xizmatida saqlanadi. Xo'sh, 40 GB hajmli qattiq diskni bir necha hafta ichida nima to'ldirib tashladi? Ushbu maqolada biz real loyihada duch kelingan aynan shu muammoni, uning ildizini hamda qayta takrorlanmasligi uchun doimiy arxitektura yechimini ko'rib chiqamiz.
1. Tashxis: Diskni Kim Yeb Qo'ydi?
Bunday vaziyatda birinchi qadam qaysi jild (directory) eng ko'p joy olayotganini aniqlashdir. Server konsolida disk holatini tekshiramiz:
df -hNatijada /dev/vda1 bo'limi 100% band ekanligi ko'rindi. Endi asosiy aybdorni topish uchun ildiz jildidan boshlab katta hajmli papkalarni qidiramiz:
sudo du -sh /* 2>/dev/null | sort -hTekshiruv natijasida /var/lib/docker jildi naqd 32 GB joy egallab turgani fosh bo'ldi. Docker jildining ichiga chuqurroq kiramiz:
sudo du -sh /var/lib/docker/* 2>/dev/null | sort -hNatija hayratlanarli: /var/lib/docker/containers/ papkasi diskning deyarli butun qismini egallab olgan. Har bir konteyner ichidagi [container-id]-json.log fayli 10-15 GB gacha kattalashib ketgan edi.
2. Muammoning Ildizi: Nega Docker Buni Qiladi?
Docker konteyner ichidagi jarayonlar tomonidan stdout va stderr oqimlariga yuborilgan barcha xabarlarni avtomatik tarzda ushlab oladi. Sukut bo'yicha (default holatda) Docker json-file drayveridan foydalanadi va unda hech qanday hajm cheklovi o'rnatilmagan bo'ladi.
Agar sizning ilovangizda, masalan Django yoki Celery-da har bir HTTP so'rovi, SQL so'rovlari yoki xatolar batafsil konsolga chiqarilsa, bu xabarlar to'xtovsiz bitta faylga yozilaveradi. Konteyner bir necha oy davomida qayta ishga tushirilmasa (restart bo'lmasa), log fayli cheksiz o'sib, butun server xotirasini egallaydi. Natijada serverda vaqtinchalik fayllar yozilmay qoladi, ma'lumotlar bazasi tranzaksiyalarni to'xtatadi va butun infratuzilma ishdan chiqadi.
3. Birinchi Yordam: Loglarni Serverni O'chirmasdan Qisqartirish
Bunday vaziyatda ko'pchilik xato qilib log faylini rm buyrug'i bilan o'chirib tashlaydi. Bu xato! Agar ochiq faylni shunchaki o'chirib yuborsangiz, Docker jarayoni (file descriptor) uni ushlab turgani sababli Linux diskdagi bo'sh joyni bo'shatmaydi. Fayl yo'qoladi, lekin disk 100% to'laligicha qolaveradi.
To'g'ri usul — faylni o'chirmasdan uning hajmini nolga tenglashtirish (truncate qilish):
sudo truncate -s 0 /var/lib/docker/containers/*/*-json.logUshbu buyruq barcha konteyner loglarini bir soniyada bo'shatadi va server darhol nafas ola boshlaydi. Xizmatlar qayta tiklanadi, ammo bu vaqtinchalik yechim. Muammoni ildizi bilan yo'qotish kerak.
4. Doimiy Yechim: Log Rotatsiyasini Sozlash
Muammo qayta takrorlanmasligi uchun biz Docker-ga loglar hajmi bo'yicha qat'iy cheklov o'rnatishimiz shart. Buni ikki xil usulda amalga oshirish mumkin.
Variant A: Butun Server Uchun Global Sozlama (Tavsiya etiladi)
Serverdagi barcha yangi ishga tushadigan konteynerlar uchun Docker konfiguratsiya fayliga kiramiz:
sudo nano /etc/docker/daemon.jsonAgar fayl mavjud bo'lmasa, uni yaratamiz va quyidagi sozlamalarni kiritamiz:
{
"log-driver": "json-file",
"log-opts": {
"max-size": "20m",
"max-file": "3"
}
}Bu sozlama nima qiladi? Har bir konteyner logi 20 megabaytdan oshganda Docker uni yangi faylga aylantiradi (rotate). Ko'pi bilan 3 ta eski fayl saqlanadi. Demak, bitta konteyner serverda hech qachon 60 megabaytdan ortiq log joyini egallay olmaydi. Sozlamani saqlab, Docker xizmatini qayta ishga tushiramiz:
sudo systemctl restart dockerVariant B: Faqat Muayyan Konteynerlar Uchun (docker-compose.yml)
Agar sizda global sozlamalarni o'zgartirish huquqi bo'lmasa yoki har bir xizmat uchun alohida hajm belgilamoqchi bo'lsangiz, docker-compose.yml faylining o'zida har bir servisga logging blokini qo'shishingiz mumkin:
services:
web:
image: my-django-app:latest
logging:
driver: "json-file"
options:
max-size: "10m"
max-file: "3"
celery_worker:
image: my-django-app:latest
logging:
driver: "json-file"
options:
max-size: "30m"
max-file: "5"5. Proaktiv Xulosa va Eng Yaxshi Amaliyotlar
Ushbu kes-stadidan chiqariladigan asosiy xulosalar:
- Production serverda sukutiy sozlamalarga ishonmang: Docker o'z-o'zidan loglarni cheklamaydi. Har qanday yangi VPS server sozlaganda
daemon.jsonfaylini to'g'rilashni odat qiling. - Loglarni to'g'ri darajalarga ajrating: Production muhitida
DEBUG=Falseekanligiga ishonch hosil qiling. Keraksiz SQL so'rovlarini konsolga chiqarish server resurslarini zoe ketkazadi. - Disk monitoringini yo'lga qo'ying: Server diski 80% yoki 85% ga yetganda Telegram yoki elektron pochta orqali ogohlantiruvchi oddiy Bash skript yoki Grafana/Prometheus kabi vositalarni o'rnating. Inqirozni u ro'y berishidan oldin to'xtatish eng yaxshi strategiyadir.
Teglar: #Docker #DevOps #Server Sozlash #Linux #Case Study