2019-cu ildir və Kubernetes-də qeydlərin yığılması üçün hələ də standart həllimiz yoxdur. Bu yazıda real təcrübədən nümunələrdən istifadə edərək axtarışlarımızı, qarşılaşdığımız problemləri və onların həlli yollarını bölüşmək istərdik.
Bununla belə, ilk növbədə, qeydlər toplayaraq müxtəlif müştərilərin çox fərqli şeyləri başa düşmələri üçün rezervasiya edəcəm:
- kimsə təhlükəsizlik və audit jurnallarını görmək istəyir;
- kimsə - bütün infrastrukturun mərkəzləşdirilmiş girişi;
- və bəziləri üçün, məsələn, balanslaşdırıcılar istisna olmaqla, yalnız proqram qeydlərini toplamaq kifayətdir.
Aşağıda müxtəlif “istək siyahıları”nı necə həyata keçirdiyimiz və hansı çətinliklərlə üzləşdiyimiz haqqında məlumat verilmişdir.
Nəzəriyyə: giriş alətləri haqqında
Giriş sisteminin komponentləri haqqında məlumat
Logging uzun bir yol keçmişdir, bunun nəticəsində jurnalların toplanması və təhlili üçün metodologiyalar hazırlanmışdır ki, bu gün bizim istifadə etdiyimiz üsuldur. Hələ 1950-ci illərdə Fortran standart giriş/çıxış axınlarının analoqunu təqdim etdi ki, bu da proqramçıya öz proqramını düzəltməyə kömək etdi. Bunlar o dövrün proqramçılarının həyatını asanlaşdıran ilk kompüter qeydləri idi. Bu gün biz onlarda giriş sisteminin ilk komponentini görürük - logların mənbəyi və ya “istehsalçısı”.
İnformatika bir yerdə dayanmadı: kompüter şəbəkələri meydana çıxdı, ilk klasterlər... Bir neçə kompüterdən ibarət mürəkkəb sistemlər işləməyə başladı. İndi sistem administratorları bir neçə maşından jurnal toplamaq məcburiyyətində qaldılar və xüsusi hallarda sistem nasazlığını araşdırmaq lazım gələrsə, OS nüvəsi mesajlarını əlavə edə bilərdilər. Mərkəzləşdirilmiş log toplama sistemlərini təsvir etmək üçün 2000-ci illərin əvvəllərində nəşr olundu , hansı remote_syslog standartlaşdırdı. Başqa bir vacib komponent belə ortaya çıxdı: log kollektoru və onların saxlanması.
Jurnalların həcminin artması və veb-texnologiyaların geniş tətbiqi ilə istifadəçilərə hansı jurnalların rahat şəkildə göstərilməli olduğu sualı ortaya çıxdı. Sadə konsol alətləri (awk/sed/grep) daha təkmil olanlarla əvəz edilmişdir izləyiciləri qeyd edin - üçüncü komponent.
Günlüklərin həcminin artması ilə əlaqədar başqa bir şey aydın oldu: loglara ehtiyac var, amma hamısı deyil. Və müxtəlif loglar müxtəlif səviyyələrdə qorunma tələb edir: bəziləri bir gündə itirilə bilər, digərləri isə 5 il saxlanmalıdır. Beləliklə, giriş sisteminə məlumat axınlarının süzülməsi və yönləndirilməsi üçün bir komponent əlavə edildi - gəlin onu adlandıraq filtr.
Yaddaş da böyük bir sıçrayış etdi: adi fayllardan əlaqəli verilənlər bazalarına, sonra isə sənəd yönümlü yaddaşa (məsələn, Elasticsearch). Beləliklə, anbar kollektordan ayrıldı.
Nəhayət, log anlayışı tarix üçün qorumaq istədiyimiz hadisələrin bir növ mücərrəd axınına qədər genişləndi. Daha doğrusu, araşdırma aparmaq və ya analitik hesabat tərtib etmək lazım gələrsə...
Nəticədə, nisbətən qısa müddət ərzində log kolleksiyası mühüm alt sistemə çevrildi və onu haqlı olaraq Big Data-nın alt bölmələrindən biri adlandırmaq olar.
Əgər bir vaxtlar adi çaplar “giriş sistemi” üçün kifayət edirdisə, indi vəziyyət çox dəyişib.
Kubernetes və loglar
Kubernetes infrastruktura gələndə artıq mövcud olan logların toplanması problemi də ondan yan keçmədi. Müəyyən mənada bu, daha da ağrılı oldu: infrastruktur platformasının idarə edilməsi nəinki sadələşdirildi, eyni zamanda mürəkkəbləşdi. Bir çox köhnə xidmətlər mikroservislərə köçməyə başlayıb. Jurnallar kontekstində bu, jurnal mənbələrinin sayının artmasında, onların xüsusi həyat dövründə və loglar vasitəsilə bütün sistem komponentlərinin əlaqələrini izləmək ehtiyacında özünü göstərir...
İrəliyə baxaraq deyə bilərəm ki, indi təəssüf ki, Kubernetes üçün digərləri ilə müsbət müqayisə edəcək standartlaşdırılmış giriş seçimi yoxdur. Cəmiyyətdə ən populyar sxemlər aşağıdakılardır:
- kimsə yığını açır EFK (Elasticsearch, Fluentd, Kibana);
- kimsə bu yaxınlarda sərbəst buraxılmağa çalışır və ya istifadə edir ;
- Bizə (və bəlkə də təkcə biz yox?..) Mən öz inkişafımdan çox razıyam - ...
Bir qayda olaraq, biz K8s klasterlərində aşağıdakı paketlərdən istifadə edirik (öz-özünə yerləşdirilən həllər üçün):
- ;
- .
Bununla belə, onların quraşdırılması və konfiqurasiyası üçün təlimatlar üzərində dayanmayacağam. Bunun əvəzinə mən onların çatışmazlıqlarına və ümumiyyətlə loglarla bağlı vəziyyətlə bağlı daha qlobal nəticələrə diqqət yetirəcəyəm.
K8-lərdə loglarla məşq edin
“Gündəlik qeydlər”, neçə nəfərsiniz?..
Kifayət qədər böyük bir infrastrukturdan logların mərkəzləşdirilmiş şəkildə toplanması logların toplanması, saxlanması və emalına sərf olunacaq xeyli vəsait tələb edir. Müxtəlif layihələrin istismarı zamanı biz müxtəlif tələblərlə və onlardan irəli gələn əməliyyat problemləri ilə qarşılaşdıq.
Gəlin ClickHouse-u sınayaq
Kifayət qədər aktiv şəkildə loglar yaradan bir proqramla layihədə mərkəzləşdirilmiş yaddaşa baxaq: saniyədə 5000-dən çox sətir. Gəlin onun qeydləri ilə işləməyə başlayaq, onları ClickHouse-a əlavə edək.
Maksimum real vaxt tələb olunan kimi, ClickHouse ilə 4 nüvəli server artıq disk alt sistemində həddən artıq yüklənəcək:
Bu cür yükləmə, mümkün qədər tez ClickHouse-da yazmağa çalışmağımızla bağlıdır. Verilənlər bazası buna artan disk yükü ilə reaksiya verir ki, bu da aşağıdakı səhvlərə səbəb ola bilər:
DB::Exception: Too many parts (300). Merges are processing significantly slower than inserts
Faktı deyil ClickHouse-da (onlarda log məlumatları var) yazma əməliyyatları zamanı öz çətinlikləri var. Onlara daxil edilən məlumatlar müvəqqəti bölmə yaradır, sonra əsas cədvəllə birləşdirilir. Nəticədə, qeyd diskdə çox tələbkar olur və yuxarıda qeyd etdiyimiz bir məhdudiyyətə də məruz qalır: 1 saniyədə 300-dən çox alt bölmə birləşdirilə bilməz (əslində bu, 300 əlavədir. saniyədə).
Bu davranışın qarşısını almaq üçün mümkün qədər böyük parçalarda və hər 1 saniyədə 2 dəfədən çox olmayaraq. Bununla belə, böyük partlayışlarla yazmaq, ClickHouse-da daha az yazmağı təklif edir. Bu, öz növbəsində, buferin daşmasına və logların itirilməsinə səbəb ola bilər. Həll yolu Fluentd buferini artırmaqdır, lakin sonra yaddaş istehlakı da artacaq.
Qeyd: ClickHouse ilə həllimizin digər problemli tərəfi bizim işimizdə bölmənin (loghouse) qoşulmuş xarici cədvəllər vasitəsilə həyata keçirilməsi ilə bağlı idi. . Bu, böyük vaxt intervallarını seçərkən həddindən artıq RAM tələb olunduğuna gətirib çıxarır, çünki metatable bütün arakəsmələr vasitəsilə təkrarlanır - hətta lazımi məlumatları ehtiva etməyənlər də. Ancaq indi bu yanaşma ClickHouse-un cari versiyaları üçün etibarlı şəkildə köhnəlmiş elan edilə bilər (c ).
Nəticədə məlum olur ki, hər bir layihənin ClickHouse-da real vaxt rejimində jurnal toplamaq üçün kifayət qədər resursu yoxdur (daha doğrusu, onların paylanması məqsədəuyğun olmayacaq). Bundan əlavə, istifadə etməlisiniz akkumulyator, daha sonra qayıdacağıq. Yuxarıda təsvir edilən hadisə realdır. Və o zaman biz müştəriyə uyğun və minimal gecikmə ilə logları toplamağa imkan verən etibarlı və sabit həll təklif edə bilmədik...
Bəs Elasticsearch?
Elasticsearch-in ağır iş yüklərini idarə etdiyi məlumdur. Gəlin bunu eyni layihədə sınayaq. İndi yük belə görünür:
Elasticsearch məlumat axınını həzm edə bildi, lakin ona belə həcmlərin yazılması CPU-dan çox istifadə edir. Buna klaster təşkil etməklə qərar verilir. Texniki cəhətdən bu problem deyil, amma belə çıxır ki, sadəcə log toplama sistemini idarə etmək üçün biz artıq təxminən 8 nüvədən istifadə edirik və sistemdə əlavə yüksək yüklənmiş komponent var...
Nəticə: bu seçim əsaslandırıla bilər, ancaq layihə böyükdürsə və onun rəhbərliyi mərkəzləşdirilmiş giriş sisteminə əhəmiyyətli resurslar sərf etməyə hazırdırsa.
O zaman təbii sual yaranır:
Hansı loglara həqiqətən ehtiyac var?
Gəlin yanaşmanın özünü dəyişdirməyə çalışaq: qeydlər eyni zamanda informativ olmalı və əhatə etməməlidir hər biri sistemdəki hadisə.
Tutaq ki, uğurlu onlayn mağazamız var. Hansı qeydlər vacibdir? Mümkün qədər çox məlumat toplamaq, məsələn, ödəniş şlüzindən, əla fikirdir. Lakin məhsul kataloqunda təsvir kəsmə xidmətinin bütün qeydləri bizim üçün vacib deyil: yalnız səhvlər və qabaqcıl monitorinq kifayətdir (məsələn, bu komponentin yaratdığı 500 səhvin faizi).
Beləliklə, belə bir nəticəyə gəldik mərkəzləşdirilmiş karotaj heç də həmişə özünü doğrultmur. Çox vaxt müştəri bütün qeydləri bir yerdə toplamaq istəyir, baxmayaraq ki, əslində bütün jurnaldan biznes üçün vacib olan mesajların yalnız şərti 5%-i tələb olunur:
- Bəzən, deyək ki, yalnız konteyner jurnalının ölçüsünü və səhv toplayıcısını (məsələn, Sentry) konfiqurasiya etmək kifayətdir.
- Səhv bildirişi və böyük bir yerli jurnalın özü hadisələri araşdırmaq üçün çox vaxt kifayət ola bilər.
- Yalnız funksional testlər və səhv toplama sistemləri ilə nəticələnən layihələrimiz var idi. Tərtibatçının qeydlərə ehtiyacı yox idi - səhv izlərindən tutmuş hər şeyi gördülər.
Həyatdan illüstrasiya
Başqa bir hekayə yaxşı nümunə ola bilər. Biz artıq Kubernetes-in tətbiqindən xeyli əvvəl hazırlanmış kommersiya həllindən istifadə edən müştərilərimizdən birinin təhlükəsizlik komandasından sorğu aldıq.
Korporativ problemlərin aşkarlanması sensoru - QRadar ilə mərkəzləşdirilmiş log toplama sistemi ilə "dostlaşmaq" lazım idi. Bu sistem syslog protokolu vasitəsilə qeydləri qəbul edə və onları FTP-dən götürə bilər. Bununla belə, onu fluentd üçün remote_syslog plagininə inteqrasiya etmək dərhal mümkün olmadı (məlum olduğu kimi, ). QRadar-ın qurulması ilə bağlı problemlər müştərinin təhlükəsizlik komandasının tərəfində olduğu ortaya çıxdı.
Nəticədə, biznes üçün kritik qeydlərin bir hissəsi FTP QRadar-a yükləndi, digər hissəsi isə birbaşa qovşaqlardan uzaq sistemloq vasitəsilə yönləndirildi. Bunun üçün hətta yazdıq - bəlkə də kiməsə oxşar problemi həll etməyə kömək edəcək... Nəticədə yaranan sxem sayəsində müştəri özü kritik jurnalları qəbul etdi və təhlil etdi (sevimli alətlərindən istifadə etməklə) və biz logging sisteminin dəyərini azalda bildik, yalnız keçən ay.
Başqa bir misal nə etməmək lazım olduğunu tamamilə göstərir. Emal üçün müştərilərimizdən biri hər biri istifadəçidən gələn hadisələr, multiline etdi strukturlaşdırılmamış çıxış jurnalda məlumat. Təxmin etdiyiniz kimi, bu cür qeydlər həm oxumaq, həm də saxlamaq üçün olduqca əlverişsiz idi.
Qeydlər üçün meyarlar
Bu cür nümunələr belə bir nəticəyə gətirib çıxarır ki, log toplama sistemini seçməklə yanaşı, lazımdır həmçinin logları özləri dizayn edirlər! Burada hansı tələblər var?
- Qeydlər maşın tərəfindən oxuna bilən formatda olmalıdır (məsələn, JSON).
- Qeydlər kompakt olmalıdır və mümkün problemləri aradan qaldırmaq üçün giriş dərəcəsini dəyişdirmək imkanına malik olmalıdır. Eyni zamanda, istehsal mühitlərində kimi bir giriş səviyyəsi ilə sistemləri işlətməlisiniz xəbərdarlıq və ya səhv.
- Loglar normallaşdırılmalıdır, yəni log obyektində bütün sətirlər eyni sahə tipinə malik olmalıdır.
Strukturlaşdırılmamış qeydlər logların yaddaşa yüklənməsi və onların işlənməsinin tam dayandırılması ilə bağlı problemlərə səbəb ola bilər. Bir illüstrasiya olaraq, çoxlarının səlis qeydlərdə mütləq qarşılaşdığı 400 xətası ilə bir nümunə:
2019-10-29 13:10:43 +0000 [warn]: dump an error event: error_class=Fluent::Plugin::ElasticsearchErrorHandler::ElasticsearchError error="400 - Rejected by Elasticsearch"
Səhv o deməkdir ki, növü qeyri-sabit olan sahəni hazır xəritə ilə indeksə göndərirsiniz. Ən sadə nümunə nginx jurnalında dəyişənli sahədir $upstream_status. O, həm nömrə, həm də sətirdən ibarət ola bilər. Misal üçün:
{ "ip": "1.2.3.4", "http_user": "-", "request_id": "17ee8a579e833b5ab9843a0aca10b941", "time": "29/Oct/2019:16:18:57 +0300", "method": "GET", "uri": "/staffs/265.png", "protocol": "HTTP/1.1", "status": "200", "body_size": "906", "referrer": "https://example.com/staff", "user_agent": "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/78.0.3904.70 Safari/537.36", "request_time": "0.001", "cache_status": "-", "upstream_response_time": "0.001, 0.007", "upstream_addr": "127.0.0.1:9000", "upstream_status": "200", "upstream_response_length": "906", "location": "staff"}
{ "ip": "1.2.3.4", "http_user": "-", "request_id": "47fe42807f2a7d8d5467511d7d553a1b", "time": "29/Oct/2019:16:18:57 +0300", "method": "GET", "uri": "/staff", "protocol": "HTTP/1.1", "status": "200", "body_size": "2984", "referrer": "-", "user_agent": "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/78.0.3904.70 Safari/537.36", "request_time": "0.010", "cache_status": "-", "upstream_response_time": "0.001, 0.007", "upstream_addr": "10.100.0.10:9000, 10.100.0.11:9000", "upstream_status": "404, 200", "upstream_response_length": "0, 2984", "location": "staff"}
Qeydlər göstərir ki, server 10.100.0.10 404 xətası ilə cavab verib və sorğu başqa məzmun yaddaşına göndərilib. Nəticədə qeydlərdəki dəyər belə oldu:
"upstream_response_time": "0.001, 0.007"
Bu vəziyyət o qədər yaygındır ki, hətta ayrılığa layiqdir .
Bəs etibarlılıq?
İstisnasız bütün qeydlərin həyati əhəmiyyət kəsb etdiyi vaxtlar var. Bununla da, yuxarıda təklif edilən/müzakirə olunan K8-lər üçün tipik log toplama sxemlərində problemlər var.
Məsələn, fluentd qısa müddətli konteynerlərdən log toplaya bilməz. Layihələrimizdən birində verilənlər bazası miqrasiya konteyneri 4 saniyədən az yaşadı və sonra silindi - müvafiq annotasiyaya görə:
"helm.sh/hook-delete-policy": hook-succeeded
Bu səbəbdən, miqrasiya icrası jurnalı yaddaşa daxil edilmədi. Bu işdə siyasət kömək edə bilər. before-hook-creation.
Başqa bir nümunə Docker jurnalının fırlanmasıdır. Tutaq ki, loglara aktiv şəkildə yazan bir proqram var. Normal şəraitdə biz bütün qeydləri emal etməyə müvəffəq oluruq, lakin problem yaranan kimi – məsələn, yuxarıda yanlış formatla təsvir edildiyi kimi – emal dayanır və Docker faylı fırladır. Nəticə odur ki, biznes üçün kritik qeydlər itirilə bilər.
Buna görə log axınlarını ayırmaq vacibdir, onların təhlükəsizliyini təmin etmək üçün ən qiymətli olanları birbaşa tətbiqə göndərmək. Bundan əlavə, bəzilərini yaratmaq artıq olmazdı logların "akkumulyatoru", kritik mesajları saxlayarkən qısa yaddaş əlçatmazlığına tab gətirə bilər.
Nəhayət, bunu unutmamalıyıq İstənilən alt sistemə düzgün nəzarət etmək vacibdir. Əks halda, səlis danışan bir vəziyyətdə olduğu bir vəziyyətə düşmək asandır CrashLoopBackOff və heç bir şey göndərmir və bu, vacib məlumatların itirilməsini vəd edir.
Tapıntılar
Bu yazıda Datadog kimi SaaS həllərinə baxmırıq. Burada təsvir edilən problemlərin bir çoxu qeydlərin toplanması üzrə ixtisaslaşmış kommersiya şirkətləri tərəfindən bu və ya digər şəkildə artıq həll olunub, lakin hər kəs müxtəlif səbəblərdən SaaS-dən istifadə edə bilmir. (əsas olanlar qiymət və 152-FZ uyğunluğudur).
Mərkəzləşdirilmiş log toplama əvvəlcə sadə bir iş kimi görünür, lakin heç də belə deyil. Bunu xatırlamaq vacibdir:
- Monitorinq və səhvlərin toplanması digər sistemlər üçün konfiqurasiya edilə bildiyi halda, yalnız kritik komponentlər ətraflı şəkildə daxil edilməlidir.
- İstehsalda qeydlər lazımsız yük əlavə etməmək üçün minimum səviyyədə saxlanılmalıdır.
- Qeydlər maşın tərəfindən oxuna bilən, normallaşdırılmalı və ciddi formata malik olmalıdır.
- Həqiqətən kritik jurnallar ayrı bir axınla göndərilməlidir, bunlar əsaslardan ayrılmalıdır.
- Sizi yüksək yükün partlamalarından xilas edə və anbardakı yükü daha vahid hala gətirə bilən bir günlük akkumulyatoru nəzərdən keçirməyə dəyər.
Bu sadə qaydalar, hər yerdə tətbiq olunarsa, yuxarıda təsvir olunan sxemlərin işləməsinə imkan verəcəkdir - baxmayaraq ki, vacib komponentlər (batareya) yoxdur. Bu cür prinsiplərə əməl etməsəniz, tapşırıq sizi və infrastrukturu asanlıqla sistemin digər yüksək yüklənmiş (və eyni zamanda səmərəsiz) komponentinə aparacaqdır.
PS
Bloqumuzda da oxuyun:
- «";
- «";
- «.
Mənbə: www.habr.com