Hər kəsə salam, mənim adım Alexander, mən CIAN-da mühəndis kimi işləyirəm və sistem idarəçiliyi və infrastruktur proseslərinin avtomatlaşdırılması ilə məşğulam. Əvvəlki məqalələrdən birinə şərhlərdə bizdən gündə 4 TB logları haradan əldə etdiyimizi və onlarla nə etdiyimizi söyləməyimizi istədik. Bəli, bizdə çoxlu loglar var və onları emal etmək üçün ayrıca infrastruktur klasteri yaradılıb ki, bu da problemləri tez həll etməyə imkan verir. Bu yazıda mən onu bir il ərzində getdikcə artan məlumat axını ilə işləmək üçün necə uyğunlaşdırdığımızdan danışacağam.
Haradan başladıq
Son bir neçə il ərzində cian.ru-da yük çox sürətlə artıb və 2018-ci ilin üçüncü rübündə resurs trafiki ayda 11.2 milyon unikal istifadəçiyə çatıb. O zaman kritik anlarda logların 40%-ə qədərini itirdik, buna görə də hadisələrin öhdəsindən tez gələ bilmədik və onları həll etmək üçün çox vaxt və səy sərf etdik. Biz də tez-tez problemin səbəbini tapa bilmirdik və bir müddət sonra təkrarlanırdı. Bu cəhənnəm idi və bununla bağlı nəsə etmək lazım idi.
O zaman biz qeydləri saxlamaq üçün standart indeks parametrləri ilə ElasticSearch 10 versiyası ilə 5.5.2 məlumat qovşağından ibarət klasterdən istifadə etdik. Bir ildən çox əvvəl məşhur və əlverişli bir həll kimi təqdim edildi: sonra logların axını o qədər də böyük deyildi, qeyri-standart konfiqurasiyalarla çıxış etməyin mənası yox idi.
Daxil olan qeydlərin emalı Logstash tərəfindən beş ElasticSearch koordinatorunun müxtəlif portlarında təmin edilib. Ölçüsündən asılı olmayaraq bir indeks beş parçadan ibarət idi. Saatlıq və gündəlik rotasiya təşkil edildi, nəticədə hər saatda klasterdə 100-ə yaxın yeni qəlpə meydana çıxdı. Çox jurnal olmasa da, çoxluq yaxşı öhdəsindən gəldi və heç kim onun parametrlərinə əhəmiyyət vermədi.
Sürətli böyümənin çətinlikləri
Yaradılan logların həcmi çox sürətlə artdı, çünki iki proses bir-birini üst-üstə düşürdü. Bir tərəfdən, xidmətdən istifadə edənlərin sayı artdı. Digər tərəfdən, biz C# və Python-da köhnə monolitlərimizi mişar edərək mikroservis arxitekturasına fəal şəkildə keçməyə başladıq. Monolitin hissələrini əvəz edən bir neçə onlarla yeni mikroservis infrastruktur klasteri üçün əhəmiyyətli dərəcədə daha çox jurnal yaratdı.
Bizi klasterin praktiki olaraq idarəolunmaz hala gətirdiyi nöqtəyə gətirən miqyas idi. Günlüklər saniyədə 20 min mesaj sürətlə gəlməyə başlayanda, tez-tez yararsız fırlanma qırıqların sayını 6 minə qədər artırdı və hər node üçün 600-dən çox parça var idi.
Bu, operativ yaddaşın ayrılması ilə bağlı problemlərə səbəb oldu və qovşaq qəzaya uğradıqda, bütün qırıntılar eyni vaxtda hərəkət etməyə başladı, trafiki çoxaldı və digər qovşaqları yüklədi, bu da klasterə məlumat yazmağı demək olar ki, qeyri-mümkün etdi. Və bu müddət ərzində logsuz qaldıq. Əgər serverdə problem yaranarsa, biz əsasən klasterin 1/10 hissəsini itirmişik. Çox sayda kiçik indeks mürəkkəbliyi əlavə etdi.
Günlüklər olmadan biz hadisənin səbəblərini başa düşmədik və gec-tez yenidən eyni dırmıqda addımlaya bilərdik və komandamızın ideologiyasında bu qəbuledilməz idi, çünki bütün iş mexanizmlərimiz bunun əksini etmək üçün hazırlanmışdır - heç vaxt təkrarlama eyni problemlər. Bunu etmək üçün bizə qeydlərin tam həcmi və onların demək olar ki, real vaxt rejimində çatdırılması lazım idi, çünki növbətçi mühəndislər qrupu xəbərdarlıqları təkcə metriklərdən deyil, həm də jurnallardan izləyirdi. Problemin miqyasını başa düşmək üçün o zaman logların ümumi həcmi gündə təxminən 2 TB idi.
Biz logların itkisini tamamilə aradan qaldırmağı və fors-major hallar zamanı onların ELK klasterinə çatdırılma müddətini maksimum 15 dəqiqəyə endirməyi qarşımıza məqsəd qoymuşuq (daxili KPI kimi sonradan bu rəqəmə istinad etdik).
Yeni fırlanma mexanizmi və isti-isti düyünlər
ElasticSearch versiyasını 5.5.2-dən 6.4.3-ə yeniləməklə klaster çevrilməsinə başladıq. Yenə 5-ci versiya klasterimiz öldü və biz onu söndürmək və tamamilə yeniləmək qərarına gəldik - hələ də qeydlər yoxdur. Beləliklə, biz bu keçidi cəmi bir neçə saat ərzində etdik.
Bu mərhələdəki ən genişmiqyaslı transformasiya Apache Kafka-nın ara bufer kimi koordinatoru olan üç qovşaqda həyata keçirilməsi idi. Mesaj brokeri bizi ElasticSearch ilə bağlı problemlər zamanı qeydləri itirməkdən xilas etdi. Eyni zamanda, biz klasterə 2 qovşaq əlavə etdik və məlumat mərkəzində müxtəlif raflarda yerləşən üç “isti” qovşaqla isti-isti arxitekturaya keçdik. Biz heç bir halda itirilməməli olan maskadan istifadə edərək qeydləri onlara yönləndirdik - nginx, eləcə də proqram xətası qeydləri. Kiçik qeydlər qalan qovşaqlara göndərildi - debug, xəbərdarlıq və s. və 24 saatdan sonra "isti" qovşaqlardan "vacib" qeydlər köçürüldü.
Kiçik indekslərin sayını artırmamaq üçün biz zamanın fırlanmasından yuvarlanma mexanizminə keçdik. Forumlarda indeks ölçüsünə görə fırlanmanın çox etibarsız olduğu barədə çoxlu məlumatlar var idi, buna görə də indeksdəki sənədlərin sayına görə fırlanmadan istifadə etmək qərarına gəldik. Hər bir indeksi təhlil etdik və fırlanmanın işləməli olduğu sənədlərin sayını qeyd etdik. Beləliklə, biz optimal parça ölçüsünə çatdıq - 50 GB-dan çox deyil.
Klaster optimallaşdırılması
Bununla belə, problemlərdən tam qurtula bilməmişik. Təəssüf ki, kiçik indekslər hələ də ortaya çıxdı: onlar göstərilən həcmə çatmadılar, fırlanmadılar və üç gündən köhnə indekslərin qlobal təmizlənməsi ilə silindi, çünki biz dövriyyəni tarixə görə çıxardıq. Bu, klasterdən olan indeksin tamamilə yox olması səbəbindən məlumat itkisinə səbəb oldu və mövcud olmayan indeksə yazmaq cəhdi idarəetmə üçün istifadə etdiyimiz kuratorun məntiqini pozdu. Yazı üçün ləqəb indeksə çevrildi və rollover məntiqini pozdu, bəzi indekslərin 600 GB-a qədər nəzarətsiz böyüməsinə səbəb oldu.
Məsələn, fırlanma konfiqurasiyası üçün:
сurator-elk-rollover.yaml
---
actions:
1:
action: rollover
options:
name: "nginx_write"
conditions:
max_docs: 100000000
2:
action: rollover
options:
name: "python_error_write"
conditions:
max_docs: 10000000
Əgər rollover ləqəbi yoxdursa, xəta baş verdi:
ERROR alias "nginx_write" not found.
ERROR Failed to complete action: rollover. <type 'exceptions.ValueError'>: Unable to perform index rollover with alias "nginx_write".
Bu problemin həllini növbəti iterasiyaya buraxdıq və başqa məsələ ilə məşğul olduq: daxil olan logları emal edən (lazımsız məlumatların silinməsi və zənginləşdirilməsi) Logstash-ın çəkmə məntiqinə keçdik. Biz onu docker-compose vasitəsilə işə saldığımız docker-ə yerləşdirdik və həmçinin log axınının operativ monitorinqi üçün Prometheus-a ölçüləri göndərən logstash-exporter-i də orada yerləşdirdik. Beləliklə, biz özümüzə hər bir jurnal növünün işlənməsi üçün cavabdeh olan logstash instansiyalarının sayını rəvan dəyişmək imkanı verdik.
Biz klasteri təkmilləşdirərkən cian.ru-nun trafiki ayda 12,8 milyon unikal istifadəçiyə qədər artdı. Nəticədə, çevrilmələrimizin istehsaldakı dəyişikliklərdən bir az geri qaldığı və "isti" qovşaqların yükün öhdəsindən gələ bilməməsi və logların bütün çatdırılmasını yavaşlatması ilə qarşılaşdıq. Biz "qaynar" məlumatları uğursuz aldıq, lakin biz qalanların çatdırılmasına müdaxilə etməli və indeksləri bərabər paylamaq üçün əl ilə çevirməli olduq.
Eyni zamanda, klasterdəki logstash instansiyalarının parametrlərinin miqyasının dəyişdirilməsi və dəyişdirilməsi onun yerli docker-bəstəkar olması və bütün hərəkətlərin əl ilə yerinə yetirilməsi ilə çətinləşdi (yeni sonlar əlavə etmək üçün bütün sənədləri əl ilə keçmək lazım idi). serverlər və docker-compose up -d hər yerdə).
Jurnalın yenidən paylanması
Bu ilin sentyabr ayında biz hələ də monoliti kəsirdik, klasterin yükü artırdı və logların axını saniyədə 30 min mesaja yaxınlaşırdı.
Növbəti iterasiyaya aparat yeniləməsi ilə başladıq. Beş koordinatordan üçə keçdik, məlumat qovşaqlarını əvəz etdik və pul və saxlama sahəsi baxımından qalib gəldik. Düyünlər üçün iki konfiqurasiyadan istifadə edirik:
- “Qaynar” qovşaqlar üçün: E3-1270 v6 / 960Gb SSD / 32 Gb x 3 x 2 (Hot3 üçün 1 və Hot3 üçün 2).
- “İsti” qovşaqlar üçün: E3-1230 v6 / 4Tb SSD / 32 Gb x 4.
Bu iterasiyada biz ön xətt nginx qeydləri ilə eyni yer tutan mikroservislərin giriş qeydləri ilə indeksi üç “qaynar” qovşaqdan ibarət ikinci qrupa köçürdük. İndi biz məlumatları "isti" qovşaqlarda 20 saat saxlayırıq və sonra onları "isti" qovşaqlara qeydlərin qalan hissəsinə ötürürük.
Kiçik indekslərin fırlanmalarını yenidən konfiqurasiya etməklə yoxa çıxması problemini həll etdik. İndi indekslər hər 23 saatdan bir fırlanır, hətta orada az məlumat olsa belə. Bu, qəlpələrin sayını bir qədər artırdı (onların təxminən 800-ü var idi), lakin klaster performansı baxımından buna dözmək olar.
Nəticədə, klasterdə altı "isti" və yalnız dörd "isti" qovşaq var idi. Bu, uzun müddət ərzində sorğularda bir qədər gecikməyə səbəb olur, lakin gələcəkdə qovşaqların sayının artırılması bu problemi həll edəcək.
Bu iterasiya həm də yarı avtomatik miqyaslamanın olmaması problemini həll etdi. Bunun üçün biz Nomad klaster infrastrukturunu yerləşdirdik - istehsalda artıq yerləşdirdiyimiz kimi. Hələlik, Logstash miqdarı yükdən asılı olaraq avtomatik olaraq dəyişmir, lakin biz buna gələcəyik.
Gələcək üçün planlar
Tətbiq edilmiş konfiqurasiya mükəmməl şəkildə ölçülür və indi biz 13,3 TB məlumat saxlayırıq - bütün qeydləri 4 gün ərzində, xəbərdarlıqların təcili təhlili üçün lazımdır. Biz bəzi qeydləri Graphite-ə əlavə etdiyimiz metriklərə çeviririk. Mühəndislərin işini asanlaşdırmaq üçün bizdə infrastruktur klasteri üçün ölçülər və ümumi problemlərin yarı avtomatik təmiri üçün skriptlər var. Gələn il üçün nəzərdə tutulan məlumat qovşaqlarının sayını artırdıqdan sonra biz məlumatların saxlanmasına 4 gündən 7 günə keçəcəyik. Bu, operativ iş üçün kifayət edəcək, çünki biz həmişə hadisələri mümkün qədər tez araşdırmağa çalışırıq və uzunmüddətli araşdırmalar üçün telemetriya məlumatları var.
2019-cu ilin oktyabr ayında cian.ru-ya gələn trafik ayda 15,3 milyon unikal istifadəçiyə qədər artmışdı. Bu, logların çatdırılması üçün memarlıq həllinin ciddi sınağı oldu.
İndi biz ElasticSearch-i 7-ci versiyaya yeniləməyə hazırlaşırıq. Bununla belə, bunun üçün biz ElasticSearch-də bir çox indekslərin xəritələşdirilməsini yeniləməli olacağıq, çünki onlar 5.5 versiyasından köçüb və 6-cı versiyada köhnəlmiş kimi elan ediliblər (onlar sadəcə versiyada mövcud deyil). 7). Bu o deməkdir ki, yeniləmə prosesi zamanı mütləq bir növ fors-major olacaq və bu, problem həll olunana qədər bizi qeydlərsiz qoyacaq. 7-ci versiyadan biz ən çox təkmilləşdirilmiş interfeys və yeni filtrlərlə Kibana gözləyirik.
Biz əsas məqsədimizə nail olduq: logların itirilməsini dayandırdıq və infrastruktur klasterinin dayanma müddətini həftədə 2-3 qəzadan ayda bir neçə saat texniki xidmət işlərinə qədər azaldıb. İstehsalda bütün bu işlər demək olar ki, görünməzdir. Bununla belə, indi xidmətimizlə nə baş verdiyini dəqiq müəyyən edə bilərik, biz bunu tez bir zamanda sakit rejimdə edə bilərik və qeydlərin itiriləcəyindən narahat olmaya bilərik. Ümumiyyətlə, biz razıyıq, xoşbəxtik və daha sonra danışacağımız yeni istismarlara hazırlaşırıq.
Mənbə: www.habr.com