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

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

Фабиан Рейнарц (Fabian Reinartz) — разработчик на софтуер, запален по Go и любител на сложни предизвикателства. Той е и мейнтейнер на Prometheus и съосновател на Kubernetes SIG instrumentation. Преди това е работил като production инженер в 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 (глобален запит)

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

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

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

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

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

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

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

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

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

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

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

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

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

Даунсэмплинг на стари данни е неизменна необходимост за всяко решение за дългосрочно съхранение и надхвърля стандартния 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 и поставяйки свързани данни близо един до друг. Чрез този подход можем да комбинираме множество единични заявки в минималното количество обемни операции.

Уплътняване и даунсэмплинг

След като новият блок от времеви серии данни успешно се зареди в обектното хранилище, го разглеждаме като “исторически” данни, които веднага стават достъпни чрез 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. Създайте bucket на AWS S3 или GCS. Настройте Sidecar да копира данни в тези bucket-и. Сега можете да минимизирате локалното съхранение на данни.
2. Разгърнете Store Gateway и го свържете с вече съществуващ gossip кластер. Сега можете да изпращате заявки за данни в резервни копия!
3. Разгърнете Compactor, за да подобрите ефективността на заявките за дълги периоди, използвайки компресия и downsampling.

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

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

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

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

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

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

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