Преводот на статијата е подготвен специјално за студентите на курсот .
е развивач на софтвер, Go fanatic и решавач на проблеми. Тој е исто така одржувач на Prometheus и ко-основач на Kubernetes SIG инструментацијата. Во минатото, тој беше производствен инженер во SoundCloud и го водеше тимот за следење во CoreOS. Во моментов работи во Google.
- Инфраструктурен инженер во Improbable. Тој е заинтересиран за новите технологии и проблемите на дистрибуираните системи. Тој има искуство во програмирање на ниско ниво во Intel, искуство со соработници во Mesos и искуство во производство на SRE од светска класа во Improbable. Посветен на подобрување на светот на микросервисите. Неговите три љубови: Голанг, отворен код и одбојка.
Гледајќи го нашиот водечки производ SpatialOS, можете да погодите дека Improbable бара високо динамична, глобална облак инфраструктура со десетици Kubernetes кластери. Ние бевме едни од првите што користевме систем за следење . Prometheus е способен да следи милиони метрики во реално време и доаѓа со моќен јазик за прашања што ви овозможува да ги извлечете потребните информации.
Едноставноста и сигурноста на Прометеј е една од неговите главни предности. Меѓутоа, откако поминавме одредена скала, наидовме на неколку недостатоци. За да ги решиме овие проблеми развивме е проект со отворен код создаден од Improbable за беспрекорно да ги трансформира постоечките кластери Prometheus во единствен систем за следење со неограничено складирање на историски податоци. Thanos е достапен на Github .
Нашите цели со Танос
Во одреден размер се јавуваат проблеми кои се надвор од можностите на ванила Прометеј. Како сигурно и економично да се складираат петабајти историски податоци? Може ли ова да се направи без да се загрози времето на одговор? Дали е можно да се пристапи до сите метрики лоцирани на различни сервери на Prometheus со едно барање за API? Дали постои начин да се комбинираат реплицираните податоци собрани со помош на Prometheus HA?
За да ги решиме овие проблеми, го создадовме Thanos. Следните делови опишуваат како пристапивме кон овие прашања и ги објаснуваме нашите цели.
Барање податоци од повеќе примероци на Prometheus (глобално барање)
„Прометеј“ нуди функционален пристап кон сердинг. Дури и еден сервер Prometheus обезбедува доволна приспособливост за ослободување на корисниците од комплексноста на хоризонталното сечење во речиси сите случаи на употреба.
Иако ова е одличен модел за распоредување, често е неопходно да се пристапи до податоци на различни сервери на Prometheus преку еден API или UI - глобален приказ. Се разбира, можно е да се прикажат повеќе барања во еден панел Grafana, но секое барање може да се изврши само на еден сервер Prometheus. Од друга страна, со Thanos можете да барате и да собирате податоци од повеќе сервери на Prometheus бидејќи сите се достапни од една крајна точка.
Претходно, за да добиеме глобален поглед во Improbable, ги организиравме нашите примери на Prometheus на повеќе нивоа . Ова значеше создавање на еден мета-сервер Prometheus кој собира некои од метриките од секој лист-сервер.
Овој пристап се покажа проблематичен. Ова резултираше со посложени конфигурации, додавање на дополнителна потенцијална точка на неуспех и примена на сложени правила за да се осигура дека федеративната крајна точка ги прима само податоците што и се потребни. Покрај тоа, овој вид на федерација не ви дозволува да добиете вистински глобален приказ, бидејќи не се достапни сите податоци од едно барање API.
Тесно поврзан со ова е унифициран приказ на податоците собрани на серверите Prometheus со висока достапност (HA). HA моделот на Prometheus самостојно собира податоци двапати, што е толку едноставно што не може да биде поедноставно. Сепак, користењето комбиниран и дедупликат приказ на двата текови би било многу поудобно.
Секако, има потреба од високо достапни сервери Prometheus. Во Improbable, ние навистина сериозно го сфаќаме следењето на податоците од минута во минута, но да се има по еден пример на Prometheus по кластер е единствена точка на неуспех. Секоја грешка во конфигурацијата или хардверски дефект потенцијално може да доведе до губење на важни податоци. Дури и едноставното распоредување може да предизвика мали пореметувања во собирањето метрика бидејќи рестартирањето може да биде значително подолго од интервалот на стругање.
Сигурно складирање на историски податоци
Евтиното, брзо и долгорочно складирање на метрика е нашиот сон (го споделуваат повеќето корисници на Прометеј). Во Неверојатно, бевме принудени да го конфигурираме периодот на задржување на метриката на девет дена (за Прометеј 1.8). Ова додава очигледни граници на тоа колку далеку можеме да погледнеме назад.
Прометеј 2.0 се подобри во овој поглед, бидејќи бројот на временски серии повеќе не влијае на севкупните перформанси на серверот (види. ). Сепак, Прометеј ги складира податоците на локалниот диск. Иако компресија на податоци со висока ефикасност може значително да ја намали локалната употреба на SSD, на крајот сепак постои ограничување на количината на историски податоци што може да се складираат.
Дополнително, во Improbable се грижиме за доверливост, едноставност и цена. Големите локални дискови се потешки за ракување и за правење резервни копии. Тие чинат повеќе и бараат повеќе алатки за резервна копија, што резултира со непотребна сложеност.
Намалување на примерокот
Откако почнавме да работиме со историски податоци, сфативме дека постојат фундаментални тешкотии со big-O кои ги прават барањата побавни и побавни додека работиме со недели, месеци и години на податоци.
Стандардно решение за овој проблем би било (симнување на примероци) - намалување на фреквенцијата на земање примероци на сигналот. Со намалувањето на примерокот, можеме да „намалиме“ на поголем временски опсег и да одржуваме ист број примероци, одржувајќи ги прашањата одговорни.
Преземањето примероци од старите податоци е неизбежен услов за кое било решение за долгорочно складирање и е надвор од опсегот на ванила Прометеј.
Дополнителни цели
Една од првичните цели на проектот Thanos беше беспрекорно да се интегрира со сите постоечки инсталации на Prometheus. Втората цел беше леснотијата на работа со минимални бариери за влез. Сите зависности треба лесно да се задоволат и за малите и за големите корисници, што значи и ниска основна цена.
Архитектура на Танос
Откако ќе ги наведеме нашите цели во претходниот дел, ајде да ги разгледаме и да видиме како Танос ги решава овие проблеми.
Глобален поглед
За да добиеме глобален приказ на постојните примероци на Prometheus, треба да поврземе влезна точка за едно барање со сите сервери. Токму тоа го прави компонентата Thanos. . Распореден е до секој сервер на Prometheus и делува како прокси, опслужувајќи ги локалните податоци на Prometheus преку gRPC Store API, овозможувајќи податоци за временски серии да се преземаат по ознака и временски опсег.
Од другата страна е компонентата Querier без државјанство која е намалена, која не прави ништо повеќе од само одговарање на барањата PromQL преку стандардниот Prometheus HTTP API. Querier, Sidecar и другите компоненти на Thanos комуницираат преку .
- Querier, по добивањето на барањето, се поврзува со соодветниот Store API сервер, односно со нашите Sidecars и прима податоци за временски серии од соодветните сервери Prometheus.
- После тоа, ги комбинира одговорите и извршува барање PromQL на нив. Querier може да ги спои и разделените податоци и дупликатите податоци од серверите на Prometheus HA.
Ова решава голем дел од нашата загатка - комбинирање на податоци од изолирани сервери на Prometheus во еден приказ. Всушност, Thanos може да се користи само за оваа функција. Не треба да се прават промени на постоечките сервери на Prometheus!
Неограничен рок на траење!
Сепак, порано или подоцна ќе сакаме да складираме податоци надвор од нормалното време на задржување на Prometheus. Избравме складирање на објекти за складирање на историски податоци. Тој е широко достапен во секој облак, како и во центрите за податоци во просториите и е многу исплатлив. Покрај тоа, речиси секое складирање на предмети е достапно преку добро познатиот S3 API.
Прометеј запишува податоци од RAM на диск приближно на секои два часа. Зачуваниот блок на податоци ги содржи сите податоци за одреден временски период и е непроменлив. Ова е многу погодно бидејќи Thanos Sidecar може едноставно да го погледне директориумот со податоци на Prometheus и, како што ќе станат достапни нови блокови, да ги вчита во кофи за складирање на предмети.
Вчитувањето во складирање на предмети веднаш по пишувањето на дискот, исто така, ви овозможува да ја одржите едноставноста на стругалката (Prometheus и Thanos Sidecar). Што ја поедноставува поддршката, трошоците и дизајнот на системот.
Како што можете да видите, резервната копија на податоците е многу едноставна. Но, што е со барањето податоци во складирањето на објекти?
Компонентата Thanos Store делува како прокси за преземање податоци од складирање на објекти. Како и Thanos Sidecar, тој учествува во кластерот за озборувања и го имплементира Store API. На овој начин, постоечкиот Querier може да го третира како Sidecar, како друг извор на податоци за временски серии - не е потребна посебна конфигурација.
Блоковите на податоци за временски серии се состојат од неколку големи датотеки. Нивното вчитување на барање би било доста неефикасно, а нивното локално кеширање би барало огромна количина на меморија и простор на дискот.
Наместо тоа, Store Gateway знае како да се справи со форматот за складирање Prometheus. Благодарение на паметниот распоредувач на прашања и кеширањето само на потребните индексни делови од блоковите, можно е да се намалат сложените барања на минимален број HTTP барања за приговор на датотеките за складирање. На овој начин, можете да го намалите бројот на барања за четири до шест реда на големина и да постигнете времиња на одговор кои генерално тешко се разликуваат од барања до податоци на локален SSD.
Како што е прикажано на дијаграмот погоре, Thanos Querier значително ги намалува трошоците по барање за податоци за складирање на објекти со користење на форматот за складирање Prometheus и ставање поврзани податоци рамо до рамо. Користејќи го овој пристап, можеме да комбинираме многу поединечни барања во минимален број на масовни операции.
Набивање и намалување на примерокот
Штом нов блок од податоци од временски серии е успешно вчитан во складирање на објекти, ние го третираме како „историски“ податок, кој е веднаш достапен преку Портата на продавницата.
Меѓутоа, по некое време, блоковите од еден извор (Прометеј со странична карта) се акумулираат и повеќе не го користат целосниот потенцијал за индексирање. За да го решиме овој проблем, воведовме друга компонента наречена 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 е доволно флексибилен за да се приспособи за да одговара на вашите потреби. Ова е особено корисно кога мигрирате од обичен Прометеј. Ајде брзо да го повториме она што го научивме за компонентите на Thanos со брз пример. Еве како да го однесете вашиот ванила Прометеј во светот на „неограничено складирање на метрика“:
- Додајте Thanos Sidecar на вашите сервери Prometheus - на пример, контејнер за странична кола во Kubernetes pod.
- Распоредете повеќе копии на Thanos Querier за да можете да прегледувате податоци. Во оваа фаза лесно е да се постави озборување помеѓу Scraper и Querier. За да ја проверите интеракцијата на компонентите, користете ја метриката „thanos_cluster_members“.
Само овие два чекори се доволни за да се обезбеди глобален приказ и непречено отстранување на податоците од потенцијалните реплики на Prometheus HA! Едноставно поврзете ги вашите контролни табли со крајната точка на Querier HTTP или директно користете го Thanos UI.
Меѓутоа, ако ви треба резервна копија на метрика и долгорочно складирање, ќе треба да завршите уште три чекори:
- Создадете кофа AWS S3 или GCS. Конфигурирајте го Sidecar да ги копира податоците во овие корпи. Локалното складирање податоци сега може да се минимизира.
- Распоредете го Store Gateway и поврзете го со вашиот постоечки кластер за озборувања. Сега можете да побарате резервна копија на податоците!
- Распоредете го Compactor за да ја подобрите ефикасноста на барањето во долги временски периоди користејќи набивање и намалување на примерокот.
Доколку сакате да дознаете повеќе, не двоумете се да ја погледнете нашата и !
Во само пет чекори, го претворивме Prometheus во сигурен систем за следење со глобален поглед, неограничено време на складирање и потенцијална висока достапност на метрика.
Повлечете барање: ни требате!
е проект со отворен код од самиот почеток. Беспрекорната интеграција со Prometheus и можноста за користење само дел од Thanos го прави одличен избор за скалирање на вашиот систем за следење без напор.
Секогаш ги поздравуваме барањата и проблемите за повлекување на GitHub. Во меѓувреме, слободно контактирајте со нас преку Github Issues или Slackако имате прашања или повратни информации или сакате да го споделите вашето искуство со користењето! Ако ви се допаѓа она што го правиме во Improbable, не двоумете се да не контактирате - !
Извор: www.habr.com