Как стать автором
Обновить
5
0

Software Engineer

Отправить сообщение

Согласись, что есть разница в производительности при тестировании VM на SSD или HDD?

Но при каких условиях S3 будет быстрее для запросов на чтение по сравнению с local storage?

там архитектурно невозможен горизонтальный мердж, то есть объединение нескольких одинаковых блоков в один

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

Во-первых, они используют версию 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 месяца.

Во-первых, VM использует упрощенную модель хранения данных. Подробнее об этом можно прочитать здесь: https://www.robustperception.io/evaluating-performance-and-correctness/

Рекомендую читателям ознакомится и с ответом: https://valyala.medium.com/evaluating-performance-and-correctness-victoriametrics-response-e27315627e87

Можете подробнее рассказать как именно это влияет на вас?

Большое спасибо за детальный ответ!
Можете поделиться ресурсами выделенными под сторадж и статистику его использования? Интересует использование 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.»

Я в курсе данной статьи. Для интересующихся темой очень рекомендую прочесть и ответ на нее — 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. Пример КХ показывает, что система может быть крайне жизнеспособной и производительной и без этой фичи.

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

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

Насколько я помню, плагин table в Grafana загружает все строки и только потом делает по ним пагинацию. Т.е. это пагинация на стороне фронт-энда. Если у вас будет значимое кол-во логов в базе — таблица может «подвесить» бразуер.
На каком этапе сейчас находится PromHouse? На гитхабе не заметно активности последние 3 месяца.
Визуализировать в Grafana можно.
На графиках удобно отслеживать интенсивность получения логов от приложений.
А вот табличная форма отображения требует доработок, т.к. встроеный плагин `table` расчитан на небольшие обьемы данных. Поэтому мы используем свой плагин таблиц, который умеет в пагинацию(отправку запросов в КХ с LIMIT N, M), кеширование ответов, визуализацию JSON в виде раскрывающегося дерева.
Вы можете найти что-нибудь подходящее здесь:
clickhouse-datasource
dashboards
Не указано как именно осуществлялась вставка. В документации CH указано, что оптимальным считается вставка батчами по 100к записей.
Prometheus представляет собой time-series database. Нет никакой надобности писать в influxdb — Grafana прекрасно работает с Prometheus.

Но Вы правы, для Prometheus понадобится и сервер и агент (экспортер). Хотя и в Вашем случае понадобиться telegraf и influxdb
Думаю, стоит упомянуть так же anomaly detection. Штука весьма полезная и часто может подсказать вам о проблеме. В качестве примера можно привести алерт, который будет сравнивать частоту чтений из postgres. Если частота чтений в течении 5 минут меньше на 60% чем усредненное за последний час — это явный признак того, что с базой что-то случилось и ей пора уделить внимание.
Статью о Prometheus без упоминания об интеграции с Grafana и правда тяжело найти, но эта статья как раз из таких. Я много читал о Grafana, но до сих пор не возникало надобности в её использовании — все задачи отлично решались с помощью консолей.

Информация

В рейтинге
Не участвует
Откуда
Киев, Киевская обл., Украина
Зарегистрирован
Активность