Bu gün layihəmizdə monolit koddan əlavə onlarla mikroservis fəaliyyət göstərir. Onların hər biri monitorinq tələb edir. Bunu DevOps mühəndisləri tərəfindən belə həcmlərdə etmək problemlidir. Biz tərtibatçılar üçün xidmət kimi işləyən monitorinq sistemi hazırlamışıq. Onlar müstəqil olaraq monitorinq sisteminə metrikalar yaza, onlardan istifadə edə, onlara əsaslanan tablolar yarada, hədd dəyərlərinə çatdıqda onlara xəbərdarlıqlar əlavə edə bilərlər. DevOps mühəndisləri ilə - yalnız infrastruktur və sənədlər.
Bu yazı mənim çıxışımın stenoqramıdır RIT++ üzərində. Çoxları bizdən hesabatların mətn variantlarını oradan hazırlamağı xahiş etdi. Əgər siz konfransda olmusunuzsa və ya videoya baxmısınızsa, yeni heç nə tapa bilməyəcəksiniz. Və hər kəsə - pişik altında xoş gəlmisiniz. Belə bir sistemə necə gəldiyimizi, necə işlədiyini və onu necə yeniləməyi planlaşdırdığımızı sizə xəbər verəcəyəm.
Keçmiş: sxemlər və planlar
Mövcud monitorinq sisteminə necə gəldik? Bu suala cavab vermək üçün 2015-ci ilə getmək lazımdır. Budur o zaman necə görünürdü:
Monitorinq üçün cavabdeh olan təxminən 24 qovşaqımız var idi. Bir yerdə nəyisə izləyən, mesajlar göndərən, funksiyaları yerinə yetirən müxtəlif cronlar, skriptlər, demonlar var. Düşündük ki, nə qədər uzağa getsə, belə bir sistem daha az yaşaya bilər. Onu inkişaf etdirməyin mənası yoxdur: bu, çox ağırdır.
Biz tərk edəcəyimiz və inkişaf etdirəcəyimiz və tərk edəcəyimiz monitorinq elementlərini seçmək qərarına gəldik. Onlardan 19-u var idi.Yalnız qrafitlər, aqreqatorlar və idarə paneli kimi Qrafana qaldı. Bəs yeni sistem necə görünəcək? Bunun kimi:
Ölçülər anbarımız var: bunlar sürətli SSD sürücülərinə əsaslanacaq qrafitlərdir, bunlar ölçülər üçün müəyyən aqreqatorlardır. Sonrakı - tablosunu və Moiranı xəbərdarlıq olaraq göstərmək üçün Grafana. Biz həm də anomaliyaları tapmaq üçün bir sistem hazırlamaq istədik.
Standart: Monitorinq 2.0
2015-ci ildə planlar belə görünürdü. Amma biz bunun üçün təkcə infrastrukturu və xidmətin özünü deyil, həm də sənədləri hazırlamalı idik. Biz özümüz üçün monitorinq 2.0 adlandırdığımız korporativ standart hazırlamışıq. Sistem üçün tələblər nə idi?
- daimi mövcudluq;
- metrik saxlama intervalı = 10 saniyə;
- metriklərin və tablosunun strukturlaşdırılmış saxlanması;
- SLA > 99,99%
- UDP (!) vasitəsilə hadisə ölçülərinin toplanması.
Bizə UDP lazım idi, çünki bizdə çoxlu trafik və ölçülər yaradan hadisələr var. Onların hamısı bir anda qrafitdə yazılsa, anbar dağılacaq. Biz həmçinin bütün ölçülər üçün birinci səviyyəli prefiksləri seçdik.
Prefikslərin hər biri müəyyən xüsusiyyətlərə malikdir. Serverlər, şəbəkələr, konteynerlər, resurslar, proqramlar və s. üçün ölçülər var. Aydın, ciddi, tipli filtrləmə tətbiq olundu, burada biz birinci səviyyəli göstəriciləri qəbul edirik, qalanlarını isə sadəcə atırıq. Biz bu sistemi 2015-ci ildə belə planlaşdırdıq. İndiki vəziyyətdə nə var?
Təqdimat: monitorinq komponentlərinin qarşılıqlı əlaqə sxemi
İlk növbədə, biz proqramlara nəzarət edirik: PHP kodumuz, proqramlarımız və mikroservislərimiz - bir sözlə, tərtibatçılarımızın yazdıqları hər şey. Bütün proqramlar metrikləri UDP vasitəsilə Brubeck toplayıcısına göndərir (statsd, C-də yenidən yazılmışdır). Sintetik testlərin nəticələrinə görə ən sürətli olduğu ortaya çıxdı. Və artıq yığılmış ölçüləri TCP vasitəsilə Graphite-ə göndərir.
Taymerlər kimi ölçülərə malikdir. Bu çox lazımlı bir şeydir. Məsələn, hər bir istifadəçinin xidmətə qoşulması üçün siz Brubeck-ə cavab müddəti metrikasını göndərirsiniz. Bir milyon cavab gəldi və aqreqator cəmi 10 metrik verdi. Sizdə gələn insanların sayı, maksimum, minimum və orta cavab vaxtları, median və 4 faiz var. Sonra məlumatlar Graphite-ə ötürülür və biz onların hamısını canlı görürük.
Aparat, proqram təminatı, sistem ölçüləri və köhnə Munin monitorinq sistemimiz (o, 2015-ci ilə qədər bizimlə işləyirdi) üçün aqreqasiyamız da var. Bütün bunları C'ish daemon CollectD vasitəsilə toplayırıq (orada müxtəlif plaginlər tikilir, o, quraşdırıldığı host sisteminin bütün resurslarını sorğulaya bilər, sadəcə olaraq konfiqurasiyada məlumatların hara yazılacağını göstərin. ) və onun vasitəsilə məlumatları Graphite-də yazın. O, həmçinin python plaginlərini və qabıq skriptlərini dəstəkləyir, beləliklə, siz öz fərdi həllərinizi yaza bilərsiniz: CollectD bu məlumatları yerli və ya uzaq hostdan (Curl-un mövcud olduğunu nəzərə alaraq) toplayacaq və Graphite-ə göndərəcək.
Bundan əlavə, topladığımız bütün göstəricilər Carbon-c-relay-ə göndərilir. Bu, C-də dəyişdirilmiş Graphite-nin Karbon Relay həllidir. Bu, aqreqatorlarımızdan göndərdiyimiz bütün ölçüləri toplayan və onları qovşaqlar vasitəsilə istiqamətləndirən marşrutlaşdırıcıdır. Həmçinin marşrutlaşdırma mərhələsində o, ölçülərin etibarlılığını yoxlayır. Birincisi, onlar əvvəllər göstərdiyim prefiks sxeminə uyğun olmalıdırlar və ikincisi, qrafit üçün etibarlı olmalıdırlar. Əks halda, düşürlər.
Sonra Carbon-c-relay ölçüləri Qrafit klasterinə göndərir. Metriklər üçün əsas yaddaş olaraq Go-da yenidən yazılmış Carbon-cache-dən istifadə edirik. Go-carbon, çox yivliliyinə görə performans baxımından Carbon-cache-dən çox üstündür. O, məlumatları özünə götürür və pıçıltı paketindən (standart, python ilə yazılmış) istifadə edərək diskə yazır. Anbarlarımızdan məlumatları oxumaq üçün biz Graphite API-dən istifadə edirik. Standart Graphite WEB-dən daha sürətli işləyir. Sonrakı data ilə nə baş verir?
Qrafanaya gedirlər. Biz əsas məlumat mənbəyi kimi qrafit klasterlərimizdən istifadə edirik, üstəlik, ölçüləri göstərmək, idarə panelləri qurmaq üçün veb interfeysi kimi Grafanamız var. Hər bir xidmət üçün tərtibatçılar öz tablosunu yaradırlar. Sonra onlara əsaslanaraq, tətbiqlərindən yazdıqları ölçüləri göstərən qrafiklər qururlar. Grafana ilə yanaşı, bizdə SLAM da var. Bu, qrafitdən alınan məlumatlar əsasında SLA hesablayan pitonik iblisdir. Dediyim kimi, bizdə bir neçə onlarla mikroservis var, onların hər birinin öz tələbləri var. SLAM-ın köməyi ilə biz sənədlərə gedirik və onu Graphite-də olanlarla müqayisə edirik və tələblərin xidmətlərimizin mövcudluğuna necə uyğun olduğunu müqayisə edirik.
Davam etmək: xəbərdar etmək. Güclü bir sistemlə təşkil olunur - Moira. O, müstəqildir, çünki onun başlıq altında öz Qrafiti var. SKB Kontur-dan olan uşaqlar tərəfindən hazırlanıb, python və Go ilə yazılmış, tam açıq mənbədir. Moira qrafitlərə daxil olan eyni axını alır. Əgər nədənsə yaddaşınız ölürsə, xəbərdarlıqınız işləyəcək.
Biz Moira-nı Kubernetes-də yerləşdirdik, o, əsas verilənlər bazası kimi Redis serverlərinin çoxluğundan istifadə edir. Nəticə xətalara dözümlü bir sistemdir. O, ölçülərin axınını tetikleyiciler siyahısı ilə müqayisə edir: əgər orada heç bir qeyd yoxdursa, o, metrikanı azaldır. Beləliklə, o, dəqiqədə giqabayt ölçüləri həzm edə bilir.
Biz həmçinin ona korporativ LDAP əlavə etdik, onun köməyi ilə korporativ sistemin hər bir istifadəçisi mövcud (və ya yeni yaradılmış) tetikleyiciler haqqında özü üçün bildirişlər yarada bilər. Moira Qrafit ehtiva etdiyi üçün onun bütün xüsusiyyətlərini dəstəkləyir. Beləliklə, əvvəlcə xətti götürün və onu Grafana-ya köçürün. Məlumatların qrafiklərdə necə göstərildiyinə baxın. Və sonra eyni sətri götürüb Moiraya köçürürsən. Limitlərlə asın və çıxışda xəbərdarlıq alın. Bütün bunları etmək üçün heç bir xüsusi biliyə ehtiyacınız yoxdur. Moira SMS, e-poçt, Jira, Slack vasitəsilə xəbərdarlıq edə bilər... O, həmçinin xüsusi skriptləri dəstəkləyir. Onun tetikleyicisi olduqda və o, fərdi skriptə və ya binar-a abunə olduqda, onu işə salır və bu JSON binarını stdin-ə göndərir. Müvafiq olaraq, proqramınız onu təhlil etməlidir. Bu JSON ilə nə edəcəyiniz sizə bağlıdır. İstəyirsinizsə Telegrama göndərin, istəsəniz Jirada tapşırıqlar açın, istədiyinizi edin.
Biz həmçinin xəbərdarlıq üçün öz inkişafımızdan istifadə edirik - Imagotag. Adətən mağazalarda elektron qiymət etiketləri üçün istifadə olunan paneli ehtiyaclarımıza uyğunlaşdırdıq. Biz ona Moiradan tətiklər gətirdik. Onların hansı vəziyyətdə olduğunu, nə vaxt baş verdiyini göstərir. İnkişafdan olan bəzi uşaqlar bu panelin lehinə Slack-də və poçtda bildirişləri tərk etdilər.
Yaxşı, mütərəqqi bir şirkət olduğumuz üçün bu sistemdə Kubernetes-i də izlədik. Onu klasterdə quraşdırdığımız Heapster-dən istifadə edərək sistemə daxil etdik, məlumatları toplayır və Graphite-ə göndərir. Nəticədə sxem belə görünür:
Monitorinq komponentləri
Budur, bu tapşırıq üçün istifadə etdiyimiz komponentlərə keçidlərin siyahısı. Onların hamısı açıq mənbədir.
Qrafit:
- karbon getmək:
- pıçıldamaq:
- qrafit-api:
Karbon-c-rele:
Brubek:
Toplanmış:
Moira:
Qrafana:
yığın:
statistika
Və burada sistemin bizim üçün necə işlədiyinə dair bəzi rəqəmlər var.
Aqreqator (brubeck)
Ölçülərin sayı: ~ 300/san
Qrafit Ölçüləri Göndərmə Aralığı: 30 san
Server resursundan istifadə: ~ 6% CPU (söhbət tam hüquqlu serverlərdən gedir); ~ 1Gb RAM; ~ 3 Mbps LAN
Qrafit (karbon)
Ölçülərin sayı: ~ 1 / dəq
Metrik yeniləmə intervalı: 30 san
Metriklərin saxlanma sxemi: 30san 35d, 5dəq 90d, 10dəq 365d (uzun müddət ərzində xidmətdə nə baş verdiyini başa düşmək imkanı verir)
Server resursundan istifadə: ~10% CPU; ~ 20Gb RAM; ~ 30 Mbps LAN
Esneklik
Biz Avitoda monitorinq xidmətimizdəki çevikliyi həqiqətən yüksək qiymətləndiririk. Niyə həqiqətən belə çıxdı? Birincisi, onun tərkib hissələri bir-birini əvəz edir: həm komponentlərin özləri, həm də onların versiyaları. İkincisi, davamlılıq. Bütün layihə açıq mənbə üzərində qurulduğundan, kodu özünüz redaktə edə, dəyişikliklər edə və qutudan kənarda mövcud olmayan funksiyaları həyata keçirə bilərsiniz. Olduqca ümumi yığınlardan istifadə olunur, əsasən Go və Python, buna görə də bu olduqca sadə şəkildə edilir.
Budur əsl problemin nümunəsi. Graphite-də metrik bir fayldır. Bir adı var. Fayl adı = metrik adı. Və ora çatmağın bir yolu var. Linux-da fayl adları 255 simvolla məhdudlaşır. Və verilənlər bazası departamentindən ("daxili müştərilər" kimi) oğlanlarımız var. Onlar bizə deyirlər: “Biz SQL sorğularımızı izləmək istəyirik. Və onlar 255 simvol deyil, hər biri 8 MB-dır. Biz onları Grafana-da göstərmək, bu sorğunun parametrlərinə baxmaq və daha da yaxşısı, belə sorğuların yuxarı hissəsini görmək istəyirik. Real vaxtda göstərilsə əla olar. Onları xəbərdarlığa sövq etmək çox gözəl olardı”.
SQL sorğu nümunəsi nümunə kimi götürülür
Redis serverini və Postgres-ə gedən və bütün məlumatları oradan götürən, Graphite-ə ölçüləri göndərən Toplanmış plaginlərimizi qaldırırıq. Amma biz metrikanın adını hashlərlə əvəz edirik. Eyni hash eyni vaxtda Redis-ə açar kimi, bütün SQL sorğusu isə dəyər kimi göndərilir. Qrafananın Redis-ə getməsini və bu məlumatı götürməsini təmin etmək bizim üçün qalır. Graphite API-ni açırıq, çünki bu, bütün monitorinq komponentlərinin qrafitlə qarşılıqlı əlaqəsi üçün əsas interfeysdir və biz orada aliasByHash () adlı yeni funksiya daxil edirik - biz Grafana-dan metrikanın adını alırıq və onu Redis-ə sorğuda açar kimi istifadə edirik. cavab olaraq biz “SQL sorğumuz” olan açarın dəyərini alırıq. Beləliklə, biz Grafanaya nəzəri olaraq orada göstərilə bilməyən SQL sorğusunun displeyini onun üzərindəki statistik göstəricilərlə (zənglər, sıralar, ümumi_vaxt, ...) gətirdik.
Nəticələri
Mövcudluq Monitorinq xidmətimiz istənilən proqramdan və istənilən koddan 24/7 mövcuddur. Yaddaşlara girişiniz varsa, xidmətə məlumat yaza bilərsiniz. Dil önəmli deyil, qərarlar önəmli deyil. Yalnız bir rozetkanı necə açacağınızı, orada bir metri atacağınızı və yuvanı necə bağlayacağınızı bilmək lazımdır.
Etibarlılıq. Bütün komponentlər nasazlığa dözümlüdür və iş yüklərimizi yaxşı idarə edir.
Aşağı giriş həddi. Bu sistemdən istifadə etmək üçün Grafana-da proqramlaşdırma dillərini və sorğuları öyrənməyə ehtiyac yoxdur. Sadəcə tətbiqinizi açın, ona ölçüləri Graphite-ə göndərəcək bir yuva əlavə edin, bağlayın, Grafana-nı açın, orada tablolar yaradın və Moira vasitəsilə bildirişlər alaraq ölçülərinizin davranışına baxın.
Müstəqillik. Bütün bunları DevOps mühəndislərinin köməyi olmadan özünüz edə bilərsiniz. Və bu həddindən artıq xüsusiyyətdir, çünki siz layihənizi indi izləyə bilərsiniz, heç kimdən soruşmaq lazım deyil - nə işə başlamaq, nə də dəyişiklik etmək.
Biz nəyə çalışırıq?
Aşağıda sadalananların hamısı sadəcə mücərrəd düşüncələr deyil, ən azı ilk addımların atıldığı bir şeydir.
- anomaliya detektoru. Qrafit anbarlarımıza gedəcək və müxtəlif alqoritmlərdən istifadə edərək hər bir metrikanı yoxlayacaq bir xidmət yaratmaq istəyirik. Artıq baxmaq istədiyimiz alqoritmlər var, məlumatlar var, onunla necə işləməyi bilirik.
- metadata. Bir çox xidmətlərimiz var, onlar zamanla dəyişir, eləcə də onlarla işləyən insanlar. Qeydləri əl ilə saxlamaq bir seçim deyil. Beləliklə, metadata indi mikroservislərimizə daxil edilmişdir. Onu kimin hazırladığı, qarşılıqlı əlaqədə olduğu dillər, SLA tələbləri, bildirişlərin hara və kimə göndərilməsi göstərilir. Xidməti yerləşdirərkən bütün müəssisə məlumatları müstəqil şəkildə yaradılır. Nəticədə iki keçid əldə edirsiniz - biri tetikleyiciler üçün, digəri Grafana-da idarə panelləri üçün.
- Hər evdə monitorinq. İnanırıq ki, bütün tərtibatçılar belə bir sistemdən istifadə etməlidirlər. Bu halda siz həmişə trafikinizin harada olduğunu, ona nə baş verdiyini, hara düşdüyünü, zəif nöqtələrinin harada olduğunu başa düşürsünüz. Məsələn, bir şey gəlib xidmətinizi pozarsa, bu barədə menecerin zəngi zamanı deyil, xəbərdarlıqdan xəbər tutacaqsınız və dərhal təzə qeydləri aça və orada nə baş verdiyini görə bilərsiniz.
- Yüksək performans. Layihəmiz daim böyüyür və bu gün dəqiqədə təxminən 2 metrik dəyər emal edir. Bir il əvvəl bu rəqəm 000 000 idi.Və artım davam edir və bu o deməkdir ki, bir müddət sonra Graphite (pıçıltı) disk alt sistemini çox ağır yükləməyə başlayacaq. Dediyim kimi, bu monitorinq sistemi komponentlərin bir-birini əvəz edə bilməsi səbəbindən kifayət qədər çox yönlüdür. Xüsusilə Graphite üçün kimsə öz infrastrukturunu saxlayır və daim genişləndirir, lakin biz başqa yolla getməyə qərar verdik: istifadə ölçülərimiz üçün bir anbar kimi. Bu keçid demək olar ki, tamamlandı və çox tezliklə bunun necə edildiyini sizə daha ətraflı izah edəcəyəm: çətinliklər nələr idi və necə aradan qaldırıldı, miqrasiya prosesi necə keçdi, mən məcburi olaraq seçilmiş komponentləri və onların konfiqurasiyalarını təsvir edəcəyəm.
Diqqətinizə görə təşəkkürlər! Mövzu ilə bağlı suallarınızı verin, burada və ya sonrakı yazılarda cavab verməyə çalışacağam. Ola bilsin ki, kimsə oxşar monitorinq sisteminin qurulması və ya oxşar vəziyyətdə Clickhouse-a keçid təcrübəsi var - şərhlərdə paylaşın.
Mənbə: www.habr.com