Hər kəsə salam, mənim adım Aleksandr, mən CIAN-da mühəndis olaraq çalışıram və sistem administrasiyası ilə infrastruktur proseslərinin avtomatlaşdırılması ilə məşğul oluram. Keçən yazılardan birinin şərhlərində bizdən soruşdular ki, gündə 4 TB-lıq logları haradan alırıq və onlarla nə edirik. Bəli, loglarımız çoxdur və onların emalı üçün ayrı bir infrastruktur klasteri yaradılmışdır ki, bu da bizə problemləri tez həll etməyə imkan tanıyır. Bu məqalədə mən bir il ərzində onu daima artan məlumat axını ilə işləmək üçün necə adaptasiya etdiyimizi izah edəcəyəm.
Başlamış olduğumuz yer
Son bir neçə ildə cian.ru saytına olan yük çox sürətlə artdı və 2018-ci ilin üçüncü rübündə resursun ziyarətçi sayı ayda 11.2 milyon unikal istifadəçiyə çatdı. O vaxt kritik anlarda logların 40%-dəkini itirirdik, bu da bizə hadisələrlə tez məşğul olmağa imkan vermirdi və onların həllinə çox vaxt və enerji sərf edirdik. Həmçinin, problemi tapmaqda tez-tez çətinlik çəkirdik və o, müəyyən bir vaxtdan sonra təkrarlanırdı. Bu, nəsə etməli olduğumuz bir vəziyyət idi.
O dövrdə logları saxlamaq üçün 5.5.2 versiyalı ElasticSearch ilə 10 məlumat noddan ibarət bir klaster istifadə edirdik. Onu daha bir il əvvəl populyar və əlverişli bir həll olaraq əlavə etmişdik: o vaxt log axını bu qədər böyük deyildi, qeyri-standart konfiqurasiyaları düşünməyə dəyməzdi.
Giriş loglarının emalı Logstash tərəfindən beş ElasticSearch koordinatorunda müxtəlif portlarda təmin edilirdi. Bir indeks, ölçüsündən asılı olmayaraq, beş sharddan ibarət idi. Saatlıq və gündəlik rotasiya təşkil olunmuşdu, nəticədə klasterdə hər saat təxminən 100 yeni shard yaranırdı. Loglar çox olmadıqda, klaster işini görürdü və onun parametrləri üzərində heç kim çox dayanmadı.
Sürətli artım problemləri
Yaradılan logların həcmi çox sürətlə artdı, çünki iki proses bir-birini tamamladı. Bir tərəfdən, xidmətin istifadəçiləri artdı. Digər tərəfdən, biz köhnə monolitləri C# və Python dilində paralel mikrosistem memarlığına aktiv keçməyə başladıq. Bir neçə on yeni mikrosistem, monolitin bəzi hissələrini əvəz edərək, infrastruktur klasteri üçün daha çox loglar yaradmağa başladı.
Məhz bu miqyaslanma klasterin çoxlu idarə olunmaz hala gəlməsinə səbəb oldu. Loglar saniyəyə 20 min mesaj sürəti ilə gəlməyə başladıqda, tez-tez mənasız rotasiya shardların sayını 6 minə çatdırdı, bir nód üçün 600-dən çox shard düşdü.
Bu, əməli yaddaşın ayrılması ilə bağlı problemlərə səbəb oldu, nódun çökməsi zamanı bütün shardların eyni anda köçürülməsi başlayır, bu da trafikləri artırır və digər nódları yükləyirdi, bu da klasterdə məlumat yazılmasını demək olar ki, mümkün etmirdi. Və bu dövrdə loglarımız olmurdu. server Biz 1/10 klasteri itiraf edirdik. Kiçik ölçülü çox sayda indeks, çətinliklərimizi artırırdı.
Gözləmə siyahısı olmadan hadisənin səbəblərini anlamırdıq və bir gün eyni səhvləri təkrarlaya bilərdik, bu isə komandamızın ideologiyası üçün yolverilməz idi, çünki iş mexanizmlərimiz bunun əksinə, eyni problemləri heç vaxt təkrarlamamaq üzərində qurulmuşdur. Buna görə tam log həcminə və onların demək olar ki, real vaxt rejimində göndərilməsinə ehtiyacımız var idi, çünki növbətçi mühəndis komandası yalnız metriklərdən deyil, loglardan da alerta baxırdı. Problemin miqyasını anlamaq üçün — o dövrdə gündəlik log həcmi təxminən 2 TB idi.
Bizim məqsədimiz - log itkisinin tamamilə qarşısını almaq və fövqəladə hallar zamanı logların ELK klasterinə göndərilmə müddətini maksimum 15 dəqiqəyə endirmək idi (bu rəqəmə gələcəkdə daxili KPI kimi istinad edəcəyik).
Yeni dövriyyə mexanizmi və hot-warm düyünləri
Klasteri çevirmək üçün ElasticSearch versiyasını 5.5.2-dən 6.4.3-ə yeniləməklə başladıq. 5-ci versiyanın klasteri bir daha qaldı, onu söndürməyi və tamamilə yeniləməyi qərara aldıq - loglar belə yoxdur. Beləliklə, bu keçidi yalnız bir neçə saat ərzində etdik.
Bu mərhələdə ən əhəmiyyətli dəyişiklik üç düyünə koordinatör kimi Apache Kafka-nın vasitəçi buffer olaraq tətbiq edilməsi oldu. Mesaj brokeri ElasticSearch ilə problemlər zamanı log itkisindən qurtulmağımıza kömək etdi. Eyni zamanda, klasterimizə 2 düyün əlavə etdik və fərqli serverlərdə yerləşən üç "isti" düyünlə hot-warm arxitekturasına keçdik. Onlara itirilməməsi lazım olan logları - nginx və tətbiq səhvləri loglarını yönləndirdik. Digər düyünlərə isə kiçik loglar - debug, warning və s. göndərildi, 24 saatdan sonra isə "isti" düyünlərdən "önəmli" loglar köçürüldü.
Kiçik ölçülü indekslərin sayını artırmamaq üçün zamanla dövriyyədən ölçü əsaslı mexanizmə keçdik. Forumlarda indeks ölçüsünə görə dövriyyənin çox etibarsız olduğu haqqında çoxlu məlumat var idi, buna görə də biz indeksdəki sənəd sayına görə dövriyyə tətbiq etməyə qərar verdik. Hər indeksin sayını analiz etdik və dövriyyənin başlaması lazım olduğu sənəd sayını qeydə aldıq. Beləliklə, optimal shard ölçüsünə - 50 GB-dan çox olmadan - nail olduq.
Klasterin optimallaşdırılması
Amma tamamilə problemlərdən azad ola bilmədik. Təəssüf ki, hələ də kiçik indekslər meydana gəlirdi: onlar tələb olunan həcmi çatdıra bilmirdi, dövriyyəyə salınmırdı və üç gündən köhnə indekslərin qlobal təmizlənməsi ilə silinirdi, çünki tarixə görə dövriyyəni aradan qaldırdıq. Bu, məlumatların itirilməsinə səbəb oldu, çünki klusterdən bir indeks tamamilə yox olurdu və mövcud olmayan bir indeksə yazma cəhdi istifadə etdiyimiz curator logikasını pozurdu. Yazma üçün alias indeksə çevrilirdi və rollover logikasını pozaraq bəzi indekslərin 600 Gb-a qədər nəzarətsiz artmasına səbəb olurdu.
Məsələn, dövriyyə konfiqurasiyası üçün:
curator-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
Rollover alias olmadan bir xəta baş verdi:
ERROR alias "nginx_write" not found.
ERROR Failed to complete action: rollover. : Unable to perform index rollover with alias "nginx_write".
Bu problemin həllini növbəti iterasiya üçün saxladıq və başqa bir məsələyə keçdik: Logstash-ın daxil olan logları emal edən pull logika ilə işləməyə başladıq (artıq məlumatların silinməsi və zənginləşdirmə). Onu docker-da yerləşdirdik, docker-compose ilə başladıq, burada logstash-exporter yerləşdirdik, o da Prometheus-a log axını üçün metrikləri göndərir. Beləliklə, logların emalından məsul olan logstash instansiyalarının sayını rahatca dəyişdirmək imkanını verdik.
Biz klosteri inkişaf etdirərkən, cian.ru-nun aylıq unikal istifadəçi sayı 12.8 milyon artdı. Nəticədə, gördüyümüz dəyişikliklər istehsalda baş verən dəyişikliklərə tam uyğun gəlmədi və "isti" nodelərin yükü idarə edə bilməməsi ilə qarşılaşdıq, bu da logların çatdırılmasına gecikmələrə səbəb oldu. "İsti" məlumatları problemsiz aldıq, amma qalanlarının çatdırılmasında müdaxilə etməli olduq və indeksləri bərabər paylamaq üçün əl manevrləri ilə rollover etməli olduq.
Bu arada, klosterdə logstash instansiyalarının miqyaslandırılması və tənzimlənməsi çətinləşdi, çünki bu, yerli docker-compose idi və bütün əməliyyatlar əl ilə həyata keçirilirdi (yeni uç nöqtələr əlavə etmək üçün bütün serverlərdə docker-compose up -d yerinə yetirmək lazım idi).
Logların yenidən paylanması
Bu ilin sentyabr ayında hələ də monolit parçalamağa davam edirdik, klasterdə yük artırdı və log axını saniyədə 30 min mesajla yaxınlaşırdı.
Növbəti iterasiyaya avadanlıqları yeniləməklə başladıq. Beş koordinatordan üç nəfərə keçdik, məlumat nodlarını dəyişdik və həm maliyyə, həm də saxlama həcmi qazanmış olduq. Nodlar üçün iki konfiqurasiya istifadə edirik:
- "İsti" nodlar üçün: E3-1270 v6 / 960Gb SSD / 32 Gb x 3 x 2 (Hot1 üçün 3 və Hot2 üçün 3).
- "İsti" nodlar üçün: E3-1230 v6 / 4Tb SSD / 32 Gb x 4.
Bu iterasiyada mikroservislərin giriş loqlarını əhatə edən indeksin əvvəlki üç "isti" noddan ibarət olan ikinci qrupa köçürülməsini təmin etdik. İndi "isti" nodlarda məlumatları 20 saat saxlayırıq, sonra isə onları digər loqlarla birlikdə "isti" nodlardan "isti" nodlara köçürürük.
Kiçik indekslərin itməsi problemini onların rotasiyasını yenidən tənzimləməklə həll etdik. İndi indekslər, orada az məlumat olsa belə, hər halda 23 saatda bir rotasiya olunur. Bu, bölmələrin sayını bir az artırdı (təxminən 800 oldu), lakin klasterin performansı baxımından bu, dözüləndir.
Nəticədə, klasterdə altı "isti" və cəmi dörd "isti" nod yaranıb. Bu, uzun müddətli sorğularda azacıq gecikməyə səbəb olur, lakin gələcəkdə nodların sayını artırmaq bu problemi həll edəcək.
Bu iterasiyada yarı avtomatik miqyaslama problemini də həll etdik. Bunun üçün infrastruktur Nomad klasterini - artıq istehsalda yerləşdirdiyimizə bənzər bir klasteri işə saldıq. Hələ Logstashın sayı yükə görə avtomatik dəyişmir, lakin buna da gələcəyik.
Gələcək planlar
Reallaşdırılan konfiqurasiya yaxşı miqyaslanır və indiyə qədər 13.3 TB məlumat saxlayırıq — 4 gün ərzində bütün loqlar, bu, təcili alertlərin araşdırılması üçün vacibdir. Bir hissə loqlarımızı metriklərə çeviririk ki, onları Graphite-də toplayırıq. Mühəndislərin işini asanlaşdırmaq üçün infrastruktur klasteri üçün metriklərimiz və tipik problemlərin yarı avtomatik düzəldilməsi üçün skriptlərimiz var. Gələcək il planlaşdırılan data nodların sayının artmasından sonra məlumatların saxlanılma müddətini 4 gündən 7 günə çıxaracağıq. 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, uzunmüddətli araşdırmalar üçün isə telemetriya məlumatları mövcuddur.
2019-cu ilin oktyabrında cian.ru saytının aylıq istifadəçi sayı artıq 15.3 milyon unikala çatdı. Bu, loqların çatdırılması üçün mimari qərarın ciddi sınağı oldu.
İndi ElasticSearch-ı 7-ci versiyaya yeniləməyə hazırlaşırıq. Lakin bunun üçün 5.5 versiyasından köçmüş olan bir çox indeksin mappingini yeniləmək lazımdır, çünki onlar 6-cı versiyada deprecated elan edilib (7-ci versiyada isə onlar tamamilə yoxdur). Bu isə o deməkdir ki, yeniləmə prosesi zamanı mütləq bir fövqəladə hal olacaq, hansı ki, sualın həlli vaxtında bizi loqlardan məhrum edəcək. 7-ci versiyadan ən çox Kibana-nın inkişaf etmiş interfeysi və yeni filtrlarını gözləyirik.
Əsas məqsədimizə çatdıq: loqoları itirməyi dayandırdıq və infrastruktur klasterinin dayanıqlığını həftədə 2-3 düşüşdən ayda bir neçə saat xidmət işlərinə endirdik. Bu işlərin istehsalatda demək olar ki, heç bir əlaməti yoxdur. Ancaq indi xidmətimizdə baş verənləri dəqiq müəyyən edə bilirik, bunu sakit rejimdə sürətlə edə bilirik və loqoların itiriləcəyindən narahat olmuruq. Ümumilikdə, məmnunuq, xoşbəxtik və gələcək fədakarlıqlara hazırlaşırıq, onları sonra sizə paylaşacağıq.
Mənbə: habr.com
