SRE (Site Reliability Engineering) veb-layihələrin mövcudluğunu təmin etmək üçün bir yanaşmadır. Bu, DevOps üçün çərçivə hesab olunur və DevOps təcrübələrini tətbiq etməkdə uğur qazanmağın yolları haqqında danışır. Bu məqalədə tərcümə kitablar Google-dan. Mən bu tərcüməni özüm hazırladım və monitorinq proseslərini başa düşməkdə öz təcrübəmə əsaslandım. Telegram kanalında и Mən həmçinin xidmət səviyyəsinin məqsədləri haqqında həmin kitabın 4-cü fəslinin tərcüməsinə keçid dərc etdim.
Pişik tərəfindən tərcümə. Oxumaqdan həzz alın!
Google-un SRE komandaları uğurlu monitorinq və bildiriş sistemlərinin yaradılması üçün əsas prinsiplərə və ən yaxşı təcrübələrə malikdirlər. Bu fəsildə veb səhifə ziyarətçisinin hansı problemlərlə qarşılaşa biləcəyi və veb səhifələrin göstərilməsini çətinləşdirən problemlərin necə həll ediləcəyi barədə təlimat verilir.
Anlayışlar
Monitorinqlə bağlı mövzuları müzakirə etmək üçün istifadə olunan vahid lüğət yoxdur. Hətta Google-da aşağıdakı terminlər çox istifadə olunmur, lakin biz ən çox yayılmış şərhləri sadalayacağıq.
Monitorinq
Sistem haqqında real vaxt rejimində kəmiyyət məlumatlarının toplanması, işlənməsi, yığılması və göstərilməsi: sorğuların sayı və sorğu növləri, xətaların sayı və xəta növləri, sorğunun emal müddəti və serverin işləmə müddəti.
Ağ qutu monitorinqi
Qeydlər, Java Virtual Maşın profilləşdirmə ölçüləri və ya daxili statistika yaradan HTTP işləyicisi ölçüləri daxil olmaqla daxili sistem komponentləri tərəfindən göstərilən ölçülərə əsaslanan monitorinq.
Qara qutu monitorinqi
Tətbiq davranışının istifadəçi nöqteyi-nəzərindən sınaqdan keçirilməsi.
İdarə paneli
Xidmətlərin əsas sağlamlıq göstəricilərinin icmalını təqdim edən interfeys (adətən veb). İdarə panelində filtrlər, göstərilən göstəriciləri seçmək imkanı və s. ola bilər. İnterfeys istifadəçilər üçün ən vacib olan göstəriciləri müəyyən etmək üçün nəzərdə tutulub. İdarə paneli texniki dəstək işçiləri üçün məlumatları da göstərə bilər: sorğuların növbəsi, yüksək prioritet səhvlərin siyahısı və müəyyən bir məsuliyyət sahəsi üçün təyin edilmiş mühəndis.
Xəbərdarlıq (bildiriş)
Bir şəxs tərəfindən e-poçt və ya digər vasitələrlə qəbul edilməsi nəzərdə tutulan bildirişlər, səhvlər və ya sorğu növbəsinin artması ilə baş verə bilər. Bildirişlər aşağıdakı kimi təsnif edilir: biletlər, e-poçt xəbərdarlıqları və ani mesajlaşma mesajları.
Kök səbəb
Bir dəfə düzəldildikdən sonra bir daha baş verməməli olan proqram qüsuru və ya insan xətası. Problemin bir neçə əsas səbəbi ola bilər: prosesin avtomatlaşdırılmasının qeyri-kafi olması, proqram təminatının nasazlığı, tətbiq məntiqinin kifayət qədər işlənməməsi. Bu amillərin hər biri kök səbəb ola bilər və onların hər biri aradan qaldırılmalıdır.
Node və maşın (qovşaq və maşın)
Fiziki serverdə, virtual maşında və ya konteynerdə işləyən tətbiqin tək nümunəsinə istinad etmək üçün dəyişdirilə bilən terminlər. Bir maşın bir neçə xidmətə sahib ola bilər. Xidmətlər ola bilər:
- bir-birinə bağlıdır: məsələn, keşləmə serveri və veb server;
- bir avadanlığa aid olmayan xidmətlər: məsələn, kod anbarı və konfiqurasiya sistemi üçün sehrbaz, məsələn, və ya .
Basmaq
Proqram konfiqurasiyasında hər hansı dəyişiklik.
Nə üçün monitorinq lazımdır
Tətbiqlərə nəzarət edilməsinin bir neçə səbəbi var:
Uzunmüddətli tendensiyaların təhlili
Verilənlər bazası nə qədər böyükdür və nə qədər sürətlə böyüyür? Gündəlik istifadəçilərin sayı necə dəyişir?
Performans müqayisəsi
Acme Bucket of Bytes 2.72-də Ajax DB 3.14 ilə müqayisədə sorğular daha sürətlidir? Əlavə node göründükdən sonra sorğular nə qədər yaxşı saxlanılır? Sayt keçən həftə ilə müqayisədə daha yavaş işləyir?
Xəbərdarlıq (bildirişlər)
Bir şey xarabdır və kimsə onu düzəltməlidir. Və ya tezliklə bir şey pozulacaq və kimsə onu tezliklə yoxlamalıdır.
Tabloların yaradılması
Panellər əsas suallara cavab verməli və onlardan nəsə daxil etməlidir — gecikmələr (gecikmə), trafik (trafik), səhvlər (səhvlər) və yük ölçüsü (doyma).
Retrospektiv təhlilin aparılması (debugging)
Sorğunun emal gecikməsi artdı, lakin eyni vaxtda başqa nə baş verdi?
Monitorinq sistemləri biznes kəşfiyyat sistemləri üçün məlumat mənbəyi kimi və təhlükəsizlik insidentlərinin təhlilini asanlaşdırmaq üçün faydalıdır. Bu kitab SRE-lərin təcrübəyə malik olduğu mühəndislik sahələrinə diqqət yetirdiyinə görə biz burada monitorinq üsullarını müzakirə etməyəcəyik.
Monitorinq və xəbərdarlıqlar sistemə onun nə vaxt xarab olduğunu və ya pozulmaq üzrə olduğunu bildirməyə imkan verir. Sistem avtomatik olaraq özünü təmir edə bilməyəndə biz insandan xəbərdarlığı təhlil etməsini, problemin hələ də aktiv olub-olmadığını müəyyən etməsini, onu həll etməsini və kök səbəbini müəyyən etməsini istəyirik. Əgər sistem komponentlərini yoxlamırsınızsa, sadəcə olaraq "nəsə bir az qəribə görünür" deyə heç vaxt xəbərdarlıq almayacaqsınız.
Bir insanı bildirişlərlə yükləmək işçinin vaxtının kifayət qədər bahalı istifadəsidir. Əgər işçi işləyirsə, xəbərdarlıq iş prosesini dayandırır. Əgər işçi evdədirsə, xəbərdarlıq şəxsi vaxtı və bəlkə də yuxunu kəsir. Xəbərdarlıqlar çox tez-tez baş verdikdə, işçilər onları gözdən keçirir, onları təxirə salır və ya gələn xəbərdarlıqlara məhəl qoymurlar. Zaman zaman səs-küy hadisələri ilə maskalanan real xəbərdarlığa məhəl qoymurlar. Xidmətin dayandırılması uzun müddət davam edə bilər, çünki səs-küy hadisələri problemin tez bir zamanda diaqnoz qoyulmasına və düzəldilməsinə mane olur. Effektiv xəbərdarlıq sistemləri yaxşı siqnal-küy nisbətinə malikdir.
Monitorinq sistemi üçün ağlabatan gözləntilərin müəyyən edilməsi
Mürəkkəb bir tətbiq üçün monitorinqin qurulması özlüyündə mürəkkəb mühəndislik işidir. Əhəmiyyətli toplama, nümayiş etdirmək və xəbərdarlıq alətləri infrastrukturuna malik olsa belə, 10-12 nəfərdən ibarət Google SRE komandası adətən monitorinq sistemlərini qurmaq və saxlamaqdan ibarət olan bir və ya iki nəfəri əhatə edir. Biz monitorinq infrastrukturunu birləşdirdikcə və mərkəzləşdirdikcə bu rəqəm zamanla azaldı, lakin hər bir SRE komandasında adətən yalnız monitorinq üçün ayrılmış ən azı bir nəfər var. Deməliyik ki, monitorinq sisteminin idarə panellərinə baxmaq olduqca maraqlı olsa da, SRE qrupları kiminsə problemləri izləmək üçün ekrana baxmasını tələb edən vəziyyətlərdən ehtiyatla qaçırlar.
Ümumilikdə, Google optimal faktdan sonra analiz alətləri ilə sadə və sürətli monitorinq sistemlərinə keçdi. Biz hədləri proqnozlaşdırmağa çalışan və ya kök səbəbi avtomatik aşkar etməyə çalışan "sehrli" sistemlərdən qaçırıq. Son istifadəçi sorğularında nəzərdə tutulmayan məzmunu aşkar edən sensorlar yeganə əks nümunədir; Bu sensorlar sadə qaldıqca, ciddi anomaliyaların səbəblərini tez bir zamanda aşkar edə bilirlər. Tutumların planlaşdırılması və ya trafikin proqnozlaşdırılması kimi monitorinq məlumatlarından istifadə üçün digər formatlar daha mürəkkəbdir. Çox uzun müddət ərzində (aylar və ya illər) aşağı seçmə sürətində (saatlarla və ya günlərlə) müşahidə uzunmüddətli tendensiyanı aşkar edəcək.
Google SRE komandası mürəkkəb asılılıq iyerarxiyaları ilə qarışıq uğur qazandı. Biz nadir hallarda “verilənlər bazasının yavaş olduğunu bilsəm, verilənlər bazasının yavaş olduğuna dair xəbərdarlıq alıram, əks halda saytın yavaş olduğuna dair xəbərdarlıq alıram” kimi qaydalardan istifadə edirik. Asılılığa əsaslanan qaydalar adətən sistemimizin dəyişməz hissələrinə, məsələn, məlumat mərkəzinə istifadəçi trafikinin süzülməsi sistemi kimi aiddir. Məsələn, "məlumat mərkəzinə trafikin süzülməsi konfiqurasiya edilibsə, istifadəçi sorğularının emalında gecikmələr barədə mənə xəbərdarlıq etməyin" məlumat mərkəzindən xəbərdarlıqlar üçün ümumi qaydalardan biridir. Google-da bir neçə komanda mürəkkəb asılılıq iyerarxiyalarını dəstəkləyir, çünki infrastrukturumuzda davamlı refaktorinq daimi sürəti var.
Bu fəsildə təsvir edilən bəzi fikirlər hələ də aktualdır: xüsusilə daim dəyişən sistemlərdə simptomdan kök səbəbə daha sürətli keçmək imkanı həmişə var. Buna görə də, bu fəsildə monitorinq sistemləri üçün bəzi məqsədlər və bu məqsədlərə nail olmaq yolları göstərilsə də, monitorinq sistemlərinin komandadakı hər kəs üçün sadə və başa düşülən olması vacibdir.
Eynilə, səs-küy səviyyələrini aşağı və siqnal səviyyələrini yüksək saxlamaq üçün xəbərdarlıq edilmiş aktivlərin monitorinqinə yanaşmalar çox sadə və etibarlı olmalıdır. İnsanlar üçün xəbərdarlıq yaradan qaydalar asan başa düşülməli və aydın problem təqdim etməlidir.
Semptomlar səbəblərə qarşı
Monitorinq sisteminiz iki suala cavab verməlidir: “nə qırdı” və “niyə sındı”.
"Nə qırıldı" simptomdan, "niyə qırıldı" isə səbəbdən danışır. Aşağıdakı cədvəldə bu cür əlaqələrin nümunələri göstərilir.
Bir simptom
Səbəb
HTTP xətası 500 və ya 404 əldə edilir
Verilənlər bazası serverləri əlaqələri rədd edir
Yavaş server cavabları
Yüksək CPU istifadəsi və ya zədələnmiş Ethernet kabeli
Antarktidadakı istifadəçilər pişik GIF-ləri almırlar
CDN-iniz alimlərə və pişiklərə nifrət edir, buna görə də bəzi IP ünvanları qara siyahıya salındı
Şəxsi məzmun hər yerdən əlçatan oldu
Yeni proqram təminatının buraxılışı firewall-a bütün ACL-ləri unutdurdu və hamını içəri buraxdı
“Nə” və “niyə” maksimum siqnal və minimum səs-küylə yaxşı monitorinq sistemi yaratmaq üçün ən vacib tikinti bloklarından bəziləridir.
Qara qutu və Ağ qutu
Biz kritik ölçülər üçün geniş Ağ qutu monitorinqini sadə Qara qutu monitorinqi ilə birləşdiririk. Qara qutuyu Ağ qutu ilə müqayisə etməyin ən asan yolu odur ki, Qara qutu simptoma diqqət yetirir və proaktiv monitorinqdən daha çox reaktivdir: “sistem hazırda düzgün işləmir”. Ağ qutu sistemlərin daxili yoxlama imkanlarından asılıdır: hadisə qeydləri və ya veb serverlər. Beləliklə, White-box gözlənilən problemləri, sorğunun təkrar ötürülməsi kimi görünən nasazlıqları və s. aşkar etməyə imkan verir.
Qeyd edək ki, çox qatlı sistemdə bir mühəndisin məsuliyyət sahəsindəki simptom başqa bir mühəndisin məsuliyyət sahəsindəki simptomdur. Məsələn, verilənlər bazası performansı azalıb. Yavaş verilənlər bazası oxunması onları aşkar edən verilənlər bazası SRE-nin simptomudur. Bununla belə, yavaş veb-saytı müşahidə edən ön uç SRE üçün eyni yavaş verilənlər bazası oxunmasının səbəbi yavaş verilənlər bazasıdır. Buna görə də, ağ qutu monitorinqi nə qədər geniş olmasından asılı olaraq bəzən simptoma, bəzən də səbəbə yönəldilir.
Sazlama üçün telemetriya toplayan zaman Ağ qutu monitorinqi tələb olunur. Əgər veb serverlər verilənlər bazası sorğularına ləng cavab verirlərsə, siz veb serverin verilənlər bazası ilə nə qədər tez əlaqə saxladığını və onun nə qədər tez cavab verdiyini bilməlisiniz. Əks halda, siz yavaş verilənlər bazası serveri ilə veb server və verilənlər bazası arasında şəbəkə problemi arasında fərq qoya bilməyəcəksiniz.
Xəbərdarlıq göndərərkən qara qutu monitorinqinin əsas üstünlüyü var: problem artıq real simptomlarla nəticələndikdə siz alıcıya bildiriş göndərirsiniz. Digər tərəfdən, hələ yaranmamış, lakin qaçılmaz olan Qara qutu problemi üçün monitorinq faydasızdır.
Dörd qızıl siqnal
Dörd qızıl monitorinq siqnalı gecikmə, trafik, səhvlər və doymadır. Yalnız dörd istifadəçi sistemi ölçülərini ölçə bilirsinizsə, bu dördünə diqqət yetirin.
Gecikmə
Sorğunu emal etmək üçün tələb olunan vaxt. Uğurlu və uğursuz sorğuların gecikmə müddətini ayırd etmək vacibdir. Məsələn, verilənlər bazası və ya digər backend ilə əlaqənin itirilməsi nəticəsində yaranan HTTP 500 xətası çox tez diaqnoz edilə bilər, lakin HTTP 500 xətası uğursuz sorğunu göstərə bilər. 500 xətanın ümumi gecikmə müddətinə təsirinin müəyyən edilməsi səhv nəticələrə gətirib çıxara bilər. Digər tərəfdən, yavaş bir səhv hətta sürətli bir səhvdir! Buna görə də, sadəcə səhvləri süzgəcdən keçirməkdənsə, səhvlərin gecikməsinə nəzarət etmək vacibdir.
hərəkət
Sisteminizə edilən sorğuların sayı yüksək səviyyəli sistem ölçüləri ilə ölçülür. Veb xidməti üçün bu ölçü adətən sorğuların xarakterinə (məsələn, statik və ya dinamik məzmun) bölünən saniyədə HTTP sorğularının sayını təmsil edir. Audio axın sistemi üçün bu ölçü şəbəkənin I/O sürətinə və ya eyni vaxtda seansların sayına diqqət yetirə bilər. Əsas dəyər saxlama sistemi üçün bu ölçü əməliyyatlar və ya saniyədə axtarış nəticələri ola bilər.
Səhvlər
Bu, açıq (məsələn, HTTP 500), gizli (məsələn, HTTP 200, lakin etibarsız məzmunla birləşdirilmiş) və ya siyasət (məsələn, "Bir saniyə ərzində cavab almısınızsa, hər hansı bir saniyə xətadır") olan uğursuz sorğuların dərəcəsidir. HTTP cavab kodları bütün uğursuzluq şərtlərini ifadə etmək üçün kifayət deyilsə, qismən nasazlığı aşkar etmək üçün ikincil (daxili) protokollar tələb oluna bilər. Bütün bu cür uğursuz sorğuların monitorinqi informativ olmaya bilər, eyni zamanda sistem testləri səhv məzmunu emal etdiyinizi aşkar etməyə kömək edəcək.
Doyma
Metrik xidmətinizin nə qədər intensiv istifadə edildiyini göstərir. Bu, ən çox məhdud olan resursları müəyyən edən sistem monitorinqi tədbiridir (məsələn, yaddaş məhdud sistemdə yaddaşı göstərir, I/O məhdudlaşdırılmış sistemdə, I/O-ların sayını göstərir). Qeyd edək ki, bir çox sistemlər 100% istifadəyə çatmazdan əvvəl performansını pisləşdirir, ona görə də istifadə məqsədinə malik olmaq vacibdir.
Mürəkkəb sistemlərdə doyma yüksək səviyyəli yük ölçmələri ilə tamamlana bilər: xidmətiniz ikiqat trafiki düzgün idarə edə bilərmi, yalnız 10% daha çox trafiki idarə edə bilərmi və ya hazırda olduğundan daha az trafiki idarə edə bilərmi? Sorğunun mürəkkəbliyini dəyişdirən parametrləri olmayan (məsələn, "Mənə heç nə vermə" və ya "Mənə unikal tək monoton tam ədəd lazımdır") nadir hallarda konfiqurasiyanı dəyişən sadə xidmətlər üçün statik yük testi dəyəri adekvat ola bilər. Bununla belə, əvvəlki paraqrafda müzakirə edildiyi kimi, əksər xidmətlər məlum yuxarı həddi olan CPU istifadəsi və ya şəbəkə bant genişliyi kimi dolayı siqnallardan istifadə etməlidir. Artan gecikmə tez-tez doymanın aparıcı göstəricisidir. Kiçik bir pəncərədə (məsələn, bir dəqiqə) 99-cu faizin cavab müddətini ölçmək çox erkən doyma siqnalını təmin edə bilər.
Nəhayət, doyma gözlənilən doyma ilə bağlı proqnozlarla da əlaqələndirilir, məsələn: “Deyəsən, verilənlər bazanız sabit diskinizi 4 saat ərzində dolduracaq”.
Əgər siz bütün dörd qızıl siqnalı ölçsəniz və ölçülərdən birində problem olduqda (və ya doyma halında, yaxın problem) bir insanı xəbərdar etsəniz, xidmətiniz monitorinqlə az-çox əhatə olunacaq.
"Quyruq" (və ya alətlər və performans) ilə bağlı narahatlıqlar
Sıfırdan bir monitorinq sistemi yaratarkən, orta qiymətlərə əsaslanan bir sistem inkişaf etdirmək istəyi var: orta gecikmə, qovşaqların orta CPU istifadəsi və ya orta verilənlər bazası dolğunluğu. Son iki misalın təhlükəsi göz qabağındadır: prosessorlar və verilənlər bazası çox gözlənilməz şəkildə məhv edilir. Eyni şey gecikməyə də aiddir. Əgər siz saniyədə 100 sorğu ilə orta gecikmə müddəti 1000 ms olan veb xidməti işlədirsinizsə, sorğuların 1%-i 5 saniyə çəkə bilər. İstifadəçilər bir neçə belə veb-xidmətdən asılıdırsa, bir arxa ucun 99-cu faiz dili asanlıqla frontendin median cavab müddəti ola bilər.
Yavaş orta və çox yavaş sorğular arasında fərq qoymağın ən sadə yolu faktiki gecikmələr deyil, statistikada ifadə olunan sorğuların ölçülərini toplamaqdır (göstərmək üçün yaxşı vasitə histoqramlardır): xidmət 0 ms arasında vaxt aparan neçə sorğuya xidmət etdi və 10 ms, 10 ms ilə 30 ms arasında, 30 ms ilə 100 ms arasında, 100 ms ilə 300 ms arasında və s. sorğuların.
Ölçmələr üçün müvafiq detal səviyyəsinin seçilməsi
Sistemin müxtəlif elementləri müxtəlif detal səviyyələrində ölçülməlidir. Misal üçün:
- Müəyyən müddət ərzində CPU istifadəsinin monitorinqi yüksək gecikmələrə səbəb olan uzunmüddətli sıçrayışları göstərməyəcək.
- Digər tərəfdən, ildə 9 saatdan çox olmayan fasilələri (99,9% illik iş vaxtı) hədəfləyən veb xidməti üçün dəqiqədə bir və ya iki dəfədən çox HTTP 200 cavabının yoxlanılması çox güman ki, lazımsız yerə tez-tez baş verir.
- Eyni şəkildə, hər 99,9-1 dəqiqədə bir dəfədən çox 2% əlçatanlıq üçün sabit disk yerini yoxlamaq, yəqin ki, lazım deyil.
Ölçmələrinizin dənəvərliyini necə tərtib etdiyinizə diqqət yetirin. CPU yükünün saniyədə bir dəfə toplanması maraqlı məlumatlar təmin edə bilər, lakin belə tez-tez ölçmələr toplamaq, saxlamaq və təhlil etmək çox bahalı ola bilər. Əgər monitorinq məqsədiniz yüksək detallılıq tələb edirsə və yüksək həssaslıq tələb etmirsə, siz serverdə ölçülər toplusunu qurmaqla və sonra həmin ölçüləri toplamaq və birləşdirmək üçün xarici sistem qurmaqla bu xərcləri azalda bilərsiniz. Siz edə bilərsiniz:
- Hər saniyə CPU yükünü ölçün.
- Detalları 5%-ə qədər azaldın.
- Hər dəqiqə ölçüləri ümumiləşdirin.
Bu strategiya sizə yüksək təhlil və saxlama xərcləri tələb etmədən yüksək zəriflikdə məlumat toplamağa imkan verəcək.
Mümkün qədər sadə, lakin daha sadə deyil
Müxtəlif tələblərin bir-birinin üzərinə qoyulması çox mürəkkəb monitorinq sistemi ilə nəticələnə bilər. Məsələn, sisteminizdə aşağıdakı mürəkkəb elementlər ola bilər:
- Müxtəlif göstəricilərin bütün növləri üçün müxtəlif faizlərdə sorğunun emal gecikməsi üçün müxtəlif hədlərə uyğun xəbərdarlıqlar.
- Mümkün səbəbləri aşkar etmək və müəyyən etmək üçün əlavə kodun yazılması.
- Problemlərin mümkün səbəblərinin hər biri üçün əlaqəli tablolar yaradın.
Potensial fəsadların mənbələri heç vaxt bitmir. Bütün proqram sistemləri kimi, monitorinq o qədər mürəkkəb ola bilər ki, kövrək olur və dəyişdirilməsi və saxlanması çətinləşir.
Buna görə də, monitorinq sisteminizi mümkün qədər sadələşdirmək üçün dizayn edin. Nə izləyəcəyinizi seçərkən aşağıdakıları nəzərə alın:
- Ən tez-tez real hadisələri tutan qaydalar mümkün qədər sadə, proqnozlaşdırıla bilən və etibarlı olmalıdır.
- Nadir hallarda həyata keçirilən məlumatların toplanması, yığılması və xəbərdarlıq üçün konfiqurasiya (məsələn, bəzi SRE komandaları üçün rübdən az) silinməlidir.
- Toplanmış, lakin heç bir önizləmə panelində göstərilməyən və ya hər hansı xəbərdarlıq tərəfindən istifadə edilən göstəricilər silinməyə namizəddir.
Google-da əsas ölçülərin toplanması və yığılması, xəbərdarlıqlar və idarə panelləri ilə birlikdə nisbətən müstəqil sistem kimi yaxşı işləyir (Google-un monitorinq sistemi əslində bir neçə alt sistemə bölünür, lakin insanlar adətən bu alt sistemlərin bütün aspektlərindən xəbərdardırlar). Mürəkkəb sistemlərin tədqiqi üçün monitorinqi digər üsullarla birləşdirmək cazibədar ola bilər: sistemin təfərrüatlı profili, prosesin sazlanması, istisnalar və ya uğursuzluqlar haqqında təfərrüatların izlənilməsi, yük testi, jurnalların toplanması və təhlili və ya trafikin yoxlanılması. Bunların əksəriyyətinin əsas monitorinqlə ümumi cəhətləri olsa da, onları qarışdırmaq həddən artıq çox nəticə ilə nəticələnəcək və mürəkkəb və kövrək sistem yaradacaq. Proqram təminatının inkişafının bir çox digər aspektlərində olduğu kimi, aydın, sadə, sərbəst birləşdirilən inteqrasiya nöqtələri ilə müxtəlif sistemləri dəstəkləmək ən yaxşı strategiyadır (məsələn, uzun müddət ərzində ardıcıl qala bilən formatda ümumiləşdirilmiş məlumatları əldə etmək üçün veb API-dən istifadə etmək) ).
Prinsipləri Birlikdə Bağlamaq
Bu fəsildə müzakirə edilən prinsiplər Google SRE komandaları tərəfindən təsdiqlənən və onlara əməl edilən monitorinq və xəbərdarlıq fəlsəfəsinə birləşdirilə bilər. Bu monitorinq fəlsəfəsinə riayət etmək arzuolunandır, xəbərdarlıq metodologiyanızı yaratmaq və ya ona yenidən baxmaq üçün yaxşı başlanğıc nöqtəsidir və təşkilatınızın ölçüsündən və ya xidmətin və ya sistemin mürəkkəbliyindən asılı olmayaraq, əməliyyat funksiyalarınızla bağlı düzgün sualları verməyə kömək edə bilər.
Monitorinq və xəbərdarlıq qaydaları yaratarkən aşağıdakı sualları vermək yalan pozitivlərdən və lazımsız xəbərdarlıqlardan qaçmağa kömək edə bilər:
- Bu qayda təcili, hərəkətə çağıran və qaçılmaz olaraq istifadəçiyə təsir edən sistemin başqa cür aşkar edilməyən vəziyyətini aşkar edirmi?
- Mən bu xəbərdarlığın xeyirxah olduğunu bilə-bilə qulaqardına vura bilərəmmi? Nə vaxt və niyə bu xəbərdarlığa məhəl qoymamaq olar və bu ssenaridən necə qaça bilərəm?
- Bu xəbərdarlıq istifadəçilərin mənfi təsirə məruz qalması deməkdirmi? Trafik filtrasiyası və ya xəbərdarlıqların süzülməli olduğu test sistemlərindən istifadə zamanı istifadəçilərin mənfi təsirə məruz qalmadığı hallar varmı?
- Bu xəbərdarlığa cavab olaraq tədbir görə bilərəmmi? Bu tədbirlər təcilidir, yoxsa səhərə qədər gözləmək olar? Fəaliyyət təhlükəsiz şəkildə avtomatlaşdırıla bilərmi? Bu hərəkət uzunmüddətli bir həll olacaq, yoxsa qısamüddətli həll yolu?
- Bəzi insanlar bu problemlə bağlı bir neçə xəbərdarlıq alır, beləliklə, xəbərdarlıqların sayını azaltmağın bir yolu varmı?
Bu suallar siqnallar və xəbərdarlıq sistemləri ilə bağlı əsas fəlsəfəni əks etdirir:
- Hər dəfə xəbərdarlıq gələndə dərhal reaksiya verməliyəm. Yorulmadan gündə bir neçə dəfə təcili reaksiya verə bilərəm.
- Hər bir xəbərdarlıq müvafiq olmalıdır.
- Xəbərdarlığa verilən hər bir cavab insan müdaxiləsini tələb etməlidir. Bildiriş avtomatik işlənilə bilərsə, o, gəlməməlidir.
- Xəbərdarlıqlar əvvəllər mövcud olmayan yeni problem və ya hadisə haqqında olmalıdır.
Bu yanaşma müəyyən fərqləri gizlədir: əgər xəbərdarlıq əvvəlki dörd şərtə cavab verirsə, xəbərdarlığın White-box və ya Black-Box monitorinq sistemindən göndərilməsinin fərqi yoxdur. Bu yanaşma müəyyən fərqləri də gücləndirir: səbəblərdən çox, simptomları müəyyən etməyə daha çox səy sərf etmək daha yaxşıdır; səbəblərə gəldikdə, yalnız qaçılmaz səbəblərdən narahat olmaq lazımdır.
Uzunmüddətli monitorinq
Bugünkü məhsuldarlıq mühitlərində monitorinq sistemləri dəyişən proqram arxitekturası, iş yükü xüsusiyyətləri və performans hədəfləri ilə daim inkişaf edən istehsal sistemini izləyir. Hal-hazırda avtomatlaşdırılması çətin olan xəbərdarlıqlar adi hala çevrilə bilər, hətta müraciət etməyə dəyər. Bu məqamda kimsə problemin əsas səbəblərini tapıb aradan qaldırmalıdır; belə bir həll mümkün deyilsə, siqnala cavab tam avtomatlaşdırma tələb edir.
Monitorinq qərarlarının uzunmüddətli məqsədləri nəzərə alaraq qəbul edilməsi vacibdir. Bu gün işləyən hər bir xəbərdarlıq insanı sabah sistemi təkmilləşdirməkdən yayındırır, buna görə də uzunmüddətli perspektivdə monitorinq sistemini təkmilləşdirmək üçün lazım olan vaxt üçün məhsuldar sistemin mövcudluğu və ya performansında azalma olur. Bu fenomeni göstərmək üçün iki nümunəyə baxaq.
Bigtable SRE: Həddindən artıq həyəcan nağılı
Google-un daxili infrastrukturu adətən xidmət səviyyəsi (SLO) ilə təmin edilir və ölçülür. Uzun illər əvvəl Bigtable-ın SLO xidməti canlı müştərini simulyasiya edən sintetik əməliyyatın orta performansına əsaslanırdı. Bigtable-dəki problemlər və yaddaş yığınının daha aşağı səviyyələri səbəbindən orta performans "böyük" quyruq tərəfindən idarə olunurdu: sorğuların ən pis 5%-i əksər hallarda qalanlardan əhəmiyyətli dərəcədə yavaş idi.
SLO həddinə yaxınlaşdıqca e-poçt bildirişləri, SLO həddi keçdikdə isə messencer xəbərdarlıqları göndərildi. Hər iki xəbərdarlıq növü olduqca tez-tez göndərilirdi, bu da qəbuledilməz miqdarda mühəndislik vaxtı sərf edirdi: komanda həqiqətən aktual olan bir neçəsini tapmaq üçün xəbərdarlıqları çeşidləməyə xeyli vaxt sərf etdi. Biz tez-tez istifadəçilərə faktiki təsir edən problemi qaçırırdıq, çünki xəbərdarlıqların yalnız bəziləri həmin problemlə bağlı idi. Xəbərdarlıqların bir çoxu infrastrukturda anlaşılan problemlərə görə təcili deyildi və standart şəkildə işlənib və ya ümumiyyətlə işlənməyib.
Vəziyyəti düzəltmək üçün komanda üç istiqamətli bir yanaşma tətbiq etdi: Bigtable-ın performansını yaxşılaşdırmaq üçün çox çalışarkən, biz müvəqqəti olaraq SLO hədəfimizi sorğuya cavab gecikməsi üçün 75-ci faiz olaraq təyin etdik. E-poçt xəbərdarlıqlarını da söndürdük, çünki onların sayı o qədər çox idi ki, onların diaqnostikasına vaxt sərf etmək mümkün deyildi.
Bu strategiya bizə tənəffüs otağına daim taktiki məsələləri həll etməkdənsə, Bigtable-da və saxlama yığınının aşağı təbəqələrində uzunmüddətli problemləri həll etməyə başlamağa imkan verdi. Mühəndislər hər zaman xəbərdarlıqlarla bombalanmadan işi görə bilirdilər. Nəhayət, xəbərdarlıq emalının müvəqqəti təxirə salınması bizə xidmətimizin keyfiyyətini yaxşılaşdırmağa imkan verdi.
Gmail: Proqnozlaşdırıla bilən, Alqoritmik İnsan Cavabları
Yarandığı vaxtda Gmail axtarış indeksinin proses hissələrini toplulaşdırmaq üçün nəzərdə tutulmuş dəyişdirilmiş İş Növbəsi prosesinin idarə edilməsi sistemi üzərində qurulmuşdu. İş növbəsi uzunmüddətli proseslərə uyğunlaşdırıldı və sonradan Gmail-ə tətbiq olundu, lakin qeyri-şəffaf planlaşdırıcı kodundakı bəzi səhvləri düzəltmək çox çətin oldu.
O zaman Gmail monitorinqi elə qurulmuşdu ki, Workqueue istifadə edərək fərdi tapşırıqlar ləğv edildikdə xəbərdarlıqlar işə salınsın. Bu yanaşma ideal deyildi, çünki hətta o dövrdə Gmail minlərlə tapşırıq yerinə yetirirdi, onların hər biri istifadəçilərimizin faizinin bir hissəsinə verilirdi. Biz Gmail istifadəçilərini yaxşı istifadəçi təcrübəsi ilə təmin etməkdən çox narahat idik, lakin bu qədər xəbərdarlıqları idarə etmək mümkün deyildi.
Bu problemi həll etmək üçün Gmail SRE, istifadəçilərə təsirini minimuma endirmək üçün planlaşdırıcının mümkün qədər yaxşı şəkildə sazlanmasına kömək edən alət yaratdı. Komanda uzunmüddətli həll yolu tapılana qədər problemin aşkarlanmasından düzəltməyə qədər bütün dövrü sadəcə avtomatlaşdırıb-avtomatlaşdırmaqla bağlı bəzi müzakirələr apardı, lakin bəziləri belə bir həllin problemin əslində həllini gecikdirəcəyindən narahat idilər.
Bu gərginlik komandada adi hal idi və tez-tez öz intizamına inamsızlığı əks etdirirdi: bəzi komanda üzvləri düzgün düzəliş üçün vaxt vermək istəsələr də, digərləri son düzəlişin unudulacağından və müvəqqəti düzəlişin əbədi olacağından narahatdırlar. Bu məsələ diqqətə layiqdir, çünki vəziyyəti qalıcı etmək əvəzinə problemləri müvəqqəti həll etmək çox asandır. Menecerlər və texniki heyət uzunmüddətli düzəlişlərin həyata keçirilməsində, hətta ilkin “ağrı” azaldıqdan sonra da potensial uzunmüddətli düzəlişlərin dəstəklənməsi və prioritetləşdirilməsində əsas rol oynayır.
Daimi, təkrarlanan xəbərdarlıqlar və alqoritmik cavablar qırmızı bayraq olmalıdır. Komandanızın bu xəbərdarlıqları avtomatlaşdırmaq istəməməsi komandanın alqoritmlərə etibar edə biləcəyinə inamının olmaması deməkdir. Bu həll edilməli olan ciddi problemdir.
Uzun müddətli
Ümumi mövzu Bigtable və Gmail nümunələrini əlaqələndirir: qısamüddətli və uzunmüddətli mövcudluq arasındakı rəqabət. Çox vaxt güclü səy kövrək sistemə yüksək əlçatanlığa nail olmağa kömək edə bilər, lakin bu yol adətən qısa müddətli olur, komandanın tükənməsi və həmin qəhrəman komandanın az sayda üzvündən asılılıqla dolu olur.
Nəzarət olunan, əlçatanlığın qısa müddətli azalması çox vaxt ağrılıdır, lakin sistemin uzunmüddətli sabitliyi üçün strateji əhəmiyyət kəsb edir. Hər bir xəbərdarlığa təcrid olunmuş şəkildə baxmaq yox, ümumi siqnal həcminin sağlam, düzgün əlçatan bir sistemə və həyat qabiliyyətli komandaya və əlverişli proqnoza gətirib çıxarıb-aparmadığını nəzərə almaq vacibdir. Rəhbərliyə rüblük hesabatlarda xəbərdarlıq tezliyi statistikasını (adətən bir növbə üzrə insidentlər kimi ifadə edilir, burada insident bir neçə əlaqəli insidentdən ibarət ola bilər) təhlil edirik ki, bu da qərar qəbul edənlərə xəbərdarlıq sisteminin yükü və ümumi komandanın sağlamlığı ilə bağlı daimi fikir əldə etməyə imkan verir.
Nəticə
Sağlam monitorinq və xəbərdarlıq yolu sadə və aydındır. O, xəbərdarlıqları tetikleyen problemin simptomlarına diqqət yetirir və səbəbin monitorinqi problemlərin aradan qaldırılmasına kömək edir. Nəzarət etdiyiniz yığında daha yüksək olsanız, monitorinq simptomları daha asandır, baxmayaraq ki, verilənlər bazası yükünün və performansının monitorinqi birbaşa verilənlər bazasının özündə aparılmalıdır. E-poçt bildirişləri çox məhdud faydalılığa malikdir və asanlıqla səs-küyə çevrilir; Bunun əvəzinə, e-poçt xəbərdarlıqlarını işə salan bütün cari məsələləri izləyən tablosundan istifadə etməlisiniz. İdarə paneli tarixi korrelyasiyaları təhlil etmək üçün hadisə jurnalı ilə də birləşdirilə bilər.
Uzunmüddətli perspektivdə, monitorinqin sürətli diaqnozu dəstəkləməsini təmin etmək üçün məqsədləri uyğunlaşdıraraq, simptomlar və gözlənilən real problemlər haqqında xəbərdarlıqların uğurlu dövriyyəsinə nail olmaq lazımdır.
Tərcüməni sona qədər oxuduğunuz üçün təşəkkür edirik. Monitorinq haqqında telegram kanalıma abunə olun и .
Mənbə: www.habr.com