Beləliklə, siz ölçüləri toplayırsınız. Bizim kimi. Metrikləri də toplayırıq. Təbii ki, biznes üçün lazımdır. Bu gün biz monitorinq sistemimizin ilk linki - statsd-a uyğun birləşmə serveri haqqında danışacağıq. , niyə yazdıq və niyə brubeckdən imtina etdik.
Əvvəlki yazılarımızdan (, ) öyrənə bilərsiniz ki, bir müddət istifadə edərək işarələr topladıq . Bu, C dilində yazılmışdır. Kod baxımından, o, bir fiş kimi sadədir (bu, töhfə vermək istədiyiniz zaman vacibdir) və ən əsası, o, saniyədə 2 milyon metrik (MPS) həcmimizi ən yüksək nöqtədə idarə edir. heç bir problem olmadan. Sənədlərdə ulduz işarəsi ilə 4 milyon MPS dəstəyi göstərilir. Bu o deməkdir ki, Linux-da şəbəkəni düzgün konfiqurasiya etsəniz, göstərilən rəqəmi əldə edəcəksiniz. (Şəbəkəni olduğu kimi tərk etsəniz, nə qədər MPS əldə edə biləcəyinizi bilmirik). Bu üstünlüklərə baxmayaraq, brubeklə bağlı bir neçə ciddi şikayətimiz var idi.
İddia 1. Layihənin yaradıcısı Github onu dəstəkləməyi dayandırdı: yamaqlar və düzəlişlər dərc etmək, bizim və (yalnız bizim deyil) PR-ı qəbul etmək. Son bir neçə ayda (2018-ci ilin fevral-mart aylarında) aktivlik bərpa olundu, lakin bundan əvvəl demək olar ki, 2 il tam sakitlik var idi. Bundan əlavə, layihə hazırlanır , yeni funksiyaların tətbiqi üçün ciddi maneə ola bilər.
İddia 2. Hesablamaların dəqiqliyi. Brubeck toplamaq üçün cəmi 65536 dəyər toplayır. Bizim vəziyyətimizdə, bəzi ölçülər üçün, toplama dövründə (30 saniyə) daha çox dəyər gələ bilər (pikdə 1). Bu seçmə nəticəsində maksimum və minimum dəyərlər faydasız görünür. Məsələn, bu kimi:
Olduğu kimi
Necə olmalı idi
Eyni səbəbdən, məbləğlər ümumiyyətlə səhv hesablanır. Buraya 32 bitlik float daşması olan bir səhv əlavə edin, bu, zahirən günahsız bir metrik qəbul edərkən serveri segfault-a göndərir və hər şey əla olur. Səhv, yeri gəlmişkən, düzəldilməyib.
Və, nəhayət, İddia X. Yazı zamanı biz onu tapa bildiyimiz 14 az və ya çox işləyən bütün statsd tətbiqlərinə təqdim etməyə hazırıq. Təsəvvür edək ki, bəzi tək infrastruktur o qədər böyüyüb ki, 4 milyon MPS qəbul etmək artıq kifayət deyil. Və ya hələ böyüməmiş olsa belə, ölçülər sizin üçün o qədər vacibdir ki, hətta qrafiklərdəki qısa, 2-3 dəqiqəlik enişlər artıq kritik hala gələ bilər və menecerlər arasında keçilməz depressiyaya səbəb ola bilər. Depressiyanın müalicəsi nankor bir iş olduğundan, texniki həllər lazımdır.
Birincisi, səhvlərə dözümlülük, belə ki, serverdə qəfil problem ofisdə psixiatrik zombi apokalipsisinə səbəb olmasın. İkincisi, Linux şəbəkə yığınına dərindən girmədən və tələb olunan ölçüyə "enində" sakitcə böyümədən 4 milyon MPS-dən çox qəbul edə bilmək üçün miqyaslandırma.
Ölçələmək üçün yerimiz olduğundan, səhvlərə dözümlülüklə başlamaq qərarına gəldik. "HAQQINDA! Səhv tolerantlığı! Bu sadədir, biz bunu edə bilərik” deyə düşündük və hər birində brubeck nüsxəsini qaldıraraq 2 server işə saldıq. Bunun üçün biz hər iki serverə metrikləri olan trafiki köçürməli və hətta bunun üçün yazmalı olduq . Biz bununla qüsura dözüm problemini həll etdik, amma... çox yaxşı deyil. Əvvəlcə hər şey əla görünürdü: hər bir brubek öz toplama versiyasını toplayır, hər 30 saniyədə bir dəfə Graphite-ə məlumat yazır, köhnə intervalın üzərinə yazır (bu, Qrafit tərəfində edilir). Bir server qəfil uğursuz olarsa, bizdə həmişə ümumi məlumatların öz nüsxəsi olan ikincisi olur. Ancaq problem budur: server uğursuz olarsa, qrafiklərdə "mişar" görünür. Bu, Brubekin 30 saniyəlik intervallarının sinxronlaşdırılmaması və qəza zamanı onlardan birinin üzərinə yazılmaması ilə bağlıdır. İkinci server işə salındıqda eyni şey olur. Olduqca dözümlüdür, amma daha yaxşısını istəyirəm! Ölçeklenebilirlik problemi də aradan qalxmayıb. Bütün ölçülər hələ də bir serverə "uçur" və buna görə də biz şəbəkə səviyyəsindən asılı olaraq eyni 2-4 milyon MPS ilə məhdudlaşırıq.
Problem haqqında bir az düşünsəniz və eyni zamanda kürəklə qar qazsanız, ağlınıza aşağıdakı açıq fikir gələ bilər: paylanmış rejimdə işləyə bilən statsd lazımdır. Yəni, vaxt və ölçülərdə qovşaqlar arasında sinxronizasiya həyata keçirən biri. "Əlbəttə, belə bir həll yəqin ki, artıq mövcuddur" dedik və Google-a getdik... Və heç nə tapmadılar. Müxtəlif statsd üçün sənədləri nəzərdən keçirdikdən sonra ( 11.12.2017 dekabr XNUMX-ci il tarixinə) biz heç nə tapmadıq. Göründüyü kimi, nə tərtibatçılar, nə də bu həllərin istifadəçiləri hələ o qədər çox ölçülərlə qarşılaşmayıblar, əks halda onlar mütləq bir şey tapacaqlar.
Və sonra Just for Fun hakatonunda yazılmış "oyuncaq" statsd - bioyino haqqında xatırladıq (layihənin adı hakaton başlamazdan əvvəl skript tərəfindən yaradılıb) və təcili olaraq öz statistikamıza ehtiyacımız olduğunu başa düşdük. Nə üçün?
- çünki dünyada çox az statsd klon var,
- çünki istənilən və ya ona yaxın xətaya dözümlülük və miqyaslılığı təmin etmək mümkündür (o cümlədən serverlər arasında məcmu ölçülərin sinxronlaşdırılması və münaqişələrin göndərilməsi probleminin həlli),
- çünki metrikləri brubekdən daha dəqiq hesablamaq mümkündür,
- çünki Brubekin bizə praktiki olaraq təqdim etmədiyi daha ətraflı statistikanı özünüz toplaya bilərsiniz,
- çünki mənim öz hiperperformans paylanmış miqyaslı laboratoriya proqramımı proqramlaşdırmaq şansım oldu, bu başqa oxşar hiperforun arxitekturasını tam təkrar etməyəcək... yaxşı, bu qədər.
Nə yazmaq lazımdır? Əlbəttə, Rustda. Niyə?
- çünki artıq bir prototip həll var idi,
- çünki məqalənin müəllifi o vaxt Rustu artıq tanıyırdı və onu açıq mənbəyə yerləşdirmək imkanı ilə istehsal üçün nəsə yazmağa can atırdı,
- çünki GC ilə dillər alınan trafikin təbiətinə görə (demək olar ki, real vaxtda) bizim üçün uyğun deyil və GC fasilələri praktiki olaraq qəbuledilməzdir,
- çünki C ilə müqayisə edilə bilən maksimum performansa ehtiyacınız var
- çünki Rust bizə qorxmaz paralellik təqdim edir və biz onu C/C++-da yazmağa başlasaydıq, brubekdən daha çox zəifliklərə, bufer daşqınlarına, yarış şəraitinə və digər qorxulu sözlərə rast gələrdik.
Rusta qarşı mübahisə də olub. Şirkətin Rustda layihələr yaratmaq təcrübəsi yox idi və indi biz də ondan əsas layihədə istifadə etməyi planlaşdırmırıq. Ona görə də heç nəyin alınmayacağına dair ciddi qorxular var idi, amma biz şans vermək qərarına gəldik və cəhd etdik.
Vaxt keçdi...
Nəhayət, bir neçə uğursuz cəhddən sonra ilk işləyən versiya hazır oldu. Nə olub? Bu baş verdi.
Hər bir qovşaq öz ölçülər dəstini alır və onları toplayır və yekun toplama üçün onların tam dəstinin tələb olunduğu növlər üçün ölçüləri birləşdirmir. Düyünlər bir növ paylanmış kilid protokolu ilə bir-birinə bağlıdır ki, bu da onların arasından Böyük Birinə ölçülər göndərməyə layiq olan yeganə (burada ağladıq) seçməyə imkan verir. Hazırda bu problem tərəfindən həll edilir , lakin gələcəkdə müəllifin ambisiyaları uzanır Raft, burada ən layiqlisi, əlbəttə ki, konsensus lideri node olacaq. Konsensusa əlavə olaraq, qovşaqlar tez-tez (defolt olaraq saniyədə bir dəfə) həmin saniyədə toplaya bildikləri əvvəlcədən yığılmış ölçülərin hissələrini qonşularına göndərirlər. Məlum olub ki, miqyaslama və nasazlığa dözümlülük qorunub saxlanılır - hər bir node hələ də ölçülərin tam dəstini saxlayır, lakin ölçülər artıq yığılmış, TCP vasitəsilə göndərilir və ikili protokola kodlanır, beləliklə, təkrarlama xərcləri UDP ilə müqayisədə əhəmiyyətli dərəcədə azalır. Kifayət qədər çox sayda daxil olan ölçülərə baxmayaraq, yığılma çox az yaddaş və hətta daha az CPU tələb edir. Bizim yüksək sıxılma qabiliyyətimiz üçün bu, yalnız bir neçə onlarla meqabayt məlumatdır. Əlavə bir bonus olaraq, burbeck-də olduğu kimi Graphite-də lazımsız məlumatların yenidən yazılmasını almırıq.
Metrikləri olan UDP paketləri sadə Round Robin vasitəsilə şəbəkə avadanlığında qovşaqlar arasında balanssızdır. Əlbəttə ki, şəbəkə avadanlığı paketlərin məzmununu təhlil etmir və buna görə də heç bir şey bilmədiyi metrikləri qeyd etmədən saniyədə 4M-dən çox paket çəkə bilər. Nəzərə alsaq ki, ölçülər hər paketdə bir-bir gəlmir, onda bu yerdə heç bir performans problemi gözləmirik. Server qəzaya uğrayarsa, şəbəkə cihazı tez (1-2 saniyə ərzində) bu faktı aşkar edir və qəzaya uğramış serveri fırlanmadan çıxarır. Bunun nəticəsi olaraq, passiv (yəni lider olmayan) qovşaqlar qrafiklərdə azalmalara diqqət yetirmədən praktiki olaraq açıla və söndürülə bilər. İtirdiyimiz maksimum, son saniyədə gələn metriklərin bir hissəsidir. Liderin qəfil itirilməsi/bağlanması/dəyişməsi yenə də kiçik anomaliya yaradacaq (30 saniyəlik interval hələ də sinxron deyil), lakin qovşaqlar arasında əlaqə varsa, bu problemlər, məsələn, sinxronizasiya paketləri göndərməklə minimuma endirilə bilər. .
Daxili quruluş haqqında bir az. Tətbiq, əlbəttə ki, çoxillikdir, lakin yivləmə arxitekturası brubeck-də istifadə olunandan fərqlidir. Brubekdəki iplər eynidir - onların hər biri həm məlumat toplamaq, həm də toplamaq üçün məsuliyyət daşıyır. Bioyinoda işçilər iki qrupa bölünür: şəbəkəyə cavabdeh olanlar və aqreqasiyaya cavabdeh olanlar. Bu bölmə ölçülərin növündən asılı olaraq tətbiqi daha çevik idarə etməyə imkan verir: intensiv birləşmə tələb olunan yerlərdə aqreqatorlar əlavə edə bilərsiniz, şəbəkə trafikinin çox olduğu yerdə isə şəbəkə axınlarının sayını əlavə edə bilərsiniz. Hazırda serverlərimizdə 8 şəbəkə və 4 aqreqasiya axınında işləyirik.
Hesablama (toplamadan məsul olan) hissəsi olduqca darıxdırıcıdır. Şəbəkə axınları ilə doldurulmuş buferlər sayma axınları arasında paylanır, burada onlar sonradan təhlil edilir və birləşdirilir. İstək əsasında digər qovşaqlara göndərilmək üçün ölçülər verilir. Bütün bunlar, o cümlədən qovşaqlar arasında məlumat göndərmək və konsulla işləmək, çərçivədə işləyən asinxron şəkildə həyata keçirilir. .
İnkişaf zamanı daha çox problem ölçüləri qəbul etmək üçün cavabdeh olan şəbəkə hissəsinə səbəb oldu. Şəbəkə axınlarını ayrı-ayrı qurumlara ayırmağın əsas məqsədi axının sərf etdiyi vaxtı azaltmaq istəyi idi. heç bir rozetkadan məlumatları oxumaq üçün. Asinxron UDP və müntəzəm recvmsg-dən istifadə edən seçimlər tez bir zamanda yox oldu: birincisi hadisənin işlənməsi üçün çox istifadəçi sahəsi CPU istehlak edir, ikincisi isə çoxlu kontekst keçidləri tələb edir. Buna görə də indi istifadə olunur böyük tamponlarla (və buferlər, cənab zabitlər, sizin üçün heç nə deyil!). Müntəzəm UDP dəstəyi recvmmsg lazım olmayan yüngül hallar üçün qorunur. Multimesaj rejimində əsas şeyə nail olmaq mümkündür: çox vaxt şəbəkə ipi OS növbəsini çəkir - məlumatları rozetkadan oxuyur və onu istifadəçi sahəsi buferinə ötürür, yalnız bəzən doldurulmuş buferin verilməsinə keçir. aqreqatorlar. Soketdəki növbə praktiki olaraq yığılmır, atılan paketlərin sayı praktiki olaraq artmır.
Qeyd
Varsayılan parametrlərdə bufer ölçüsü kifayət qədər böyük olaraq təyin edilmişdir. Birdən serveri özünüz sınamaq qərarına gəlsəniz, az sayda ölçmə göndərdikdən sonra şəbəkə axını buferində qalaraq Graphite-ə çatmayacağı ilə qarşılaşa bilərsiniz. Az sayda ölçülərlə işləmək üçün konfiqurasiyada bufsize və tapşırıq növbəsinin ölçüsünü daha kiçik dəyərlərə təyin etməlisiniz.
Nəhayət, qrafik həvəskarları üçün bəzi qrafiklər.
Hər bir server üçün daxil olan ölçülərin sayına dair statistika: 2 milyon MPS-dən çox.
Düyünlərdən birinin söndürülməsi və daxil olan metriklərin yenidən paylanması.
Çıxan ölçülər üzrə statistika: yalnız bir node həmişə göndərir - basqın rəhbəri.
Müxtəlif sistem modullarında səhvləri nəzərə alaraq hər bir nodeun işinin statistikası.
Daxil olan ölçülərin təfərrüatları (metrik adlar gizlidir).
Bütün bunlarla bundan sonra nə etməyi planlaşdırırıq? Əlbəttə, kod yaz, lənətə gəl...! Layihənin əvvəlcə açıq mənbə olması planlaşdırılırdı və bütün ömrü boyu belə qalacaq. Bizim yaxın planlarımıza öz Raft versiyamıza keçmək, həmyaşıd protokolunu daha portativ protokola dəyişmək, əlavə daxili statistika, yeni ölçülər növləri, səhv düzəlişləri və digər təkmilləşdirmələr daxildir.
Təbii ki, hər kəs layihənin inkişafında kömək edə bilər: PR yaradın, Məsələlər, mümkünsə cavab verəcəyik, təkmilləşdirəcəyik və s.
Bununla belə, hamı budur, fillərimizi alın!
Mənbə: www.habr.com