Во-первых, они используют версию 2.2.0, хотя актуальная версия - 2.8.0
Версии VM и Mimir были актуальными на момент бенчмарка. Вы тестировали оба решения или выбор был сделан только на основе статей и документации?
В статье отсутствует информация об использовании S3, который является ключевым компонентом и сильно влияет на производительность.
В статье достаточно много времени уделяется object storage. Но я не понимаю как использование S3 может в положительном ключе влиять на производительность по сравнению с более быстрыми и доступными локальными дисками?
в Mimir для хранения 3,5 Тб метрик требуется всего 3 Тб дискового пространства
Вы имеете в виду 3.5TB были сжаты в 3TB? Если это так, то в VM можете ожидать 1TB согласно цифрам из бенчмарка.
В статье проводится бенчмарк в течение одних суток
Валидное замечание. Время бенчмарка, к сожалению, ограничено его стоимостью.
учитывая многоуровневый merge данных в Mimir, реальное потребление места на данных за день и месяц может значительно отличаться.
Аналогично работает слияние и рекомпрессия данных в VictoriaMetrics. Данные могут сжиматься вплоть до 1 месяца.
Можете поделиться ресурсами выделенными под сторадж и статистику его использования? Интересует использование cpu, ram, дискового пространства, кол-во уникальных рядов, кол-во собранных точек, скорость их вставки и средний «вес» точки в байтах, кол-во обрабатываемых запросов на чтение. Спасибо!
Очень жалко выглядит когда в рекламной статье пишут голословно про проблемы конкурента. Приводите ссылки на 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.»
Тогда уж стоит упомянуть и другой доклад с PromCon 2019, где говорится о проблемах VictoriaMetrics с ребалансом и потерей данных при rolling-reboot (нет auto-heal).
Хм, я не услышал ничего про «потерей данных при rolling-reboot» в том докладе. Пожалуйста уточните, что именно имеется в виду или сбросьте линк на ту часть доклада, где об этом говориться.
Решардинга действительно нет, но я и не считаю, что он настолько важен для VM. Пример КХ показывает, что система может быть крайне жизнеспособной и производительной и без этой фичи.
Я предложил бы вам больше рассказывать про детали своего продукта, а не хаять конкурента опыта с которым вы не имеете.
Тут согласен! Считаю, что подобные статьи должны быть больше сконцентрированы на технических аспектах, это не соревнование.
Насколько я помню, плагин table в Grafana загружает все строки и только потом делает по ним пагинацию. Т.е. это пагинация на стороне фронт-энда. Если у вас будет значимое кол-во логов в базе — таблица может «подвесить» бразуер.
Визуализировать в Grafana можно.
На графиках удобно отслеживать интенсивность получения логов от приложений.
А вот табличная форма отображения требует доработок, т.к. встроеный плагин `table` расчитан на небольшие обьемы данных. Поэтому мы используем свой плагин таблиц, который умеет в пагинацию(отправку запросов в КХ с LIMIT N, M), кеширование ответов, визуализацию JSON в виде раскрывающегося дерева.
Думаю, стоит упомянуть так же anomaly detection. Штука весьма полезная и часто может подсказать вам о проблеме. В качестве примера можно привести алерт, который будет сравнивать частоту чтений из postgres. Если частота чтений в течении 5 минут меньше на 60% чем усредненное за последний час — это явный признак того, что с базой что-то случилось и ей пора уделить внимание.
Статью о Prometheus без упоминания об интеграции с Grafana и правда тяжело найти, но эта статья как раз из таких. Я много читал о Grafana, но до сих пор не возникало надобности в её использовании — все задачи отлично решались с помощью консолей.
Но при каких условиях S3 будет быстрее для запросов на чтение по сравнению с local storage?
Вы можете сказать сколько в среднем байт на точку данных требуется в вашей инсталляции? Я думаю, так будет проще рассуждать про сжатие.
Версии VM и Mimir были актуальными на момент бенчмарка. Вы тестировали оба решения или выбор был сделан только на основе статей и документации?
В статье достаточно много времени уделяется object storage. Но я не понимаю как использование S3 может в положительном ключе влиять на производительность по сравнению с более быстрыми и доступными локальными дисками?
Вы имеете в виду 3.5TB были сжаты в 3TB? Если это так, то в VM можете ожидать 1TB согласно цифрам из бенчмарка.
Валидное замечание. Время бенчмарка, к сожалению, ограничено его стоимостью.
Аналогично работает слияние и рекомпрессия данных в VictoriaMetrics. Данные могут сжиматься вплоть до 1 месяца.
Рекомендую читателям ознакомится и с ответом: https://valyala.medium.com/evaluating-performance-and-correctness-victoriametrics-response-e27315627e87
Можете подробнее рассказать как именно это влияет на вас?
Не скажу, что это выглядит «жалко», скорее «агрессивно». Все-таки это статья о сравнении двух подходов. Но считаю правильным приводит такие ссылки на issue и надеюсь автор это сделает. Во всяком случае, другие его статьи всегда аргументированны и подкреплены фактами — medium.com/@valyala
Ну насколько я знаю, у thanos все-таки есть проблемы с шардированием, как ни странно, индекса. Посмотрите, например, на статы gitlab — gitlab.com/gitlab-com/gl-infra/infrastructure/issues/8685#note_261760187. Здесь индекс для «db» занимает 2TB и, как я понимаю, thanos-store потребует именно такой обьем ОЗУ на машине чтобы запуститься. Поправьте, если я ошибаюсь.
Даунсемлпинг не такая простая вещь, чтобы ее просто «включить». Для читателей предлагаю ознакомиться с github.com/thanos-io/thanos/issues/813.
Если мы говорим о даунсемплинге счетчиков (метрик, которые только увеличиваются), то сокращения разрешения до 1ч еще может быть валидным. Но представьте что произойдет с информативностью метрики использованию CPU, если сохраниться только одна точка в 1ч — она просто станет бессмысленной. К примеру, у gitlab только 6% метрик даунсемплированы. Я признаю, что даунсемплинг это хорошая вещь, но только нужно четко понимать как ее использовать.
Это действительно так! Но нужно уточнить, что при росте кол-ва прометеусов в инфраструктуре качество работы такого подхода будет сильно ухудшаться. Например, если у вас около 100 прометеусов, то для обработки запроса нужно будет ждать ответа от самого медленного из них + возможные сетевые проблемы. В таком случае, мониторинг может перестать быть оперативным. Но для маленьких сетапов это будет работать.
Валидное замечание, на мой взгляд. Это определнно нужно учитывать!
Я бы тоже не принимал в расчет downsampling, т.к. он не помогает уменьшить размер данных на диске — thanos.io/components/compact.md/#downsampling-resolution-and-retention. Хорошее сжатие же помогает не только сэкономить место, но и позволяет многократно увеличить производительность системы, т.к. чем меньше данные занимают места, тем меньше времени система проведет считывая их с диска.
Я в курсе данной статьи. Для интересующихся темой очень рекомендую прочесть и ответ на нее — medium.com/@valyala/evaluating-performance-and-correctness-victoriametrics-response-e27315627e87. Здесь очень важно услышать обе стороны, а еще лучше — проверить и посмотреть все самому.
К сожалению, автор приведенной вами статьи не приводит исходный код бенчмарка, на основе которого он получил результаты. Бенчмарк же взятый из исходников прометеуса показывает, что VM быстрее — github.com/VictoriaMetrics/VictoriaMetrics/commit/b6f22a62cb385db5eb149789c42aaddd246a6750
Хм, я не услышал ничего про «потерей данных при rolling-reboot» в том докладе. Пожалуйста уточните, что именно имеется в виду или сбросьте линк на ту часть доклада, где об этом говориться.
Решардинга действительно нет, но я и не считаю, что он настолько важен для VM. Пример КХ показывает, что система может быть крайне жизнеспособной и производительной и без этой фичи.
Тут согласен! Считаю, что подобные статьи должны быть больше сконцентрированы на технических аспектах, это не соревнование.
На графиках удобно отслеживать интенсивность получения логов от приложений.
А вот табличная форма отображения требует доработок, т.к. встроеный плагин `table` расчитан на небольшие обьемы данных. Поэтому мы используем свой плагин таблиц, который умеет в пагинацию(отправку запросов в КХ с LIMIT N, M), кеширование ответов, визуализацию JSON в виде раскрывающегося дерева.
clickhouse-datasource
dashboards
Но Вы правы, для Prometheus понадобится и сервер и агент (экспортер). Хотя и в Вашем случае понадобиться telegraf и influxdb