Server diskini eng ko'p "jimgina" to'ldiradigan narsa log fayllardir. Ilova har bir xatoni, veb-server har bir so'rovni, tizim esa har bir hodisani yozib boradi va hech kim bu fayllarni tozalamasa, ular oylar davomida gigabaytlab o'sadi. Disk 100 foizga yetganda ma'lumotlar bazasi yozishni to'xtatadi, sessiyalar saqlanmaydi va sayt xato qaytara boshlaydi. Linux'da bu muammoning standart yechimi logrotate dasturidir: u loglarni belgilangan jadval bo'yicha aylantiradi, eskilarini siqadi va kerakli sondan ortig'ini o'chiradi.
Diskni nima to'ldirayotganini aniqlash
Sozlashdan oldin aynan qaysi loglar katta ekanini bilish kerak. Avval diskning umumiy holatini, so'ngra /var/log ichidagi eng katta papka va fayllarni ko'rib chiqing. Ko'p hollarda aybdor bitta-ikkita fayl bo'ladi: ilovaning xato logi yoki veb-serverning kirish logi.
df -h /
sudo du -sh /var/log/* 2>/dev/null | sort -h | tail -10
journalctl --disk-usage
Agar /var/log kichik bo'lsa-yu, disk baribir to'la bo'lsa, ilova papkasini ham tekshiring. Laravel'ning storage/logs, WordPress'ning wp-content/debug.log yoki o'zingiz yozgan skriptlarning loglari ko'pincha standart rotatsiyadan tashqarida qoladi, chunki tizim ular haqida bilmaydi.
Misol: maktab saytidagi 4 GB lik xato logi
Samarqanddagi xususiy maktabning Laravel'da yozilgan misol.uz sayti bir kuni o'quvchilar baholarini saqlamay qo'ydi. Tekshiruvda ma'lum bo'ldiki, ilova bir necha oy davomida har bir so'rovda bir xil ogohlantirishni yozgan va laravel.log hajmi 4 GB ga yetib, diskdagi bo'sh joyni tugatgan. Faylni tozalash muammoni vaqtincha hal qildi, lekin asosiy tuzatish ikki qismdan iborat bo'ldi: ogohlantirish manbai kodda tuzatildi va loglar uchun logrotate qoidasi qo'shildi. Shundan keyin log hech qachon bir necha o'n megabaytdan oshmadi.
logrotate qanday ishlaydi
Asosiy sozlamalar /etc/logrotate.conf faylida, alohida xizmatlar uchun qoidalar esa /etc/logrotate.d/ papkasida saqlanadi. Ko'pchilik tarqatmalarda logrotate kuniga bir marta systemd taymeri yoki cron orqali ishga tushadi. Har bir qoida qaysi fayllarga tegishli ekanini, qanchalik tez-tez aylantirishni, nechta eski nusxani saqlashni va aylantirishdan keyin nima qilishni belgilaydi. Masalan, rotate 14 va daily birgalikda "so'nggi 14 kunlik logni saqla, undan eskisini o'chir" degan ma'noni beradi.
Ilova loglari uchun qoida yozish
Ilova uchun alohida fayl yarating, masalan /etc/logrotate.d/misol. Quyidagi qoida loglarni har kuni aylantiradi, 14 ta nusxani saqlaydi va ularni gzip bilan siqadi. delaycompress eng oxirgi nusxani bir kun siqmasdan qoldiradi, bu esa hali yozib bo'linmagan faylni buzib qo'ymaslik uchun foydali.
/var/www/misol/storage/logs/*.log {
daily
rotate 14
compress
delaycompress
missingok
notifempty
copytruncate
}
copytruncate direktivasi faylni nusxalab, keyin asl faylni nolga qisqartiradi. Bu usul logni ochiq holda ushlab turadigan va signal orqali qayta ochishni bilmaydigan ilovalar uchun qulay. Uning kamchiligi shundaki, nusxalash va qisqartirish orasidagi qisqa vaqtda yozilgan bir necha qator yo'qolishi mumkin. Agar dastur logni qayta ochishni qo'llab-quvvatlasa, create va postrotate usuli ishonchliroq.
Nginx loglari va postrotate
Nginx paketi odatda o'z qoidasi bilan keladi, lekin uni tushunib olish foydali. Bu yerda eski fayl boshqa nomga o'tkaziladi, yangisi kerakli huquqlar bilan yaratiladi va Nginx'ga USR1 signali yuboriladi. Signal olgan Nginx log fayllarini qayta ochadi va yangi faylga yoza boshlaydi, xizmatni qayta ishga tushirish shart emas.
/var/log/nginx/*.log {
daily
rotate 30
compress
delaycompress
missingok
notifempty
create 0640 www-data adm
sharedscripts
postrotate
[ -f /var/run/nginx.pid ] && kill -USR1 $(cat /var/run/nginx.pid)
endscript
}
sharedscripts bo'lmasa, postrotate bloki har bir log fayl uchun alohida bajariladi. U bilan esa barcha fayllar aylantirilgandan keyin bir marta ishlaydi, bu ko'p domenli serverlarda ortiqcha signallarning oldini oladi.
Qoidani sinash
Yangi qoidani darhol ishonchli deb hisoblamang. -d parametri hech narsani o'zgartirmasdan nima qilinishini ko'rsatadi, -f esa vaqtdan qat'i nazar aylantirishni majburan bajaradi. Natijada papkada .1 va keyinroq .gz kengaytmali fayllar paydo bo'lishi kerak.
sudo logrotate -d /etc/logrotate.d/misol
sudo logrotate -f /etc/logrotate.d/misol
ls -lh /var/www/misol/storage/logs/
systemd jurnali va o'chirilgan, lekin ochiq fayllar
journalctl --disk-usage katta hajm ko'rsatsa, jurnalni ham cheklash kerak. Uni bir martalik tozalash va doimiy chegara qo'yish mumkin.
sudo journalctl --vacuum-size=500M
# /etc/systemd/journald.conf
[Journal]
SystemMaxUse=500M
sudo systemctl restart systemd-journald
Ba'zan log fayl qo'lda rm bilan o'chirilgan bo'lsa ham disk bo'shamaydi. Sababi, uni yozayotgan jarayon faylni hali ochiq ushlab turadi va joy jarayon to'xtamaguncha qaytarilmaydi. Bunday fayllarni quyidagi buyruq ko'rsatadi; yechim tegishli xizmatni qayta ishga tushirish. Shu sababli faol logni o'chirish o'rniga uni truncate -s 0 bilan bo'shatgan ma'qul.
sudo lsof +L1 | grep -i log
Shared hostingda o'z logrotate'ingiz
Shared hostingda tizim va veb-server loglarini provayder boshqaradi, lekin ilovangizning o'z loglari sizning kvotangizdan joy oladi. Root huquqi bo'lmasa ham logrotate'ni oddiy foydalanuvchi sifatida ishga tushirish mumkin: buning uchun o'z sozlama faylingiz va o'z holat fayli (-s) kerak. Buyruqni ISPmanager panelidagi cron vazifalari orqali kunlik jadvalga qo'yasiz. Yo'llarni o'z akkauntingizga moslang va logrotate serverda qaysi manzilda turganini which logrotate bilan tekshiring.
# ~/logrotate.conf
/home/user/www/misol.uz/storage/logs/*.log {
weekly
rotate 8
compress
missingok
notifempty
copytruncate
}
# cron: har kuni 03:30 da
30 3 * * * /usr/sbin/logrotate -s $HOME/.logrotate.state $HOME/logrotate.conf
Agar hostingda bunday buyruq mavjud bo'lmasa yoki kvota tez-tez to'lsa, sayt.uz texnik yordamiga murojaat qilib, loglaringiz va disk sarfingizni birga ko'rib chiqishingiz mumkin. Eng muhimi, logni faqat tozalash emas, uni o'stirayotgan takroriy xatoni ham topib tuzatish: aks holda rotatsiya muammoni faqat yashiradi.