Комментарии 9
мы тоже у себя тестируем, в ограниченный прод запустили маленький под-проект. выбрали по большей части изза вкусностей как раз расширеного QL, даже багу там нашли )) в итоге одна виктория заменила самописный сервис и базу мускуля на почти террабайт. финансовые данные, могу только сказать пока что
Поэтому Thanos рекомендует уменьшать время хранения данныех (data retention) в локальном storage до 6-8 часов, чтобы снизить этот overhead большого количества мелких блоков.
Thanos Sidecar в этот момент заметит это, сообщит об ошибке, может свалиться и после этого перестать работать.
Store Gateway может отдавать неконсистентные данные из-за race'ов между Compactor'ом и Sidecar'ами.
Все компоненты Thanos сложно поместить в один Kubernetes кластер, в отличие от кластерных компонент VictoriaMetrics.
В отличие от Thanos, VictoriaMetrics редко теряет данные.

Очень жалко выглядит когда в рекламной статье пишут голословно про проблемы конкурента. Приводите ссылки на issue или не упоминайте вообще.


Часто кластер Thanos неправильно работал, неправильно подключались к нему ноды из-за gossip протокола. Поэтому решили его оттуда убрать. Я считаю, что это правильное решение.

Это было минорное изменение версии 0.5, которое было запланировано за несколько версий до. Т.к к тому времени большинство уже пользовалось sd_file и sd_dns.


VictoriaMetrics в отличие от Thanos, масштабируется как вертикально так и горизонтально.

Лишь показывает что вы не представляете как масштабировать Thanos. Зачем тогда упоминать его? Там кстати и шардировать можно.


Это Thanos Compact, который занимается слиянием мелких файлов
Эти файлы, если их не сливать в более крупные файлы, то их количество может вырастить очень существенно.

Вы видимо не понимаете что именно делает thanos-compact. Компакшн файлов — это лишь малая часть, основная часть — это downsampling. Создаются усреднения для ренджей 5m и 1h, где каждая точка по сути содержит 5 значений (min, max, sum, count, avg) чтобы все функции продолжали работать на усредненных данных корректно. Далее когда вы делаете query за большой диапазон времени (например за месяц, год) thanos-store использует эти посчитанные данные. Т.е. raw данные не используются, даже если они у вас есть за годы назад. И основная отличительная черта Thanos — что можно настроить retention и хранить raw только за последние 2 недели, а 1h — бесконечно, что очень дешево на S3-IA.


Перед тем, как начать работать с Thanos, нужно создать storage bucket в Object Storage, такой как S3 или GCS, чтобы Thanos sidecar мог туда записывать данные.

Если мы говорим про легкость сетапа — S3 вовсе не обязателен для начала работы с Thanos и получения global-view из нескольких прометеев.


Нам не нужно держать подключение от VictoriaMetrics ко всем Prometheus'ам, потому что Prometheus'ы сами подключаются к VictoriaMetrics и передают данные.

Большинство минусов которые вы описываете не относятся к сравнению Thanos или VictoriaMetrics, a являются сравнением схем remote-write и thanos-sidecar. При этом Thanos так же поддерживает remote-write Т.е. он может так же стоять в центре и получать данные, как и VictoriaMetrics и m3db.
Но его отличительная черта, что он так же позволяет локализовать данные и не посылать их в единое место. И все равно иметь global-view и long term storage при этом. Представьте ситуцию когда у вас несколько регионов в AWS. Вы можете в каждом регионе иметь свой prometheus который пишет данные в локальный S3. Вы приходите из центральной графаны за мизерным обьемом тех точек графиков на которые вы смотрите (ответы на PromQL запросы), а основные гигабайты остаются лежать локально. А в случае remote-write вы бы все время передавали эти гигабайты со всех регионов, без разницы смотрит на них кто-либо или нет, и платили за траффик.


Если записывать реальные данные, то пользователи говорят о 2-5 кратном уменьшение размера данных на диске по сравнению с Prometheus и Thanos.

Очевидно вы пытаетесь сказать про "уменьшение размера данных" не принимая в расчет downsampling с retention, который ваш продукт не умеет в отличии от Thanos и m3db.


В отличие от Thanos, исходный код VictoriaMetrics написан с нуля и оптимизирован по скорости и потребляемым ресурсам.

https://www.robustperception.io/evaluating-performance-and-correctness
"Prometheus server's compression (which both Cortex and Thanos use) is slightly better by about 10% than VictoriaMetrics and that in addition VictoriaMetrics was not storing all the information that Prometheus does."
"This shows that Prometheus is faster in all cases, by ~2.0-4.4x."


Adidas внедряет VictoriaMetrics и даже сделал доклад на последнем PromCon 2019

Тогда уж стоит упомянуть и другой доклад с PromCon 2019, где говорится о проблемах VictoriaMetrics с ребалансом и потерей данных при rolling-reboot (нет auto-heal). Для сравнения в Thanos всегда можно перегенировать 5m,1h опять по raw данным. m3db поддерживает rebalance.


К сожалению доклад выполнен в худших маркетинговых традициях, которые в технической среде сразу приводят к нелюбви к продукту. Даже удивительно, что он сделан СТО.
Я предложил бы вам больше рассказывать про детали своего продукта, а не хаять конкурента опыта с которым вы не имеете.
image

Очень жалко выглядит когда в рекламной статье пишут голословно про проблемы конкурента. Приводите ссылки на issue или не упоминайте вообще.

Не скажу, что это выглядит «жалко», скорее «агрессивно». Все-таки это статья о сравнении двух подходов. Но считаю правильным приводит такие ссылки на issue и надеюсь автор это сделает. Во всяком случае, другие его статьи всегда аргументированны и подкреплены фактами — medium.com/@valyala

Лишь показывает что вы не представляете как масштабировать Thanos. Зачем тогда упоминать его? Там кстати и шардировать можно.

Ну насколько я знаю, у thanos все-таки есть проблемы с шардированием, как ни странно, индекса. Посмотрите, например, на статы gitlab — gitlab.com/gitlab-com/gl-infra/infrastructure/issues/8685#note_261760187. Здесь индекс для «db» занимает 2TB и, как я понимаю, thanos-store потребует именно такой обьем ОЗУ на машине чтобы запуститься. Поправьте, если я ошибаюсь.

Вы видимо не понимаете что именно делает thanos-compact. Компакшн файлов — это лишь малая часть, основная часть — это downsampling. Создаются усреднения для ренджей 5m и 1h, где каждая точка по сути содержит 5 значений (min, max, sum, count, avg) чтобы все функции продолжали работать на усредненных данных корректно. Далее когда вы делаете query за большой диапазон времени (например за месяц, год) thanos-store использует эти посчитанные данные. Т.е. raw данные не используются, даже если они у вас есть за годы назад. И основная отличительная черта Thanos — что можно настроить retention и хранить raw только за последние 2 недели, а 1h — бесконечно, что очень дешево на S3-IA.

Даунсемлпинг не такая простая вещь, чтобы ее просто «включить». Для читателей предлагаю ознакомиться с github.com/thanos-io/thanos/issues/813.
Если мы говорим о даунсемплинге счетчиков (метрик, которые только увеличиваются), то сокращения разрешения до 1ч еще может быть валидным. Но представьте что произойдет с информативностью метрики использованию CPU, если сохраниться только одна точка в 1ч — она просто станет бессмысленной. К примеру, у gitlab только 6% метрик даунсемплированы. Я признаю, что даунсемплинг это хорошая вещь, но только нужно четко понимать как ее использовать.

Если мы говорим про легкость сетапа — S3 вовсе не обязателен для начала работы с Thanos и получения global-view из нескольких прометеев.

Это действительно так! Но нужно уточнить, что при росте кол-ва прометеусов в инфраструктуре качество работы такого подхода будет сильно ухудшаться. Например, если у вас около 100 прометеусов, то для обработки запроса нужно будет ждать ответа от самого медленного из них + возможные сетевые проблемы. В таком случае, мониторинг может перестать быть оперативным. Но для маленьких сетапов это будет работать.

Большинство минусов которые вы описываете не относятся к сравнению Thanos или VictoriaMetrics, a являются сравнением схем remote-write и thanos-sidecar. При этом Thanos так же поддерживает remote-write Т.е. он может так же стоять в центре и получать данные, как и VictoriaMetrics и m3db.
Но его отличительная черта, что он так же позволяет локализовать данные и не посылать их в единое место. И все равно иметь global-view и long term storage при этом. Представьте ситуцию когда у вас несколько регионов в AWS. Вы можете в каждом регионе иметь свой prometheus который пишет данные в локальный S3. Вы приходите из центральной графаны за мизерным обьемом тех точек графиков на которые вы смотрите (ответы на PromQL запросы), а основные гигабайты остаются лежать локально. А в случае remote-write вы бы все время передавали эти гигабайты со всех регионов, без разницы смотрит на них кто-либо или нет, и платили за траффик.

Валидное замечание, на мой взгляд. Это определнно нужно учитывать!

Очевидно вы пытаетесь сказать про «уменьшение размера данных» не принимая в расчет downsampling с retention, который ваш продукт не умеет в отличии от Thanos и m3db.

Я бы тоже не принимал в расчет downsampling, т.к. он не помогает уменьшить размер данных на диске — thanos.io/components/compact.md/#downsampling-resolution-and-retention. Хорошее сжатие же помогает не только сэкономить место, но и позволяет многократно увеличить производительность системы, т.к. чем меньше данные занимают места, тем меньше времени система проведет считывая их с диска.

www.robustperception.io/evaluating-performance-and-correctness
«Prometheus server's compression (which both Cortex and Thanos use) is slightly better by about 10% than VictoriaMetrics and that in addition VictoriaMetrics was not storing all the information that Prometheus does.»

Я в курсе данной статьи. Для интересующихся темой очень рекомендую прочесть и ответ на нее — medium.com/@valyala/evaluating-performance-and-correctness-victoriametrics-response-e27315627e87. Здесь очень важно услышать обе стороны, а еще лучше — проверить и посмотреть все самому.

«This shows that Prometheus is faster in all cases, by ~2.0-4.4x.»

К сожалению, автор приведенной вами статьи не приводит исходный код бенчмарка, на основе которого он получил результаты. Бенчмарк же взятый из исходников прометеуса показывает, что VM быстрее — github.com/VictoriaMetrics/VictoriaMetrics/commit/b6f22a62cb385db5eb149789c42aaddd246a6750

Тогда уж стоит упомянуть и другой доклад с PromCon 2019, где говорится о проблемах VictoriaMetrics с ребалансом и потерей данных при rolling-reboot (нет auto-heal). 

Хм, я не услышал ничего про «потерей данных при rolling-reboot» в том докладе. Пожалуйста уточните, что именно имеется в виду или сбросьте линк на ту часть доклада, где об этом говориться.
Решардинга действительно нет, но я и не считаю, что он настолько важен для VM. Пример КХ показывает, что система может быть крайне жизнеспособной и производительной и без этой фичи.

Я предложил бы вам больше рассказывать про детали своего продукта, а не хаять конкурента опыта с которым вы не имеете.

Тут согласен! Считаю, что подобные статьи должны быть больше сконцентрированы на технических аспектах, это не соревнование.

Грязный маркетинг — неотъемлимая часть продвижения VM, это их основная фишка же

Лишь показывает что вы не представляете как масштабировать Thanos. Зачем тогда упоминать его? Там кстати и шардировать можно.

Расскажите подробнее, как масштабировать Thanos, и сравните сложность масштабирования Thanos с масштабированием VictoriaMetrics. Про шардирование тоже расскажите, не забывая про открытые баги, связанные с шардированием.


Вы видимо не понимаете что именно делает thanos-compact. Компакшн файлов — это лишь малая часть, основная часть — это downsampling. Создаются усреднения для ренджей 5m и 1h, где каждая точка по сути содержит 5 значений (min, max, sum, count, avg) чтобы все функции продолжали работать на усредненных данных корректно. Далее когда вы делаете query за большой диапазон времени (например за месяц, год) thanos-store использует эти посчитанные данные. Т.е. raw данные не используются, даже если они у вас есть за годы назад. И основная отличительная черта Thanos — что можно настроить retention и хранить raw только за последние 2 недели, а 1h — бесконечно, что очень дешево на S3-IA.

Даунсемплинг в Thanos сложно назвать решением, готовым к production — см. открытые баги по даунсемплингу в Thanos.


При этом Thanos так же поддерживает remote-write Т.е. он может так же стоять в центре и получать данные, как и VictoriaMetrics и m3db.

У Thanos receiver есть небольшая проблемка — он не production-read.


Представьте ситуцию когда у вас несколько регионов в AWS. Вы можете в каждом регионе иметь свой prometheus который пишет данные в локальный S3. Вы приходите из центральной графаны за мизерным обьемом тех точек графиков на которые вы смотрите (ответы на PromQL запросы), а основные гигабайты остаются лежать локально. А в случае remote-write вы бы все время передавали эти гигабайты со всех регионов, без разницы смотрит на них кто-либо или нет, и платили за траффик.

Хороший пример. Такую же схему можно реализовать и на основе VictoriaMetrics — данные в каждом регионе записываются в локальный экземпляр VictoriaMetrics, для global querying view используем Promxy поверх всех экземпляров VictoriaMetrics.


https://www.robustperception.io/evaluating-performance-and-correctness
"Prometheus server's compression (which both Cortex and Thanos use) is slightly better by about 10% than VictoriaMetrics and that in addition VictoriaMetrics was not storing all the information that Prometheus does."
"This shows that Prometheus is faster in all cases, by ~2.0-4.4x."

Рекомендую почитать ответ на эту статью — https://medium.com/@valyala/evaluating-performance-and-correctness-victoriametrics-response-e27315627e87 .


Тогда уж стоит упомянуть и другой доклад с PromCon 2019, где говорится о проблемах VictoriaMetrics с ребалансом и потерей данных при rolling-reboot (нет auto-heal)

Не могу найти в этом докладе упоминания про проблемы с потерей данных при rolling update. Кластер VictoriaMetrics поддерживает rolling update всех компонент без потери данных.

хорошее замечание, я не такой спец по обоим продуктам, но по самому тексту можно уже понять предвзятость или если хотите определенную симпатию к одному продукту и антипатию к другому.
Все компоненты Thanos сложно поместить в один Kubernetes кластер, в отличие от кластерных компонент VictoriaMetrics

https://github.com/thanos-io/kube-thanos/.


Если посмотреть по их issues, то можно увидеть что у них постоянно возникают какие-то операционные проблемы с Thanos

У нас были похожие проблемы, они исчезли после перехода на remote write.


С одной стороны я рад что соревнуются два open source проекта, но печально что методы в этой борьбе остались те же — рекламные статьи о преимуществах без сравнительных графиков и отзывах клиентов

https://github.com/thanos-io/kube-thanos/

Расскажите, как поместить все компоненты Thanos, включая Thanos Sidecars, в один K8S кластер, если у вас много Prometheus'ов раскиданы по разным датацентрам?


У нас были похожие проблемы, они исчезли после перехода на remote write.

Неужели это решило проблемы с нехваткой оперативной памяти в Thanos Store Gateway?

Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.