Qeydlər sistemin gözlənildiyi kimi işlədiyini (və ya işləmədiyini) başa düşməyə imkan verən vacib bir hissədir. Mikroservis arxitekturası şəraitində jurnallarla işləmək Xüsusi Olimpiadanın ayrıca intizamına çevrilir. Həll edilməli olan çoxlu məsələlər var:
- proqramdan logları necə yazmaq olar;
- logları harada yazmaq olar;
- logların saxlanması və işlənməsi üçün necə çatdırılması;
- logları necə emal etmək və saxlamaq.
Hal-hazırda məşhur konteynerləşdirmə texnologiyalarının istifadəsi problemin həlli variantları sahəsində tırmığın üstünə qum əlavə edir.
Məhz bu barədə Yuri Buşmelevin "Kütlələrin toplanması və çatdırılması sahəsində dırmıq xəritəsi" məruzəsinin stenoqramı var.
Kimin vecinə deyil, zəhmət olmasa pişiyin altında.
Mənim adım Yuri Buşmelevdir. Mən Lazada üçün işləyirəm. Bu gün mən loglarımızı necə hazırladığımızdan, onları necə yığdığımızdan və orada nə yazdığımızdan danışacağam.
Biz haradanıq? Biz kimik? Lazada Cənub-Şərqi Asiyanın altı ölkəsində 1 nömrəli onlayn pərakəndə satıcıdır. Bütün bu ölkələr məlumat mərkəzləri arasında bölüşdürülür. İndi cəmi 4 məlumat mərkəzi var.Bu nə üçün vacibdir? Çünki bəzi qərarlar mərkəzlər arasında əlaqənin çox zəif olması ilə bağlı idi. Mikroservis arxitekturamız var. Artıq 80 mikroservisimizin olduğunu görəndə təəccübləndim. Mən tapşırığa loglarla başlayanda onlardan cəmi 20-si var idi.Üstəlik, PHP irsinin kifayət qədər böyük bir parçası var ki, mən də onunla yaşamalı və dözməli oldum. Bütün bunlar bizim üçün hazırda bütövlükdə sistem üçün dəqiqədə 6 milyondan çox mesaj yaradır. Bundan sonra bununla necə yaşamağa çalışdığımızı və bunun niyə belə olduğunu göstərəcəyəm.
Bu 6 milyon mesajla birtəhər yaşamalısan. Onlarla nə etməliyik? 6 milyon mesaj lazımdır:
- proqramdan göndərin
- çatdırılma üçün qəbul edin
- analiz və saxlama üçün çatdırmaq.
- təhlil etmək
- bir şəkildə saxlamaq.
Üç milyon mesaj olanda təxminən eyni görünüşə sahib idim. Çünki bir az qəpiklə başladıq. Orada ərizə jurnallarının yazıldığı aydındır. Məsələn, verilənlər bazasına qoşula bilmədi, verilənlər bazasına qoşula bildi, amma bir şey oxuya bilmədi. Bununla yanaşı, mikroservislərimizin hər biri giriş jurnalı da yazır. Mikroservisə gələn hər bir sorğu jurnala düşür. Niyə bunu edirik? Tərtibatçılar izləyə bilmək istəyirlər. Hər bir giriş jurnalı traceid sahəsini ehtiva edir, ona uyğun olaraq xüsusi interfeys bütün zənciri açır və izi gözəl şəkildə göstərir. İz sorğunun necə getdiyini göstərir və bu, tərtibatçılarımıza hər hansı naməlum zibillə daha sürətli məşğul olmağa kömək edir.
Bununla necə yaşamaq olar? İndi seçim sahəsini qısaca təsvir edəcəyəm - bu problem ümumiyyətlə necə həll olunur. Günlüklərin toplanması, ötürülməsi və saxlanması problemini necə həll etmək olar.
Ərizədən necə yazmaq olar? Aydındır ki, müxtəlif yollar var. Xüsusilə dəbli yoldaşların dediyi kimi, ən yaxşı təcrübə var. Babaların dediyi kimi iki növ köhnə məktəb var. Başqa yollar da var.
Günlüklərin toplanması ilə vəziyyət təxminən eynidır. Bu xüsusi hissəni həll etmək üçün o qədər də çox variant yoxdur. Onların sayı daha çoxdur, amma hələ çox deyil.
Ancaq çatdırılma və sonrakı təhlil ilə variasiyaların sayı partlamağa başlayır. İndi hər variantı təsvir etməyəcəyəm. Düşünürəm ki, əsas variantlar mövzu ilə maraqlanan hər kəsə yaxşı məlumdur.
Mən sizə Lazadada bunu necə etdiyimizi və hər şeyin necə başladığını göstərəcəyəm.
Bir il əvvəl Lazada gəldim və log layihəsinə göndərildim. Orada belə idi. Tətbiqdən jurnal stdout və stderr-ə yazılmışdır. Hər şey dəbli bir şəkildə edildi. Ancaq sonra tərtibatçılar onu standart axınlardan atdılar və sonra infrastruktur mütəxəssisləri bunu birtəhər başa düşəcəklər. İnfrastruktur mütəxəssisləri və tərtibatçılar arasında "uh ... yaxşı, gəlin onları qabıqlı bir fayla sarıyaq, vəssalam" deyənlər də var. Və bütün bunlar bir konteynerdə olduğu üçün onu düz qabın özünə bükdülər, kataloqun xəritəsini çəkdilər və ora qoydular. Düşünürəm ki, baş verənlər hamıya aydındır.
Gəlin bir az da irəli baxaq. Bu logları necə çatdırdıq. Kimsə td-agenti seçdi, o, əslində səlis danışır, lakin kifayət qədər səlis deyil. Mən hələ də bu iki layihənin əlaqəsini başa düşə bilmirəm, amma deyəsən, eyni şeydir. Ruby-də yazılmış bu səlis, log fayllarını oxuyur, bəzi müntəzəm ifadələrdən istifadə edərək onları JSON-da təhlil edir. Sonra onları Kafkaya göndərdilər. Üstəlik, Kafkada hər API üçün 4 ayrı mövzumuz var idi. Niyə 4? Çünki canlı var, səhnələşdirmə var və stdout və stderr olduğu üçün. Tərtibatçılar onları istehsal edir və infrastruktur işçiləri onları Kafkada yaratmalıdır. Üstəlik, Kafka başqa bir departament tərəfindən idarə olunurdu. Ona görə də bilet yaratmaq lazım idi ki, orada hər api üçün 4 mövzu yaratsınlar. Hamı bunu unudub. Ümumiyyətlə, zibil və tullantı idi.
Bundan sonra onunla nə etdik? Kafkaya göndərdik. Kafkadan irəlidə, logların yarısı Loqstaşa uçdu. Günlüklərin digər yarısı paylaşıldı. Bəziləri bir Qreyloqa, bəziləri digər Qreyloqa uçdu. Nəticədə bütün bunlar bir Elasticsearch klasterinə çevrildi. Yəni bütün bu qarışıqlıq axırda oraya düşdü. Bunu etməli deyilsən!
Yuxarıdan baxanda belə görünür. Bunu etməli deyilsən! Burada problemli sahələr dərhal rəqəmlərlə qeyd olunur. Əslində bunlardan daha çoxu var, amma 6-sı həqiqətən problemlidir, onlarla nəsə etmək lazımdır. İndi onlar haqqında ayrıca danışacağam.
Burada (1,2,3) faylları yazırıq və müvafiq olaraq burada bir anda üç dırmıq var.
Birincisi (1) biz onları hardasa yazmalıyıq. API-yə birbaşa fayla yazmaq imkanı vermək həmişə arzuolunan deyil. API-nin bir konteynerdə təcrid edilməsi və daha da yaxşısı, onun yalnız oxunması arzu edilir. Mən sistem administratoruyam, ona görə də bu şeylərə bir az alternativ baxışım var.
İkinci məqam (2,3) API-yə çoxlu müraciətlərimizin olmasıdır. API fayla çoxlu məlumat yazır. Fayllar böyüyür. Biz onları döndərməliyik. Çünki əks halda orada heç bir diski saxlaya bilməyəcəksiniz. Onları çevirmək pisdir, çünki onlar qabıq vasitəsilə bir kataloqa yönləndirilir. Onu döndərmək üçün heç bir yolumuz yoxdur. Siz tətbiqə tutacaqları yenidən açmağı deyə bilməzsiniz. Çünki tərtibatçılar sizə axmaq kimi baxacaqlar: “Hansı deskriptorlar? Biz ümumiyyətlə stdout-a yazırıq. Çərçivələr copytruncate-i logrotate etdi, bu da sadəcə faylın surətini çıxarır və orijinalı yükləyir. Müvafiq olaraq, bu kopyalama prosesləri arasında disk sahəsi adətən tükənir.
(4) Fərqli API-lərdə fərqli formatlarımız var idi. Onlar bir az fərqli idi, lakin regexp fərqli yazılmalıdır. Hamısı Kukla tərəfindən idarə olunduğundan, öz tarakanları olan böyük bir qrup sinif var idi. Üstəlik, td-agent çox vaxt yaddaşı yeyə bilər, axmaq ola bilər, sadəcə işləyir və heç nə etmədiyini iddia edə bilər. Zahirən onun heç nə etmədiyini anlamaq mümkün deyildi. Ən yaxşı halda yıxılacaq, sonra da kimsə onu qaldıracaq. Daha doğrusu, siqnal uçacaq, kimsə gedib onu əlləri ilə qaldıracaq.
(6) Və ən zibil və tullantı - bu elasticsearch idi. Çünki köhnə versiya idi. Çünki o vaxt fədakar ustalarımız yox idi. Sahələri üst-üstə düşə bilən heterojen loglarımız var idi. Fərqli proqramların müxtəlif jurnalları eyni sahə adları ilə yazıla bilər, lakin eyni zamanda içərisində fərqli məlumatlar ola bilər. Yəni, bir jurnal sahədə, məsələn, səviyyədə Tam ədəd ilə gəlir. Başqa bir jurnal səviyyə sahəsində bir String ilə gəlir. Statik xəritələmə olmadıqda belə gözəl bir şey çıxır. Əgər indeksin fırlanmasından sonra ilk olaraq elasticsearch-a sətirli mesaj gəlibsə, onda biz normal yaşayırıq. Əgər birincisi Tam ədədlə gəlibsə, o zaman String ilə gələn bütün sonrakı mesajlar sadəcə atılır. Çünki sahə növü uyğun gəlmir.
Bu sualları verməyə başladıq. Qərara gəldik ki, günahkarları axtarmayaq.
Ancaq bir şey etmək lazımdır! Aydın olan budur ki, biz standartlar yaratmalıyıq. Bizim artıq müəyyən standartlar var idi. Bəzilərini bir az sonra gətirdik. Xoşbəxtlikdən, o zaman bütün API-lər üçün vahid log formatı artıq təsdiqlənmişdi. O, birbaşa xidmətin qarşılıqlı əlaqə standartlarına yazılır. Müvafiq olaraq, jurnalları almaq istəyənlər onları bu formatda yazmalıdırlar. Əgər kimsə bu formatda loglar yazmırsa, biz heç nəyə zəmanət vermirik.
Bundan əlavə, qeydlərin qeyd edilməsi, çatdırılması və toplanması üsulları üçün vahid standartın olmasını istərdim. Əslində, onları hara yazmaq, necə çatdırmaq lazımdır. İdeal vəziyyət layihələrin eyni kitabxanadan istifadə etməsidir. Go üçün ayrıca giriş kitabxanası, PHP üçün ayrıca kitabxana var. Bizdə olan hər kəs onlardan istifadə etməlidir. Hazırda mən deyərdim ki, biz 80 faiz uğur qazanırıq. Ancaq bəziləri kaktusları yeməyə davam edir.
Və orada (slaydda) “Giriş çatdırılması üçün SLA” çətinliklə görünməyə başlayır. Hələ ki, yoxdur, amma biz bunun üzərində işləyirik. Çünki infra deyəndə çox rahatdır ki, filan yerə filan formatda və saniyədə N mesajdan çox yazmasan, böyük ehtimalla ora çatdıracağıq. Çox baş ağrısını götürür. SLA varsa, o, sadəcə əladır!
Problemi həll etməyə necə başladıq? Əsas tırmık td-agent ilə idi. Günlüklərimizin hara getdiyi bəlli deyildi. Onlar çatdırılır? Onlar gedir? Onsuz da onlar haradadırlar? Buna görə də, td-agentin birinci maddə ilə əvəz edilməsi qərara alındı. Onu nə ilə əvəz etmək üçün seçimlər, mən burada qısaca qeyd etdim.
Səlis. Birincisi, mən onunla əvvəlki işdə rastlaşdım və o da vaxtaşırı ora düşdü. İkincisi, bu eynidir, yalnız profildə.
filebeat. Bizim üçün necə yaxşı oldu? Onun Go-da olması və bizim Go-da böyük təcrübəmiz var. Müvafiq olaraq, əgər bir şey varsa, onu birtəhər özümüzə əlavə edə bilərdik. Ona görə də götürmədik. Özünüz üçün yenidən yazmağa başlamaq üçün heç bir vəsvəsə olmasın deyə.
Sysadmin üçün aşkar həll yolu bu miqdarda olan bütün növ sistem loglarıdır (syslog-ng/rsyslog/nxlog).
Və ya özünüzdən bir şey yazın, lakin biz onu atdıq, həmçinin filebeat. Bir şey yazırsansa, iş üçün faydalı bir şey yazsan daha yaxşıdır. Günlükləri çatdırmaq üçün hazır bir şey götürmək daha yaxşıdır.
Buna görə də seçim əslində syslog-ng və rsyslog arasında seçimə gəldi. Mən sadəcə olaraq rsyslog-a meyl etdim, çünki artıq Kuklada rsyslog üçün dərslərimiz var idi və onlar arasında bariz bir fərq tapmadım. Syslog nədir, syslog nədir. Bəli, bəzi sənədlər daha pis, bəziləri daha yaxşıdır. O, bu yolu bilir və bunu başqa cür edir.
Və rsyslog haqqında bir az. Birincisi, çoxlu modulları olduğu üçün sərindir. İnsan tərəfindən oxuna bilən RainerScript (müasir konfiqurasiya dili) var. Möhtəşəm bonus odur ki, biz onun standart alətləri ilə td-agentin davranışını təqlid edə bildik və tətbiqlər üçün heç nə dəyişməyib. Yəni, biz td-agenti rsyslog-a dəyişdiririk və hələ hər şeyə toxunmuruq. Və dərhal işlək çatdırılma alırıq. Sonra, mmnormalize rsyslog haqqında gözəl şeydir. Bu, qeydləri təhlil etməyə imkan verir, lakin Grok və regexp ilə deyil. O, abstrakt sintaksis ağacı yaradır. O, jurnalları tərtibçinin mənbə kodunu təhlil etdiyi kimi təhlil edir. Bu, çox sürətli işləməyə, az CPU yeməyə imkan verir və ümumiyyətlə, bu, çox gözəl bir şeydir. Bir çox başqa bonuslar var. Mən onların üzərində dayanmayacağam.
rsyslog-un daha çox mənfi cəhətləri var. Onlar bonuslarla təxminən eynidir. Əsas problemlər ondan ibarətdir ki, onu bişirməyi bacarmalısan və versiyanı seçməlisən.
Biz unix yuvasında logları yazmağa qərar verdik. Və /dev/log-da deyil, çünki orada bir qarışıq sistem qeydləri var, bu boru kəmərində jurnal var. Beləliklə, xüsusi bir yuvaya yazaq. Onu ayrıca qaydalar dəstinə əlavə edəcəyik. Heç nəyə qarışmayaq. Hər şey şəffaf və başa düşülən olacaq. Beləliklə, biz əslində etdik. Bu yuvaları olan kataloq standartlaşdırılıb və bütün konteynerlərə ötürülür. Konteynerlər onlara lazım olan rozetkanı görə bilir, açıb ona yaza bilirlər.
Niyə fayl olmasın? Çünki hamı oxuyub , faylı docker-ə yönləndirməyə çalışdı və aşkar etdi ki, rsyslog-u yenidən başlatdıqdan sonra fayl deskriptoru dəyişir və docker bu faylı itirir. Başqa bir şey açır, amma yazdıqları yuva deyil. Qərara gəldik ki, bu problemdən yan keçək və eyni zamanda bloklama problemindən də yan keçək.
Rsyslog slaydda göstərilən hərəkətləri yerinə yetirir və qeydləri relay və ya Kafkaya göndərir. Kafka köhnə yolla gedir. Rayleigh - Mən logları çatdırmaq üçün təmiz rsyslogdan istifadə etməyə çalışdım. Standart rsyslog alətlərindən istifadə edərək Mesaj Növbəsi olmadan. Əsasən işləyir.
Ancaq sonradan bu hissəyə necə doldurulacağına dair nüanslar var (Logstash/Graylog/ES). Bu hissə (rsyslog-rsyslog) məlumat mərkəzləri arasında istifadə olunur. Budur, bant genişliyinə qənaət etməyə və müvafiq olaraq kanal dolduqda başqa bir məlumat mərkəzindən bəzi qeydlər alacağımız ehtimalını artırmağa imkan verən sıxılmış tcp bağlantısı. Çünki bizdə hər şey pis olan İndoneziya var. Daimi problem buradadır.
Fikirləşdik ki, əslində necə nəzarət edirik, tətbiqdən qeyd etdiyimiz qeydlər hansı ehtimalla bu sona çatır? Metriklərə başlamaq qərarına gəldik. Rsyslog-un bir növ sayğacları olan öz statistika toplama modulu var. Məsələn, o, növbənin ölçüsünü və ya belə bir hərəkət üçün neçə mesajın gəldiyini göstərə bilər. Onsuz da onlardan nəsə ala bilərsiniz. Üstəlik, konfiqurasiya edə biləcəyiniz xüsusi sayğaclara malikdir və o, məsələn, bəzi API-nin qeyd etdiyi mesajların sayını göstərəcəkdir. Sonra Python-da rsyslog_exporter yazdım və hamısını Prometeyə göndərdik və plan qurduq. Biz həqiqətən Graylog ölçülərini istəyirdik, lakin indiyə qədər onları qurmağa vaxtımız olmayıb.
Problemlər nələrdir? Problem, Live API-lərimizin saniyədə 50k mesaj yazdığını bildiyimizdən (QƏFİLDƏ!) yarandı. Bu, səhnələşdirmə olmadan yalnız Live API-dir. Və Graylog bizə saniyədə cəmi 12 min mesaj göstərir. Və ağlabatan bir sual ortaya çıxdı, qalıqlar haradadır? Bundan belə nəticəyə gəldik ki, Graylog sadəcə öhdəsindən gələ bilməz. Biz baxdıq və həqiqətən Elasticsearch ilə Graylog bu axını mənimsəmədi.
Sonra, yol boyu etdiyimiz digər kəşflər.
Soketə yazılanlar bloklanıb. Bu necə oldu? Çatdırılma üçün rsyslog-dan istifadə etdiyim zaman bir anda məlumat mərkəzləri arasındakı kanalı qırdıq. Çatdırılma bir yerə qalxdı, çatdırılma başqa yerə qalxdı. Bütün bunlar rsyslog yuvasına yazan API-ləri olan bir maşına gəldi. Növbə var idi. Sonra unix yuvasına yazmaq üçün növbə doldu, bu, standart olaraq 128 paketdir. Və proqram bloklarında növbəti yaz (). Go proqramlarında istifadə etdiyimiz kitabxanaya baxdığımızda orada yazılmışdı ki, rozetkaya yazmaq bloklanmayan rejimdə olur. Heç bir şeyin qarşısının alınmadığına əmin idik. Çünki oxumuşuq bu haqda kim yazıb. Ancaq bir an var. Həm də bu zəng ətrafında sonsuz bir döngə var idi, orada mesajı yuvaya itələmək üçün daim cəhd edilirdi. Biz ona fikir vermədik. Kitabxananı yenidən yazmalı oldum. O vaxtdan bəri bir neçə dəfə dəyişdi, lakin indi bütün alt sistemlərdə kilidlərdən qurtulmuşuq. Buna görə də, rsyslog-u dayandıra bilərsiniz və heç bir şey düşməyəcək.
Növbələrin ölçüsünü izləmək lazımdır ki, bu da bu dırmıqda addımlamamağa kömək edir. Birincisi, mesajları itirməyə başladığımız zaman nəzarət edə bilərik. İkincisi, biz əsasən çatdırılma ilə bağlı problemlərimiz olduğuna nəzarət edə bilərik.
Və başqa bir xoşagəlməz məqam - mikroservis arxitekturasında 10 dəfə gücləndirmə çox asandır. O qədər də çox daxil olan sorğularımız yoxdur, lakin bu mesajların daha da irəlilədiyi qrafikə görə, giriş qeydləri sayəsində biz faktiki olaraq loglardakı yükü təxminən on dəfə artırırıq. Təəssüf ki, dəqiq rəqəmləri hesablamağa vaxtım olmadı, amma mikroservislər bunlardır. Bunu nəzərə almaq lazımdır. Belə çıxır ki, hazırda log toplama alt sistemi Lazada-da ən çox yüklənmişdir.
Elasticsearch problemini necə həll etmək olar? Bütün maşınlarda işləməmək və onları orada toplamamaq üçün qeydləri tez bir yerdə əldə etmək lazımdırsa, fayl yaddaşından istifadə edin. Bunun işləməsinə zəmanət verilir. İstənilən serverdən edilir. Sadəcə diskləri oraya yapışdırıb syslog qoymaq lazımdır. Bundan sonra, bütün logların bir yerdə olacağına zəmanət verilir. Sonra yavaş-yavaş elasticsearch, graylog və ya başqa bir şeyi konfiqurasiya etmək mümkün olacaq. Ancaq artıq bütün qeydlərə sahib olacaqsınız və üstəlik, kifayət qədər disk massivləri olduqda onları saxlaya bilərsiniz.
Hesabatımı verəndə sxem belə görünməyə başladı. Biz faktiki olaraq fayla yazmağı dayandırdıq. İndi çox güman ki, qalıqları söndürəcəyik. API ilə işləyən yerli maşınlarda biz fayllara yazmağı dayandıracağıq. Birincisi, çox yaxşı işləyən fayl saxlama var. İkincisi, bu maşınların yerləri daim tükənir, ona daim nəzarət etmək lazımdır.
Logstash və Graylog ilə bu hissə həqiqətən uçur. Buna görə də ondan qurtulmaq lazımdır. Siz birini seçməlisiniz.
Logstash və Kibana'dan imtina etmək qərarına gəldik. Çünki bizim təhlükəsizlik şöbəmiz var. Əlaqə nədir? Əlaqə ondan ibarətdir ki, X-Pack olmadan və Qalxansız Kibana loglara giriş hüquqlarını fərqləndirməyə imkan vermir. Buna görə də Qreyloqu götürdülər. Hamısı var. Mən bunu bəyənmirəm, amma işləyir. Biz yeni avadanlıq aldıq, orada təzə Graylog quraşdırdıq və ciddi formatlı bütün qeydləri ayrıca Graylog-a köçürdük. Eyni sahələrin müxtəlif növləri ilə problemi təşkilati olaraq həll etdik.
Yeni Graylog-a tam olaraq nə daxildir. Biz sadəcə hər şeyi docker-də yazdıq. Biz bir dəstə server götürdük, üç Kafka nümunəsini, 7 Graylog serverinin 2.3 versiyasını təqdim etdik (çünki mən Elasticsearch versiyası 5-i istəyirdim). Bütün bunlar HDD-dən reydlər zamanı qaldırıldı. Biz saniyədə 100 min mesaja qədər indeksləşdirmə dərəcəsi gördük. Həftədə 140 terabayt məlumat olduğunu gördük.
Və yenə dırmıq! Qarşıda iki satışımız var. Biz 6 milyon postu keçdik. Biz Graylogun çeynəməyə vaxtımız yoxdur. Birtəhər yenidən sağ qalmalısan.
Beləcə sağ qaldıq. Daha bir neçə server və SSD əlavə edildi. Hazırda biz belə yaşayırıq. İndi biz saniyədə 160k mesaj çeynəyirik. Hələ ki, həddi çatmamışıq, ona görə də real olaraq ondan nə qədər çıxa biləcəyimiz bəlli deyil.
Bunlar bizim gələcək üçün planlarımızdır. Bunlardan, həqiqətən, ən vacibi, ehtimal ki, yüksək əlçatanlıqdır. Bizdə hələ yoxdur. Bir neçə avtomobil eyni şəkildə qurulur, lakin indiyə qədər hər şey bir avtomobildən keçir. Onların arasında uğursuzluq qurmaq üçün vaxt sərf etmək lazımdır.
Graylog-dan ölçüləri toplayın.
Bizi bant genişliyini və digər hər şeyi öldürməyən bir dəli API-yə sahib olmaq üçün tarif limiti yaradın.
Və nəhayət, tərtibatçılarla bir növ SLA imzalayın ki, biz bu qədər xidmət edə bilək. Daha çox yazsanız, üzr istəyirəm.
Və sənədləri yazın.
Qısacası, yaşadığımız hər şeyin nəticələri. Birincisi, standartlar. İkincisi, syslog tortdur. Üçüncüsü, rsyslog slaydda yazıldığı kimi işləyir. Və keçək suallara.
Suallar.
Sual: Niyə götürməməyə qərar verdilər ... (filebeat?)
Cavab: Fayla yazmaq lazımdır. Mən həqiqətən istəmirdim. API saniyədə minlərlə mesaj yazdıqda, hətta saatda bir dəfə dönsəniz belə, bu hələ də seçim deyil. Boruya yaza bilərsiniz. Tərtibatçılar məndən soruşdular: "Yazdığımız proses aşağı düşsə nə olacaq?" Sadəcə onlara nə cavab verəcəyimi tapmadım və dedim: "Yaxşı, yaxşı, bunu etməyək."
Sual: HDFS-ə niyə sadəcə qeydlər yazmırsınız?
CavabA: Bu növbəti addımdır. Əvvəldən bu barədə düşündük, lakin hazırda bununla məşğul olmaq üçün heç bir resurs olmadığından, bu, bizim uzunmüddətli həllimizdə dayanır.
Sual: Sütun formatı daha uyğun olardı.
Cavab: Mən başa düşürəm. Biz hər iki əlimizlə “tərəfdarıq”.
Sual: Siz rsyslog-a yazın. Orada həm TCP, həm də UDP mövcuddur. Bəs UDP varsa, o zaman çatdırılmaya necə zəmanət verirsiniz?
CavabA: İki məqam var. Birincisi, mən dərhal hər kəsə deyirəm ki, biz logların çatdırılmasına zəmanət vermirik. Çünki tərtibatçılar gəlib dedikdə: “Gəlin orada maliyyə məlumatlarını yazmağa başlayaq və bir şey baş verərsə, siz onu bizim üçün harasa qoyacaqsınız” deyəndə biz onlara “Əla! Gəlin rozetkaya yazmaq üçün bloklamağa başlayaq və bunu əməliyyatlarda edək ki, onu bizim üçün rozetkaya qoymağınız və qarşı tərəfdən aldığımıza əmin olun. Və bu anda hər kəs dərhal lazımsız olur. Əgər yoxsa, onda hansı suallarımız var? Əgər rozetkaya yazılmağa zəmanət vermək istəmirsinizsə, onda niyə çatdırılmaya zəmanət verək? Biz ən yaxşı səy göstəririk. Biz, həqiqətən, mümkün qədər çox və ən yaxşı şəkildə çatdırmağa çalışırıq, lakin 100% zəmanət vermirik. Ona görə də orada maliyyə məlumatlarını yazmağa ehtiyac yoxdur. Bunun üçün əməliyyat məlumat bazaları var.
Sual: API jurnala bəzi mesajlar yaradanda və nəzarəti mikroservislərə ötürəndə, müxtəlif mikroservislərdən gələn mesajların səhv ardıcıllıqla gəlməsi problemi ilə qarşılaşmısınız? Bu səbəbdən qarışıqlıq yaranır.
CavabA: Onların fərqli ardıcıllıqla gəlməsi normaldır. Buna hazır olmalısan. Çünki hər hansı bir şəbəkə çatdırılması sizə sifariş təmin etmir və ya bunun üçün xüsusi resurslar sərf etməlisiniz. Əgər biz fayl anbarlarını götürsək, onda hər bir API qeydləri öz faylında saxlayır. Əksinə, rsyslog onları orada qovluqlara parçalayır. Orada hər bir API-nin öz qeydləri var, siz gedib baxa bilərsiniz və sonra bu jurnaldakı vaxt damğasından istifadə edərək onları müqayisə edə bilərsiniz. Əgər onlar Graylog-a baxmağa gedirlərsə, onda onlar vaxt damğasına görə sıralanacaqlar. Orada hər şey yaxşı olacaq.
Sual: Vaxt möhürü millisaniyələrlə dəyişə bilər.
Cavab: Vaxt damğası API özü tərəfindən yaradılır. Əslində bütün məqam budur. Bizdə NTP var. API artıq mesajın özündə vaxt möhürü yaradır. Bu rsyslog tərəfindən əlavə edilmir.
Sual: Məlumat mərkəzləri arasında qarşılıqlı əlaqə çox aydın deyil. Data-mərkəz çərçivəsində logların necə toplanaraq emal edildiyi aydın olur. Məlumat mərkəzləri arasında qarşılıqlı əlaqə necədir? Yoxsa hər bir məlumat mərkəzi öz həyatını yaşayır?
Cavab: Təxminən. Bizdə hər bir ölkə bir məlumat mərkəzində yerləşir. Hazırda bizdə yayılma yoxdur ki, bir ölkə müxtəlif məlumat mərkəzlərində yerləşdirilsin. Buna görə də onları birləşdirməyə ehtiyac yoxdur. Hər mərkəzin içərisində Log Relay var. Bu Rsyslog serveridir. Əslində, iki idarəetmə maşını. Eyni şəkildə qurulurlar. Ancaq hələlik trafik onlardan birindən keçir. O, hər şeyi ümumiləşdirir. Hər ehtimala qarşı disk növbəsi var. O, jurnalları sıxır və onları mərkəzi məlumat mərkəzinə (Sinqapur) göndərir, burada daha sonra onlar artıq Graylogda zəhərlənirlər. Və hər bir məlumat mərkəzinin öz fayl yaddaşı var. Əlaqəni itirdiyimiz halda, orada bütün qeydlərimiz var. Orada qalacaqlar. Onlar orada saxlanılacaq.
Sual: Anormal vəziyyətlər zamanı oradan qeydlər alırsınız?
Cavab: Oraya (fayl yaddaşına) gedib baxa bilərsiniz.
Sual: Siz qeydləri itirməməyinizə necə nəzarət edirsiniz?
Cavab: Biz əslində onları itiririk və biz bunu izləyirik. Monitorinq bir ay əvvəl başlayıb. Go API-lərinin istifadə etdiyi kitabxananın ölçüləri var. O, rozetkaya neçə dəfə yaza bilmədiyini saya bilir. Hazırda çətin bir evristik var. Orada bufer var. Ondan rozetkaya mesaj yazmağa çalışır. Bufer aşıbsa, onları atmağa başlayır. Və onları nə qədər atdığını hesablayır. Orada sayğaclar daşmağa başlasa, bundan xəbərimiz olacaq. İndi onlar da prometeyə gəlirlər və siz Grafanadakı qrafikləri görə bilərsiniz. Siz xəbərdarlıqları qura bilərsiniz. Amma onların kimə göndəriləcəyi hələ bəlli deyil.
Sual: Elasticsearch-də qeydləri ehtiyatla saxlayırsınız. Neçə replikanız var?
Cavab: Bir replika.
Sual: Yalnız bir xəttdir?
Cavab: Bu master və replikadır. Məlumatlar iki nüsxədə saxlanılır.
Sual: Siz rsyslog buferinin ölçüsünü hər hansı bir şəkildə dəyişdirdinizmi?
Cavab: Biz dataqramları xüsusi unix yuvasına yazırıq. Bu dərhal bizə 128 kilobayt məhdudiyyət qoyur. Daha çox yaza bilmərik. Bunu standarta yazdıq. Anbara girmək istəyənlər 128 kilobayt yazırlar. Kitabxanalar, üstəlik, kəsildi və mesajın kəsildiyi bir bayraq qoydu. Mesajın özünün standartında qeyd zamanı kəsilib-kəsilmədiyini göstərən xüsusi bir sahəmiz var. Beləliklə, bu anı izləmək imkanımız var.
Sual: Qırılmış JSON yazırsınız?
Cavab: Paket çox böyük olduğu üçün pozulmuş JSON ya relay zamanı atılacaq. Və ya Graylog silinəcək, çünki o, JSON-u təhlil edə bilməyəcək. Ancaq burada düzəldilməli olan nüanslar var və onlar əsasən rsyslog ilə bağlıdır. Mən artıq orada bir neçə məsələni doldurmuşam, hələ üzərində işləmək lazımdır.
Sual: Niyə Kafka? RabbitMQ-nu sınamısınız? Graylog belə yüklər altında yığılmır?
Cavab: Bu Graylog ilə işləmir. Və Graylog formalaşır. Onun üçün həqiqətən problemlidir. O, bir növ şeydir. Və əslində buna ehtiyac yoxdur. Mən rsyslog-dan birbaşa elasticsearch-a yazmaq və sonra Kibana baxmaq istərdim. Amma mühafizəçilərlə məsələni həll etməliyik. Bu, Graylogu atıb Kibana istifadə etdiyimiz zaman inkişafımızın mümkün variantıdır. Logstash heç bir məna kəsb etməyəcək. Çünki rsyslog ilə də eyni şeyi edə bilərəm. Və onun elasticsearch-a yazmaq üçün modulu var. Graylog ilə biz birtəhər yaşamağa çalışırıq. Hətta bir az düzəliş etdik. Ancaq təkmilləşdirmə üçün hələ də yer var.
Kafka haqqında. Tarixən də belə olub. Mən gələndə artıq orada idi və artıq ona loglar yazılırdı. Biz sadəcə olaraq klasterimizi qaldırdıq və logları ona köçürdük. Biz onu idarə edirik, onun necə hiss etdiyini bilirik. RabbitMQ-ya gəlincə... RabbitMQ ilə problemimiz var. Və RabbitMQ bizim üçün inkişaf edir. İstehsalımızda var və bununla bağlı problemlər var idi. İndi satışdan əvvəl onu şamanlaşdıracaq, normal işləməyə başlayacaqdı. Amma ondan əvvəl onu istehsala buraxmağa hazır deyildim. Daha bir şey var. Graylog AMQP 0.9 versiyasını oxuya bilər və rsyslog AMQP 1.0 versiyasını yaza bilər. Və ortada hər ikisini edə biləcək tək bir həll yoxdur. Biri və ya digəri var. Ona görə də hazırda yalnız Kafka. Ancaq nüanslar da var. Çünki istifadə etdiyimiz rsyslog versiyasının omkafka rsyslog-dan yığdığı bütün mesaj buferini itirə bilər. Nə qədər ki, biz buna dözürük.
Sual: Kafka sizdə olduğu üçün istifadə edirsiniz? Başqa məqsədlər üçün istifadə olunmur?
Cavab: Data Science komandası tərəfindən istifadə edilən Kafka. Bu, tamamilə ayrı bir layihədir, bu barədə təəssüf ki, heç nə deyə bilmərəm. Mən bilmirəm. Onu Data Science komandası idarə edirdi. Günlüklər başlayanda, özlərini qoymamaq üçün istifadə etməyə qərar verdilər. İndi biz Graylog-u yeniləmişik və uyğunluğu itirmişik, çünki Kafkanın köhnə versiyası var. Özümüz yaratmalı idik. Eyni zamanda, hər bir API üçün bu dörd mövzudan xilas olduq. Biz hamı üçün bir geniş zirvə, bütün səhnələşdirmələr üçün bir geniş top düzəltdik və hər şeyi orada çəkirik. Graylog bütün bunları paralel olaraq çıxarır.
Sual: Bu rozetkalı şamanizm bizə niyə lazımdır? Konteynerlər üçün syslog log drayverindən istifadə etməyə cəhd etmisinizmi?
Cavab: Bu sualı verdiyimiz vaxt dokerlə münasibətlərimiz gərgin idi. Bu docker 1.0 və ya 0.9 idi. Docker özü qəribə idi. İkincisi, əgər siz də ona logları itələyirsinizsə... Məndə təsdiqlənməmiş bir şübhə var ki, o, docker demonu vasitəsilə bütün logları özündən keçir. Əgər bir API çılğınlaşsa, o zaman qalan API-lər stdout və stderr göndərə bilməyəcəkləri faktı ilə qarşılaşacaqlar. Bunun hara aparacağını bilmirəm. Bu yerdə docker syslog sürücüsündən istifadə etməyin lazım olmadığı hissi səviyyəsində bir şübhəm var. Funksional sınaq departamentimizin qeydləri olan öz Graylog klasteri var. Onlar docker log sürücülərindən istifadə edirlər və orada hər şey qaydasındadır. Ancaq dərhal Graylog-a GELF yazırlar. Bütün bunlara başladığımız anda bizə sadəcə işləmək lazım idi. Ola bilsin, sonra kimsə gəlib deyəndə ki, yüz ildir ki, normal işləyir, biz cəhd edəcəyik.
Sual: Siz rsyslog istifadə edərək məlumat mərkəzləri arasında çatdırırsınız. Niyə Kafkada olmasın?
Cavab: Biz bunu edirik və əslində belədir. İki səbəbə görə. Kanal tamamilə ölüdürsə, bütün loglarımız, hətta sıxılmış formada olsa da, onun içindən keçməyəcəkdir. Və kafka onlara prosesdə sadəcə uduzmağa imkan verir. Beləliklə, bu logların yapışmasından xilas oluruq. Biz bu işdə birbaşa olaraq Kafkadan istifadə edirik. Yaxşı bir kanalımız varsa və onu azad etmək istəyiriksə, biz onların rsyslog-dan istifadə edirik. Amma əslində, siz onu elə qura bilərsiniz ki, keçə bilmədiklərini atsın. Hazırda biz sadəcə olaraq rsyslog çatdırılmasından birbaşa haradasa, haradasa Kafkadan istifadə edirik.
Mənbə: www.habr.com