На всички привет. По-долу е представено разшифрованието .
– система за мониторинг на различни системи и услуги, с помощта на която системните администратори могат да събират информация за текущите параметри на системите и да настроят известия за получаване на уведомления за отклонения в работата на системите.
В доклада ще бъде направено сравнение и — проекти за дългосрочно съхранение на метрики Prometheus.
Първо ще разкажа за Prometheus. Това е система за мониторинг, която събира метрики от зададени цели и ги съхранява в локално хранилище. 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 ГБ памет и постепенно да нараствате до стотици процесори и 1 ТБ памет. VictoriaMetrics може да използва всички тези ресурси. Нейната производителност ще нарасне приблизително 100 пъти в сравнение с 1-ядрена система.
Историята на Thanos започна през ноември 2017 г., когато се появи първият публичен комит. Преди това Thanos е бил разработван вътре в компанията .
През юни 2019 г. имаше знаков релиз 0.5.0, в който протокол. Той беше премахнат от Thanos, защото се показа не от най-добрата си страна. Често клъстерът Thanos не работеше правилно, възлите не се свързваха правилно поради gossip протокола. Затова решихме да го премахнем. Смятам, че това е правилното решение.
В същия юни 2019 г. те подадоха заявка номер в .
И след няколко месеца Thanos беше приет в , който включва Prometheus, Kubernetes и други популярни проекти.
През януари 2018 г. започна разработката на VictoriaMetrics.
През септември 2018 г. за първи път публично споменах VictoriaMetrics.
През декември 2018 г. публикувахме версия с един възел.
През май 2019 г. изходните кодове както на версията с един възел, така и на клъстерната версия.
През юни 2019 г., както Thanos, ние подадохме заявка в фондацията CNCF под номер . Подадохме заявка един ден по-рано от Thanos.
Но, за съжаление, до сега не сме били приети. Нуждаем се от помощ от общността.
Нека разгледаме най-важните слайдове, показващи архитектурата на Thanos и VictoriaMetrics.
Започваме с Thanos. Жълтите компоненти — това са компонентите на Prometheus. Всичко останало — това са компонентите на Thanos. Започваме с най-важния компонент. Thanos Sidecar — това е компонент, който се инсталира до всеки Prometheus. Той се грижи за зареждането на данни от Prometheus от локалното хранилище в S3 или в друг Обектен Хранилище.
Има и такъв компонент, като Thanos Store Gateway, който може да прочита тези данни от Object Storage при входящи запитвания от Thanos Query. Thanos Query реализира PromQL и Prometheus API. Тоест отвън изглежда като Prometheus. Приема запитвания 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 ще работи неефективно. Това е Thanos Compact, който се занимава с обединението на малки файлове в Object Storage в по-големи файлове, които са били качени там от Thanos Sidecar. Thanos Sidecar качва там файлове с данни за два часа. Тези файлове, ако не се обединяват в по-големи, могат да се увеличат значително. Колкото повече такива файлове, толкова повече памет е необходима за Thanos Store Gateway, толкова повече ресурси са нужни за предаването на данни по мрежата и метаданни. Работата на Thanos Store Gateway става неефективна. Затова е необходимо задължително да се стартира Thanos Compact, който обединява малките файлове в по-големи, за да има по-малко от тези файлове и за да се намали натоварването на Thanos Store Gateway.
Има и такъв компонент като Thanos Ruler. Той изпълнява правилата за известяване на Prometheus и може да изчислява правилата за записване на Prometheus, за да записва данните отново в Object Storage. Но този компонент не се препоръчва за употреба, тъй като той .
Такава е простата схема на Thanos.
Сега да сравним със схемата на VictoriaMetrics.
VictoriaMetrics има 2 версии: Single-node и клъстерна версия. Single-node работи на един компютър. В Single-node няма тези компоненти, просто един бинарен файл. Този бинарен файл на слайда изглежда като този квадрат. Всичко, което се намира вътре в квадрата, е съдържанието на бинарния файл за версията Single-node. Не е нужно да знаете за него. Просто стартирате бинарния файл — и всичко функционира.
Кластерната версия е по-сложна. Вътре в нея се намират три различни компонента: vmselect, vminsert и vmstorage. От имената им трябва да е ясно с какво се занимава всеки един от тях. Компонентът Insert приема данни в различни формати: от Prometheus remote write API, Influx line протокола, Graphite протокола и от OpenTSDB протокола. Компонентът Insert ги приема, парсира и разпределя между наличните компоненти за съхранение, където данните се запазват. , както и Prometheus querying API, и може да бъде използван като заместител на Prometheus в Grafana или други Prometheus API клиенти. Select приема promql заявки, парсира ги, извлича необходимите данни за изпълнение на тази заявка от storage възлите, обработва тези данни и връща отговор.
Нека сравним сложността на инсталиране на Thanos и VictoriaMetrics.
Да започнем с Thanos. Преди да започнете работа с Thanos, трябва да създадете bucket в Object Storage, като S3 или GCS, за да може Thanos Sidecar да записва данни там.
След това за всеки Prometheus трябва да инсталирате Thanos Sidecar. Преди това не забравяйте да изключите data compaction в Prometheus. Data compaction периодично компресира данните в локалното хранилище на Prometheus, за да намали потреблението на ресурси.
Когато инсталирате Thanos Sidecar на вашите Prometheus инстанции, трябва да изключите този data compaction, тъй като Thanos Sidecar не може да работи правилно при включен data compaction. Това означава, че вашият Prometheus започва да запазва данните на блокове по два часа и спира да обединява тези блокове в по-големи. Следователно, ако правите заявки, които надвишават продължителността за последните два часа, те ще работят по-малко ефективно в сравнение с това, как биха могли да работят, ако data compaction беше включен.
Поради това Thanos препоръчва да се намали времето за съхранение на данните (data retention) в локалното хранилище до 6-8 часа, за да се намали този overhead на многото малки блокове.
След като сте инсталирали Thanos Sidecar, трябва за всеки Object Storage Bucket да инсталирате два компонента. Това са Thanos Compactor и Thanos Store Gateway.
След това трябва да инсталирате Thanos Query и да го настроите, така че да може да се свързва с всички Thanos Store Gateway, които имате, а също и да може да се свързва с всички Thanos Sidecar.
Тук може да има малък проблем.
Трябва да настроите надеждно и защитено свързване от Thanos Query към тези компоненти. И ако вашите Prometheus-и се намират в различни дата центрове или в различни VPC, достъпът отвън е забранен. Но за да работи Thanos Query, трябва да намерите начин да настроите свързването там.
Ако имате много такива дата центрове, надеждността на цялата система съответно намалява. Тъй като Thanos Query трябва постоянно да поддържа връзки с всички Thanos Sidecar, разположени в различни дата центрове. При всяко входящо запитване той ще насочва заявките към всичките Thanos Sidecar. Ако връзката прекъсне, ще получите или непълен набор от данни, или ще получите отговор "класът не работи".
В VictoriaMetrics всичко е малко по-просто. За версията с единичен възел е достатъчно да стартирате един бинарник и всичко работи.
В кластерната версия е достатъчно да стартирате всички споменати три типа компоненти в нужното ви количество, или да използвате за автоматизация на стартирането на компонентите в Kubernetes. Още планираме да направим оператор за Kubernetes. Helm chart не покрива някои ситуации и може да причини проблеми. Например, той позволява намаляване на броя на storage node, което може да доведе до загуба на данни.
След като стартирате един бинарник или кластерната версия, достатъчно е да добавите в конфигурацията на Prometheus , за да започне да записва данни паралелно в локалния storage и в remote storage. Както забелязахте, такава конфигурация би трябвало да работи значително по-надеждно в сравнение с конфигурацията на 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 и ги комбинират в по-големи блокове данни. Тъй като компакторите не са синхронизирани с Sidecar, може да се случи следното: Sidecar все още не е завършил записването на блока, а компакторът решава, че този блок е напълно записан. Компакторът започва да го чете. Той чете блока не в пълен вид и спира да работи. Вижте подробности. .
Store Gateway може да предоставя несъответстващи данни поради конфликти между компактора и Sidecar. Тук е същото, защото Store Gateway не е синхронизиран с компактори и Sidecar. Съответно, могат да възникнат състояния на конфликт, когато Store Gateway не вижда част от данните или вижда излишни данни.
Компонентът Query в Thanos по подразбиране предоставя частичен резултат, ако някои Sidecar или Store Gateway не са налични в момента. Ще получите част от данните и дори няма да знаете, че не сте получили всички данни. Това е естественото му поведение. В подобна ситуация VictoriaMetrics връща етикетирани данни като частични.
За разлика от Thanos, VictoriaMetrics рядко губи данни. Дори ако свързването от Prometheus към VictoriaMetrics е прекъснато, това не е проблем, тъй като Prometheus продължава да записва новите входящи данни в Write Ahead Log, размерът на който е равен на 2 часа. Ако в рамките на два часа възстановите свързването с VictoriaMetrics, данните няма да се загубят. Prometheus .
За разлика от Thanos, който записва данни в object storage само след два часа, Prometheus автоматично репликира данните чрез remote write протокола в remote storage, като например VictoriaMetrics. Нямате причина да се притеснявате за загуба на local storage в Prometheus. Ако случайно загубите local storage, в най-лошия случай ще загубите последните няколко секунди данни, които не са успели да се запишат в remote storage.
Kubernetes автоматично управлява кластера, за разлика от Thanos. Всички компоненти на Thanos е трудно да бъдат поставени в един Kubernetes кластер, в противоречие с кластерните компоненти на VictoriaMetrics.
Съпоставянето на VictoriaMetrics е много лесно за нова версия. Просто спирате VictoriaMetrics, актуализирате бинарните файлове и стартирате отново. При спирането чрез SIGINT сигнал всички бинарни файлове на VictoriaMetrics извършват graceful shutdown. Те правилно запазват нужните данни и коректно затварят входящите връзки, за да не загубите нищо. Следователно, при актуализацията, няма да загубите нищо.
Разширяването на кластера в VictoriaMetrics е много просто. Просто добавяте необходимите компоненти и продължавате да работите.
За подводните камъни в Thanos и VictoriaMetrics.
Thanos има следните подводни камъни. Prometheus трябва да съхранява данните за последните два часа. Ако те се загубят, ще ги загубите напълно, тъй като те все още не са успели да се запишат в Object Storage, като S3.
Компонентът Store Gateway и компонентът сompactor може да изискват много памет за работа с големи Object Storage, ако там се съхраняват много малки файлове. Колкото по-голямо е количеството и обемът на файловете, толкова повече оперативна памет изискват Store Gateway и сompactor за съхраняване на метаинформацията. Thanos има много проблеми по отношение на това, че .
Thanos се рекламира, че може да скалира безкрайно на базата на броя на вашите Prometheus. Всъщност, това не е вярно. Всички заявки преминават през компонента Query, който трябва паралелно да запита всички компоненти Store Gateway и всички компоненти Sidecar, да извлече данни от тях и след това да ги предварително обработи. Очевидно е, че скоростта на заявките е ограничена от най-бавното слабо звено, най-бавния Store Gateway или най-бавния Sidecar.
Тези компоненти могат да бъдат неравномерно натоварени. Например, имате Prometheus, който събира милиони метрики в секунда. И имате Prometheus, в който се събират хиляди метрики в секунда. Prometheus, в който се събират милиони метрики в секунда, натоварва сървъра, на който работи, много повече. Съответно Sidecar там работи по-бавно. И изобщо всичко там работи бавно. И компонентът Query ще вади данни оттам много бавно. Следователно производителността на целия ви клъстер ще бъде ограничена от този бавен Sidecar.
По подразбиране Thanos предоставя частични данни, ако някои Sidecar’и или Store Gateway са недостъпни. Например, ако Sidecar’ите ви са разпределени по целия свят в различни дата центрове, вероятността за прекъсване на връзката и недостъпност на компонентите значително нараства. Следователно, в повечето случаи ще получавате частични данни, дори и да не знаете за това.
VictoriaMetrics също има свои подводни камъни. Първият подводен камък е опцията, която ограничава обема на оперативната памет, използвана за кеша на VictoriaMetrics. По подразбиране тя е 60% от оперативната памет на машината, на която е стартирана VictoriaMetrics, или 60% от RAM на пода на VictoriaMetrics в Kubernetes.
Ако неправилно промените това значение, можете да унищожите производителността на VictoriaMetrics. Например, ако зададете твърде ниска стойност, данните може да не се побират в кеша на VictoriaMetrics. Поради това тя ще трябва да извършва излишна работа и да натоварва процесора с диска. Ако направите тази опция твърде голяма, това увеличава, на първо място, вероятността VictoriaMetrics да аварийно изключи с грешка out of memory, и, на второ място, ще доведе до това, че в операционната система ще остане много малко оперативна памет за файловия кеш. А VictoriaMetrics разчита на файловия кеш за производителност. Ако не е достатъчно, натоварването на диска може значително да се увеличи. Затова съвет: не променяйте параметъра без крайна необходимост.
Втората опция. Това е retentionPeriod — период, който по подразбиране е зададен на 1 месец. Това е времето, през което VictoriaMetrics съхранява данните. След изтичане на този срок, VictoriaMetrics изтрива данните.
Много хора стартират VictoriaMetrics без този параметър и записват данни в продължение на месец. А след това питат: защо данните изчезнаха за предходния месец? Защото retentionPeriod по подразбиране е 1 месец. Затова е нужно да знаете и да зададете правилния retentionPeriod.
Нека разгледаме уникалните възможности.
Thanos разполага с функция, наречена downsampling: 5-минутни и часови интервали, които често . Ако потърсите в Google и погледнете техните проблеми в GitHub, ще откриете много проблеми, свързани с това downsampling, което понякога неработи правилно или работи не така, както очакват потребителите.
Thanos разполага с дедупликация на данни за Prometheus HA двойки. Когато два Prometheus-а събират едни и същи метрики от същите целеви обекти и Thanos ги съхранява в Object Storage. Thanos може да дедупликира тези данни правилно, за разлика от VictoriaMetrics.
Thanos разполага с компонент за известия, който беше на схемата на Thanos. Но .
При Thanos е предимство, че кодът на Thanos и Prometheus е общ. 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 на 1ТБ. Това може да бъде значително, ако често запитвате исторически данни от клъстера на Thanos.
За кластера Thanos е необходимо да плащате сървъри за компонентите Compact, Store Gateway и Query, които изискват много памет и CPU за големи обеми данни.
Разходите за VictoriaMetrics са такива. Ако съхранявате данни на HDD дискове в GCE, излиза 40 $ за 1 ТБ. За VictoriaMetrics са достатъчни обикновени HDD дискове, не са нужни SSD, които струват пет пъти повече. VictoriaMetrics е оптимизирана за HDD.
За VictoriaMetrics са нужни сървъри за компонентите: или Single-node, или за клъстерни компоненти, които в отличие от компонентите на Thanos, изискват значително по-малко CPU и RAM, съответно ще бъде по-евтино.
Примери за внедряване.
Пример за внедряване на Thanos е Gitlab. Gitlab функционира изцяло на Thanos. Но там не всичко е гладко. Ако погледнете техните , можете да видите, че постоянно им възникват някакви : не им достига памет за компонентите Store Gateway или Query. Постоянно трябва да увеличават обема на паметта.
Заради това разходите за решаване на тези проблеми се увеличават.
Второто внедряване, което може да бъде по-успешно, е компанията Improbable, които започнаха разработката на Thanos. Те публикуваха изходния код на Thanos. Improbable е компания, занимаваща се с разработка на игрови двигатели.
Публичните примери за внедряване на VictoriaMetrics включват:
- wix.com - конструктор на сайтове
- Adidas внедрява VictoriaMetrics и дори направи доклад на последния PromCon 2019
- TrafficStars - рекламна мрежа
- Seznam.cz - популярен чешки търсач.
А след това следват ноунейм компании, които в момента не мога да назова. Те не дадоха съгласие.
- Една голяма компания за разработка на игри. По-голяма от Improbable.
- Голяма компания за разработка на графичен софтуер.
- Голяма руска банка.
- Европейски производител на вятърни турбини, който успешно е тествал VictoriaMetrics. Този производител внедрява VictoriaMetrics за мониторинг на данни, получени от вятърни турбини със скорост от 50 сензора в секунда на всеки сензор. Във всяка вятърна турбина има няколко стотин сензора. Те имат няколко стотин вятърни турбини.
- Руски авиолинии, които искат да внедрят VictoriaMetrics, но все още не могат. Ние сме в етап на договора с тях.
Изводи.
VictoriaMetrics и Thanos решават подобни задачи, но по различни начини:
- Глобален изглед на заявки
- хоризонтално мащабиране
- произволно запазване
Благодаря.
Очакваме ви на нашия .
Само регистрирани потребители могат да участват в анкетата. , моля.
Какво използвате за дългосрочно съхранение за Prometheus?
35,3%Thanos6
0,0%Cortex0
0,0%M3DB0
41,2%VictoriaMetrics7
23,5%друго4
Гласували 17 потребители. 16 потребители се въздържаха.
Източник: habr.com
