Monitoring, logging va automation park miqyosida

Shu kursda oldinroq ko'rib chiqilgan har bir log va metrika vositasi — journalctl, dmesg, /proc, top — bir vaqtda bitta server atrofida tushuntirilgan edi: SSH orqali kiring, buyruqni ishga tushiring, chiqishni o'qing. Bu ish jarayoni taxminan o'ntadan yuztagacha server oralig'ida masshtablanishdan to'xtaydi. Alohida vositalar noto'g'ri bo'lgani uchun emas, balki har bir hostni qo'lda tekshirayotgan inson park sur’atiga yetisha olmagani va disk to'lgan tungi soat 3 da uyg'oq bo'la olmagani uchun. Bu maqola o'sha asoslar — log'lar, metrikalar va rejalashtirilgan vazifalar — inson ishtirokisiz, bir vaqtning o'zida ko'plab hostlarda ishlashi kerak bo'lganda nima o'zgarishini ko'rib chiqadi: mahalliy bo'lgan narsani markazlashtirish va rejalashtirilgan tekshiruvlarni avtomatik javoblarga aylantirish.

Nimalarni o'rganasiz

Bu maqola oxirida siz quyidagilarni qila olasiz:

• har bir hostdagi alohida log fayllar va qo'lda tekshiruvlar nega oz sonli serverlardan tashqariga masshtablanmasligini tushuntirish;
• journald log'larini markaziy manzilga yo'naltirish;
• Prometheus pull modelini tushuntirish va node_exporter metrikalar endpoint’ini bevosita o'qish;
• shunchaki log qatoriga emas, shartga asoslanib ishga tushadigan alert qoidasini yozish;
• cron/systemd timer avtomatlashtirishini oldingi maqoladagi o'sha Ansible modelidan foydalanib, bitta hostdan butun parkka kengaytirish.

Masshtabda markazlashtirish nega majburiy

journalctl bilan o'qiladigan bitta serverning log'lari "bu mashinada nima bo'ldi" degan savolga javob beradi. Park bo'yicha hodisa — ellikta instansiyaga tarqatilgan yomon deployment, uni chaqiradigan har bir servis uchun ishdan chiqqan umumiy upstream bog'liqlik — boshqa savolga javob berishni talab qiladi: "vaqt bo'yicha bog'lab qaraganda, har bir mashinada nima bo'ldi". Faol hodisa paytida buni har bir hostga navbatma-navbat SSH orqali kirib qayta tiklash — markazlashgan logging aynan oldini olish uchun mavjud bo'lgan nosozlik.

journalctl --since "10 minutes ago" -p err

journalctl maqolasida ko'rib chiqilgan bu buyruq bitta hostda to'g'ri birinchi qadam. Park miqyosida esa unga teng savol — "oxirgi o'n daqiqada qaysi hostlar xato log'ini yozgan" — har bir hostning log'lari allaqachon bitta ma’lumotlar to'plami sifatida so'rov yuborish mumkin bo'lgan joyga oqib borishini talab qiladi.

journald’ni markaziy manzilga yo'naltirish

systemd-journal-remote va systemd-journal-upload systemd ning o'zi bilan birga keladi va uchinchi tomon bog'liqligini kiritmasdan journal yozuvlarini HTTP(S) orqali markaziy journal serveriga uzatadi:

sudo apt install systemd-journal-remote

# /etc/systemd/journal-upload.conf
[Upload]
URL=https://log-collector.internal:19532

sudo systemctl enable --now systemd-journal-upload

Allaqachon kengroq observability stack’ini standart qilib olgan jamoalar uchun markaziy syslog serveriga rsyslog orqali yo'naltirish yoki log'larni Loki (Grafana’ning Prometheus bilan juftlikda ishlash uchun mo'ljallangan log yig'ish tizimi) yoki ELK/OpenSearch stack’iga jo'natish production’da ko'proq uchraydigan tanlovlar. Aniq manzil asosiy tamoyildan kamroq muhim: har bir hostning log'lari o'sha hostni tark etishi va inson yoki alert qoidasi avval ellikta mashinadan qaysi biriga SSH orqali kirishni hal qilmasdan so'rov yuborishi mumkin bo'lgan bitta joyga tushishi kerak.

Metrikalar: Prometheus pull modeli

Log'lar alohida hodisalarni yozsa, metrikalar vaqt bo'yicha raqamli o'lchovlarni yozadi — CPU’dan foydalanish, xotira bosimi, so'rov kechikishi, diskdagi bo'sh joy. Ular muntazam oraliqda o'lchab olinadi va trendni grafikka chizish hamda chegaraga asoslangan alert berishni umuman mumkin qiladigan narsa shu. Hozirgi infratuzilmadagi yetakchi ochiq manbali metrikalar tizimi — Prometheus pull modelidan foydalanadi: har bir host o'z metrikalarini biror joyga yuborish (push) o'rniga, Prometheus’ning o'zi har bir kuzatiladigan host taqdim etadigan oddiy HTTP endpoint’ni vaqti-vaqti bilan olib turadi (scrape qiladi).

sudo apt install prometheus-node-exporter
sudo systemctl enable --now prometheus-node-exporter
curl -s http://localhost:9100/metrics | head -n 15

# HELP node_cpu_seconds_total Seconds the CPUs spent in each mode.
# TYPE node_cpu_seconds_total counter
node_cpu_seconds_total{cpu="0",mode="idle"} 837291.42
node_cpu_seconds_total{cpu="0",mode="user"} 4213.11
# HELP node_memory_MemAvailable_bytes Memory available for starting new applications.
# TYPE node_memory_MemAvailable_bytes gauge
node_memory_MemAvailable_bytes 6.442450944e+09

node_exporter ataylab sodda qilingan: u /proc fayl tizimi maqolasida allaqachon ko'rib chiqilgan o'sha kernel interfeyslarini — CPU vaqti, xotira, disk statistikasi — o'qiydi va ularni oddiy matnli HTTP sifatida qayta e’lon qiladi. Bu formatni Prometheus serveri jadval bo'yicha (odatda har 15–60 soniyada) scrape qilib, vaqt qatori (time series) sifatida saqlay oladi.

Har bir metrika ustidagi # TYPE qatori bezak emas — u metrika turini nomlaydi. Ikki eng keng tarqalgan tur shunchalik farq qiladiki, ularni chalkashtirish intervyudagi klassik qoqilish:

• Counter (node_cpu_seconds_total, counter deb belgilangan) faqat o'sadi va faqat jarayon qayta ishga tushganda nolga qaytadi. Uning xom qiymati o'z-o'zidan ma’nosiz — CPU jami 837 291 soniya bo'sh turgani hech kimni qiziqtirmaydi. Muhimi — uning o'zgarish tezligi. Shuning uchun counter’lar deyarli har doim rate() ga o'raladi: rate(node_cpu_seconds_total{mode="idle"}[5m]) oxirgi besh daqiqadagi soniyasiga bo'sh CPU-soniyalarni, ya’ni joriy bo'sh turish ulushini beradi.
• Gauge (node_memory_MemAvailable_bytes, gauge deb belgilangan) ham o'sishi, ham kamayishi mumkin va aynan hozir ma’noli bo'lgan qiymatni ifodalaydi — mavjud xotira, diskdagi bo'sh joy, harorat. Gauge rate() siz, to'g'ridan-to'g'ri o'qiladi, chunki uning lahzalik qiymatining o'zi javob.

Amaliy qoida: agar savol "bu qanchalik tez sodir bo'lyapti" bo'lsa, bu counter va sizga rate() kerak. Agar savol "joriy daraja qanday" bo'lsa, bu gauge va siz uni shundayligicha o'qiysiz. Gauge’ga rate() qo'llash yoki counter’ning xom jami biror narsani anglatadi deb o'qish — birinchi Prometheus so'rovidagi eng keng tarqalgan ikki xato.

# prometheus.yml (on the Prometheus server, not the monitored host)
scrape_configs:
  - job_name: "node"
    static_configs:
      - targets:
          - "web-01.internal:9100"
          - "web-02.internal:9100"

Pull modelining bevosita amaliy oqibati bor: agar Prometheus host’ning /metrics endpoint’iga umuman yeta olmasa, bu yo'qlikning o'zi ma’lumot beradi. Scrape’larga javob berishni to'xtatgan host yo ishlamayapti, yo tarmoqdan ajralib qolgan, yoki exporter ishdan chiqqan. Prometheus buni shunchaki ma’lumot yo'qligi sifatida emas, target’ning down holati sifatida ko'rsatadi. Push’ga asoslangan tizim esa, aksincha, "xabar qiladigan hech narsa yo'q"ni "host yo'qolib qolgan"dan boshqa vositalar bilan ajratishi kerak, chunki ikkala holatda ham sukunat bir xil ko'rinadi.

Alerting: chegarani chaqiruvga aylantirish

Hech qanday alert biriktirilmagan metrika — kimdir unga qarashni eslab qolishi kerak bo'lgan grafik. Alerting bu bo'shliqni yopadi: u shartni uzluksiz baholaydi va shart rost bo'lgan zahoti insonni xabardor qiladi (yoki avtomatlashtirishni ishga tushiradi).

# alert_rules.yml
groups:
  - name: node-alerts
    rules:
      - alert: HighDiskUsage
        expr: (node_filesystem_avail_bytes{mountpoint="/"} / node_filesystem_size_bytes{mountpoint="/"}) < 0.10
        for: 10m
        labels:
          severity: warning
        annotations:
          summary: "Disk usage above 90% on {{ $labels.instance }}"

expr — jonli metrikalarga nisbatan baholanayotgan shart. Bu yerda / dagi mavjud joy umumiy hajmning 10% idan pastga tushishi. for: 10m alert haqiqatan ishga tushishidan oldin shart o'n daqiqa davomida uzluksiz saqlanib turishini talab qiladi. Bu aynan qisqa, o'z-o'zidan to'g'rilanadigan sakrash uchun kimnidir chaqirmaslik uchun mavjud (masalan, siqish joyni qaytarib bo'shatishidan oldin diskni vaqtincha to'ldiradigan log rotation). Bu oynani to'g'ri sozlash — haqiqiy, takrorlanib turadigan operatsion mulohaza: juda qisqa bo'lsa, alert’lar hech kim ishonmaydigan shovqinga aylanadi, juda uzun bo'lsa, haqiqatan shoshilinch muammo e’tiborsiz qolib ketadi.

Bu yerda intervyularda bevosita so'raladigan vazifalar taqsimoti bor: Prometheus faqat qoidani baholaydi va alert ishga tushganini hal qiladi — u xabarnomani yubormaydi. Alert ishga tushganda Prometheus uni alohida komponent — Alertmanager ga uzatadi. Uning butun vazifasi ishga tushgan alert’larni haqiqiy xabarnomalarga aylantirish: ularni label bo'yicha to'g'ri manzilga yo'naltirish (severity: warning — Slack kanaliga, severity: critical — PagerDuty’ga), bog'liq alert’larni guruhlash (shunda ellikta host ishdan chiqishi ellikta emas, bitta xabarnoma hosil qiladi), zaxira Prometheus serverlaridan kelgan bir xil alert’ning takrorlanishini olib tashlash va rejalashtirilgan texnik xizmat paytida alert’larni o'chirib qo'yish (silencing). "Alert qoidasini yozish" va "kerakli odam chaqirilishini ta’minlash" ikki alohida konfiguratsiya vazifasi bo'lishining sababi shu bo'linish: qoida Prometheus’da, chaqirish mantiqi esa Alertmanager’da yashaydi.

Bu Disk to'lganda troubleshooting maqolasidagi qo'lda disk tekshiruvining bevosita, masshtablangan davomchisi. Bu df dan olingan o'sha signal, faqat endi u kimdir tasodifan buyruqni qo'lda ishga tushirgandagina emas, parkdagi har bir host bo'yicha uzluksiz baholanadi.

Park bo'ylab avtomatlashtirish: cron va systemd timer’larni kengaytirish

cron asoslari va systemd timer’lar maqolalarida takrorlanadigan vazifani bitta hostda rejalashtirish ko'rib chiqildi. Park miqyosida har bir alohida hostdagi rejalashtirish mexanizmi o'zgarishi shart emas — "bu vazifani bu mashinada har kecha ishga tushir" uchun systemd timer hali ham to'g'ri vosita. Lekin bu timer unit’ini har bir hostga deploy qilish va bir xil holda saqlash o'zgaradi. Bu aynan Infrastructure as Code asoslari maqolasida Ansible umuman konfiguratsiya uchun hal qilishi ko'rib chiqilgan muammo:

# ansible playbook excerpt: ship the same systemd timer to every web host
- name: Deploy log cleanup timer
  hosts: web
  become: true
  tasks:
    - name: Install the cleanup script
      copy:
        src: files/log-cleanup.sh
        dest: /usr/local/bin/log-cleanup.sh
        mode: "0755"

    - name: Install the systemd service unit
      copy:
        src: files/log-cleanup.service
        dest: /etc/systemd/system/log-cleanup.service

    - name: Install the systemd timer unit
      copy:
        src: files/log-cleanup.timer
        dest: /etc/systemd/system/log-cleanup.timer

    - name: Enable and start the timer
      systemd:
        name: log-cleanup.timer
        enabled: true
        state: started
        daemon_reload: true

Bu playbook’ni web inventory guruhiga qarshi ishga tushirish o'sha guruhdagi har bir hostga bir xil log tozalash skripti va timer’ni idempotent tarzda o'rnatadi va yoqadi. Agar hech narsa siljimagan bo'lsa, ikkinchi ishga tushirish hech qanday o'zgarish kiritmaydi — aynan Infrastructure as Code asoslari maqolasida ko'rib chiqilganidek. "Yuzta server bir xil tungi vazifani qanday qilib ishonchli ishga tushiradi" degan savolga amaliy javob shu: yuzta odam yuzta cron vazifasini qo'lda sozlashni eslab qolishi emas, bitta inventory faylida belgilangan parkka qo'llaniladigan bitta playbook.

Amaliy vaziyat: park bo'ylab disk alert’ini diagnostika qilish

Muammo. Yuqorida belgilangan HighDiskUsage alert’i o'n ikkita web serverdan uchtasi uchun bir vaqtda ishga tushadi.

Tekshirish. Metrikalar allaqachon markazlashgani uchun birinchi qadam — uchta alohida SSH sessiyasi emas, butun park bo'yicha bitta Prometheus so'rovi:

node_filesystem_avail_bytes{mountpoint="/"} / node_filesystem_size_bytes{mountpoint="/"}

Bu ta’sirlangan uchta hostning umumiy jihati — bir xil deployment, bir xil log rotation konfiguratsiyasi — bormi, darhol ko'rsatadi. Bu faqat o'n ikkita hostning hammasining ma’lumotlari bitta so'rov yuborish mumkin bo'lgan tizimda turgani uchungina ko'rinadi.

Buyruq. Ta’sirlangan uchta hostdan birida aniq sababni Disk to'lganda troubleshooting maqolasida allaqachon ko'rib chiqilganidek tasdiqlang:

sudo du -xh --max-depth=2 / | sort -rh | head -n 10

12G   /var/log
9.8G  /var/log/nginx

Natija. Ta’sirlangan uchta hostning hammasi ikki kun oldin bir xil deployment’ni olgan. U debug darajasidagi access log'ni yoqqan, log tozalash skripti ning rotation siyosati esa buni hisobga oladigan qilib sozlanmagan edi.

Xulosa. Alert birinchi hostda chegara kesib o'tilgan zahoti haqiqiy, park bo'yicha muammoni to'g'ri aniqladi. Markazlashgan metrikalar "uchta alohida hodisa"ni "uchta hostga ta’sir qilgan bitta asl sabab"ga aylantirdi va u uchta mustaqil tekshiruv o'rniga bitta so'rov bilan topildi.

Keng tarqalgan xatolar

• Dashboard’ni alert o'rnini bosadigan narsa deb hisoblash. Dashboard faqat kimdir unga faol qarab turgandagina yordam beradi. Yuqoridagi disk to'lishi vaziyatini kimdir grafikni kuzatib turganmi yoki yo'qmi, qat’i nazar, alert bir necha soat oldin ushlagan bo'lardi.
• Alert chegaralarini for: oynasisiz o'rnatish. Chegarani qisqa vaqtga kesib o'tib, o'z-o'zidan to'g'rilanadigan metrika (rejalashtirilgan vazifa paytidagi qisqa CPU sakrashi) usiz yolg'on signal hosil qiladi va javob beruvchilarni alerting tizimiga ishonmaslikka o'rgatadi.
• Rejalashtirilgan vazifani har bir hostga "faqat bir marta" qo'lda deploy qilish. Bu Infrastructure as Code asoslari maqolasidagi imperativ skript muammosining park miqyosidagi versiyasi. U park o'zgarmaguncha va kimdir qaysi hostlar aslida qo'lda o'zgarishni olganini unutmaguncha ishlaydi.
• Prometheus’dagi scrape target’ining down bo'lishi metrikaning o'zi joyida, shunchaki "vaqtincha yo'q" degani deb o'ylash. Yuqorida ko'rib chiqilganidek, ulanib bo'lmaydigan target’ning o'zi signal. U odatda host, exporter yoki ular orasidagi tarmoq yo'li ishdan chiqqanini anglatadi, shunchaki ko'rsatish uchun ma’lumot yo'qligini emas.

Mashqlar

1. Lab VM’ga prometheus-node-exporter ni o'rnating, uning /metrics endpoint’iga curl bilan so'rov yuboring va qaysi qator mavjud xotirani, qaysisi root fayl tizimidan foydalanishni ko'rsatishini aniqlang.
2. Besh daqiqa davomida 90% dan yuqori bo'lib turgan CPU’dan foydalanish uchun Prometheus alert qoidasini yozing (uni to'g'ri yozish uchun ishlab turgan Prometheus serveri shart emas) va for: uchun qanday qiymat tanlashingizni hamda nega ekanini tushuntiring.
3. Infrastructure as Code asoslari maqolasidagi Ansible modelidan foydalanib, o'zingiz tanlagan systemd timer’ni lab hostlari guruhiga deploy qiladigan playbook yozing va playbook’ning ikkinchi ishga tushirilishi hech qanday o'zgarish xabar qilmasligini tasdiqlang.
4. Pull modeli (Prometheus hostlarni scrape qiladi) nega ulanib bo'lmaydigan hostni ko'rinadigan tarzda down qilishini, push modeli (hostlar metrikalarni biror joyga yuboradi) esa xuddi shu nosozlikni "host’da shunchaki xabar qiladigan yangi narsa yo'q edi" holati bilan bir xil ko'rsatishi mumkinligini qisqa paragrafda tushuntiring.

Xulosa

Park miqyosidagi operatsiyalar har bir host bo'yicha qo'lda tekshiruvlarni uchta markazlashgan mexanizm bilan almashtiradi: har bir hostdagi hodisalar bitta ma’lumotlar to'plami sifatida so'rov yuborilishi mumkin bo'lishi uchun log'larni yo'naltirish, host’ning sukunatining o'zi aniqlanadigan signal bo'lishi uchun Prometheus uslubidagi pull’ga asoslangan metrikalar tizimi va chegarani kesib o'tishni hech kim qaramaydigan grafik o'rniga xabarnomaga aylantiradigan alert qoidalari. Oldingi maqolalardagi rejalashtirish va konfiguratsiyani boshqarish vositalari — systemd timer’lar, Ansible — park miqyosida o'zgarmaydi. O'zgaradigan narsa shuki, ular qo'lda takrorlanish o'rniga o'sha infrastructure-as-code intizomi orqali har bir hostga deploy qilinadi va bir xil holda saqlanadi. DevOps: keyingi qadamlar bu modulni yakunlaydi va bu yerda ko'rib chiqilgan hamma narsani ishlayotgan Linux administratori odatda bu yerdan qayerga borishi bilan bog'laydi.

Manbalar

• Prometheus hujjatlari
• Prometheus: node_exporter
• Grafana Labs: Loki hujjatlari
• freedesktop.org: systemd-journal-remote(8)