Танос - мащабируем Прометей

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

Фабиан Райнарц е разработчик на софтуер, Go фанатик и решава проблеми. Той също така поддържа Prometheus и е съосновател на Kubernetes SIG instrumentation. В миналото той е бил производствен инженер в SoundCloud и е ръководил екипа за мониторинг в CoreOS. В момента работи в Google.

Бартек Плотка - Инфраструктурен инженер в Improbable. Любител е на новите технологии и проблемите на разпределените системи. Той има опит в програмирането на ниско ниво в Intel, опит като сътрудник в Mesos и опит в производството на SRE от световна класа в Improbable. Ангажиран с подобряването на света на микроуслугите. Неговите три любови са Golang, отворен код и волейбол.

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

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

Бъдете в течение с последните новини от Improbable.

Нашите цели с Танос

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

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

Заявка за данни от множество екземпляри на Prometheus (глобална заявка)

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

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

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

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

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

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

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

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

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

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

Намаляване на дискретизацията

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

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

Намаляването на старите данни е неизбежно изискване за всяко решение за дългосрочно съхранение и надхвърля ванилия Prometheus.

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

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

Архитектура на Танос

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

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

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

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

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

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

Неограничено време за съхранение!

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

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

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

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

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

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

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

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

Уплътняване и намаляване на дискретизацията

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

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

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

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

Не се изисква специална конфигурация, за да може потребителят да използва данни с намалена точност. Querier автоматично превключва между различни разделителни способности и необработени данни, докато потребителят увеличава и намалява. Ако желае, потребителят може да контролира това директно чрез параметъра "стъпка" в заявката.

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

Правила за запис

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

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

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

Силата на Танос

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

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

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

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

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

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

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

Заявка за изтегляне: имаме нужда от вас!

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

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

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

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