Здравейте всички. По-долу е дешифрирането .
– система за наблюдение на различни системи и услуги, с помощта на която системните администратори могат да събират информация за текущите параметри на системите и да настройват аларми за получаване на известия за отклонения в работата на системите.
Докладът ще сравни и — проекти за дългосрочно съхранение на метрики на Prometheus.
Нека първо ви разкажа за Прометей. Това е система за мониторинг, която събира показатели от дадени цели и ги съхранява в локално хранилище. Prometheus може да записва показатели в отдалечено хранилище, може да генерира предупреждения и правила за запис.
Ограничения на Prometheus:
- Той няма изглед на глобална заявка. Това е, когато имате множество независими екземпляри на prometheus. Те събират показатели. И вие искате да направите заявка върху всички тези показатели, събрани от различни инстанции на prometheus. Прометей не позволява това.
- С prometheus производителността е ограничена само до един сървър. Prometheus не може автоматично да се мащабира до множество сървъри. Можете само ръчно да разделите вашите цели между няколко Prometheus.
- Обхватът на показателите в Prometheus е ограничен само до един сървър по същата причина, поради която не може автоматично да се мащабира автоматично до множество сървъри.
- В Prometheus не е толкова лесно да се организира безопасността на данните.
Решения на тези проблеми/задачи?
Решенията са:
Всички тези решения са за отдалечено съхранение на данни, събрани от Prometheus. Те решават проблема с отдалеченото съхранение от предишния слайд по различни начини. В тази презентация ще говоря само за първите две решения: и .
За първи път информация за се появи на . Архитектурата е описана и как работи.
Thanos взема данните, които Prometheus е записал на локалния диск и ги копира на S3, или към друг обект за съхранение.
Така Thanos предоставя глобален изглед на заявка. Можете да правите заявки за данни, съхранявани в обектно хранилище, от множество екземпляри на Prometheus.
Thanos поддържа PromQL и .
Thanos използва кода на Prometheus за съхраняване на данни.
Thanos е разработен от същите разработчици като Prometheus.
Около . Тук където за първи път говорихме .
VictoriaMetrics получава данни от няколко prometheus протокол, поддържан от Prometheus.
VictoriaMetrics предоставя глобален изглед на заявка, тъй като множество екземпляри на Prometheus могат да записват данни в един VictoriaMetrics. Съответно можете да правите заявки за всички тези данни.
VictoriaMetrics също поддържа, като Thanos, PromQL и API за заявки на Prometheus.
За разлика от Thanos, изходният код на VictoriaMetrics е написан от нулата и е оптимизиран за скорост и потребление на ресурси.
VictoriaMetrics, за разлика от Thanos, мащабира както вертикално, така и хоризонтално. Яжте , който се мащабира вертикално. Можете да започнете с един процесор и 1 GB памет и да стигнете до стотици процесори и 1 TB памет. VictoriaMetrics знае как да използва всички тези ресурси. Производителността му ще се увеличи с около 100 пъти в сравнение с 1-ядрена система.
Историята на Thanos започва през ноември 2017 г., когато се появява първият публичен ангажимент. Преди това Thanos е разработен вътрешно .
През юни 2019 г. имаше забележително издание 0.5.0, в което протокол. Той беше отстранен от Thanos, защото не се представи добре. Често клъстерът Thanos не работи правилно, възлите се свързват неправилно с него поради протокола за клюки. Затова решихме да го премахнем от там. Вярвам, че това е правилното решение.
През същия юни 2019 г. те изпратиха номер на заявление в .
И след няколко месеца Танос беше приет , който включва Prometheus, Kubernetes и други популярни проекти.
През януари 2018 г. започна разработката на VictoriaMetrics.
През септември 2018 г. за първи път публично споменах VictoriaMetrics.
През декември 2018 г. беше публикувана версията с един възел.
През май 2019 източници на версия с един възел и клъстер.
През юни 2019 г., също като Танос, подадохме молба до фондацията CNCF под номер . Кандидатствахме един ден преди Танос да кандидатства.
Но за съжаление все още не сме приети там. Необходима е помощ от общността.
Помислете за най-важните слайдове, показващи архитектурата на Thanos и VictoriaMetrics.
Да започнем с Танос. Жълтите компоненти са компоненти на Прометей. Всичко останало са компоненти на 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 Sidecar на свой ред изпраща заявки до Prometheus и получава данни за последните два часа.
В допълнение към тези компоненти има и незадължителен компонент, без който Танос ще се чувства зле. Това е Thanos Compact, който обединява малки файлове в Object Storage в по-големи файлове, които са качени тук от Thanos Sidecars. Thanos Sidecar качва файлове с данни там за два часа. Тези файлове, ако не бъдат обединени в по-големи файлове, техният брой може да нарасне много значително. Колкото повече такива файлове, толкова повече памет е необходима за Thanos Store Gateway, толкова повече ресурси са необходими за прехвърляне на данни по мрежата, метаданни. Thanos Store Gateway става неефективен. Ето защо е необходимо да стартирате Thanos Compact, който обединява малки файлове в по-големи, така че да има по-малко такива файлове и да се намали натоварването на Thanos Store Gateway.
Има и такъв компонент като Thanos Ruler. Той изпълнява правилата за предупреждение на Prometheus и може да изчисли правилата за запис на Prometheus, за да запише данни обратно в Object Storage. Но този компонент не се препоръчва да се използва, т.к. Той .
Ето една проста схема за Thanos.
Сега нека сравним със схемата на VictoriaMetrics.
VictoriaMetrics има 2 версии: с един възел и клъстерна версия. Единичен възел работи на един компютър. Единичният възел няма тези компоненти, а само един двоичен файл. Този двоичен файл на слайда изглежда като този квадрат. Всичко вътре в квадрата е съдържанието на двоичния файл за версията с един възел. Не е нужно да знаете за това. Просто стартирайте двоичния файл - и всичко работи за нас.
Клъстерната версия е по-трудна. В него има три различни компонента: vmselect, vminsert и vmstorage. От името им трябва да става ясно с какво се занимава всеки от тях. Компонентът Insert приема данни в различни формати: от API за отдалечен запис на Prometheus, протокола Influx line, протокола Graphite и протокола OpenTSDB. Компонентът Insert ги приема, анализира ги и ги разпределя между съществуващите компоненти за съхранение, където данните вече се съхраняват. Компонентът Select от своя страна приема PromQL заявки. Той изпълнява , както и API за заявки на Prometheus и може да се използва като заместител на Prometheus в Grafana или други клиенти на API на Prometheus. Select взема promql заявка, анализира я, чете необходимите данни за изпълнение на тази заявка от възли за съхранение, обработва тези данни и връща отговор.
Нека сравним сложността на инсталирането на Thanos и VictoriaMetrics.
Да започнем с Танос. Преди да започнете да работите с Thanos, трябва да създадете кофа в Object Storage, като S3 или GCS, така че Thanos Sidecar да може да записва данни там.
След това за всеки Prometheus трябва да инсталирате Thanos Sidecar. Преди това трябва да запомните да деактивирате уплътняването на данни в Prometheus. Уплътняването на данни периодично компресира данните в локалното хранилище на Prometheus, за да намали потреблението на ресурси.
Когато инсталирате Thanos Sidecar на вашия Prometheus, трябва да деактивирате това уплътняване на данни, защото Thanos Sidecar не работи правилно с активирано уплътняване на данни. Това означава, че вашият Prometheus започва да записва данни на блокове от по два часа и спира да обединява тези блокове в по-големи. Съответно, ако правите заявки, които надвишават продължителността на последните два часа, тогава те няма да работят толкова ефективно, колкото биха могли да работят, ако уплътняването на данни беше активирано.
Поради това Thanos препоръчва намаляване на времето за задържане на данни в локалното хранилище до 6-8 часа, за да се намалят тези разходи за голям брой малки блокове.
След като инсталирате Thanos Sidecar, трябва да инсталирате два компонента за всяка кофа за съхранение на обекти. Това са Thanos Compactor и Thanos Store Gateway.
След това трябва да инсталирате Thanos Query и да го конфигурирате, така че да може да се свързва с всички Thanos Store Gateways, които имате, както и да може да се свързва с всички Thanos Sidecars.
Тук може да има малък проблем.
Трябва да настроите надеждна и сигурна връзка от Thanos Query към тези компоненти. И ако имате Prometheus'y, разположен в различни центрове за данни или в различни VPC, тогава връзките към тях отвън са забранени. Но за да работи Thanos Query, трябва по някакъв начин да конфигурирате връзката там и трябва да измислите начин.
Ако имате много такива центрове за данни, тогава, съответно, надеждността на цялата система намалява. Тъй като Thanos Query трябва постоянно да поддържа връзки с всички Thanos Sidecars, разположени в различни центрове за данни. С всяка входяща заявка, той ще изпрати заявки до всички Thanos Sidecars. Ако връзката бъде прекъсната, тогава или ще получите непълен набор от данни, или ще получите отговор „клъстерът не работи“.
Във VictoriaMetrics нещата са малко по-прости. За версията с един възел просто стартирайте един двоичен файл и всичко работи.
В клъстерираната версия е достатъчно да стартирате всички горепосочени три вида компоненти във всяко количество, от което се нуждаете, или да използвате за автоматизиране на стартирането на компоненти в Kubernetes. Планираме да направим и Kubernetes оператор. Диаграмата на кормилото не покрива някои случаи и ви позволява да снимате крака си. Например, той ви позволява да намалите броя на възлите за съхранение, което ще доведе до загуба на данни.
След като стартирате една двоична или клъстерна версия, просто трябва да добавите към конфигурацията на Prometheus така че да започне да записва данни паралелно в локално хранилище и отдалечено хранилище. Както можете да видите, тази конфигурация трябва да работи много по-надеждно от конфигурацията на Thanos. Не е необходимо да поддържаме връзка от VictoriaMetrics с всички Prometheus, защото самите Prometheus се свързват с VictoriaMetrics и прехвърлят данни.
Обмислете поддръжка за Thanos и VictoriaMetrics.
Thanos трябва да държи под око Sidecar, за да не спрат да качват данни в Object Storage. Те могат да спрат това изтегляне на данни поради грешки при изтеглянето, например вашата мрежова връзка с Object Storage е временно загубена или Object Storage временно не е достъпно. Thanos Sidecar ще забележи това в този момент, ще съобщи за грешка, може да се срине и след това да спре да работи. Ако не го наблюдавате, вашите данни вече няма да се прехвърлят в Object Storage. Ако времето за задържане изтече (препоръчва се 6-8 часа), тогава ще загубите данни, които не са попаднали в Object Storage.
Компакторите Thanos може да спрат да работят поради . Компакторите вземат данни от Object Storage и ги обединяват в по-големи части от данни. Тъй като компакторите не са синхронизирани с Sidecars, може да се случи следното: Sidecar все още не е имал време да добави блока, Compactor решава, че този блок е напълно написан. Compactor започва да го чете. Прочита блока непълно и спира да работи. Виж детайлите .
Store Gateway може да върне несъвместими данни поради състезания между Compactor и Sidecars. Тук е същото, защото Store Gateway не е синхронизиран с Compactors и Sidecars по никакъв начин. Съответно условия на надпревара могат да възникнат, когато Store Gateway не вижда част от данните или вижда допълнителни данни.
Компонентът Query в Thanos връща частичен резултат по подразбиране, ако някои Sidecars или Store Gateways не са налични в момента. Ще получите част от данните и дори няма да знаете, че не сте получили всички данни. Ето как работи по подразбиране. В подобна ситуация VictoriaMetrics връща етикетирани данни като частични.
За разлика от Thanos, VictoriaMetrics рядко губи данни. Дори ако връзката от Prometheus към VictoriaMetrics бъде прекъсната, това не е проблем, тъй като Prometheus продължава да записва входящи нови данни в Write Ahead Log, което е с продължителност 2 часа. Ако възстановите връзката с VictoriaMetrics в рамките на два часа, данните няма да бъдат загубени. Прометей .
За разлика от Thanos, който записва данни в обектно хранилище само след два часа, Prometheus автоматично репликира данни чрез протокол за отдалечен запис в отдалечено хранилище, като VictoriaMetrics. Не се страхувате от загуба на локално хранилище в Prometheus. Ако той внезапно загуби локално хранилище, тогава ще загубите последните секунди от данни, които не са имали време да запишат в отдалечено хранилище в най-лошия случай.
Kubernetes управлява клъстера автоматично за разлика от Thanos. Трудно е да поставите всички компоненти на Thanos в един клъстер на Kubernetes, за разлика от клъстерните компоненти на VictoriaMetrics.
VictoriaMetrics има много лесен ъпгрейд до новата версия. Просто спрете VictoriaMetrics, актуализирайте двоичните файлове и започнете. Когато бъдат спрени чрез сигнал SIGINT, всички двоични файлове на VictoriaMetrics извършват грациозно изключване. Те правилно съхраняват необходимите данни, правилно затварят входящите връзки, за да не загубят нищо. Така че няма да загубите нищо, когато надстроите.
За VictoriaMetrics е много лесно да разшири клъстера. Просто добавете необходимите компоненти и продължете да работите.
За капаните в Thanos и VictoriaMetrics.
Танос има следните клопки. Prometheus трябва да съхранява данни за последните два часа. Ако се изгубят, ще ги загубите напълно, тъй като не са имали време да пишат в Object Storage, като S3.
Компонентът Store Gateway и компонентът compactor могат да отнемат много памет, за да се справят с голямо хранилище на обекти, ако там се съхраняват много малки файлове. Колкото по-голям е броят и размерът на файловете, толкова повече RAM изискват Store Gateway и компакторът за съхраняване на мета информация. Танос има много въпроси относно какво .
Thanos се рекламира като способен да се увеличава неограничено според броя на Prometheus, който имате. Всъщност това не е вярно. Тъй като всички заявки минават през компонента Query, който трябва да анкетира всички компоненти на Store Gateway и всички компоненти на Sidecar паралелно, извлича данни от там и след това ги обработва предварително. Очевидно е, че скоростта на заявките е ограничена от най-бавната слаба връзка, най-бавния Store Gateway или най-бавния Sidecar.
Тези компоненти може да са неравномерно натоварени. Например, имате Prometheus, който събира милиони показатели в секунда. Има и Prometheus, който събира хиляди показатели в секунда. Prometheus, който събира милиони метрики в секунда, натоварва много повече сървъра, на който работи. Съответно там Sidecar е по-бавен. И като цяло там всичко е бавно. И компонентът Query ще изтегля данни много бавно оттам. Съответно производителността на целия ви клъстер ще бъде ограничена от този бавен Sidecar.
По подразбиране Thanos връща частични данни, ако някои Sidecars или Store Gateways са недостъпни. Например, ако имате Sidecars, разпръснати по целия свят в различни центрове за данни, тогава вероятността от прекъсване на връзката и недостъпност на компонентите се увеличава значително. Съответно в повечето случаи ще получите частични данни, без дори да знаете.
VictoriaMetrics също има клопки. Първата клопка е опция, която ограничава количеството RAM, използвано за кеша на VictoriaMetrics. По подразбиране е 60% RAM на машината, на която работи VictoriaMetrics, или 60% RAM на VictoriaMetrics pod в Kubernetes.
Ако промените тази стойност неправилно, можете да разрушите производителността на VictoriaMetrics. Например, ако стойността е зададена твърде ниска, тогава данните може вече да не се побират в кеша на VictoriaMetrics. Поради това тя ще трябва да работи допълнително и да зарежда процесора с диска. Ако направите тази опция твърде голяма, това увеличава, първо, вероятността VictoriaMetrics да се срине с грешка за липса на памет, и второ, това ще доведе до факта, че операционната система ще има много малко останала RAM памет за файла кеш памет. И VictoriaMetrics разчита на файловия кеш за производителност. Ако не е достатъчно, тогава натоварването на диска може значително да се увеличи. Ето защо, съвет: не променяйте параметъра, освен ако не е абсолютно необходимо.
Втори вариант. Този retentionPeriod е период, който е зададен на 1 месец по подразбиране. Това е времето, през което VictoriaMetrics съхранява данните. След този период VictoriaMetrics изтрива данните.
Много хора стартират VictoriaMetrics без тази опция и записват данни за един месец. И тогава питат: защо изчезнаха данните за предходния месец? Тъй като по подразбиране RetentionPeriod е 1 месец. Следователно трябва да знаете и да зададете правилния retentionPeriod.
Нека да преминем през уникалните характеристики.
Thanos има функция, наречена downsampling: 5-минутни и почасови интервали, които често са . Ако потърсите в Google и разгледате техния проблем в github, има много проблеми, свързани с това намаляване на разделителната способност, че понякога не работи правилно или не работи според очакванията на потребителите.
Thanos има дедупликация на данни за Prometheus HA двойки. Когато два Prometheus събират едни и същи показатели от едни и същи цели и Thanos ги добавя към Object Storage. Thanos може правилно да дедуплира тези данни, за разлика от VictoriaMetrics.
Thanos има компонент за предупреждение, който беше на схемата на Thanos. Но той .
Танос има предимството, че Танос и Прометей споделят един и същ код. Thanos и Prometheus са разработени от едни и същи разработчици. С подобрения в 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 за 1TB. Това може да бъде важно, ако често изисквате исторически данни от клъстера Thanos.
За клъстер Thanos трябва да платите за сървъри за компоненти Compact, Store Gateway, Query, които изискват много памет, CPU за големи количества данни.
VictoriaMetrics има следните разходи. Ако съхранявате данни на GCE HDD, тогава излизат $40 за 1TB. За VictoriaMetrics са достатъчни обикновените HDD устройства, не са необходими SSD, които струват пет пъти повече. VictoriaMetrics е оптимизиран за HDD.
VictoriaMetrics се нуждае от сървъри за компоненти: или Single-nod, или за клъстерни компоненти, които, за разлика от компонентите на Thanos, изискват много по-малко CPU, RAM - съответно ще бъде по-евтино.
Примери за изпълнение.
За Thanos примерът за внедряване е Gitlab. Gitlab работи изцяло на Thanos. Но там не всичко е толкова гладко. Ако ги погледнете , тогава можете да видите, че те постоянно имат някои : Няма достатъчно памет за Store Gateway или Query компоненти. Те постоянно трябва да увеличават обема на паметта.
Поради това разходите за решаване на тези проблеми се увеличават.
Втората реализация, която може да е по-успешна, е Improbable, който започна разработката на Thanos. Те пуснаха източника на Thanos. Improbable е компания, която разработва двигатели за игри.
VictoriaMetrics има публични примери за внедряване, които са:
- wix създател на уебсайтове
- Adidas прилага VictoriaMetrics и дори направи презентация на последния PromCon 2019
- Рекламна мрежа TrafficStars
- Seznam.cz е популярна чешка търсачка.
И тогава имаше компании без име, които не мога да назова сега. Те не се съгласиха.
- Един основен разработчик на игри. По-голям от невероятно.
- Голям разработчик на графичен софтуер.
- Голяма руска банка.
- Европейски производител на вятърни турбини, който успешно тества VictoriaMetrics. Този производител внедрява VictoriaMetrics за наблюдение на данни от вятърни турбини със скорост от 50 проби в секунда на сензор. Всяка вятърна турбина има няколкостотин сензора. Имат няколкостотин вятърни турбини.
- Руски авиокомпании, които искат да внедрят VictoriaMetrics, но все още не могат. Ние сме на етап договор с тях.
Заключения.
VictoriaMetrics и Thanos решават подобни проблеми, но по различни начини:
- Глобален изглед на заявка
- хоризонтално мащабиране
- произволно задържане
Благодаря.
Очакваме ви на нашия .
В анкетата могат да участват само регистрирани потребители. , Моля те.
Какво използвате като дългосрочно съхранение за Prometheus?
-
35,3%Танос6
-
0,0%Cortex0
-
0,0%M3DB0
-
41,2%VictoriaMetrics7
-
23,5%други4
17 потребители гласуваха. 16 потребители се въздържаха.
Източник: www.habr.com