🥇Monitorinq ölüb? — Yaşasın monitorinq

2008-ci ildən şirkətimiz əsasən infrastrukturun idarə edilməsi və veb-layihələr üçün gecə-gündüz texniki dəstək ilə məşğuldur: bizim 400-dən çox müştərimiz var ki, bu da Rusiya e-ticarətinin təxminən 15%-ni təşkil edir. Buna görə çox müxtəlif bir arxitektura dəstəklənir. Bir şey düşsə, 15 dəqiqə ərzində onu düzəltməyə borcluyuq. Ancaq qəzanın baş verdiyini başa düşmək üçün layihəni izləmək və hadisələrə reaksiya vermək lazımdır. Bunu necə etmək olar?

Hesab edirəm ki, düzgün monitorinq sisteminin təşkilində problem var. Əgər problem olmasaydı, mənim çıxışım bir tezisdən ibarət olardı: “Prometheus + Grafana və 1, 2, 3 plaginlərini quraşdırın.” Təəssüf ki, bu, artıq belə işləmir. Və əsas problem odur ki, hər kəs proqram komponentləri baxımından 2008-ci ildə mövcud olan bir şeyə inanmağa davam edir.

Monitorinq sisteminin təşkilinə gəlincə, mən cəsarətlə deyərdim ki... səlahiyyətli monitorinqi olan layihələr mövcud deyil. Və vəziyyət o qədər pisdir ki, bir şey yıxılsa, onun diqqətdən kənarda qalma riski var - axırda hamı "hər şeyə nəzarət edildiyinə" əmindir.
Ola bilsin ki, hər şey izlənilir. Bəs necə?

Hamımız aşağıdakı kimi bir hekayə ilə qarşılaşdıq: müəyyən devops, müəyyən bir admin işləyir, bir inkişaf qrupu onlara gəlir və deyir - "azad olunduq, indi nəzarət edin". Nə monitorinq? Bu necə işləyir?

TAMAM. Biz köhnə üsulla izləyirik. Və o, artıq dəyişir və məlum olur ki, siz C xidməti ilə qarşılıqlı əlaqədə olan B xidmətinə çevrilən A xidmətinə nəzarət edirsiniz. Amma inkişaf qrupu sizə deyir: “Proqramı quraşdırın, o, hər şeyə nəzarət etməlidir!”

Bəs nə dəyişdi? - Hər şey dəyişdi!

2008 Hər şey yaxşıdır

Bir neçə tərtibatçı, bir server, bir verilənlər bazası serveri var. Hər şey buradan gedir. Bəzi məlumatlarımız var, zabbix, Nagios, cacti quraşdırırıq. Və sonra biz CPU, disk əməliyyatı və disk sahəsi haqqında aydın xəbərdarlıqlar təyin etdik. Saytın cavab verməsini və sifarişlərin verilənlər bazasına daxil olmasını təmin etmək üçün bir neçə əl yoxlaması da edirik. Və budur - biz daha çox və ya daha az qorunuruq.

İdarəçinin o zaman monitorinqi təmin etmək üçün gördüyü işlərin həcmini müqayisə etsək, onun 98%-i avtomatik olub: monitorinqi həyata keçirən şəxs Zabbix-i necə quraşdırmağı, onu necə konfiqurasiya etməyi və xəbərdarlıqları konfiqurasiya etməyi başa düşməlidir. Və 2% - xarici yoxlamalar üçün: saytın cavab verdiyini və verilənlər bazasına sorğu göndərdiyini, yeni sifarişlərin gəldiyini.

2010 Yük artır

Axtarış motoru əlavə edərək interneti genişləndirməyə başlayırıq. Məhsul kataloqunun bütün məhsulları ehtiva etdiyinə əmin olmaq istəyirik. Və bu məhsul axtarışı işləyir. Verilənlər bazasının işləməsi, sifarişlərin verilməsi, saytın xaricdən cavab verməsi və iki serverdən cavab verməsi və başqa serverə balanslaşdırılarkən istifadəçinin saytdan qovulmaması və s. Daha çox qurum var.

Üstəlik, infrastrukturla əlaqəli qurum hələ də menecerin başında ən böyüyü olaraq qalır. Hələ də beynimdə belə bir fikir var ki, monitorinqi aparan şəxs zabbix quraşdıracaq və onu konfiqurasiya edə biləcək şəxsdir.

Lakin eyni zamanda, xarici yoxlamaların aparılması, axtarış indeksləşdirici sorğu skriptləri toplusunun yaradılması, indeksləşdirmə prosesi zamanı axtarışın dəyişdiyini yoxlamaq üçün bir sıra skriptlər, malların göndərildiyini yoxlayan skriptlər dəsti üzərində iş görünür. çatdırılma xidməti və s. və s.

Qeyd: 3 dəfə “skriptlər toplusu” yazmışam. Yəni monitorinq üçün cavabdeh olan şəxs artıq sadəcə zabbix quraşdıran deyil. Bu kodlaşdırmağa başlayan bir insandır. Amma komandanın fikrində hələ heç nə dəyişməyib.

Amma dünya dəyişir, getdikcə mürəkkəbləşir. Virtuallaşdırma təbəqəsi və bir neçə yeni sistem əlavə olunur. Bir-birləri ilə qarşılıqlı əlaqə qurmağa başlayırlar. Kim dedi ki, "mikroservislər kimi iyi gəlir?" Ancaq hər bir xidmət fərdi olaraq veb sayt kimi görünür. Biz ona müraciət edib başa düşə bilərik ki, o, lazımi məlumatları verir və öz-özünə işləyir. Və əgər siz 5-7-10 ildir inkişaf edən layihədə daim iştirak edən idarəçisinizsə, bu biliklər yığılır: yeni səviyyə yaranır – siz onu dərk etdiniz, başqa səviyyə yaranır – siz bunu dərk etdiniz...

Amma nadir hallarda kimsə bir layihəni 10 il müşayiət edir.

Monitorinqçinin CV

Tutaq ki, siz dərhal 20 tərtibatçı işə götürən, 15 mikroservis yazan yeni bir başlanğıca gəldiniz və sizə deyilir: “CI/CD qurun. Xahiş edirəm." Siz CI/CD qurmusunuz və birdən eşidirsiniz: “Tətbiqin orada necə işləyəcəyini anlamadan “kub”da istehsalla işləmək bizim üçün çətindir. Bizi eyni "kubda" qum qutusu edin.
Bu kubda qum qutusu düzəldirsiniz. Dərhal sizə deyirlər: "Biz istehsaldan hər gün yenilənən bir səhnə məlumat bazası istəyirik ki, onun verilənlər bazasında işlədiyini başa düşək, eyni zamanda istehsal məlumat bazasını korlamasın."

Sən bütün bunların içində yaşayırsan. Buraxılışına 2 həftə qalıb, sizə deyirlər: “İndi bütün bunlara nəzarət edək...” Yəni. klaster infrastrukturunun monitorinqi, mikroservis arxitekturasının monitorinqi, xarici xidmətlərlə işin monitorinqi...

Həmkarlarım isə adi sxemi başlarından çıxarıb deyirlər: “Yaxşı, burada hər şey aydındır! Bütün bunlara nəzarət edəcək proqram quraşdırın”. Bəli, bəli: Prometheus + Grafana + plaginləri.
Və əlavə edirlər: "İki həftəniz var, hər şeyin təhlükəsiz olduğundan əmin olun."

Gördüyümüz bir çox layihələrdə monitorinq üçün bir nəfər ayrılır. Təsəvvür edin ki, biz 2 həftə müddətinə monitorinq etmək üçün bir insanı işə götürmək istəyirik və ona CV yazırıq. İndiyə qədər dediyimiz hər şeyi nəzərə alsaq, bu insan hansı bacarıqlara malik olmalıdır?

O, dəmir infrastrukturunun işinin monitorinqini və xüsusiyyətlərini başa düşməlidir.
O, Kubernetesin monitorinqinin xüsusiyyətlərini başa düşməlidir (və hər kəs "kub"a getmək istəyir, çünki hər şeydən mücərrəd edə, gizlənə bilərsən, çünki admin qalanları ilə məşğul olacaq) - özünü, infrastrukturunu və tətbiqləri necə izləməyi başa düşməlidir. içəri.
O, xidmətlərin bir-biri ilə xüsusi üsullarla əlaqə saxladığını anlamalı və xidmətlərin bir-biri ilə qarşılıqlı əlaqəsinin xüsusiyyətlərini bilməlidir. Bəzi xidmətlərin sinxron əlaqədə olduğu bir layihəni görmək olduqca mümkündür, çünki başqa yol yoxdur. Məsələn, arxa uç REST vasitəsilə, gRPC vasitəsilə kataloq xidmətinə keçir, məhsulların siyahısını alır və onu geri qaytarır. Burada gözləyə bilməzsən. Və digər xidmətlərlə asinxron işləyir. Sifarişi çatdırılma xidmətinə köçürün, məktub göndərin və s.
Yəqin ki, siz artıq bütün bunlardan üzmüsünüz? Buna nəzarət etməli olan admin isə daha da qarışdı.
O, düzgün planlaşdırmağı və planlaşdırmağı bacarmalıdır - iş getdikcə daha çox olur.
Buna görə də o, xüsusi olaraq necə izlənəcəyini anlamaq üçün yaradılmış xidmətdən strategiya yaratmalıdır. Ona layihənin arxitekturası və onun inkişafı + inkişafda istifadə olunan texnologiyalar haqqında anlayış lazımdır.

Tamamilə normal bir vəziyyəti xatırlayaq: bəzi xidmətlər PHP-də, bəzi xidmətlər Go-da, bəzi xidmətlər JS-də. Onlar bir növ bir-biri ilə işləyirlər. “Mikroservis” termini buradan gəlir: o qədər fərdi sistemlər var ki, tərtibatçılar layihəni bütövlükdə başa düşə bilmirlər. Komandanın bir hissəsi JS-də özbaşına işləyən və sistemin qalan hissəsinin necə işlədiyini bilməyən xidmətlər yazır. Digər hissə Python-da xidmətləri yazır və digər xidmətlərin necə işləməsinə mane olmur; onlar öz ərazilərində təcrid olunurlar. Üçüncüsü, PHP və ya başqa bir şeydə xidmətlər yazmaqdır.
Bütün bu 20 nəfər 15 xidmətə bölünüb və bütün bunları anlamalı olan yalnız bir admin var. Dayan! biz sadəcə sistemi 15 mikroxidmətə böldük, çünki 20 nəfər bütün sistemi başa düşə bilmir.

Amma buna nədənsə nəzarət etmək lazımdır...

Nəticə nədir? Nəticədə, bütün tərtibatçılar qrupunun başa düşə bilmədiyi hər şeyi ortaya qoyan bir adam var və eyni zamanda o, yuxarıda qeyd etdiyimiz şeyi bilməli və edə bilməlidir - aparat infrastrukturu, Kubernetes infrastrukturu və s.

Nə deyim... Hyuston, problemlərimiz var.

Müasir proqram təminatı layihəsinin monitorinqi özlüyündə proqram layihəsidir

Monitorinqin proqram təminatı olduğuna dair yanlış inancdan biz möcüzələrə inanırıq. Ancaq möcüzələr, təəssüf ki, baş vermir. Siz zabbix quraşdıra və hər şeyin işləməsini gözləyə bilməzsiniz. Grafana quraşdırmağın və hər şeyin yaxşı olacağına ümid etməyin mənası yoxdur. Vaxtın çox hissəsi xidmətlərin işinin və onların bir-biri ilə qarşılıqlı əlaqəsinin yoxlanılmasının təşkilinə, xarici sistemlərin necə işlədiyini yoxlamağa sərf olunacaq. Əslində, vaxtın 90%-i skriptlərin yazılmasına deyil, proqram təminatının hazırlanmasına sərf olunacaq. Və bu layihənin işini başa düşən komanda tərəfindən idarə olunmalıdır.
Bu vəziyyətdə bir nəfər monitorinqə atılırsa, fəlakət baş verəcək. Hansı ki, hər yerdə olur.

Məsələn, Kafka vasitəsilə bir-biri ilə əlaqə saxlayan bir neçə xidmət var. Sifariş gəldi, sifarişlə bağlı Kafkaya mesaj göndərdik. Sifariş haqqında məlumatı dinləyən və malları göndərən bir xidmət var. Sifarişlə bağlı məlumatları dinləyən və istifadəçiyə məktub göndərən xidmət var. Və sonra bir dəstə daha çox xidmət görünür və biz çaşqın olmağa başlayırıq.

Əgər siz də bunu admin və tərtibatçılara buraxılışa az vaxt qaldığı mərhələdə versəniz, şəxs bütün bu protokolu başa düşməlidir. Bunlar. Bu miqyasda bir layihə əhəmiyyətli vaxt tələb edir və bu, sistemin inkişafında nəzərə alınmalıdır.
Ancaq çox vaxt, xüsusən də startaplarda monitorinqin sonraya qədər necə təxirə salındığını görürük. “İndi biz Konsepsiya sübutunu hazırlayacağıq, onunla işə başlayacağıq, yıxılsın - qurban verməyə hazırıq. Sonra biz bütün bunlara nəzarət edəcəyik”. Layihə pul qazanmağa başlayanda (və ya əgər) biznes daha çox funksiya əlavə etmək istəyir - çünki işə başlamışdır, ona görə də onu daha da yaymaq lazımdır! Və siz elə bir nöqtədəsiniz ki, əvvəlcə əvvəlki hər şeyi izləməlisiniz, bu da vaxtın 1%-ni deyil, daha çoxunu tələb edir. Yeri gəlmişkən, monitorinq üçün tərtibatçılara ehtiyac duyulacaq və onlara yeni funksiyalar üzərində işləməyə icazə vermək daha asandır. Nəticədə yeni funksiyalar yazılır, hər şey alt-üst olur və siz sonsuz çıxılmaz vəziyyətə düşürsünüz.

Beləliklə, layihəni əvvəldən necə izləmək olar və monitorinq edilməli olan bir layihə əldə etsəniz, amma haradan başlayacağınızı bilmirsinizsə nə etməli?

Birincisi, planlaşdırmaq lazımdır.

Lirik yayınma: çox vaxt onlar infrastrukturun monitorinqi ilə başlayırlar. Məsələn, bizdə Kubernetes var. Prometheus-u Grafana ilə quraşdıraraq, “kub”u izləmək üçün plaginləri quraşdırmaqla başlayaq. Təkcə tərtibatçılar deyil, həm də administratorlar belə uğursuz təcrübəyə malikdirlər: “Biz bu plaqini quraşdıracağıq, lakin yəqin ki, plagin bunu necə edəcəyini bilir.” İnsanlar vacib hərəkətlərdən çox sadə və sadədən başlamağı sevirlər. Və infrastrukturun monitorinqi asandır.

Əvvəlcə nəyi və necə izləmək istədiyinizə qərar verin və sonra alət seçin, çünki başqaları sizin yerinizə düşünə bilməz. Və etməlidirlər? Digər insanlar universal bir sistem haqqında öz-özünə düşünürdülər - və ya bu plagin yazıldığında heç düşünmədilər. Və bu plaqinin 5 min istifadəçisi olması onun heç bir faydası olmadığı anlamına gəlmir. Bəlkə sən 5001-ci olacaqsan, çünki əvvəllər orada 5000 nəfər var idi.

İnfrastrukturun monitorinqinə başlasanız və proqramınızın arxa hissəsi cavab verməyi dayandırarsa, bütün istifadəçilər mobil proqramla əlaqəni itirəcək. Səhv görünəcək. Gəlib sizə “Tətbiq işləmir, burada nə edirsiniz?” deyəcəklər. - "Biz monitorinq edirik." — “Tətbiqin işləmədiyini görmürsənsə, necə nəzarət edirsən?!”

Hesab edirəm ki, monitorinqi tam olaraq istifadəçinin giriş nöqtəsindən başlamaq lazımdır. İstifadəçi proqramın işlədiyini görmürsə, bu, uğursuzluqdur. Və monitorinq sistemi ilk növbədə bu barədə xəbərdarlıq etməlidir.
Və yalnız bundan sonra biz infrastruktura nəzarət edə bilərik. Və ya paralel olaraq edin. İnfrastruktur ilə daha asandır - burada nəhayət, sadəcə zabbix quraşdıra bilərik.
İndi işlərin işləmədiyini başa düşmək üçün tətbiqin köklərinə getməlisiniz.

Əsas fikrim budur ki, monitorinq inkişaf prosesi ilə paralel getməlidir. Əgər siz monitorinq qrupunu digər tapşırıqlar üçün (CI/CD yaratmaq, sandboxing, infrastrukturun yenidən təşkili) yayındırsanız, monitorinq geridə qalmağa başlayacaq və siz heç vaxt inkişafa çata bilməyəcəksiniz (yaxud gec-tez onu dayandırmalı olacaqsınız).

Hər şey səviyyələrə görə

Mən monitorinq sisteminin təşkilini belə görürəm.

1) Tətbiq səviyyəsi:

tətbiqin iş məntiqinin monitorinqi;
xidmətlərin sağlamlıq göstəricilərinin monitorinqi;
inteqrasiya monitorinqi.

2) İnfrastruktur səviyyəsi:

orkestr səviyyəsinin monitorinqi;
sistem proqram təminatının monitorinqi;
dəmir səviyyəsinin monitorinqi.

3) Yenə tətbiq səviyyəsi - lakin mühəndislik məhsulu olaraq:

tətbiq jurnallarının toplanması və monitorinqi;
APM;
izləmə.

4) Xəbərdarlıq:

xəbərdarlıq sisteminin təşkili;
vəzifə sisteminin təşkili;
hadisələrin emalı üçün “bilik bazası”nın və iş axınının təşkili.

Vacibdir: Biz xəbərdarlığa sonra deyil, dərhal çatırıq! Monitorinqi işə salmağa və “birtəhər sonra” kimin xəbərdarlıq alacağını müəyyən etməyə ehtiyac yoxdur. Axı, monitorinqin vəzifəsi nədir: sistemin harada səhv işlədiyini anlamaq və lazımi insanlara bu barədə məlumat vermək. Bunu sona qədər tərk etsəniz, düzgün insanlar yalnız "bizim üçün heç bir şey işləmir" deyə bir şeyin səhv getdiyini biləcəklər.

Tətbiq Layeri - Biznes Məntiqi Monitorinqi

Burada proqramın istifadəçi üçün işlədiyini yoxlamaqdan danışırıq.

Bu səviyyə inkişaf mərhələsində həyata keçirilməlidir. Məsələn, şərti Prometeyimiz var: o, yoxlamaları edən serverə gedir, son nöqtəni çəkir və son nöqtə gedib API-ni yoxlayır.

Tez-tez saytın işlədiyinə əmin olmaq üçün ana səhifəyə nəzarət etmək istənildikdə, proqramçılar API-nin işlədiyinə əmin olmaq üçün hər dəfə çəkilə bilən bir tutacaq verirlər. Bu anda proqramçılar hələ də /api/test/helloworld-u götürüb yazır
Hər şeyin işlədiyinə əmin olmağın yeganə yolu? - Yox!

Belə çeklərin yaradılması mahiyyətcə tərtibatçıların vəzifəsidir. Vahid testləri kodu yazan proqramçılar tərəfindən yazılmalıdır. Çünki onu idarəçiyə sızdırsanız, "Dostum, burada bütün 25 funksiya üçün API protokollarının siyahısı var, lütfən, hər şeyə nəzarət edin!" - heç nə alınmayacaq.
Əgər “salam dünya” çap etsəniz, heç kim API-nin işləməli olduğunu və işlədiyini bilməyəcək. Hər bir API dəyişikliyi çeklərin dəyişməsinə səbəb olmalıdır.
Artıq belə bir probleminiz varsa, xüsusiyyətləri dayandırın və bu çekləri yazacaq və ya itkiləri qəbul edəcək tərtibatçıları ayırın, heç bir şeyin yoxlanılmadığını və uğursuz olacağını qəbul edin.

Texniki göstərişlər:

Yoxlamaları təşkil etmək üçün xarici server təşkil etməyinizə əmin olun - layihənizin xarici dünya üçün əlçatan olduğundan əmin olmalısınız.
Yalnız fərdi son nöqtələr deyil, bütün API protokolu üzrə yoxlamaları təşkil edin.
Test nəticələri ilə prometey son nöqtəsi yaradın.

Tətbiq səviyyəsi - sağlamlıq göstəricilərinin monitorinqi

İndi biz xidmətlərin xarici sağlamlıq göstəricilərindən danışırıq.

Xarici monitorinq sistemindən çağırdığımız xarici yoxlamalardan istifadə edərək tətbiqin bütün "tutacaqlarını" izləməyi qərara aldıq. Lakin bunlar istifadəçinin “gördüyü” “tutacaqlar”dır. Xidmətlərimizin özlərinin işlədiyinə əmin olmaq istəyirik. Burada daha yaxşı bir hekayə var: K8-lərin sağlamlıq yoxlamaları var ki, heç olmasa “kub” özü xidmətin işlədiyinə əmin olsun. Amma gördüyüm çeklərin yarısı eyni çap “salam dünya”dır. Bunlar. Beləliklə, yerləşdirmədən sonra bir dəfə çəkir, cavab verdi ki, hər şey yaxşıdır - hamısı budur. Və xidmət, əgər öz API təmin edirsə, eyni API üçün çoxlu sayda giriş nöqtələrinə malikdir, buna da nəzarət edilməlidir, çünki onun işlədiyini bilmək istəyirik. Biz isə artıq daxildə buna nəzarət edirik.

Bunu texniki cəhətdən düzgün şəkildə necə həyata keçirmək olar: hər bir xidmət cari performansı ilə bağlı son nöqtəni ortaya qoyur və Grafana (və ya hər hansı digər tətbiq) qrafiklərində biz bütün xidmətlərin vəziyyətini görürük.

Hər bir API dəyişikliyi çeklərin dəyişməsinə səbəb olmalıdır.
Sağlamlıq göstəriciləri ilə dərhal yeni xidmət yaradın.
Bir admin tərtibatçıların yanına gələrək “Mənə bir neçə xüsusiyyət əlavə et ki, hər şeyi başa düşüm və bu barədə monitorinq sistemimə məlumat əlavə et” deyə bilər. Lakin tərtibatçılar adətən “Çıxışdan iki həftə əvvəl heç nə əlavə etməyəcəyik” cavabını verirlər.
İnkişaf menecerləri bilsinlər ki, belə itkilər olacaq, inkişaf menecerlərinin rəhbərliyi də bilsin. Çünki hər şey düşəndə kimsə yenə də zəng edib “daim düşən xidmətə” nəzarət etməyi tələb edəcək (c)
Yeri gəlmişkən, tərtibatçıları Grafana üçün plaginlər yazmaq üçün ayırın - bu adminlər üçün yaxşı kömək olacaq.

Tətbiq Layeri - İnteqrasiya Monitorinqi

İnteqrasiya monitorinqi kritik biznes sistemləri arasında kommunikasiyaların monitorinqinə diqqət yetirir.

Məsələn, bir-biri ilə əlaqə saxlayan 15 xidmət var. Bunlar artıq ayrı saytlar deyil. Bunlar. xidməti öz başına çəkə bilmərik, /helloworld əldə edə və xidmətin işlədiyini başa düşə bilmərik. Çünki sifariş verən internet xidməti sifariş haqqında məlumatı avtobusa - avtobusdan göndərməlidir, anbar xidməti bu mesajı almalı və onunla daha da işləməlidir. Və e-poçt paylama xidməti bunu bir şəkildə daha da emal etməlidir və s.

Müvafiq olaraq, biz hər bir fərdi xidmətə baxaraq, bunların hamısının işlədiyini başa düşə bilmərik. Çünki bizim müəyyən bir avtobusumuz var ki, onun vasitəsilə hər şey əlaqə saxlayır və qarşılıqlı əlaqə yaradır.
Buna görə də, bu mərhələ digər xidmətlərlə qarşılıqlı əlaqə üçün xidmətlərin sınaqdan keçirilməsi mərhələsini qeyd etməlidir. Mesaj brokerinə nəzarət etməklə rabitə monitorinqini təşkil etmək mümkün deyil. Məlumat verən bir xidmət və onu qəbul edən xidmət varsa, brokeri izləyərkən biz yalnız yan-yana uçan məlumatları görəcəyik. Bu məlumatların qarşılıqlı əlaqəsini birtəhər izləyə bilsək belə - müəyyən bir istehsalçı məlumatları yerləşdirir, kimsə onu oxuyur, bu axın Kafkaya getməyə davam edir - bir xidmət mesajı bir versiyada göndərirsə, bu yenə də bizə məlumat verməyəcək. , lakin digər xidmət bu versiyanı gözləmirdi və onu atladı. Biz bu barədə bilməyəcəyik, çünki xidmətlər bizə hər şeyin işlədiyini söyləyəcək.

Nə etməyi tövsiyə edirəm:

Sinxron rabitə üçün: son nöqtə əlaqəli xidmətlərə sorğular göndərir. Bunlar. biz bu son nöqtəni götürürük, bütün nöqtələrə gedən və "Mən ora çəkə bilərəm və ora çəkə bilərəm, ora çəkə bilərəm ..." deyən xidmətin içindəki bir skript çəkirik.
Asinxron rabitə üçün: daxil olan mesajlar - son nöqtə test mesajları üçün avtobusu yoxlayır və emal vəziyyətini göstərir.
Asinxron rabitə üçün: gedən mesajlar - son nöqtə test mesajlarını avtobusa göndərir.

Adətən olduğu kimi: məlumatı avtobusa atan bir xidmətimiz var. Biz bu xidmətə gəlirik və onun inteqrasiya sağlamlığı haqqında bizə məlumat verməyinizi xahiş edirik. Və əgər xidmət daha bir yerdə (WebApp) bir mesaj istehsal etməlidirsə, o zaman bu test mesajını verəcəkdir. Və əgər biz Sifariş Processing tərəfində bir xidmət işlədiriksə, o, əvvəlcə müstəqil olaraq nə yerləşdirə biləcəyini yazır və əgər bəzi asılı şeylər varsa, o, avtobusdan bir sıra test mesajlarını oxuyur, onları emal edə, hesabat verə biləcəyini başa düşür və , lazım gələrsə, onları daha da yerləşdirin və bu barədə deyir - hər şey qaydasındadır, mən sağam.

Çox vaxt "bunu döyüş məlumatlarında necə sınaqdan keçirə bilərik?" Sualını eşidirik. Məsələn, eyni sifariş xidmətindən danışırıq. Sifariş malların silindiyi anbara mesajlar göndərir: biz bunu döyüş məlumatlarında sınaqdan keçirə bilmərik, çünki "mallarım silinəcək!" Həll yolu: Bütün bu testi əvvəldən planlaşdırın. Siz həmçinin istehza edən vahid testləriniz var. Beləliklə, biznesin fəaliyyətinə zərər verməyən bir əlaqə kanalınızın olduğu daha dərin bir səviyyədə edin.

İnfrastruktur səviyyəsi

İnfrastrukturun monitorinqi çoxdan özünün monitorinqi hesab edilən bir şeydir.

İnfrastrukturun monitorinqi ayrıca proses kimi işə salına bilər və edilməlidir.
Həqiqətən istəsəniz belə, işləyən bir layihədə infrastruktur monitorinqi ilə başlamamalısınız. Bu, bütün devoplar üçün bir ağrıdır. “Əvvəlcə mən klasterə nəzarət edəcəm, infrastruktura nəzarət edəcəm” – yəni. Birincisi, o, aşağıda olanlara nəzarət edəcək, lakin tətbiqə daxil olmayacaq. Çünki tətbiq devoplar üçün anlaşılmaz bir şeydir. Bu ona sızdırıldı və o, bunun necə işlədiyini başa düşmür. Amma o, infrastrukturu anlayır və ondan başlayır. Ancaq yox - hər zaman əvvəlcə tətbiqi izləməlisiniz.
Xəbərdarlıqların sayı ilə həddi aşmayın. Müasir sistemlərin mürəkkəbliyini nəzərə alsaq, siqnallar daim uçur və siz bu siqnallar dəstəsi ilə birtəhər yaşamalısınız. Zəng edən şəxs isə yüzlərlə növbəti xəbərdarlığa baxaraq “Mən bu barədə düşünmək istəmirəm” deyə qərar verəcək. Xəbərdarlıqlar yalnız kritik şeylər barədə məlumat verməlidir.

Biznes vahidi kimi tətbiq səviyyəsi

Əsas məqamlar:

ELK. Bu sənaye standartıdır. Nədənsə qeydləri birləşdirmirsinizsə, dərhal bunu etməyə başlayın.
APM. Xarici APM-lər tətbiq monitorinqini tez bir zamanda bağlamaq üçün bir yol kimi (NewRelic, BlackFire, Datadog). Heç olmasa bir şəkildə sizinlə nə baş verdiyini başa düşmək üçün bu şeyi müvəqqəti quraşdıra bilərsiniz.
İzləmə. Onlarla mikroservisdə siz hər şeyi izləməlisiniz, çünki sorğu artıq öz-özünə yaşamır. Daha sonra əlavə etmək çox çətindir, buna görə inkişafda izləməni dərhal planlaşdırmaq daha yaxşıdır - bu, tərtibatçıların işi və faydasıdır. Əgər hələ də həyata keçirməmisinizsə, həyata keçirin! Bax Jaeger/Zipkin

Xəbərdarlıq

Bildiriş sisteminin təşkili: bir dəstə şeyin monitorinqi şəraitində bildirişlərin göndərilməsi üçün vahid sistem olmalıdır. Grafana'da edə bilərsiniz. Qərbdə hamı PagerDuty-dən istifadə edir. Xəbərdarlıqlar aydın olmalıdır (məsələn, haradan gəldilər...). Bildirişlərin ümumiyyətlə qəbul edilməsinə nəzarət etmək məsləhətdir
Növbətçi sistemin təşkili: xəbərdarlıqlar hər kəsə göndərilməməlidir (ya hamı kütlə içində reaksiya verəcək, ya da heç kim reaksiya verməyəcək). Tərtibatçılar da çağırışda olmalıdırlar: məsuliyyət sahələrini müəyyənləşdirməyinizə əmin olun, aydın təlimatlar verin və orada dəqiq olaraq bazar ertəsi və çərşənbə günləri kimə, çərşənbə axşamı və cümə günləri isə kimə zəng etməli olduğunuzu yazın (əks halda onlar heç kimə zəng etməyəcəklər. böyük bir problem hadisəsi - sizi oyatmaqdan və ya narahat etməkdən qorxacaqlar: insanlar ümumiyyətlə digər insanlara zəng etməyi və oyatmağı sevmirlər, xüsusən də gecə). Və izah edin ki, kömək istəmək səriştəsizliyin göstəricisi deyil (“Mən kömək istəyirəm, bu o deməkdir ki, mən pis işçiyəm”), kömək istəmələri təşviq edin.
“Bilik bazası”nın təşkili və insidentin işlənməsi üçün iş axını: hər bir ciddi insident üçün ölümdən sonrakı əməliyyat planlaşdırılmalı və müvəqqəti tədbir kimi hadisəni həll edəcək tədbirlər qeyd edilməlidir. Və təkrar xəbərdarlıqların günah olduğunu bir təcrübə edin; onlar kod və ya infrastruktur işində düzəldilməlidir.

Texnologiya yığını

Təsəvvür edək ki, yığınımız aşağıdakı kimidir:

məlumatların toplanması - Prometheus + Grafana;
log analizi - ELK;
APM və ya İzləmə üçün - Jaeger (Zipkin).

Seçimlərin seçimi kritik deyil. Çünki başlanğıcda sistemə necə nəzarət edəcəyinizi başa düşdünüzsə və plan yazdınızsa, o zaman tələblərinizə uyğun alətlər seçməyə başlayırsınız. Sual, ilk növbədə nəyi izləmək üçün seçdiyinizdir. Çünki bəlkə də başlanğıcda seçdiyiniz alət heç sizin tələblərinizə uyğun gəlmir.

Son vaxtlar hər yerdə gördüyüm bir neçə texniki məqam:

Prometeyi Kubernetesin içinə itələyirlər - bunu kim çıxarıb?! Əgər klasteriniz çöksə, nə edəcəksiniz? Əgər sizin içərinizdə mürəkkəb klaster varsa, o zaman klasterin daxilində bir növ monitorinq sistemi, bəziləri isə xaricdə olmalıdır ki, bu da klasterin içindən məlumat toplayacaq.

Klasterin içərisində logları və başqa hər şeyi toplayırıq. Amma monitorinq sistemi kənarda olmalıdır. Çox vaxt, Promtheus-un daxili olaraq quraşdırıldığı bir klasterdə saytın işini xarici yoxlayan sistemlər də var. Xarici dünya ilə əlaqəniz kəsilibsə və proqram işləmirsə? Məlum oldu ki, içəridə hər şey qaydasındadır, lakin bu, istifadəçilər üçün işləri asanlaşdırmır.

Tapıntılar

İnkişafın monitorinqi kommunal xidmətlərin quraşdırılması deyil, proqram məhsulunun hazırlanmasıdır. Bugünkü monitorinqin 98%-i kodlaşdırmadır. Xidmətlərdə kodlaşdırma, xarici yoxlamaları kodlaşdırmaq, xarici xidmətləri yoxlamaq və hamısı budur.
Tərtibatçılarınızın vaxtını monitorinqə sərf etməyin: bu, onların işinin 30%-ni çəkə bilər, lakin buna dəyər.
Devops, bir şeyə nəzarət edə bilməyəcəyiniz üçün narahat olmayın, çünki bəzi şeylər tamamilə fərqli düşüncə tərzidir. Siz proqramçı deyildiniz və monitorinq işi məhz onların işidir.
Əgər layihə artıq işləyirsə və monitorinq edilmirsə (və siz menecersinizsə), monitorinq üçün resurslar ayırın.
Əgər məhsul artıq istehsaldadırsa və siz “monitorinq qurmaq” deyilən devopssunuzsa, bütün bunları yazdıqlarımı rəhbərliyə izah etməyə çalışın.

Bu, Saint Highload++ konfransındakı hesabatın genişləndirilmiş versiyasıdır.

Əgər mənim bu barədə fikirlərim və fikirlərim və əlaqəli mövzularla maraqlanırsınızsa, buradan edə bilərsiniz kanalı oxuyun 🙂

Mənbə: www.habr.com

Monitorinq ölüb? - Yaşasın monitorinq