Избор на складирање податоци за Прометеј: Танос против ВикторијаМетрикс

Здраво на сите. Подолу е транскриптот извештај од Големиот мониторинг состанок 4.

Прометеј – систем за следење на различни системи и услуги, со помош на кој системските администратори можат да собираат информации за тековните параметри на системите и да поставуваат предупредувања за да добиваат известувања за отстапувања во работата на системите.

Извештајот ќе содржи споредба Thanos и Викторија Метрикс — проекти за долгорочно складирање на метриката на Прометеј.

Прво, ќе ви кажам за Прометеј. Ова е систем за следење што собира метрика од одредени цели и ги зачувува на локално складирање. Прометеј може да снима метрика на далечинско складирање и може да генерира предупредувања и правила за снимање.

Ограничувања на Прометеј:

• Нема глобален преглед на барањето. Ова е кога имате повеќе независни случаи на прометеј. Тие собираат метрика. И сакате да побарате над сите овие метрики собрани од различни случаи на прометеј. Прометеј не го дозволува тоа.
• Со Prometheus, перформансите се ограничени на само еден сервер. Prometheus не се скалира автоматски на повеќе сервери. Можете само рачно да ги поделите вашите цели помеѓу повеќе Prometheus.
• Опсегот на метрика во Prometheus е ограничен на само еден сервер од истата причина што не може автоматски да се скалира на повеќе сервери.
• Не е толку лесно да се организира безбедноста на податоците во Прометеј.

Решенија за овие проблеми/предизвици?

Решенијата се:

• Thanos
• Викторија Метрикс
• Uber M3
• Кортекс

Сите овие решенија се за далечинско складирање на податоците собрани од Прометеј. Тие го решаваат проблемот со далечинско складирање од претходниот слајд на различни начини. Во оваа презентација ќе зборувам само за првите две решенија: Thanos и Викторија Метрикс.

За прв пат информации за Thanos се појави од страна овој линк. Таму е опишана архитектурата Thanos и како функционира.

Танос ги зема податоците што ги зачувал Прометеј на локалниот диск и ги копира на S3, за да GCS или на друго складирање на предмети.

Така, Thanos обезбедува глобален преглед на барањето. Можете да побарате податоци зачувани во складирање на објекти од повеќе примероци на Prometheus.

Thanos поддржува PromQL и API за пребарување на Прометеј.

Танос користи код на Прометеј за складирање податоци.

Thanos е развиен од истите развивачи како Prometheus.

на Викторија Метрикс. Еве линк, каде првпат разговаравме Викторија Метрикс.

VictoriaMetrics добива податоци од неколку прометеј API за далечинско пишување протокол поддржан од Прометеј.

VictoriaMetrics обезбедува глобален преглед на барањето, бидејќи повеќе примероци на Prometheus можат да напишат податоци на една VictoriaMetrics. Според тоа, можете да поставувате прашања за сите овие податоци.

VictoriaMetrics исто така поддржува, како што се Thanos, PromQL и Prometheus за пребарување API.

За разлика од Thanos, изворниот код на VictoriaMetrics е напишан од нула и е оптимизиран за брзина и потрошувачка на ресурси.

VictoriaMetrics, за разлика од Thanos, се скали и вертикално и хоризонтално. Јадете Верзија со еден јазол, кој се скали вертикално. Можете да започнете со еден процесор и 1 GB меморија и постепено да пораснете до стотици процесори и 1 TB меморија. VictoriaMetrics може да ги користи сите овие ресурси. Неговите перформанси ќе се зголемат приближно 100 пати во споредба со системот со 1 јадро.

Историјата на Танос започна во ноември 2017 година, кога се појави првото јавно залагање. Пред ова, Танос беше развиен внатрешно неверојатно.io.

Во јуни 2019 година имаше значајно издание 0.5.0, во кое отстранети озборувања протокол. Тој беше отстранет од Танос бидејќи не се претстави добро. Често кластерот Thanos не работеше правилно, јазлите поврзани со него неправилно поради протоколот за озборувања. Затоа, решивме да го отстраниме од таму. Мислам дека ова е вистинската одлука.

Истиот јуни 2019 година испратија број на апликација 256 в Фондација за Cloud Native Computing.

И по неколку месеци Танос беше примен во Фондација за Cloud Native Computing, кој ги вклучува Прометеј, Кубернетес и други популарни проекти.

Во јануари 2018 година започна развојот на VictoriaMetrics.

Во септември 2018 година, за прв пат јавно ја спомнав VictoriaMetrics.

Во декември 2018 година, беше објавена верзија со еден јазол.

Во мај 2019 беа објавени извори на верзии со еден јазол и кластер.

Во јуни 2019 година, исто како и Танос, поднесовме апликација до фондацијата CNCF под број 255. Аплициравме еден ден пред да се пријави Танос.

Но, за жал, сè уште не сме примени таму. Потребна е помош од заедницата.

Да ги погледнеме најважните слајдови кои ја прикажуваат архитектурата на Танос и ВикторијаМетрикс.

Да почнеме со Танос. Жолтите компоненти се компоненти на Прометеј. Сè друго се компоненти на Thanos. Да почнеме со најважната компонента. Thanos Sidecar е компонента што се инсталира веднаш до секој Prometheus. Ги вчитува податоците на Prometheus од локалното складирање во S3 или друг објект за складирање.

Постои и компонента наречена Thanos Store Gateway, која може да ги чита овие податоци од Object Storage по дојдовни барања од Thanos Query. Thanos Query имплементира PromQL и Prometheus API. Односно, однадвор личи на Прометеј. Прима барања PromQL, ги испраќа до Thanos Store Gateway, Thanos Store Gateway ги повлекува потребните податоци од Object Storage, ги испраќа назад.

Но, ние складираме податоци во Object Storage без последните два часа поради карактеристиката на имплементацијата на Thanos Sidecar, која не може да ги прикачи последните два часа на Object Storage S3, бидејќи Prometheus сè уште нема создадено датотеки за овие два часа во локално складирање.

Како решивте да го заобиколите ова? Thanos Query, покрај барањата до Thanos Store Gateway, испраќа паралелни барања до секој Thanos Sidecar, кој се наоѓа веднаш до Prometheus.

А Танос Сидекар, пак, ги испраќа барањата понатаму до Прометеј и ги враќа податоците за последните два часа.

Покрај овие компоненти, постои и опционална компонента без која Thanos нема да има добри перформанси. Ова е Thanos Compact, кој е одговорен за спојување на мали датотеки на Object Storage во поголеми датотеки што беа поставени овде од Thanos Sidecars. Thanos Sidecar поставува датотеки со податоци таму за два часа. Овие датотеки, доколку не се спојат во поголеми датотеки, тогаш нивниот број може значително да порасне. Колку повеќе такви датотеки, толку повеќе меморија е потребна за Thanos Store Gateway, толку повеќе ресурси се потребни за пренос на податоци преку мрежата и метаподатоци. Thanos Store Gateway станува неефикасен. Затоа, неопходно е да се изврши Thanos Compact, кој ги спојува малите датотеки во поголеми, за да има помалку такви датотеки и да ги намали трошоците на Thanos Store Gateway.

Постои и таква компонента како Танос Владетел. Ги извршува правилата за предупредување на Prometheus и може да ги процени правилата за снимање на Prometheus со цел да ги запише податоците назад во Object Storage. Но, оваа компонента не се препорачува да се користи, бидејќи ... Тој има тенденција да враќа нецелосни податоци.

Ова е едноставната шема на Танос.

Сега да го споредиме со шемата VictoriaMetrics.

VictoriaMetrics има 2 верзии: верзија со еден јазол и кластер. Еден јазол работи на еден компјутер. Еден јазол ги нема овие компоненти, само еден бинарен. Овој бинарен на слајдот изгледа како овој квадрат. Сè што е внатре во квадратот е содржината на бинарната датотека за верзијата со еден јазол. Не треба да знаеш за него. Вие само го стартувате бинарното и сè работи за нас.

Кластер верзијата е посложена. Внатре во него има три различни компоненти: vmselect, vminsert и vmstorage. Од нивното име треба да биде јасно што прави секој од нив. Компонентата Insert прифаќа податоци во различни формати: од Prometheus далечинско запишување API, протоколот Influx линија, протоколот Graphite и протоколот OpenTSDB. Компонентата Insert ги прифаќа, ги анализира и ги дистрибуира помеѓу постоечките компоненти за складирање, каде што податоците се веќе зачувани. Компонентата Select, пак, прифаќа PromQL барања. Тој спроведува PromQL, како и API за барање на Prometheus, и може да се користи како замена за Prometheus во Grafana или други клиенти на Prometheus API. Select прифаќа барање promql, го анализира, ги чита потребните податоци за извршување на ова барање од јазлите за складирање, ги обработува овие податоци и враќа одговор.

Ајде да ја споредиме сложеноста на инсталирањето на Thanos и VictoriaMetrics.

Да почнеме со Танос. Пред да започнете да работите со Thanos, треба да креирате кофа во Object Storage, како што се S3 или GCS, за да може Thanos Sidecar да пишува податоци на него.

Потоа за секој Prometheus треба да го инсталирате Thanos Sidecar. Пред ова, треба да запомните да го оневозможите набивањето на податоците во Прометеј. Набивањето податоци периодично ги компресира податоците во локалното складирање на Prometheus со цел да се намали потрошувачката на ресурси.

Кога ќе го инсталирате Thanos Sidecar на вашиот Prometheus, мора да го оневозможите ова набивање податоци бидејќи Thanos Sidecar не работи правилно со овозможено набивање податоци. Ова значи дека вашиот Прометеј започнува да зачувува податоци во двочасовни блокови и престанува да ги спојува тие блокови во поголеми. Според тоа, ако поставувате прашања што го надминуваат времетраењето на последните два часа, тогаш тие нема да работат толку ефикасно како што би можеле да работат ако е овозможено набивање на податоците.

Затоа, Thanos препорачува да се намали времето на задржување на податоците во локалното складирање на 6-8 часа со цел да се намали горната потрошувачка на голем број мали блокови.

Откако ќе го инсталирате Thanos Sidecar, мора да инсталирате две компоненти за секоја кофа за складирање објекти. Тоа се Thanos Compactor и Thanos Store Gateway.

После тоа, треба да го инсталирате Thanos Query и да го конфигурирате за да може да се поврзе со сите Thanos Store Gateway што ги имате, а исто така да може да се поврзе со сите Thanos Sidecars.

Тука може да има мал проблем.

Треба да конфигурирате сигурна и сигурна врска од Thanos Query до овие компоненти. И ако вашиот Prometheus се наоѓа во различни центри за податоци или во различни VPC, тогаш врските со нив однадвор се забранети. Но, за Thanos Query да работи, треба некако да ја конфигурирате врската таму и треба да откриете начин.

Ако имате многу такви центри за податоци, тогаш, соодветно, веродостојноста на целиот систем се намалува. Бидејќи Thanos Query мора постојано да одржува врски со сите Thanos Sidecars лоцирани во различни центри за податоци. За секое дојдовно барање, ќе ги пренасочува барањата до сите Thanos Sidecars. Ако врската е прекината, или ќе добиете нецелосен сет на податоци или ќе добиете одговор „кластерот е прекинат“.

Во VictoriaMetrics сè е малку поедноставно. За верзијата со еден јазол, само треба да извршите еден бинарен и сè работи.

Во кластер верзијата, доволно е да ги вклучите сите горенаведени три типа на компоненти во која било количина што ви треба, или да ги користите табела на кормилото за автоматизирање на лансирањето на компоненти во Kubernetes. Планираме да направиме и Kubernetes оператор. Табелата на Helm не опфаќа некои случаи и ви дозволува да пукате во стапалото. На пример, ви овозможува да го намалите бројот на јазли за складирање, што ќе доведе до губење на податоци.

Откако ќе лансирате една бинарна или кластерирана верзија, само треба да го додадете Prometheus во конфигурацијата поставка за далечинско пишување URLтака што ќе почне да пишува податоци паралелно со локалното складирање и далечинското складирање. Како што можете да видите, оваа конфигурација треба да работи многу посигурно во споредба со конфигурацијата на Thanos. Не треба да одржуваме врска од VictoriaMetrics до сите Prometheus, бидејќи самиот Prometheus се поврзува со VictoriaMetrics и пренесува податоци.

Да ја разгледаме поддршката на Thanos и VictoriaMetrics.

Thanos треба да го надгледува Sidecar за да се увери дека нема да престане да вчитува податоци во Object Storage. Тие може да го прекинат преземањето на податоци поради грешки во преземањето, на пример, вашата мрежна врска со Object Storage е привремено прекината или Object Storage е привремено недостапна. Thanos Sidecar ќе го забележи ова во овој момент, ќе пријави грешка, може да се сруши и потоа да престане да работи. Ако не го следите, тогаш ќе престанете да пренесувате податоци во Object Storage. Ако времето на задржување помине (се препорачува 6-8 часа), тогаш ќе ги изгубите податоците што не завршиле во Складирање на објекти.

Компакторите на Thanos може да престанат да работат поради трки со Sidecar. Компакторите земаат податоци од Object Storage и ги спојуваат во поголеми парчиња податоци. Бидејќи набивачите не се синхронизирани со Sidecars, ова може да се случи: Sidecar сè уште немал време да го заврши блокот, Compactor одлучи дека овој блок е целосно напишан. Компактор почнува да го чита. Не го чита блокот целосно и престанува да работи. Видете детали тука.

Store Gateway може да врати неконзистентни податоци поради трките помеѓу Compactor и Sidecars. Овде е истото, бидејќи портата на продавницата на кој било начин не е синхронизирана со Compactors и Sidecars. Соодветно на тоа, условите за трка може да се појават кога Портата продавница не гледа дел од податоците или гледа непотребни податоци.

Компонентата Query во Thanos стандардно враќа делумен резултат ако некои Sidecars или Store Gateways не се достапни во моментот. Ќе добиете дел од податоците, а нема ни да знаете дека не сте ги добиле сите податоци. Вака работи стандардно. Во слична ситуација, VictoriaMetrics враќа означените податоци како делумни.

За разлика од Thanos, VictoriaMetrics ретко губи податоци. Дури и ако врската од Prometheus до VictoriaMetrics е прекината, ова не е проблем, бидејќи Prometheus продолжува да ги снима дојдовните нови податоци во дневникот за пишување однапред, чија големина е 2 часа. Ако ја вратите врската со VictoriaMetrics во рок од два часа, вашите податоци нема да се изгубат. Прометеј може да додаде податоци откако ќе ја врати врската со VictoriaMetrics.

За разлика од Thanos, кој запишува податоци во складирање на објекти само по два часа, Prometheus автоматски ги реплицира податоците користејќи го протоколот за далечинско запишување на далечинско складирање, како што е VictoriaMetrics. Не се плашите од губење на локалното складирање во Прометеј. Ако одеднаш изгубил локално складирање, тогаш во најлош случај ќе ги изгубите последните секунди од податоците што немале време да се снимаат во далечинско складирање.

Kubernetes автоматски управува со кластерот, за разлика од Thanos. Тешко е да се постават сите компоненти на Thanos во еден кластер Kubernetes, за разлика од компонентите на кластерот VictoriaMetrics.

VictoriaMetrics има многу едноставно ажурирање на новата верзија. Само запрете ја VictoriaMetrics, ажурирајте ги бинарните датотеки и стартувајте ја. Кога се запрени преку сигнал SIGINT, сите бинарни датотеки на VictoriaMetrics вршат грациозно исклучување. Тие правилно ги зачувуваат потребните податоци, правилно ги затвораат дојдовните врски за да не изгубат ништо. Така нема да изгубите ништо при надградба.

VictoriaMetrics го олеснува проширувањето на кластерот. Само додадете ги потребните компоненти и продолжете да работите.

За стапици во Thanos и VictoriaMetrics.

Танос ги има следните стапици. Прометеј мора да складира податоци во последните два часа. Ако се изгубат, ќе ги изгубите целосно бидејќи сè уште не се напишани во Object Storage како S3.

Компонентата Store Gateway и компонентата за компактор може да бараат многу меморија за да работат со голем простор за складирање на објекти ако има многу мали датотеки складирани таму. Колку е поголем бројот и големината на датотеките, толку повеќе Store Gateway и компактор RAM се потребни за складирање на метаинформации. Танос има многу проблеми во врска со фактот дека Чувајте ги портите и компакторите со просечен обем на снимени податоци.

Танос се рекламира на неодредено време со количината на Прометеј што ја имате. Ова всушност не е точно. Бидејќи сите барања минуваат низ компонентата Query, која истовремено мора да ги испита сите компоненти на Store Gateway и сите компоненти на Sidecar, повлечете ги податоците од таму и потоа претходно обработете ги. Очигледно, брзината на барањето е ограничена од најбавната слаба врска, најбавниот Store Gateway или најбавниот Sidecar.

Овие компоненти може да бидат нерамномерно натоварени. На пример, имате Прометеј, кој собира милиони метрики во секунда. И тука е Прометеј, кој собира илјадници метрики во секунда. Prometheus, кој собира милиони метрика во секунда, става многу поголем товар на серверот на кој работи. Според тоа, Sidecar работи побавно таму. И воопшто таму се работи полека. И компонентата Query ќе ги повлече податоците од таму многу бавно. Според тоа, перформансите на целиот ваш кластер ќе бидат ограничени од овој бавен Sidecar.

Стандардно, Thanos дава делумни податоци ако некои Sidecars и или Store Gateway не се достапни. На пример, ако вашите Sidecars се расфрлани низ светот во различни центри за податоци, тогаш веројатноста за неуспех на врската и недостапност на компонентите значително се зголемуваат. Соодветно на тоа, во повеќето случаи ќе добиете делумни податоци без воопшто да го знаете.

ВикторијаМетрикс има и стапици. Првата замка е опцијата што ја ограничува количината на RAM меморија што се користи за кешот на VictoriaMetrics. Стандардно, тоа е еднакво на 60% од RAM-от на машината каде работи VictoriaMetrics или 60% од RAM-от на VictoriaMetrics pod во Kubernetes.

Ако неправилно ја промените оваа вредност, може да ги уништите перформансите на VictoriaMetrics. На пример, ако ја поставите вредноста премногу ниска, податоците може повеќе да не се вклопуваат во кешот на VictoriaMetrics. Поради ова, таа ќе мора да направи дополнителна работа и да ги вчита процесорот и дискот. Ако ја направите оваа опција премногу голема, таа ја зголемува, прво, веројатноста VictoriaMetrics да се сруши со грешка без меморија, и, второ, ќе доведе до фактот дека ќе остане многу малку RAM во меморијата на оперативниот систем за кешот на датотеки. И VictoriaMetrics се потпира на кешот на датотеки за перформанси. Ако не е доволно, оптоварувањето на дискот може значително да се зголеми. Затоа, совет: не менувајте го параметарот освен ако е апсолутно неопходно.

Втора опција. Ова е RetentionPeriod - период што стандардно е поставен на 1 месец. Ова е должината на времето кога VictoriaMetrics складира податоци. По овој период, VictoriaMetrics ги брише податоците.

Многу луѓе работат на VictoriaMetrics без овој параметар и снимаат податоци за еден месец. И тогаш прашуваат: зошто исчезнаа податоците за претходниот месец? Бидејќи стандардниот период на задржување е 1 месец. Затоа, треба да го знаете и поставите точниот период на задржување.

Ајде да ги погледнеме уникатните карактеристики.

Thanos има карактеристика наречена намалување на примерокот: 5-минутни и часовни интервали, кои често не работи правилно. Ако пребарувате на Google и го погледнете нивниот проблем на github, има многу проблеми поврзани со ова намалување на примерокот, дека понекогаш не работи правилно или не работи како што очекуваат корисниците.

Танос има дедупликација на податоци за паровите Прометеј ХА. Кога двајца Prometheus собираат исти метрики од истите цели и Танос ги складира во Object Storage. Thanos може правилно да ги дуплира овие податоци, за разлика од VictoriaMetrics.

Thanos има компонента за предупредување што беше во шемата на Thanos. Но, тој не се препорачува за употреба во производството.

Танос има предност што Танос и Прометеј го делат истиот код. Thanos и Prometheus се развиени од исти програмери. Со подобрувања на Танос или Прометеј, победува другата страна.

Главната карактеристика на VictoriaMetrics е MetricsQL. Ова се екстензии на VictoriaMetrics за PromQL, за кои зборував на претходниот голем состанок за следење.

VictoriaMetrics поддржува вчитување податоци користејќи многу различни протоколи. VictoriaMetrics не само што може да прифаќа податоци од Prometheus, туку и преку протоколите Influx, OpenTSDB и Graphite.

Податоците на VictoriaMetrics заземаат многу помалку простор во споредба со Thanos и Prometheus.

Ако снимате вистински податоци, корисниците зборуваат за 2-5 пати намалување на големината на податоците на дискот во споредба со Prometheus и Thanos.

Друга предност на VictoriaMetrics е тоа што е оптимизирана за брзина.

Да ги погледнеме трошоците за инфраструктурата.

Една од предностите на Thanos е тоа што ги складира податоците во складирање на објекти, што е релативно евтино.

Кога складирате податоци во складирање на објекти, мора да платите за операциите за пишување и читање податоци (10 долари за милион операции). Кога пишувате податоци за складирање на објекти, ги плаќате трошоците за хостирање за поставување податоци на Интернет; ако вашиот кластер не е во AWS, таму е бесплатен. Кога читате податоци, плаќате помеѓу 10 и 230 долари за 1 ТБ. Ова може да биде значајно ако често барате историски податоци од кластерот Thanos.

За Thanos кластерот, треба да платите за сервери за Compact, Store Gateway, Query компоненти кои бараат многу меморија и CPU за големи количини на податоци.

VictoriaMetrics ги има следните трошоци. Ако складирате податоци на GCE HDD-дискови, тогаш тие излегуваат на 40 долари за 1 TB. За VictoriaMetrics, обичните HDD-дискови се доволни; не се потребни SSD-дискови, кои чинат пет пати повеќе. VictoriaMetrics е оптимизирана за HDD.

ВикторијаМетрикс бара сервери за компоненти: или Еднокреветни или групирани компоненти, кои, за разлика од компонентите на Thanos, бараат многу помалку CPU и RAM - и соодветно ќе бидат поевтини.

Примери за имплементација.

Танос има пример за имплементација во Gitlab. Gitlab работи целосно на Thanos. Но, таму не е сè така мазно. Ако ги погледнете прашања, тогаш може да се види дека тие постојано имаат некои оперативни проблеми со Танос: Нема доволно меморија за компонентите Store Gateway или Query. Тие постојано треба да ја зголемуваат количината на меморија.

Поради ова се зголемуваат трошоците за решавање на овие проблеми.

Втората имплементација, која може да биде поуспешна, е компанијата Improbable, која започна да го развива Thanos. Тие го објавија изворниот код на Thanos. Improbable е компанија која развива мотори за игри.

VictoriaMetrics има примери за јавна имплементација:

• Градител на веб-страници wix.com
• Адидас ја имплементира VictoriaMetrics, па дури и направи презентација на последниот PromCon 2019
• TrafficStars - рекламна мрежа
• Seznam.cz е популарен чешки пребарувач.

И тогаш имаше компании без име кои не можам да ги именувам сега. Тие не се согласија.

• Еден голем развивач на игри. Поголемо од неверојатно.
• Главен развивач на графички софтвер.
• Голема руска банка.
• Европски производител на ветерни турбини кој успешно ја тестираше VictoriaMetrics. Овој производител ја имплементира VictoriaMetrics за следење на податоците собрани од турбините на ветер со брзина од 50 примероци во секунда по сензор. Секоја турбина на ветер има неколку стотици сензори. Имаат неколку стотици турбини на ветер.
• Руски авиокомпании кои сакаат да ја имплементираат VictoriaMetrics, но сè уште не можат. Ние сме во фаза на договор со нив.

Заклучоци.

VictoriaMetrics и Thanos решаваат слични проблеми, но на различни начини:

• Глобален преглед на барањето
• хоризонтално скалирање
• произволно задржување

Ви благодариме.

Ве очекуваме кај нас телеграма канал.

Само регистрирани корисници можат да учествуваат во анкетата. Најави се, вие сте добредојдени.

Што користите како долгорочно складирање за Prometheus?

• 35,3%Танос6

• 0,0%Кортекс 0

• 0,0%M3DB0

• 41,2%Викторија Метрикс7

• 23,5%друго4

Гласаа 17 корисници. 16 корисници беа воздржани.

Извор: www.habr.com