Thanos — мащабируем Prometheus

Преводът на статията е подготвен специално за студентите в курса „DevOps практики и инструменти“.

Фабиан Рейнарц (Fabian Reinartz) — разработчик на софтуер, фен на Go и любител на сложни задачи. Също така той е мейнтейнер на Prometheus и съосновател на Kubernetes SIG instrumentation. В миналото е бил инженер по продукцията в SoundCloud и е ръководил екипа по мониторинг в CoreOS. В момента работи в Google.

Бартек Плотка (Bartek Plotka) — инфраструктурен инженер в Improbable. Интересува се от нови технологии и проблеми на разпределени системи. Има опит в ниско ниво програмиране в Intel, опит като контрибутор в Mesos и световен SRE опит в Improbable. Работи за усъвършенстване на света на микросервисите. Трите му страсти: Golang, open source и волейбол.

Гледайки на нашия флагмански продукт SpatialOS, можете да се досетите, че за Improbable е нужна високомощна облачна инфраструктура от глобален мащаб с десетки Kubernetes клъстери. Бяхме сред първите, които започнаха да използват мониторинг системата Prometheus. Prometheus може да проследява милиони метрики в реално време и идва с мощен език за заявки, който позволява извличането на необходимата информация.

Простотата и надеждността на Prometheus е едно от основните му предимства. Въпреки това, когато достигнем определен мащаб, се сблъскваме с няколко недостатъка. За да решим тези проблеми, разработихме Thanos — проект с отворен код, създаден от Improbable, за безпроблемна трансформация на съществуващите Prometheus клъстери в единна система за мониторинг с неограничено хранилище на исторически данни. Thanos е наличен в Github тук..

Бъдете в крак с последните новини от Improbable.

Нашите цели с Thanos

При определен мащаб възникват проблеми, извън възможностите на ваниловия Prometheus. Как надеждно и икономично да съхраняваме петабайти исторически данни? Можем ли да го направим без да компрометираме времето за отговор на запитвания? Можем ли да получим достъп до всички метрики, разположени на различни Prometheus сървъри, с един API-запит? Можем ли по някакъв начин да обединим репликираните данни, събрани с Prometheus HA?

За да отговорим на тези въпроси, създадохме Thanos. В следващите раздели ще опишем как подходихме към решението на тези въпроси и ще обясним целите, които преследвахме.

Запитване на данни от множество инстанции на Prometheus (global query)

Prometheus предлага по-функционален подход към шардинга. Дори един Prometheus-сървър осигурява достатъчна мащабируемост, за да освободи потребителите от сложностите на хоризонталния шардинг практически при всички сценарии на употреба.

Въпреки че е отличен модел за разгръщане, често се изисква достъп до данни на различни Prometheus-сървъри чрез единен API или UI — глобален изглед. Разбира се, има възможност да се визуализират няколко запитвания в една панел на Grafana, но всяко запитване може да бъде изпълнено само на един сървър Prometheus. От друга страна, с помощта на Thanos можете да запитвате и агрегирате данни от множество Prometheus-сървъри, тъй като всички те са достъпни от една крайна точка.

Преди това, за да получим глобален изглед в Improbable, организирахме нашите инстанции Prometheus в многослойна Йерархична федерация. Това означаваше създаване на един мета-сървър Prometheus, който събира част от метриките от всеки "листов" сървър.

Този подход се оказа проблематичен. Той доведе до усложняване на конфигурацията, добавяне на допълнителна потенциална точка на отказ и прилагане на сложни правила за предоставяне на федеративната крайна точка само на необходимите данни. Освен това, такава федерация не позволява да се получи истински глобален изглед, тъй като не всички данни са налични от едно API запитване.

Това е тясно свързано с единното представяне на данните, събрани на сървъри Prometheus с висока наличност (high-availability, HA). HA-моделът на Prometheus независимо събира данни два пъти, което е толкова просто, че не може да бъде по-просто. Въпреки това, използването на комбинирано и дедuplicирано представяне на двата потока би било много по-удобно.

Разбира се, в сървърите Prometheus с висока наличност има необходимост. В Improbable наистина вземаме на сериозно мониторинга на данните в минута, но наличието на един екземпляр Prometheus в кластера е единна точка на отказ. Всяка грешка в конфигурацията или повреда на оборудването потенциално може да доведе до загуба на важни данни. Дори просто разгръщане може да доведе до малки неизправности в събирането на метрики, тъй като рестартирането може да отнеме значително повече време от интервала на сканирането.

Надеждно съхранение на исторически данни

Евтино, бързо и дългосрочно хранилище на метрики — това е нашата мечта (споделяна от мнозинството потребители на Prometheus). В Improbable бяхме принудени да настроим срока на съхранение на метрики на девет дни (за Prometheus 1.8). Това добавя очевидни ограничения за това колко назад можем да погледнем.

Prometheus 2.0 в това отношение стана по-добър, тъй като количеството времеви редици вече не влияе на общата производителност на сървъра (виж KubeCon keynote за Prometheus 2). Въпреки това Prometheus съхранява данни на локален диск. Въпреки че високо ефективното компресиране на данни може значително да намали използването на локален SSD, в крайна сметка все пак съществува ограничение на обема на съхраняваните исторически данни.

Освен това, в Improbable се грижим за надеждността, простотата и разходите. Големите локални дискове са по-трудни за експлоатация и архивиране. Те са по-скъпи и изискват повече инструменти за архивиране, което води до излишна сложност.

Даунсэмплинг

След като започнахме да работим с исторически данни, осъзнахме, че съществуват фундаментални сложности с O-голямо, които правят заявките все по-бавни, когато работим с данни за седмици, месеци и години.

Стандартното решение на този проблем е даунсэмплинг (downsampling) — намаляване на честотата на дискретизация на сигнала. Чрез понижаване на дискретизацията можем да "намалим мащаба" до по-дълъг времеви диапазон и да поддържаме предишния брой проби, което позволява запазване на отзивчивостта на заявките.

Даунсэмплингът на стари данни е неизменна необходимост за всяко решение за дългосрочно съхранение и излиза извън рамките на ваниловия Prometheus.

Допълнителни цели

Една от първоначалните цели на проекта Thanos беше безшевното интегриране с всяка съществуваща инсталация на Prometheus. Втората цел беше проста експлоатация с минимална входна бариера. Всички зависимости трябва да бъдат лесно удовлетворени както за малки, така и за големи потребители, което предполага и минимална базова цена.

Архитектура на Thanos

След като в предишния раздел бяха изброени нашите цели, нека да работим над тях и да видим как Thanos решава тези проблеми.

Глобален изглед

За да получим глобален изглед над съществуващите инстанции на Prometheus, трябва да свържем единна точка за вход на запитванията с всички сървъри. Именно това прави компонентът Thanos. Sidecar. Той се разгръща до всеки сървър на Prometheus и работи като прокси, обслужвайки локалните данни на Prometheus чрез gRPC интерфейса Store API, който позволява извличането на времеви редове данни по етикети и времеви диапазон.

От друга страна имаме хоризонтално мащабируем компонент Querier без запазване на състоянието, който прави малко повече от просто отговаряне на запитвания PromQL чрез стандартния HTTP API на Prometheus. Компонентите Querier, Sidecar и други Thanos взаимодействат по gossip протокол..

1. Querier, при получаване на запитване, се свързва с подходящия сървър на Store API, т.е. с нашите Sidecar и получава данните за времевите редове от съответните сървъри на Prometheus.
2. След това той обединява отговорите и извършва запитването по PromQL. Querier може да обединява както непокриващи се данни, така и дублирани данни от HA сървъри на Prometheus.

Това решава основната част от нашата пъзел — обединяване на данни от изолирани сървъри на Prometheus в единен изглед. Всъщност Thanos може да се използва само заради тази функция. В съществуващите сървъри на Prometheus не са необходими никакви промени!

Неограничен срок на съхранение!

Но рано или късно ще искаме да запазим данни, които надхвърлят обикновеното време на съхранение на Prometheus. За съхраняване на исторически данни избрахме обектно хранилище. То е широко достъпно в облака, както и в локалните ЦОД и е много икономично. Освен това почти всяко обектно хранилище е достъпно чрез добре познатото S3 API.

Prometheus записва данните от оперативната памет на диска на всеки два часа. Блокът на записваните данни съдържа всички данни за определен времеви период и е неизменим. Това е много удобно, тъй като Thanos Sidecar може просто да наблюдава каталога с данни на Prometheus и, когато се появят нови блокове, да ги зарежда в бакетите на обектното хранилище.

Зареждането в обектното хранилище веднага след записването на диска също така позволява да се запази простотата на „скрапера“ (Prometheus и Thanos Sidecar). Това опростява поддръжката, разходите и дизайна на системата.

Както виждате, архивирането на данни се реализира много просто. Но какво става с искането за данни в обектно хранилище?

Компонентът Thanos Store действа като прокси за получаване на данни от обектно хранилище. Както Thanos Sidecar, той участва в gossip-кластера и реализира Store API. По този начин, съществуващите Querier могат да го считат за Sidecar, като още един източник на времеви серии данни — не е необходима специална настройка.

Блоковете времеви серии данни се състоят от няколко големи файла. Зареждането им при поискване би било доста неефективно, а локалното кеширане би изисквало огромна памет и дисково пространство.

Вместо това, Store Gateway знае как да се справя с формата на съхранение на Prometheus. Със своят интелигентен планировчик на заявки и кеширане само на необходимите индексни части на блоковете, стана възможно да се намалят сложните заявки до минимално количество HTTP-заявки към файловете в обектното хранилище. По този начин броят на заявките може да бъде намален с четири до шест реда и да се постигне време за отговор, което е трудно да се различи от заявките към данни на локален SSD.

Както е показано на диаграмата по-горе, Thanos Querier значително намалява разходите за едно искане за данни в обектно хранилище, използвайки формата на съхранение на Prometheus и разполагайки свързани данни в близост. Използвайки този подход, можем да обединим множество единични заявки в минимално количество bulk-операции.

Уплътняване и понижаване на семплинг

След успешното зареждане на нов блок времеви серии данни в обектно хранилище, ние го разглеждаме като „исторически“ данни, които веднага стават достъпни чрез Store Gateway.

Обаче след известно време блоковете от един източник (Prometheus с Sidecar) се натрупват и вече не използват целия потенциал на индексирането. За да разрешим този проблем, въведохме още един компонент, наречен Compactor. Той просто прилага локален механизъм за уплътняване на Prometheus към историческите данни в обектното хранилище и може да бъде стартиран като просто периодично пакетно задание.

Благодарение на ефективно компресиране, заявките за съхранение за дълъг период не представляват проблем от гледна точка на размерите на данните. Въпреки това, потенциалната цена за разпаковане на милиард стойности и тяхното обработване неизбежно ще доведе до рязко увеличение на времето за изпълнение на заявката. От друга страна, тъй като на всеки пиксел на екрана се падат стотици точки данни, визуализирането на данните в пълно разрешение става невъзможно. Следователно, даунсэмплингът е не само възможен, но и няма да доведе до значителна загуба на точност.

За даунсэмплинг на данни, Compactor непрекъснато агрегират данни с разрешение от пет минути и един час. За всеки непреработен фрагмент, кодиран с помощта на TSDB XOR-компресия, се съхраняват различни типове агрегирани данни, като min, max или sum за един блок. Това позволява на Querier автоматично да избере агрегата, който е подходящ за даден PromQL-заявка.

За използване на данни с понижена точност на потребителя не е необходима специална конфигурация. Querier автоматично превключва между различни разрешения и непреработени данни в зависимост от увеличаването и намаляването на мащаба от потребителя. При желание потребителят може да управлява това директно чрез параметъра “step” в заявката.

Тъй като разходите за съхранение на един ГБ са малки, по подразбиране Thanos съхранява оригиналните данни, данните с разрешение от пет минути и един час. Няма нужда да се изтриват оригиналните данни.

Записващи правила

Дори с Thanos, записващите правила са съществена част от стека за мониторинг. Те намаляват сложността, закъснението и разходите на заявките. Те също така са удобни за потребителите при получаване на агрегирани данни по метрики. Thanos се основава на ванилови инстанции на Prometheus, така че е напълно приемливо да се съхраняват записващи правила и предупреждаващи правила на съществуващия сървър на Prometheus. Въпреки това, в някои случаи това може да е недостатъчно:

• Глобални предупреждения и правила (например, предупреждение, когато услуга не работи на повече от две от три клъстера).
• Правило за данни извън локалното хранилище.
• Стремеж към съхранение на всички правила и предупреждения на едно място.

За всички тези случаи Thanos включва отделен компонент, наречен Ruler, който изчислява правило и предупреждение чрез Thanos Queries. Предоставяйки добре известния StoreAPI, Query възелът може да получи достъп до свежо изчислени метрики. По-късно те също се запазват в обектно хранилище и стават достъпни посредством Store Gateway.

Мощта на Thanos

Thanos е достатъчно гъвкав, за да може да бъде настроен според вашите изисквания. Това е особено полезно при миграция от прост Prometheus. Нека да си припомним с един малък пример какво научихме за компонентите на Thanos. Ето как да прехвърлите вашия стандартен Prometheus в света на "неограниченото съхранение на метрики":

1. Добавете Thanos Sidecar към вашите Prometheus сървъри — например, съседен контейнер в Kubernetes pod.
2. Разгърнете няколко реплики на Thanos Querier за възможността да визуализирате данни. На този етап е лесно да настроите gossip между Scraper и Querier. За проверка на взаимодействието на компонентите използвайте метриката ‘thanos_cluster_members’.

Само тези две стъпки са достатъчни, за да осигурят глобален преглед и безпроблемна дедупликация на данни от потенциални HA реплики на Prometheus! Просто свържете вашите табла с HTTP Querier крайна точка или използвайте интерфейса на Thanos UI директно.

Обаче, ако ви е необходимо резервно копие на метрики и дългосрочно съхранение, трябва да извършите още три стъпки:

1. Създайте бакет AWS S3 или GCS. Настройте Sidecar да копира данни в тези бакети. Сега можете да минимизирате локалното съхранение на данни.
2. Разгърнете Store Gateway и го свържете с съществуващия gossip кластер. Сега можете да изпращате заявки за данни в резервни копия!
3. Разгърнете Compactor, за да увеличите ефективността на запитванията за дълги интервали от време, използвайки уплътняване и даунсъмплинг.

Ако искате да научите повече, не се колебайте, разгледайте нашите примери за манифеста kubernetes и първи стъпки!

Само за пет стъпки преобразувахме Prometheus в надеждна система за мониторинг с глобален преглед, неограничено време за съхранение и потенциална висока достъпност на метриките.

Pull request: нуждаем се от вас!

Thanos от самото начало беше проект с отворен код. Бесшовната интеграция с Prometheus и възможността да използвате само част от Thanos го прави страхотен избор за мащабиране на системата за мониторинг без излишни усилия.

Винаги сме радостни за GitHub Pull Request и Issues. В същото време не се колебайте да се свържете с нас чрез Github Issues или slack. Improbable-eng #thanos, ако имате въпроси или отзиви, или искате да споделите опита си с нас! Ако харесвате това, което правим в Improbable, не се колебайте да се свържете с нас — винаги имаме свободни позиции.!

Научете повече за курса.

Източник: habr.com