+994512060920
Cümə günü axşam saat altıdır. Komanda evə getməyə hazırlaşır, bu zaman müştəridən zəng gəlir: "Sifariş verə bilmirəm, ödəniş səhifəsi açılmır." Siz saytı açırsınız, işləyir. Amma müştərinin dediyi də doğrudur. Problem iki saatdır var, sadəcə heç kim bilməyib. Bu arada neçə nəfər eyni səhifədə ilişib, neçəsi səssizcə rəqibin saytına keçib, bunu heç vaxt bilməyəcəksiniz.
Bu vəziyyət proqramçıların qorxulu yuxusudur, amma təəssüf ki, çox yayılıb. Yaxşı xəbər odur ki, həll var: düzgün qurulmuş monitoring və logging. Bu yazıda onların nə olduğunu, nə ilə fərqləndiyini və kiçik komandanın da bunu necə sadə şəkildə qura biləcəyini danışacağıq.
Logging Nədir?
Logging sistemin işləyərkən özü haqqında yazdığı gündəlikdir. İstifadəçi daxil oldu, sifariş yaradıldı, ödəniş cəhdi rədd edildi, verilənlər bazasına qoşulmaq alınmadı. Hər hadisə vaxtı ilə birlikdə bir sətir kimi qeyd olunur.
Log əsasən bir sualı cavablandırır: nə baş verdi? Problem artıq yaranıbsa, səbəbi tapmaq üçün ilk baxdığınız yer logdur. Düzgün yazılmış log olmadan səhvi axtarmaq qaranlıq otaqda açar axtarmağa bənzəyir.
Monitoring Nədir?
Monitoring isə sistemin vəziyyətini davamlı izləməkdir. Server nə qədər yüklənib, saytın cavab müddəti neçə saniyədir, dəqiqədə neçə səhv qaytarılır, ödəniş uğurla keçənlərin payı nə qədərdir. Bunlar rəqəmlərlə, adətən qrafiklərlə göstərilir.
Monitoring isə başqa sualı cavablandırır: indi nə baş verir və hər şey normaldırmı? Əsas üstünlüyü odur ki, problem böyüməmişdən xəbər verir.
Logging və Monitoring Arasındakı Fərq
| Meyar | Logging | Monitoring |
|---|---|---|
| Əsas sual | Nə baş verdi? | İndi vəziyyət necədir? |
| Məlumat forması | Mətn sətirləri, hadisə qeydləri | Rəqəmlər, qrafiklər |
| Nə vaxt lazımdır | Səbəbi araşdırarkən | Problemi vaxtında görmək üçün |
| Nümunə | "Ödəniş servisi 30 saniyə cavab vermədi" | Ödəniş uğursuzluq faizinin birdən artması |
| Rolu | Detektiv kimi, nə olduğunu aydınlaşdırır | Siqnalizasiya kimi, xəbər verir |
Qısası, monitoring "bir şey səhvdir" deyir, logging isə "dəqiq nə səhvdir" deyir. Birinin olması digərini əvəz etmir.
Üçüncü Dayaq: Trace
Mikroservis arxitekturasında bir istifadəçi sorğusu bir neçə servisdən keçir. Məsələn, sifariş verəndə sorğu əvvəl API-yə, oradan stok servisinə, sonra ödəniş servisinə və bildiriş servisinə gedir. Hansı addımda gecikmə olduğunu tapmaq üçün logların hər servisdə ayrıca axtarılması çox vaxt aparır.
Trace bu yolu tək bir xətt kimi göstərir: sorğu hansı servisdən keçdi, harada nə qədər vaxt itirdi. Log, metrik və trace birlikdə observability adlanır. Əgər mikroservis arxitekturası ilə işləyirsinizsə, trace artıq lüks deyil, praktiki ehtiyacdır.
Nəyi İzləmək Lazımdır?
Ən çox edilən səhv hər şeyi izləməyə çalışmaqdır. Nəticədə yüzlərlə qrafik olur, amma heç biri baxılmır. Başlanğıc üçün bu dörd göstərici kifayətdir:
- Gecikmə: İstifadəçi sorğuya nə qədər gözləyir. Ortalama yox, ən yavaş sorğulara baxın, çünki narazı istifadəçilər adətən onlardır.
- Səhv sayı: Dəqiqədə neçə sorğu uğursuz olur. 500 səhvlərinin ani artımı adətən ciddi problemin ilk əlamətidir.
- Sorğu həcmi: Trafik normal səviyyədədir, yoxsa qəfil düşüb? Trafikin birdən azalması da problemdir, çünki istifadəçilər saytınıza çata bilmir demək ola bilər.
- Resurs istifadəsi: Server, yaddaş, disk və verilənlər bazası bağlantıları. Disk dolanda sistem çox vaxt xəbərdarlıqsız dayanır.
Bunlara əlavə olaraq mütləq biznes göstəricilərini də izləyin: dəqiqədə neçə sifariş yaranır, neçə ödəniş tamamlanır, neçə qeydiyyat baş verir. Texniki göstəricilər normal görünsə belə, sifariş sayının sıfıra düşməsi sizə problemin harada olduğunu dərhal göstərir.
Yaxşı Log Necə Yazılır?
Logun faydalı olması üçün bir neçə qaydaya əməl etmək lazımdır.
- Səviyyələri düzgün istifadə edin: Info adi hadisələr üçün, Warning şübhəli vəziyyətlər üçün, Error isə həqiqətən uğursuz əməliyyatlar üçündür. Hər şeyi Error yazsanız, əsl səhvi tapmaq mümkün olmur.
- Kontekst əlavə edin: "Ödəniş uğursuz oldu" yetərli deyil. Hansı sifariş, hansı istifadəçi, hansı səbəb, hansı vaxt göstərilməlidir.
- Strukturlu formatdan istifadə edin: JSON formatında yazılan loglar axtarış və filtrləmə üçün çox rahatdır.
- Həssas məlumatı yazmayın: Parol, kart nömrəsi, token loga düşməməlidir. Bu, təhlükəsizlik baxımından ciddi riskdir və API təhlükəsizliyi yazımızda da toxunduğumuz məsələlərdən biridir.
- Hər yerdən bir yerə toplayın: Əgər sistem bir neçə serverdə işləyirsə, loglar bir mərkəzdə toplanmalıdır. Hər serverə ayrıca girib log oxumaq real insidentdə vaxt itkisidir.
Alert: Problemi Sizə Özü Xəbər Versin
Qrafikləri gün boyu seyr etmək mümkün deyil. Buna görə monitoringin ən vacib hissəsi alert-lərdir, yəni müəyyən şərt pozulanda avtomatik xəbərdarlıq göndərilməsi. Məsələn, "son beş dəqiqədə səhv faizi yeddi faizdən çox olarsa, komandaya mesaj göndər."
Alert qurarkən əsas qayda belədir: hər alert bir insanın hərəkət etməsini tələb etməlidir. Əgər alert gələndə heç nə etmək lazım deyilsə, deməli o alert artıqdır. Çox sayda lazımsız alert komandanı xəbərdarlıqlara laqeyd edir, nəticədə həqiqətən vacib bildiriş də gözdən qaçır.
Alert-ləri iki yerə bölmək faydalıdır. Təcili olanlar (sayt işləmir, ödəniş keçmir) dərhal zəng və ya mesajla çatmalıdır. Təcili olmayanlar (disk 70 faizə çatıb) isə gün ərzində baxılan siyahıya düşməlidir.
Deployment Sonrası Monitoring
Problemlərin böyük hissəsi yeni versiya yayımlanandan sonra yaranır. Buna görə monitoring CI/CD pipeline ilə birlikdə düşünülməlidir. Yeni versiya production-a çıxandan sonra ilk dəqiqələrdə səhv sayı və gecikməyə baxmaq, problem varsa dərhal əvvəlki versiyaya qayıtmaq (rollback) ən yaxşı vərdişlərdən biridir.
Bəzi komandalar bunu daha da irəli aparır: yeni versiya əvvəlcə trafikin kiçik hissəsinə göstərilir, metriklər normal qalarsa tədricən hamıya açılır. Bu yanaşma monitoringin düzgün qurulmasına əsaslanır və riski ciddi şəkildə azaldır.
Konteyner və Kubernetes Mühitində Monitoring
Konteynerlər müvəqqəti xarakter daşıyır. Pod yenidən başladıqda içindəki fayllar, o cümlədən log faylları itə bilər. Buna görə Kubernetes mühitində loglar konteynerin daxilində saxlanmamalı, mərkəzi sistemə göndərilməlidir. Eyni zamanda Pod, Node və Cluster səviyyəsində resurs istifadəsini izləmək lazımdır, çünki problem bəzən tətbiqin özündə yox, ona ayrılmış resursun çatışmamasındadır.
Hansı Alətlərdən İstifadə Etmək Olar?
Bazarda çoxlu seçim var və hansının uyğun olduğu layihənin ölçüsündən asılıdır.
| Alət | Nə üçün məşhurdur |
|---|---|
| Prometheus və Grafana | Açıq mənbəli metrik toplama və qrafik paneli, Kubernetes ilə çox yayılıb |
| ELK (Elasticsearch, Logstash, Kibana) | Logların toplanması, axtarışı və vizuallaşdırılması |
| Loki | Grafana ilə uyğun işləyən, nisbətən yüngül log sistemi |
| OpenTelemetry | Metrik, log və trace məlumatını standart formada toplamaq üçün |
| Sentry | Tətbiqdəki səhvləri avtomatik tutur və komandaya bildirir |
| Uptime izləyiciləri | Saytın kənardan əlçatan olub-olmadığını yoxlayır |
Kiçik layihə üçün ən sadə başlanğıc: kənardan saytı yoxlayan uptime izləyicisi, tətbiqdəki səhvləri tutan Sentry kimi bir alət və əsas göstəriciləri göstərən bir panel. Bu üçü belə, "problemi müştəridən öyrənmək" vəziyyətinin çoxunu aradan qaldırır.
Ən Çox Edilən Səhvlər
- Monitoringi sonraya saxlamaq: "Əvvəl işləsin, sonra qurarıq" yanaşması adətən ilk ciddi insidentə qədər davam edir.
- Yalnız serveri izləmək: Server sağlam görünə bilər, amma ödəniş servisi səhv qaytarır. Biznes göstəricilərini də izləmək lazımdır.
- Çox alert qurmaq: Hər şey xəbərdarlıq göndərəndə heç biri ciddi qəbul olunmur.
- Logları saxlama qaydası qoymamaq: Loglar sürətlə böyüyür. Nə qədər saxlanacağı müəyyən edilməsə, disk dolur və problemin özünə çevrilir.
- Komandada məsuliyyəti bölməmək: Alert gələndə kimin baxacağı əvvəlcədən bəlli olmalıdır.
- Yalnız Production-u izləmək: Staging mühitində də monitoring olmalıdır ki, problem istifadəçiyə çatmamış tutulsun.
Necə Başlamaq Olar?
Hər şeyi bir günə qurmağa ehtiyac yoxdur. Bu ardıcıllıq real layihələrdə yaxşı işləyir:
- Saytı kənardan yoxlayan sadə uptime izləyicisi qurun.
- Tətbiqdəki səhvləri avtomatik toplayan alət əlavə edin.
- Logları mərkəzi yerə toplayın və strukturlu formata keçin.
- Dörd əsas göstərici (gecikmə, səhv, həcm, resurs) üçün bir panel yaradın.
- İki-üç ən vacib alert qurun və kimin cavabdeh olduğunu müəyyən edin.
- Biznes göstəricilərini (sifariş, ödəniş) panelə əlavə edin.
- Sistem böyüdükcə trace əlavə edin.
Əgər layihəniz artıq mürəkkəbdirsə, ya da komandada bu sahədə təcrübə yoxdursa, monitoring və log arxitekturasını ilk gündən düzgün qurmaq sonradan düzəltməkdən xeyli ucuz başa gəlir. Bu cür işlər fərdi proqram təminatı layihələrində adətən arxitektura mərhələsində nəzərə alınır.
Tez-tez Verilən Suallar
Kiçik layihə üçün monitoring lazımdır?
Bəli. Ən sadə uptime yoxlaması belə, sayt dayananda sizə müştəridən əvvəl xəbər verir. Bu, demək olar ki, heç bir xərc tələb etmir.
Logging ilə monitoring eyni şeydir?
Xeyr. Monitoring indiki vəziyyəti rəqəmlərlə göstərir və problemdən xəbər verir. Logging isə nə baş verdiyini detallı şəkildə qeyd edir. İkisi bir-birini tamamlayır.
Bütün hadisələri loga yazmaq düzgündür?
Yox. Həddindən artıq log həm xərci artırır, həm də vacib məlumatı itirir. Əsas hadisələri və bütün səhvləri kontekstlə yazmaq daha yaxşıdır.
Alert gecə gələndə nə etməli?
Əvvəlcədən yazılmış sadə təlimat olmalıdır: nəyə baxmaq, kimə zəng etmək, lazım gələrsə rollback necə etmək. Gecə saat üçdə bunları xatırlamağa çalışmaq heç kim üçün asan deyil.
Monitoring performansa təsir edirmi?
Düzgün qurulubsa, təsiri çox kiçikdir. Əsas risk həddindən artıq detallı log yazmaqdır.
Nəticə
Problemlərin heç vaxt yaranmayacağını söyləmək mümkün deyil. Amma onları kimdən əvvəl öyrəndiyiniz sizin əlinizdədir. Monitoring problemdən xəbər verir, logging səbəbi tapmağa kömək edir, trace isə mürəkkəb sistemlərdə yolu göstərir. Bunları qurmaq üçün böyük büdcə lazım deyil, sadəcə düzgün ardıcıllıq və başlamaq qərarı lazımdır.
Layihənizdə monitoring və logging sistemini qurmaq və ya mövcud olanı gücləndirmək istəyirsinizsə, Crocusoft komandası ilə əlaqə saxlayın. Birlikdə hansı addımdan başlamağın məntiqli olduğunu müəyyən edək.
