Thanos - Ölçəklənən Prometey

Məqalənin tərcüməsi kursun tələbələri üçün xüsusi hazırlanmışdır "DevOps təcrübələri və alətləri".

Fabian Reinartz proqram tərtibatçısı, Go fanatik və problem həlledicisidir. O, həmçinin Prometheus-un baxıcısı və Kubernetes SIG cihazlarının həmtəsisçisidir. Keçmişdə o, SoundCloud-da istehsal mühəndisi olub və CoreOS-da monitorinq qrupuna rəhbərlik edib. Hazırda Google-da işləyir.

Bartek Plotka - Improbable şirkətində infrastruktur mühəndisi. O, yeni texnologiyalar və paylanmış sistemlərin problemlərini sevir. O, Intel-də aşağı səviyyəli proqramlaşdırma təcrübəsinə, Mesos-da töhfə verən təcrübəyə və Improbable-da dünya səviyyəli SRE istehsal təcrübəsinə malikdir. Mikroservislər dünyasını təkmilləşdirməklə məşğuldur. Onun üç sevgisi Qolanq, açıq mənbə və voleyboldur.

Flaqman məhsulumuz SpatialOS-a baxaraq, ehtimal edə bilərsiniz ki, Improbable-ın onlarla Kubernetes klasteri olan yüksək dinamik qlobal bulud infrastrukturuna ehtiyacı var. Biz monitorinq sistemindən ilk istifadə edənlərdən olduq Prometey. Prometheus milyonlarla real vaxt göstəricilərini izləmək qabiliyyətinə malikdir və sizə lazım olan məlumatları çıxarmaq üçün güclü sorğu dili ilə gəlir.

Prometeyin sadəliyi və etibarlılığı onun əsas üstünlüklərindən biridir. Lakin müəyyən miqyasdan keçəndən sonra bir sıra çatışmazlıqlarla qarşılaşdıq. Bu problemləri həll etmək üçün biz inkişaf etdik Thanos mövcud Prometheus klasterlərini qeyri-məhdud tarixi məlumat saxlama ilə vahid monitorinq sisteminə problemsiz şəkildə çevirmək üçün Improbable tərəfindən yaradılmış açıq mənbə layihəsidir. Thanos Github-da mövcuddur burada.

Improbable-dan ən son xəbərlərdən xəbərdar olun.

Thanos ilə hədəflərimiz

Müəyyən bir miqyasda, vanil Prometeyin imkanlarından kənar problemlər yaranır. Petabaytlarla tarixi məlumatı necə təhlükəsiz və qənaətlə saxlamaq olar? Bunu sorğunun cavab müddətini itirmədən etmək olarmı? Fərqli Prometheus serverlərində yerləşən bütün ölçülərə bir API sorğusu ilə daxil olmaq mümkündürmü? Prometheus HA ilə toplanmış təkrarlanan məlumatları birləşdirmək üçün hər hansı bir yol varmı?

Bu problemləri həll etmək üçün biz Thanos yaratdıq. Aşağıdakı bölmələr bu məsələlərə necə yanaşdığımızı təsvir edir və qarşıya qoyduğumuz məqsədləri izah edir.

Çoxsaylı Prometheus nümunələrindən sorğu datası (qlobal sorğu)

Prometheus, parçalanmaya funksional yanaşma təklif edir. Hətta tək bir Prometheus serveri demək olar ki, bütün istifadə vəziyyətlərində istifadəçiləri üfüqi parçalanmanın mürəkkəbliyindən azad etmək üçün kifayət qədər genişlənmə imkanını təmin edir.

Bu əla yerləşdirmə modeli olsa da, tez-tez müxtəlif Prometheus serverlərindəki məlumatlara tək API və ya UI - qlobal görünüş vasitəsilə daxil olmaq tələb olunur. Əlbəttə ki, bir Grafana panelində bir neçə sorğu göstərmək mümkündür, lakin hər sorğu yalnız bir Prometheus serverinə edilə bilər. Digər tərəfdən, Thanos ilə siz bir çox Prometheus serverindən məlumatları sorğulaya və birləşdirə bilərsiniz, çünki onların hamısı eyni son nöqtədən əldə edilə bilər.

Əvvəllər, Improbable-da qlobal bir görünüş əldə etmək üçün biz Prometheus nümunələrimizi çox səviyyəli olaraq təşkil etdik. İerarxik Federasiya. Bu, hər bir “yarpaq” serverdən ölçülərin bir hissəsini toplayan bir Prometheus meta serverinin yaradılması demək idi.

Thanos - Ölçəklənən Prometey

Bu yanaşma problemli olduğunu sübut etdi. Bu, daha mürəkkəb konfiqurasiya ilə nəticələndi, əlavə potensial uğursuzluq nöqtəsi əlavə etdi və federasiya edilmiş son nöqtəni yalnız ehtiyac duyduğu məlumatlarla təmin etmək üçün mürəkkəb qaydaları tətbiq etdi. Bundan əlavə, bu cür federasiya əsl qlobal görünüş əldə etməyə imkan vermir, çünki bütün məlumatlar bir API sorğusunda mövcud deyil.

Bununla yaxından əlaqəli, yüksək əlçatanlıqlı (HA) Prometheus serverlərində toplanmış məlumatların vahid görünüşüdür. Prometheus HA modeli müstəqil olaraq iki dəfə məlumat toplayır, bu da əldə etdiyi qədər sadədir. Bununla belə, hər iki axının birləşmiş və təkmilləşdirilmiş təsvirindən istifadə etmək daha rahat olardı.

Əlbəttə ki, yüksək əlçatan Prometheus serverlərinə ehtiyac var. Improbable-da biz hər dəqiqə məlumatların monitorinqinə ciddi yanaşırıq, lakin hər klasterdə bir Prometheus nümunəsinin olması yeganə uğursuzluq nöqtəsidir. İstənilən konfiqurasiya xətası və ya aparat çatışmazlığı potensial olaraq mühüm məlumatların itirilməsi ilə nəticələnə bilər. Hətta sadə yerləşdirmə metriklərin toplanmasında cüzi nasazlıqlarla nəticələnə bilər, çünki yenidən başlatma qırıntı intervalından xeyli uzun ola bilər.

Tarixi məlumatların etibarlı saxlanması

Metriklərin ucuz, sürətli və uzunmüddətli saxlanması bizim arzumuzdur (Prometheus istifadəçilərinin əksəriyyəti tərəfindən paylaşılır). Improbable-da biz ölçülərin saxlanma müddətini doqquz günə təyin etmək məcburiyyətində qaldıq (Prometheus 1.8 üçün). Bu, nə qədər geriyə baxa biləcəyimizə açıq məhdudiyyətlər əlavə edir.

Prometheus 2.0 bu baxımdan təkmilləşdi, çünki zaman seriyalarının sayı artıq serverin ümumi performansına təsir etmir (aşağıya bax). Prometheus 2 haqqında KubeCon əsas çıxışı). Bununla belə, Prometheus məlumatları yerli diskdə saxlayır. Yüksək effektiv məlumat sıxışdırması yerli SSD-nin istifadəsini əhəmiyyətli dərəcədə azalda bilsə də, son nəticədə saxlanıla bilən tarixi məlumatların miqdarında məhdudiyyət var.

Bundan əlavə, Improbable-da biz etibarlılıq, sadəlik və qiymətə əhəmiyyət veririk. Böyük yerli diskləri saxlamaq və ehtiyat nüsxələmək daha çətindir. Onlar daha baha başa gəlir və daha çox ehtiyat alətləri tələb edir, nəticədə lazımsız mürəkkəblik yaranır.

Aşağı seçmə

Tarixi məlumatlar ilə işləməyə başlayan kimi anladıq ki, həftələr, aylar və illər ərzində verilənlərlə işləsək, böyük O ilə bağlı fundamental çətinliklər var ki, sorğuları daha yavaş və yavaş edir.

Bu problemin standart həlli olacaq aşağı seçmə (aşağı seçmə) - siqnalın seçmə tezliyinin azaldılması. Aşağı seçmə ilə biz daha böyük bir zaman diapazonuna “kiçildəyə” və eyni sayda nümunələri saxlaya bilərik ki, bu da sorğularımızı cavablandıracaq.

Köhnə məlumatların nümunəsinin aşağı salınması istənilən uzunmüddətli saxlama həllinin qaçınılmaz tələbidir və vanil Prometeydən kənara çıxır.

Əlavə məqsədlər

Thanos layihəsinin ilkin məqsədlərindən biri hər hansı mövcud Prometheus qurğuları ilə qüsursuz inteqrasiya idi. İkinci məqsəd giriş üçün minimum maneə ilə sadə əməliyyat idi. İstənilən asılılıq həm kiçik, həm də böyük istifadəçilər üçün asanlıqla təmin edilməlidir ki, bu da cüzi əsas xərcləri nəzərdə tutur.

Thanos memarlığı

Əvvəlki bölmədə məqsədlərimizi sadaladıqdan sonra gəlin onların üzərində işləyək və Thanos-un bu problemləri necə həll etdiyini görək.

qlobal görünüş

Mövcud Prometheus nümunələri üzərində qlobal görünüş əldə etmək üçün biz bütün serverlərə tək sorğu giriş nöqtəsini bağlamalıyıq. Thanos komponenti məhz bunu edir. Sidecar. O, hər bir Prometheus serverinin yanında yerləşdirilir və gRPC Store API vasitəsilə yerli Prometheus məlumatlarına xidmət göstərən proksi kimi çıxış edir ki, bu da vaxt möhürü və vaxt diapazonu ilə vaxt seriyası məlumatlarını seçməyə imkan verir.

Digər tərəfdən, standart Prometheus HTTP API vasitəsilə PromQL sorğularına cavab verməkdən çox iş görən, üfüqi şəkildə miqyaslana bilən, vətəndaşlığı olmayan Querier komponentidir. Querier, Sidecar və digər Thanos komponentləri vasitəsilə qarşılıqlı əlaqə qurur qeybət protokolu.

Thanos - Ölçəklənən Prometey

  1. Querier sorğu aldıqdan sonra müvafiq Store API serverinə, yəni Sidecars-a qoşulur və müvafiq Prometheus serverlərindən zaman seriyası məlumatlarını alır.
  2. Bundan sonra o, cavabları birləşdirir və onlar üzrə PromQL sorğusunu yerinə yetirir. Querier həm üst-üstə düşməyən məlumatları, həm də Prometheus HA serverlərindən təkrarlanan məlumatları birləşdirə bilər.

Bu, tapmacamızın əsas hissəsini həll edir - təcrid olunmuş Prometheus serverlərindən məlumatların vahid görünüşdə birləşdirilməsi. Əslində, Thanos yalnız bu fürsət üçün istifadə edilə bilər. Mövcud Prometheus serverləri heç bir dəyişiklik tələb etmir!

Limitsiz saxlama vaxtı!

Bununla belə, gec-tez biz normal Prometheus saxlama müddətindən kənara çıxan məlumatları saxlamaq istəyəcəyik. Tarixi məlumatları saxlamaq üçün biz obyekt yaddaşını seçmişik. İstənilən buludda, eləcə də yerli məlumat mərkəzlərində geniş şəkildə mövcuddur və çox səmərəlidir. Bundan əlavə, demək olar ki, hər hansı bir obyekt yaddaşı tanınmış S3 API vasitəsilə mövcuddur.

Prometey RAM-dan diskə məlumatları təxminən iki saatdan bir yazır. Saxlanılan məlumat bloku müəyyən bir müddət üçün bütün məlumatları ehtiva edir və dəyişməzdir. Bu çox rahatdır, çünki Thanos Sidecar sadəcə Prometheus məlumat kataloquna baxa bilər və yeni bloklar göründükcə onları obyekt saxlama vedrələrinə yükləyə bilər.

Thanos - Ölçəklənən Prometey

Diskə yazdıqdan dərhal sonra obyekt anbarına yükləmə də “kazıyıcı” sadəliyini (Prometheus və Thanos Sidecar) toxunulmaz saxlayır. Bu, sistemin saxlanmasını, dəyərini və dizaynını asanlaşdırır.

Gördüyünüz kimi, məlumatların ehtiyat nüsxəsini çıxarmaq çox asandır. Bəs obyekt yaddaşında məlumatların sorğulanması haqqında nə demək olar?

Thanos Store komponenti obyekt anbarından məlumat almaq üçün proksi kimi çıxış edir. Thanos Sidecar kimi, dedi-qodu qruplarında iştirak edir və Store API tətbiq edir. Beləliklə, mövcud Sorğuçular onu Sidecar kimi qəbul edə bilər, vaxt seriyası məlumatlarının başqa bir mənbəyi kimi - heç bir xüsusi konfiqurasiya tələb olunmur.

Thanos - Ölçəklənən Prometey

Zaman seriyası məlumat blokları bir neçə böyük fayldan ibarətdir. Onları tələb olunduqda yükləmək olduqca səmərəsiz olardı və onları yerli olaraq keşləmə böyük miqdarda yaddaş və disk sahəsi tələb edərdi.

Bunun əvəzinə Store Gateway Prometheus yaddaş formatını necə idarə edəcəyini bilir. Ağıllı sorğu planlayıcısı və blokların yalnız zəruri indeks hissələrinin keşləşdirilməsi sayəsində obyekt saxlama fayllarına kompleks sorğuları HTTP sorğularının minimum sayına endirmək mümkün oldu. Beləliklə, sorğuların sayını dörd-altı miqyasda azaltmaq və ümumiyyətlə yerli SSD-də məlumat sorğularından fərqləndirmək çətin olan cavab müddətinə nail olmaq mümkündür.

Thanos - Ölçəklənən Prometey

Yuxarıdakı diaqramda göstərildiyi kimi, Thanos Querier, Prometheus saxlama formatından istifadə edərək və əlaqəli məlumatları yan-yana yerləşdirməklə obyektin saxlanmasında məlumat üçün hər sorğunun qiymətini əhəmiyyətli dərəcədə azaldır. Bu yanaşmadan istifadə edərək, bir çox tək sorğuları minimum sayda toplu əməliyyatlarda birləşdirə bilərik.

Sıxlaşdırma və aşağı nümunə götürmə

Zaman seriyası məlumatlarının yeni bloku obyekt anbarına uğurla yükləndikdən sonra, biz onu "tarixi" məlumat kimi qəbul edirik və bu, dərhal Store Gateway vasitəsilə əldə edilə bilər.

Lakin bir müddət sonra bir mənbədən olan bloklar (Prometheus with Sidecar) toplanır və indeksləşdirmənin bütün potensialından artıq istifadə etmir. Bu problemi həll etmək üçün biz Compactor adlı başqa bir komponent təqdim etdik. O, sadəcə olaraq yerli Prometheus sıxlaşdırma mexanizmini obyekt anbarındakı tarixi məlumatlara tətbiq edir və sadə dövri toplu iş kimi icra oluna bilər.

Thanos - Ölçəklənən Prometey

Səmərəli sıxılma sayəsində yaddaşın uzun müddət ərzində sorğulanması verilənlərin ölçüsü baxımından problem yaratmır. Bununla belə, bir milyard dəyərin açılması və onları sorğu prosessoru vasitəsilə idarə etməyin potensial dəyəri qaçılmaz olaraq sorğunun icra müddətinin kəskin artmasına səbəb olacaqdır. Digər tərəfdən, ekranda hər bir piksel üçün yüzlərlə məlumat nöqtəsi olduğundan, məlumatları tam qətnamə ilə göstərmək belə qeyri-mümkün olur. Beləliklə, aşağı seçmə yalnız mümkün deyil, lakin nəzərəçarpacaq dərəcədə dəqiqlik itkisinə səbəb olmayacaqdır.

Thanos - Ölçəklənən Prometey

Məlumatların aşağı seçilməsi üçün Compactor məlumatları davamlı olaraq beş dəqiqə və bir saatlıq qətnamə ilə birləşdirir. TSDB XOR sıxılma ilə kodlanmış hər bir xam fraqment üçün bir blok üçün min, maksimum və ya cəmi kimi müxtəlif növ cəmlənmiş məlumat saxlanılır. Bu, Querier-ə verilən PromQL sorğusu üçün uyğun olan aqreqatı avtomatik seçməyə imkan verir.

İstifadəçinin azaldılmış dəqiqlikli məlumatlardan istifadə etməsi üçün heç bir xüsusi konfiqurasiya tələb olunmur. Querier istifadəçi böyüdükcə və böyüdükcə avtomatik olaraq müxtəlif qətnamələr və xam məlumatlar arasında keçid edir. İstəyirsinizsə, istifadəçi bunu sorğudakı "addım" parametri vasitəsilə birbaşa idarə edə bilər.

Bir GB saxlama dəyəri aşağı olduğundan, Thanos standart olaraq orijinal məlumatları beş dəqiqə və bir saatlıq qətnamə ilə saxlayır. Orijinal məlumatları silməyə ehtiyac yoxdur.

Qeydiyyat qaydaları

Thanos ilə belə, qeyd qaydaları monitorinq yığınının vacib hissəsidir. Onlar sorğuların mürəkkəbliyini, gecikmə müddətini və qiymətini azaldır. Onlar həmçinin istifadəçilər üçün metriklər üzrə ümumiləşdirilmiş məlumatları əldə etmək üçün əlverişlidir. Thanos Prometheus-un vanil nümunələrinə əsaslanır, buna görə də mövcud Prometheus serverində qeyd qaydaları və xəbərdarlıq qaydalarını saxlamaq tamamilə məqbuldur. Ancaq bəzi hallarda bu kifayət olmaya bilər:

  • Qlobal xəbərdarlıq və qayda (məsələn, bir xidmət üç klasterdən ikisindən çoxunda işləmədikdə xəbərdarlıq).
  • Yerli yaddaşdan kənar verilənlər üçün qayda.
  • Bütün qaydaları və xəbərdarlıqları bir yerdə saxlamaq istəyi.

Thanos - Ölçəklənən Prometey

Bütün bu hallar üçün Thanos, Thanos Sorğuları vasitəsilə qayda və xəbərdarlığı qiymətləndirən Ruler adlı ayrıca komponenti ehtiva edir. Tanınmış StoreAPI təmin etməklə Sorğu qovşağı yeni hesablanmış ölçülərə daxil ola bilər. Daha sonra onlar həmçinin obyekt anbarında saxlanılır və Store Gateway vasitəsilə istifadəyə verilir.

Thanosun gücü

Thanos ehtiyaclarınıza uyğunlaşdırıla biləcək qədər çevikdir. Bu, adi Prometeydən köç edərkən xüsusilə faydalıdır. Kiçik bir nümunədən istifadə edərək Thanos komponentləri haqqında öyrəndiklərimizi tez nəzərdən keçirək. Vanil Prometeyinizi "məhdud metrik yaddaş" dünyasına necə gətirmək olar:

Thanos - Ölçəklənən Prometey

  1. Prometheus serverlərinizə Thanos Sidecar əlavə edin - məsələn, Kubernetes podunda qonşu konteyner.
  2. Verilənlərə baxmaq üçün çoxlu Thanos Querier replikalarını yerləşdirin. Bu nöqtədə, Scraper və Querier arasında dedi-qodu qurmaq asandır. Komponentlərin qarşılıqlı əlaqəsini yoxlamaq üçün 'thanos_cluster_members' metrikasından istifadə edin.

Təkcə bu iki addım potensial Prometheus HA replikalarından qlobal görünüş və qüsursuz məlumatların təkmilləşməsini təmin etmək üçün kifayətdir! Sadəcə olaraq idarə panellərinizi HTTP Querier son nöqtəsinə qoşun və ya birbaşa Thanos UI interfeysindən istifadə edin.

Bununla belə, ölçülərin ehtiyat nüsxəsinə və uzunmüddətli saxlanmasına ehtiyacınız varsa, atmalı olduğunuz daha üç addım var:

  1. AWS S3 və ya GCS kovası yaradın. Məlumatları bu vedrələrə köçürmək üçün Sidecar qurun. İndi yerli məlumat yaddaşını minimuma endirə bilərsiniz.
  2. Mağaza Gateway yerləşdirin və onu mövcud dedi-qodu qruplarına qoşun. İndi siz ehtiyat nüsxələrində olan məlumatlara sorğu göndərə bilərsiniz!
  3. Sıxlaşdırma və aşağı nümunələrdən istifadə edərək uzun müddət ərzində sorğu performansını yaxşılaşdırmaq üçün Compactor-u yerləşdirin.

Daha çox bilmək istəyirsinizsə, bizimlə tanış olmaqdan çəkinməyin kubernetlər açıq nümunələrdir и Başlarken!

Cəmi beş addımda biz Prometheus-u qlobal görünüş, limitsiz saxlama vaxtı və potensial yüksək göstəricilərə malik güclü monitorinq sisteminə çevirdik.

Çəkmə tələbi: sizə ehtiyacımız var!

Thanos əvvəldən açıq mənbəli layihə olmuşdur. Prometheus ilə qüsursuz inteqrasiya və Thanos-un yalnız bir hissəsindən istifadə etmək imkanı onu monitorinq sisteminizi səylə genişləndirmək üçün əla seçim edir.

Biz həmişə GitHub Pull İstəklərini və Problemlərini alqışlayırıq. Bu vaxt, Github Problemləri və ya boşluq vasitəsilə bizimlə əlaqə saxlamaqdan çekinmeyin Improbable-eng #thanossualınız və ya rəyiniz varsa və ya təcrübənizi bölüşmək istəyirsinizsə! Improbable-da gördüyümüz işləri bəyənirsinizsə, bizimlə əlaqə saxlamaqdan çekinmeyin - bizdə həmişə vakansiyalar var!

Kurs haqqında ətraflı məlumat əldə edin.

Mənbə: www.habr.com

Добавить комментарий