Mənim adım Anton Baderindir. Mən Yüksək Texnologiyalar Mərkəzində işləyirəm və sistem idarəçiliyi ilə məşğul oluram. Bir ay əvvəl toplanmış təcrübəmizi şəhərimizin İT ictimaiyyəti ilə paylaşdığımız korporativ konfransımız başa çatdı. Mən veb proqramların monitorinqi haqqında danışdım. Material bu prosesi sıfırdan qurmayan kiçik və ya orta səviyyə üçün nəzərdə tutulmuşdur.
İstənilən monitorinq sisteminin təməl daşı biznes problemlərinin həllidir. Monitorinq xatirinə monitorinq heç kimə maraqlı deyil. Biznes nə istəyir? Beləliklə, hər şey tez və səhvsiz işləsin. Müəssisələr fəal olmaq istəyirlər ki, biz özümüz xidmətdəki problemləri müəyyən edək və mümkün qədər tez aradan qaldıraq. Bunlar, əslində, keçən il müştərilərimizdən birinin layihəsində həll etdiyim problemlərdir.
Layihə haqqında
Layihə ölkədəki ən böyük loyallıq proqramlarından biridir. Biz pərakəndə satış şəbəkələrinə bonus kartları kimi müxtəlif marketinq alətləri vasitəsilə satış tezliyini artırmağa kömək edirik. Ümumilikdə layihəyə on serverdə işləyən 14 proqram daxildir.
Müsahibə zamanı mən dəfələrlə müşahidə etdim ki, adminlər həmişə veb proqramların monitorinqinə düzgün yanaşmırlar: bir çoxları hələ də əməliyyat sisteminin ölçülərinə diqqət yetirir və bəzən xidmətlərə nəzarət edirlər.
Mənim vəziyyətimdə müştərinin monitorinq sistemi əvvəllər Icinga-ya əsaslanırdı. Yuxarıda göstərilən problemləri heç bir şəkildə həll etmədi. Çox vaxt müştərinin özü bizə problemlər barədə məlumat verirdi və çox vaxt səbəbin altına düşmək üçün kifayət qədər məlumatımız yox idi.
Bundan əlavə, onun gələcək inkişafının mənasızlığı aydın şəkildə başa düşüldü. Düşünürəm ki, Icinga ilə tanış olanlar məni başa düşəcəklər. Beləliklə, layihə üçün veb proqramların monitorinq sistemini tamamilə yenidən dizayn etmək qərarına gəldik.
Prometey
Prometeyi üç əsas göstəriciyə əsasən seçdik:
- Çox sayda mövcud göstəricilər. Bizim vəziyyətimizdə onların 60 mini var. Əlbəttə, qeyd etmək lazımdır ki, biz onların böyük əksəriyyətindən (ehtimal ki, təxminən 95%) istifadə etmirik. Digər tərəfdən, onların hamısı nisbətən ucuzdur. Bizim üçün bu, əvvəllər istifadə edilən Icinga ilə müqayisədə digər ekstremaldır. Burada ölçüləri əlavə etmək xüsusi bir ağrı idi: mövcud olanlar bahalı idi (sadəcə hər hansı bir plaginin mənbə koduna baxın). Hər hansı bir plagin Bash və ya Python-da bir skript idi, istifadəyə verilməsi istehlak olunan resurslar baxımından bahadır.
- Bu sistem nisbətən az miqdarda resurs sərf edir. 600 MB RAM, bir nüvənin 15% və bir neçə onlarla IOPS bütün ölçülərimiz üçün kifayətdir. Əlbəttə ki, siz ölçü ixracatçılarını işlətməlisiniz, lakin onların hamısı Go-da yazılmışdır və eyni zamanda çox enerjiyə ehtiyacı yoxdur. Müasir reallıqlarda bunun problem olduğunu düşünmürəm.
- Kubernetes-ə köçmək imkanı verir. Müştərinin planlarını nəzərə alsaq, seçim göz qabağındadır.
ELK
Əvvəllər biz logları yığmır və emal etmirdik. Çatışmazlıqlar hər kəsə aydındır. Biz ELK-ı seçdik, çünki bu sistemlə artıq təcrübəmiz var idi. Biz orada yalnız proqram qeydlərini saxlayırıq. Əsas seçim meyarları tam mətnli axtarış və onun sürəti idi.
Slickhouse
Əvvəlcə seçim InfluxDB-nin üzərinə düşdü. Nginx qeydlərini, pg_stat_statements-dən statistik məlumatları toplamaq və Prometheus tarixi məlumatlarını saxlamaq ehtiyacını başa düşdük. Influx-u bəyənmədik, çünki vaxtaşırı çox miqdarda yaddaş istehlak etməyə başladı və çökdü. Bundan əlavə, sorğuları remote_addr ilə qruplaşdırmaq istədim, lakin bu DBMS-də qruplaşdırma yalnız teqlərə görədir. Teqlər bahalıdır (yaddaş), onların sayı şərti olaraq məhduddur.
Yenidən axtarışlarımıza başladıq. Lazım olan minimal resurs istehlakı ilə, tercihen diskdə məlumatların sıxılması ilə analitik verilənlər bazası idi.
Clickhouse bütün bu meyarlara cavab verir və biz seçimimizə heç vaxt peşman olmamışıq. Biz ona heç bir qeyri-adi miqdarda məlumat yazmırıq (daxiletmələrin sayı dəqiqədə cəmi beş mindir).
NewRelic
NewRelic tarixən bizimlə olub, çünki bu, müştərinin seçimi idi. Biz ondan APM kimi istifadə edirik.
Zabbix
Biz Zabbix-dən yalnız müxtəlif API-lərin Qara qutusuna nəzarət etmək üçün istifadə edirik.
Monitorinq yanaşmasının müəyyən edilməsi
Biz tapşırığı parçalamaq və bununla da monitorinqə yanaşmanı sistemləşdirmək istədik.
Bunun üçün sistemimizi aşağıdakı səviyyələrə böldüm:
- aparat və VMS;
- əməliyyat sistemi;
- sistem xidmətləri, proqram təminatı yığını;
- ərizə;
- iş məntiqi.
Bu yanaşma niyə əlverişlidir:
- biz hər səviyyənin işinə kimin cavabdeh olduğunu bilirik və buna əsaslanaraq xəbərdarlıqlar göndərə bilərik;
- xəbərdarlıqları basdırarkən strukturdan istifadə edə bilərik - virtual maşın bütövlükdə əlçatmaz olduqda verilənlər bazası əlçatmazlığı haqqında xəbərdarlıq göndərmək qəribə olardı.
Bizim vəzifəmiz sistemin işində pozuntuları müəyyən etmək olduğundan, biz hər bir səviyyədə xəbərdarlıq qaydalarını yazarkən diqqət yetirməyə dəyər olan müəyyən ölçüləri vurğulamalıyıq. Daha sonra “VMS”, “Əməliyyat sistemi” və “Sistem xidmətləri, proqram təminatı yığını” səviyyələrindən keçək.
Virtual maşınlar
Hostinq bizə prosessor, disk, yaddaş və şəbəkə ayırır. Və ilk iki ilə problem yaşadıq. Beləliklə, göstəricilər:
CPU-nun oğurlanması vaxtı - Amazon-da virtual maşın aldıqda (məsələn, t2.micro) başa düşməlisiniz ki, sizə bütöv bir prosessor nüvəsi deyil, yalnız onun vaxtının kvotası ayrılıb. Və onu tükəndikdə prosessor sizdən alınacaq.
Bu metrik sizə belə anları izləməyə və qərarlar qəbul etməyə imkan verir. Məsələn, daha yağlı tarif götürmək və ya fon tapşırıqlarının və API sorğularının işlənməsini müxtəlif serverlərə paylamaq lazımdırmı?
IOPS + CPU iowait time - nədənsə bir çox bulud hostinqi kifayət qədər IOPS təmin etməməklə günah işlədir. Üstəlik, aşağı IOPS ilə bir cədvəl onlar üçün bir arqument deyil. Buna görə CPU iowait-i toplamağa dəyər. Bu cüt qrafiklə - aşağı IOPS və yüksək I/O gözləməsi ilə - siz artıq hostinqlə danışa və problemi həll edə bilərsiniz.
Əməliyyat sistemi
Əməliyyat sistemi ölçüləri:
- mövcud yaddaşın həcmi % ilə;
- svopdan istifadə fəaliyyəti: vmstat swapin, swapout;
- mövcud inodların sayı və fayl sistemindəki boş yer % ilə
- orta yük;
- tw vəziyyətində birləşmələrin sayı;
- masanın dolğunluğunu yoxlamaq;
- Şəbəkənin keyfiyyətinə ss yardım proqramı, iproute2 paketindən istifadə etməklə nəzarət etmək olar - onun çıxışından RTT əlaqələrinin göstəricisini əldə edin və onu hədəf portuna görə qruplaşdırın.
Həm də əməliyyat sistemi səviyyəsində proseslər kimi bir qurumumuz var. Sistemdə onun fəaliyyətində mühüm rol oynayan bir sıra prosesləri müəyyən etmək vacibdir. Məsələn, bir neçə pgpoolunuz varsa, onların hər biri üçün məlumat toplamaq lazımdır.
Metriklər dəsti aşağıdakı kimidir:
- CPU-lar;
- yaddaş ilk növbədə rezidentdir;
- IO - tercihen IOPS-də;
- FileFd - açın və məhdudlaşdırın;
- əhəmiyyətli səhifə uğursuzluqları - bu yolla hansı prosesin dəyişdirildiyini başa düşə bilərsiniz.
Biz bütün monitorinqləri Docker-də yerləşdiririk və ölçü məlumatlarını toplamaq üçün Məsləhətçidən istifadə edirik. Digər maşınlarda biz proses ixracatçısından istifadə edirik.
Sistem xidmətləri, proqram təminatı yığını
Hər bir tətbiqin özünəməxsus xüsusiyyətləri var və müəyyən bir ölçü dəstini ayırmaq çətindir.
Universal dəst belədir:
- sorğu dərəcəsi;
- səhvlərin sayı;
- gecikmə;
- doyma.
Bu səviyyədə monitorinqin ən parlaq nümunələri Nginx və PostgreSQL-dir.
Sistemimizdə ən çox yüklənən xidmət verilənlər bazasıdır. Əvvəllər verilənlər bazasının nə etdiyini anlamaqda tez-tez çətinlik çəkirdik.
Disklərdə yüksək yük gördük, lakin yavaş qeydlər həqiqətən heç nə göstərmədi. Biz bu problemi sorğu statistikasını toplayan pg_stat_statements görünüşündən istifadə edərək həll etdik.
Adminin ehtiyacı budur.
Oxuma və yazma sorğularının fəaliyyətinin qrafiklərini qururuq:
Hər şey sadə və aydındır, hər sorğunun öz rəngi var.
Eyni dərəcədə parlaq nümunə Nginx qeydləridir. Təəccüblü deyil ki, az adam onları təhlil edir və ya zəruri olanlar siyahısında qeyd edir. Standart format çox informativ deyil və genişləndirilməlidir.
Şəxsən mən request_time, upstream_response_time, body_bytes_sent, request_length, request_id əlavə etdim. Cavab vaxtını və xətaların sayını tərtib edirik:
Cavab müddəti və səhvlərin sayının qrafiklərini qururuq. Yadınızdadır? Mən biznes məqsədləri haqqında danışdım? Tez və səhvsiz? Biz artıq bu məsələləri iki qrafiklə əhatə etmişik. Və onlardan istifadə edərək artıq növbətçi idarəçilərə zəng edə bilərsiniz.
Ancaq daha bir problem qalır - hadisənin səbəblərinin tez bir zamanda aradan qaldırılmasını təmin etmək.
Hadisənin həlli
Problemin müəyyən edilməsindən həllinə qədər bütün prosesi bir neçə mərhələyə bölmək olar:
- problemin müəyyən edilməsi;
- növbətçi inzibatçıya bildiriş;
- hadisəyə reaksiya;
- səbəblərin aradan qaldırılması.
Bunu mümkün qədər tez etməliyik. Problemi müəyyənləşdirmək və bildiriş göndərmək mərhələlərində çox vaxt qazana bilmiriksə - hər halda onlara iki dəqiqə sərf olunacaq, onda sonrakılar təkmilləşdirmə üçün sadəcə boşaldılmış sahədir.
Təsəvvür edək ki, növbətçinin telefonu zəng çaldı. O nə edəcək? Suallara cavab axtarın - nə qırdı, harada qırıldı, necə reaksiya verməli? Bu suallara necə cavab veririk:
Biz sadəcə olaraq bütün bu məlumatları bildirişin mətninə daxil edirik, ona bu problemə necə reaksiya veriləcəyini, necə həll olunacağını və onu necə gücləndirəcəyini təsvir edən viki səhifəsinə keçid veririk.
Mən hələ də tətbiq təbəqəsi və biznes məntiqi haqqında heç nə deməmişəm. Təəssüf ki, tətbiqlərimiz hələ də metrik kolleksiyanı həyata keçirmir. Bu səviyyələrdən hər hansı məlumatın yeganə mənbəyi loglardır.
Bir neçə nöqtə.
Əvvəlcə strukturlaşdırılmış jurnallar yazın. Mesajın mətninə kontekst daxil etməyə ehtiyac yoxdur. Bu, onları qruplaşdırmağı və təhlil etməyi çətinləşdirir. Logstash bütün bunları normallaşdırmaq üçün çox vaxt tələb edir.
İkincisi, şiddət səviyyələrini düzgün istifadə edin. Hər dilin öz standartı var. Şəxsən mən dörd səviyyəni ayırd edirəm:
- səhv yoxdur;
- müştəri tərəfində səhv;
- səhv bizim tərəfimizdədir, pul itirmirik, risk daşımırıq;
- Səhv bizim tərəfimizdədir, pul itiririk.
İcazə verin yekunlaşdırım. Siz biznes məntiqi əsasında monitorinq qurmağa cəhd etməlisiniz. Tətbiqin özünü izləməyə və satışların sayı, yeni istifadəçi qeydiyyatlarının sayı, hazırda aktiv istifadəçilərin sayı və s. kimi göstəricilərlə işləməyə çalışın.
Bütün biznesiniz brauzerdə bir düymədirsə, onun kliklənməsinə və düzgün işləməsinə nəzarət etməlisiniz. Qalan hər şeyin əhəmiyyəti yoxdur.
Əgər sizdə bu yoxdursa, bizim etdiyimiz kimi tətbiq qeydlərində, Nginx qeydlərində və s.-də onu tutmağa cəhd edə bilərsiniz. Tətbiqə mümkün qədər yaxın olmalısınız.
Əməliyyat sisteminin ölçüləri əlbəttə vacibdir, lakin biznes onlarla maraqlanmır, bizə onlar üçün pul ödənilmir.
Mənbə: www.habr.com