Linux loglari: arxitektura va qayerdan qidirish kerak

Server noto'g'ri ishlaganda birinchi foydali savol kamdan-kam hollarda "nega bu yuz berdi" bo'ladi — odatda "qidirishni umuman qayerdan boshlayman" degan savol tug'iladi. Deyarli har bir javob bitta joyga olib boradi: log'larga. Log — tizim yoki dastur ishlash davomida yozib boradigan hodisalarning uzluksiz qaydi: kim qachon tizimga kirgani, qaysi xizmat ishga tushgani yoki ishdan chiqqani, qaysi so'rov muvaffaqiyatsiz bo'lgani va nega. journalctl maqolasida systemd ning markazlashgan, jonli log vositasi batafsil ko'rib chiqilgan edi. Bu maqola bir qadam ortga chekinib, to'liq manzarani ko'rsatadi: Linux’da aslida nechta mustaqil log qatlami bor, har biri ma’lumotlarini qayerda saqlaydi va ular bir-biri bilan qanday bog'langan. Bu modulning qolgan qismi tayanadigan xarita aynan shu.

Nega yagona log yo'q

Yangi boshlovchi ko'pincha "log" bitta aniq joy deb kutadi. Amalda Linux’da log yozish har biri tizimning turli darajasida ishlaydigan mustaqil qatlamlar to'plamidan iborat:

Qatlam	Kim yozadi	Qayerda turadi	Qachon tekshiriladi
Kernel	Linux kernelining o'zi	Xotiradagi halqa buferi (`dmesg`), odatda journal’ga ham uzatiladi	Uskuna, drayver, xotira va boot bilan bog'liq muammolar
systemd journal	`systemd-journald`	`/run/log/journal/` yoki `/var/log/journal/` dagi binary, tuzilgan saqlash	Xizmat holati, boot ketma-ketligi — journalctl orqali
Syslog (rsyslog)	`rsyslog` xizmati	`/var/log/` ostidagi oddiy matnli fayllar	Eski ilovalar, markaziy log serveriga uzatish, uzoq muddatli matnli arxivlar
Ilovaning o'zi	Ilova yoki xizmatning o'z kodi	Har xil — o'z fayli, journal’ga uzatiladigan `stdout`/`stderr` yoki tashqi tizim	Ilova darajasidagi xatolar, biznes-mantiq hodisalari

Bu qatlamlar bir-birining o'rnini bosmaydi; har biri boshqa savolga javob beradi. Kernel darajasidagi nosozlik, masalan, ishdan chiqayotgan disk kontrolleri, hech qachon ilova log'ida ko'rinmaydi, ilovaning biznes-mantiqidagi xatoning esa kernelga umuman aloqasi yo'q.

Info

Zamonaviy Ubuntu Server o'rnatmasida bu qatlamlar to'liq alohida emas: rsyslog odatda hodisalarni systemd-journald dan o'qib, ularni an’anaviy matnli fayllarga qayta yozadi. Ya’ni bitta hodisani ko'pincha ham journalctl da, ham /var/log/syslog da topish mumkin — bu ikki raqobatlashuvchi tizim emas, bitta pipeline’ning ikki bosqichi.

`/var/log/` da aslida nima bor

ls -lh /var/log/ | head -n 15

-rw-r----- 1 syslog adm   812K Jul 24 11:02 auth.log
-rw-r----- 1 root   adm    45K Jul 24 08:12 boot.log
-rw-r----- 1 root   root   1.9M Jul 24 08:12 dmesg
-rw-r--r-- 1 root   root    24K Jul 20 06:25 dpkg.log
drwxr-xr-x 2 root   root   4.0K Jul 24 08:12 journal
-rw-r----- 1 syslog adm   2.1M Jul 24 11:05 kern.log
-rw-r----- 1 syslog adm   3.4M Jul 24 11:05 syslog
-rw-rw-r-- 1 root   utmp   0    Jul 24 08:12 wtmp

Eng ko'p ishlatiladigan fayllar:

Fayl / katalog	Mazmuni
`syslog`	Ko'p xizmatlardan yig'ilgan umumiy tizim xabarlari
`auth.log`	Autentifikatsiya va avtorizatsiya hodisalari: tizimga kirishlar, `sudo` chaqiruvlari, SSH ulanish urinishlari
`kern.log`	Faqat kernel xabarlari, oddiy matn ko'rinishida
`dmesg`	Boot paytida olingan kernel halqa buferining oddiy matnli nusxasi
`dpkg.log`	APT/dpkg orqali o'rnatilgan, yangilangan yoki olib tashlangan paketlar tarixi
`boot.log`	Boot ketma-ketligi davomida chiqarilgan xabarlar
`journal/`	`systemd-journald` ning binary ma’lumotlar ombori
`wtmp`, `btmp`, `lastlog`	`last`, `lastb` va `lastlog` orqali o'qiladigan, tuzilgan binary tizimga kirish tarixi fayllari — oddiy matn emas

Warning

auth.log egasi syslog:adm, ruxsatlari 640 — oddiy foydalanuvchi uni to'g'ridan-to'g'ri o'qiy olmaydi, faqat adm guruhi a’zolari yoki root/sudo o'qiy oladi. Bu ataylab qo'yilgan xavfsizlik chegarasi: autentifikatsiya faoliyati maxfiy ma’lumot sifatida qaraladi. wtmp, btmp va lastlog ham oddiy matn emas; ularni cat bilan ochish o'qib bo'lmaydigan binary "shovqin" chiqaradi, chunki ular faqat maxsus vositalari orqali o'qilishi uchun mo'ljallangan tuzilgan binary fayllar.

RHEL/CentOS/Rocky oilasida fayl nomlari biroz farq qiladi — ko'p sukut bo'yicha konfiguratsiyalarda auth.log o'rniga secure, syslog o'rniga messages — lekin asosiy mantiq bir xil.

`logrotate`: nega log fayllari cheksiz o'smaydi

Yuklamasi yuqori server kuniga yuzlab megabayt log yozishi mumkin. Agar bu fayllar cheksiz o'sganida, disk joyi oxir-oqibat tugab qolardi. Bu muammoni logrotate — log fayllarini avtomatik aylantiradigan (rotate qiladigan), vaqti-vaqti bilan ishga tushadigan vosita hal qiladi.

cat /etc/logrotate.d/rsyslog

/var/log/syslog
{
    rotate 7
    daily
    missingok
    notifempty
    delaycompress
    compress
    postrotate
        /usr/lib/rsyslog/rsyslog-rotate
    endscript
}

Bu konfiguratsiya nimani anglatadi:

daily — fayl kuniga bir marta aylantiriladi;
rotate 7 — faqat oxirgi 7 ta aylantirilgan nusxa saqlanadi; undan eskilari o'chiriladi;
compress — eski nusxalar .gz sifatida siqiladi va disk joyi tejaladi;
missingok — fayl mavjud bo'lmasa, xato bermaydi;
notifempty — bo'sh faylni aylantirmaydi, shunda ma’nosiz bo'sh arxiv yaratilmaydi;
postrotate ichidagi buyruq yozayotgan xizmatga fayl yana yangi ekanini, odatda signal yuborish orqali, bildiradi.

Amalda bu shunday ko'rinadi: syslog aylantirilganda u syslog.1 ga qayta nomlanadi, oldingi syslog.1 esa syslog.2.gz ga siqiladi va hokazo, rotate 7 chegarasigacha.

ls /var/log/syslog*

/var/log/syslog
/var/log/syslog.1
/var/log/syslog.2.gz
/var/log/syslog.3.gz

logrotate ning o'zi odatda kunlik cron job yoki systemd timer orqali avtomatik ishga tushadi — uni qo'lda ishga tushirishingiz shart emas, lekin uning konfiguratsiyasini tushunish disk to'lib qolishi kabi muammolarni aniqlashda qimmatli.

Danger

Ishlab turgan xizmat hali ham yozayotgan log faylini to'g'ridan-to'g'ri rm bilan o'chirish — xavfli yorliq. Fayl katalog ro'yxatidan yo'qoladi, lekin uni ochiq ushlab turgan jarayon endi ko'rinmaydigan o'sha faylga yozishda davom etadi va disk joyi hech qachon qaytarib olinmaydi. Aynan shu vaziyat va uni to'g'ri tuzatish usuli /proc fayl tizimi maqolasida ko'rib chiqilgan. Log fayllari har doim logrotate orqali yoki yozayotgan xizmatga to'g'ri signal berish orqali boshqarilishi kerak — hech qachon faylni to'g'ridan-to'g'ri o'chirish orqali emas.

`postrotate` va `copytruncate`: yozuvchi qanday qilib ortda qolmaydi

Yuqoridagi postrotate bloki rotation’dagi yagona qiyin muammoni ochib beradi: fayl .1 ga qayta nomlangandan keyin xizmat fayl yangi ekani aytilmaguncha hali ham eski, qayta nomlangan faylga yozadi. postrotate signali (HUP yoki bu yerdagi rsyslog-rotate) uni asl yo'lni qayta ochishga majbur qiladi. Log'ini qayta ochish uchun signal bilan boshqarib bo'lmaydigan xizmatga buning o'rniga muqobil copytruncate direktivasi kerak:

Direktiva	Qanday aylantiradi	Murosa
`postrotate` (qayta nomlash + signal)	Faylni qayta nomlaydi, so'ng xizmatga asl nomni qayta ochish uchun signal beradi	Ma’lumot yo'qolmaydi, lekin signal bilan log'ini qayta ochadigan xizmat kerak
`copytruncate`	Joriy faylni arxivga nusxalaydi, so'ng aslini joyida qisqartiradi (truncate)	Har qanday yozuvchi bilan ishlaydi, lekin nusxalash va qisqartirish orasidagi oraliqda yozilgan log qatorlari yo'qoladi

copytruncate log faylini ochiq ushlab turadigan va qayta ochish signalini taklif qilmaydigan ilova uchun standart javob — o'sha kichik poyga (race) oynasi evaziga. Uning nega mavjudligini va ma’lumot yo'qotish xavfini bilish "log rotation qanday ishlaydi" savolidan keyin intervyuda tez-tez beriladigan qo'shimcha savol.

Rotation qoidasini kunlik timer’ni kutmasdan sinab ko'rish mumkin — debug dry-run nima bo'lishini ko'rsatadi va hech narsani o'zgartirmaydi, majburiy ishga tushirish esa uni darhol bajaradi:

logrotate -d /etc/logrotate.d/rsyslog        # dry-run: prints decisions, writes nothing
sudo logrotate -f /etc/logrotate.d/rsyslog   # force a rotation right now

Avval qaysi manbani tekshirish kerak

Muammo turi	Birinchi tekshiriladigan manba
Server boot qilmayapti yoki uskuna muammosi gumon qilinmoqda	`dmesg`, Boot jarayoni va GRUB
Muayyan systemd xizmati ishlamayapti	`journalctl -u <service>` — journalctl
Kimdir SSH orqali tizimga kirishga uringan	`auth.log` yoki `journalctl -u ssh.service`
Yaqinda o'rnatilgan paket bilan bog'liq muammo	`dpkg.log` — apt va repozitoriylar
Sababi noaniq umumiy tizim xatosi	`syslog` yoki `journalctl -p err`
Ilova ichidagi biznes-mantiq xatosi	Ilovaning o'z log manbasi — fayl yoki `journalctl -u <app-service>`

Bu jadval keyingi ikki maqola to'ldiradigan xarita: Tizim loglari va dmesg kernel darajasidagi log yozishga chuqurroq kiradi, Loglarni tahlil qilish esa yig'ilgan log'lardan amaliy xulosalar chiqarishni ko'rib chiqadi.

Keng tarqalgan xatolar

Faqat bitta log manbasini tekshirib, shu bilan to'xtash

journalctl xizmat darajasidagi nosozliklarni aniq ko'rsatadi, lekin asl sabab kernelda bo'lsa — masalan, tarmoq drayverida — javob faqat dmesg da bo'ladi. Har qanday jiddiy muammo uchun kamida ikkita manbani birga tekshirish kerak: journal va kernel log'i.

`auth.log` yoki `wtmp` ni `cat`/`less` bilan o'qishga urinish

wtmp, btmp va lastlog matn emas, binary fayllar. Ular maxsus vositalari (last, lastb, lastlog) orqali o'qilishi kerak; ularni to'g'ridan-to'g'ri o'qish ekranga shunchaki tushunarsiz belgilar chiqaradi.

Log faylidagi `rm` disk joyini darhol bo'shatadi deb o'ylash

Yuqorida ko'rsatilganidek, jarayon hali ochiq ushlab turgan faylni o'chirish o'sha jarayon faylni yopmaguncha yoki qayta ishga tushmaguncha disk joyini qaytarmaydi. To'g'ri yondashuv — logrotate yoki xizmatni reload qilish.

Mashqlar

ls -lh /var/log/ chiqishidan beshta turli faylni tanlang va har biri nima uchun ekanini o'z so'zlaringiz bilan yozing.
/etc/logrotate.d/ ichidagi uchta faylni oching va ularning rotate, daily/weekly va compress sozlamalarini solishtiring.
last -n 10 ni va ruxsat berilgan bo'lsa sudo lastb -n 5 ni ishga tushiring va natijalarni auth.log yoki journalctl -u ssh.service bilan solishtiring.
Yuqoridagi "Avval qaysi manbani tekshirish kerak" jadvalidan uchta vaziyatni tanlang va har biri uchun ishga tushiradigan aniq buyruqni yozing.

Mashqni bajardim deyish uchun: bu maqolada tanishtirilgan beshta qatlamning har biri uchun sizni boshqasiga emas, aynan o'sha qatlamga yo'naltiradigan bitta aniq belgini ayta olishingiz kerak.

Manbalar

man7.org: syslog(3): https://man7.org/linux/man-pages/man3/syslog.3.html
man7.org: logrotate(8): https://man7.org/linux/man-pages/man8/logrotate.8.html
Ubuntu Server hujjatlari: Loglar: https://ubuntu.com/server/docs/logs
freedesktop.org: systemd-journald.service(8): https://www.freedesktop.org/software/systemd/man/latest/systemd-journald.service.html