«Sayt yotibdi!» — journalctl bilan sababni besh daqiqada topish

Qo'ng'iroq keladi: "sayt ochilmayapti". Shu daqiqada ikki xil yo'l bor. Birinchisi — taxmin qilish: restart berib ko'ramiz, balki o'tib ketar. Ikkinchisi — jurnalga qarash va nima bo'lganini bilib harakat qilish. Birinchi yo'l ba'zan tezroq tuyuladi, lekin sabab topilmagani uchun muammo ertaga yana qaytadi. Bu maqola ikkinchi yo'l haqida.

Seriya davomida hamma xizmatni systemd ostiga olib, loglarni stdout'ga yozdirib keldik — endi shu intizom o'z mevasini beradi: hamma narsaning jurnali bitta joyda, bitta asbob bilan o'qiladi.

Boshlanish nuqtasi: status va oxirgi satrlar#

Muammo bo'lganda birinchi buyruq har doim bitta:

systemctl status mysite-web

Bu yerda uch narsani birdan ko'rasiz: xizmat holati (active, failed, activating auto-restart...), qachondan beri shu holatda ekani va — eng foydalisi — jurnaldan oxirgi o'nta satr. Ko'p hollarda sabab shu o'nta satrning ichida yozib turadi: import xatosi, band port, topilmagan fayl.

Yetmasa, jurnalning o'zini ochamiz:

journalctl -u mysite-web -e     # -e: oxiridan boshlab ko'rsat
journalctl -u mysite-web -f     # -f: jonli oqim (yangi satrlar tushib turadi)

To'g'ri savol berish san'ati#

journalctl -u mysite-web ni ochsangiz, oldingizda minglab satr turadi. Loglar bilan ishlashning asosiy mahorati — hammasini o'qish emas, so'rovni toraytirish. Uchta filtr kundalik ishning to'qson foizini yopadi:

# vaqt bo'yicha: muammo qachon boshlangan bo'lsa, o'sha atrofga qaraymiz
journalctl -u mysite-web --since "14:20" --until "14:40"
journalctl -u mysite-web --since "10 min ago"

# daraja bo'yicha: faqat xatolar
journalctl -u mysite-web -p err --since today

# matn bo'yicha: aniq nimanidir qidirsak
journalctl -u mysite-web -g "Timeout" --since yesterday

Va yana bittasi — reboot bilan bog'liq muammolarda oltinga teng:

journalctl -b          # faqat shu yonishdan beri
journalctl -b -1 -e    # OLDINGI yonishning oxiri — o'chishdan avval nima bo'lgan?

-b -1 ko'p narsani ochib beradi: server o'zi o'chib qolgan bo'lsa, sababning izi (masalan OOM-killer ishi) aynan oldingi sessiyaning so'nggi satrlarida qoladi.

Yashirin kasallik: restart-halqa#

Restart=always bilan ishlaydigan xizmatning bir ayyor holati bor: u yiqilib-turib ishlayotgan bo'lishi mumkin — har safar restart uni qutqaradi va tashqaridan hammasi joyida ko'rinadi. Buni Aladdin seriyasida ogohlantirgan edim, endi ushlash usulini ko'rsataman:

# bugun necha marta ishga tushgan?
journalctl -u mysite-web --since today | grep -c "Started"

Javob 1 bo'lishi kerak (yoki deploy qilgan bo'lsangiz, deploy soniga mos). Javob 47 chiqsa — xizmatingiz kun bo'yi o'lib-tirilib yurgan. Sabab odatda takrorlanuvchi xato bo'ladi va uni yiqilish paytlarining logidan topasiz:

# oxirgi yiqilish atrofini ko'ramiz:
journalctl -u mysite-web -p err -e

Qatlamlarni ajratish: log qaysi savolga javob beradi#

Muammo har doim ham ilovada emas. "Sayt ochilmayapti" degan shikoyat ortida to'rt xil qatlam turishi mumkin va har birining o'z jurnali bor:

Savol	Qayerga qaraymiz
Umuman serverga yetib kelyaptimi?	`journalctl -u nginx` va tashqaridan `curl -I` — bu ayrimda server emas, tarmoq muammosi bo'lib chiqadi
Nginx qabul qilib, orqaga uzatolmayaptimi?	`/var/log/nginx/error.log` — 502 tekshiruv tartibi
Ilova ichida xato bormi?	`journalctl -u mysite-web -p err`
Baza javob bermayaptimi?	`journalctl -u postgresql -e`

Tartib muhim: tashqaridan ichkariga qarab yurasiz. Har qatlamda "bu qatlam sog'mi?" degan bitta savolga javob olasiz va muammo qaysi chegarada yotganini toraytirasiz — xuddi binar qidiruv kabi.

Jurnalning o'zi diskni yemasin#

Bitta amaliy detal ko'pincha e'tibordan chetda qoladi: journald ham disk egallaydi va default sozlamalarda ancha keng yashaydi. Kichik VPS'da buni chegaralab qo'ygan ma'qul:

sudo nano /etc/systemd/journald.conf

[Journal]
Storage=persistent    # jurnal reboot'dan keyin ham saqlansin (default ba'zan RAM'da!)
SystemMaxUse=500M     # jami hajm chegarasi — eski yozuvlar o'zi o'chadi

sudo systemctl restart systemd-journald
journalctl --disk-usage    # hozir qancha joy egallayotganini ko'rsatadi

Storage=persistent'ni tekshiring

Ba'zi tizimlarda jurnal faqat xotirada yashaydi — reboot bo'ldi, loglar yo'q. Ayni "server nega o'chdi" degan eng muhim savolni tekshirayotganda -b -1 bo'sh chiqadi. Storage=persistent bir qator, lekin aynan qora kunda kerak bo'ladigan qator.

Yakun#

Loglar bilan ishlash tartibi qisqa: systemctl statusdan boshlang, vaqt va daraja bilan toraytiring, reboot masalasida -b -1ni unutmang, restart- halqani grep -c "Started" bilan tekshiring va qatlamma-qatlam tashqaridan ichkariga yuring. Restart — davolash emas, og'riq qoldiruvchi; tashxis esa har doim jurnalda.

Seriyaning so'nggi qismi oldinda: sirlarni boshqarish — token va parollar qayerda yashashi kerak, qayerda esa hech qachon ko'rinmasligi kerak.