Есть несколько причин, по которым мы не выбрали VictoriaMetrics.
Во-первых, при выборе решения для мониторинга мы руководствовались ключевым требованием — унификация стека как для in-cluster мониторинга, так и для централизованного хранения метрик с множества кластеров. Да, у VictoriaMetrics есть кластерный режим, который позволяет это реализовать, но он не поддерживает решардирование данных — а это для нас критически важно.
Во-вторых, степень распространённости решения. VictoriaMetrics используется значительно меньшим числом компаний по сравнению с Prometheus. Это означает меньшую зрелость сообщества, меньшее количество готовых решений и потенциально более высокие риски при масштабировании или развитии системы.
В-третьих, VictoriaMetrics использует собственный формат хранения данных. Переход на него возможен, но обратная совместимость отсутствует. Мы рассматриваем это как существенный недостаток. При проектировании системы мы стремились обеспечить максимальную совместимость с Prometheus, а в тех случаях, где это невозможно, создать инструменты, позволяющие безболезненно переключаться между решениями в обе стороны.
Функционал миграций имеющихся баз прометея в хранилище prom++ не планируете?
Это уже есть. В Prometheus и Prom++ одинаковый формат блоков, есть отличия только в WAL. Для wal уже есть конвертер, в обе стороны. Подробней написано в github
Downsampling
Нет, на данный момент не планируется.
Хранение в s3?
Нет, а зачем? Расскажите свой кейс, возможно сможем что-то посоветовать.
Продукт будет монолит или побьете на сервисы как Thanos (и все прочие мимиры/виктории/кортексы)?
Монолит, так же как и Prometheus. При этом, есть в планах доработать еще и mimir (аналог cortex от grafana).
Будет ли у продукта будущее отдельно от платформы deckhouse? А отдельно от k8s?
Однозначно да. Мы выложили его под лицензией Apache2. Его можно запускать как в виде бинарных файлов, так и с помощью Prometheus Operator или просто в Docker контейнере.
Любой, кто пытался этим заниматься может подтвердить, что это трудоёмко, да и выигрыш временный. Через время придут новые источники с новым набором кривых лейблов id/guid и всё начнётся заново.
Да, вы правы, это непростая задача, но при систематическом подходе она не требует много времени. Мы периодически выполняем такие работы в рамках наших продуктов, включая Deckhouse Kubernetes Platform, и мы точно знаем, о чём говорим :)
И если нет - выкидывает всё лишнее.
Здесь всё не так однозначно: лейблы зачастую не нужны для дашбордов и алертов, но при расследовании инцидентов они оказываются крайне полезными. Я бы даже сказал, что такой подход больше вредит, чем помогает.
Объяснение churn - не сказать, чтобы сильно понятное.
Недавно придумал удачный пример из реальной жизни, который объясняет суть. Представьте, что вы производите чашки и упаковываете их партиями по 100 штук. В одну коробку помещается ровно 100 чашек, но все они должны быть одной модели. При высоком churn вы сделали 100 разных моделей чашек, и для каждой понадобилась отдельная коробка — в итоге у вас 100 коробок, и для доставки потребуется целая "Газель". А при churn, равном 0, вы выпустили 100 одинаковых чашек, и все они поместились в одну коробку — для доставки достаточно будет даже съездить на метро.
Exemplar - это возможность связать метрики, логи и трейсы. Например, это можно сделать на основе trace ID. Пример: у вас есть метрика (Prometheus) количества HTTP-запросов. И к каждому запросу, у которого код ответа 500, вы хотите прикрепить exemplar. За период между скрейпами у вас было 3 запроса с кодом 500. Тогда метрики будут иметь примерно следующий вид:
# HELP http_requests_total Total number of HTTP requests
# TYPE http_requests_total counter
http_requests_total{method="GET", code="500"} 3 # {trace_id="abc123"} 1620300000000
http_requests_total{method="GET", code="500"} 3 # {trace_id="def456"} 1620300005000
http_requests_total{method="GET", code="500"} 3 # {trace_id="ghi789"} 1620300010000
В этом случае при просмотре метрик, например, в Grafana и при правильной настройке всех необходимых data sources, вы сможете сразу из метрик просмотреть соответствующий спан трейсов и логи.
Также важно понимать, что возможности по хранению exemplars ограничены, и неправильно прикреплять их к каждому событию. При этом, логика добавления exemplars остаётся на ответственности разработчика (того, кто генерирует метрики).
Но при каких условиях S3 будет быстрее для запросов на чтение по сравнению с local storage?
Если мы сравниваем одну и туже систему, то ответ будет – никогда. Если сравниваем разные системы, то зависит от систем. Мое замечание заключалось в том, что если сравниваешь производительность двух систем и одна хранит данные на локальном SSD, а вторая хранит данные в S3 с letensy 1 сек, то вторая будет заведомо в проигрышной позиции.
Вы можете сказать сколько в среднем байт на точку данных требуется в вашей инсталляции? Я думаю, так будет проще рассуждать про сжатие.
У нас нет такой информации, мы никогда не замеряли это. И это не супер просто посчитать, так как нет данных по количеству точек в mimir.
В общем, что бы ответить на все эти вопросы, мы думаем сделать обширный тест, продолжительностью несколько недель, с замерами на разных этапах и красивыми картинками, и конечно же, опубликовать результаты.
Версии VM и Mimir были актуальными на момент бенчмарка. Вы тестировали оба решения или выбор был сделан только на основе статей и документации?
Да, вы правы, я упустил дату статьи.
На тот момент, когда мы принимали решение, Mimir еще не существовал, и мы выбирали между Victoria Metrics и Cortex. В процессе мы изучили документацию, провели различные тесты, включая нагрузочные, и изучили кодовую базу основных претендентов. При сопоставимых результатах по скорости ответа и записи, и потреблению ресурсов для нас решающим фактором стало отсутствие механизма решардирования данных в Victoria Metrics.
В статье достаточно много времени уделяется object storage. Но я не понимаю как использование S3 может в положительном ключе влиять на производительность по сравнению с более быстрыми и доступными локальными дисками?
Недостаточно, там не указаны значения для задержки для запросв и размера канала, хотя и говорится об использовании Google Cloud Storage. В случае с Mimir – S3 это ключевой компонент, аналогично дискам victoria metrics. Согласись, что есть разница в производительности при тестировании VM на SSD или HDD?
Вы имеете в виду 3.5TB были сжаты в 3TB? Если это так, то в VM можете ожидать 1TB согласно цифрам из бенчмарка.
Нет, смотрите, для обеспечения высокой доступности данных необходимо их хранить в нескольких копиях. В случае с VM данные записываются на несколько vmStorage, а в случае с Mimir - на несколько ingester. Важный момент заключается в том, что данные, записанные в несколько vmStorage, остаются там навсегда, тогда как ingester выгружает их в S3, после чего происходит дедубликация данных (три блока сливаются в один). Чтобы обеспечить высокую доступность данных, необходима репликация на уровне хранения в S3. Поскольку мы используем собственный S3, вопрос репликации остается актуальным для нас. В итоге, для хранения 3 ТБ метрик в S3 мы используем 3,5 ТБ дискового пространства с учетом трехкратной репликации.
Аналогично работает слияние и рекомпрессия данных в VictoriaMetrics. Данные могут сжиматься вплоть до 1 месяца.
Да, но есть нюансы. Как я писал выше, данные в VM хранятся на локальных дисках, и там архитектурно невозможен горизонтальный мердж, то есть объединение нескольких одинаковых блоков в один. Возможен только вертикальный мердж данных по времени.
Привет! Это отличная статья, и ребята проделали большую работу. Но всегда есть нюансы. Мы еще не проводили детальный анализ статьи, но есть пара моментов, которые делают ее не так однозначной:
Во-первых, они используют версию 2.2.0, хотя актуальная версия - 2.8.0. Версия 2.4 внесла существенные изменения, которые, по нашим замерам, сокращают потребление ресурсов на 30-40%.
В статье отсутствует информация об использовании S3, который является ключевым компонентом и сильно влияет на производительность.
В Mimir данные хранятся на дисках vmStorage, а в Mimir используется S3. Например, при использовании replication factor 3, в Mimir для хранения 3,5 Тб метрик требуется всего 3 Тб дискового пространства. Это основано на реальных данных нашего проекта, где мы используем Ceph S3 с replication factor 3.
В статье проводится бенчмарк в течение одних суток, но вряд ли Mimir и Victoriametrics используются для хранения данных такого маленького периода. Кроме того, учитывая многоуровневый merge данных в Mimir, реальное потребление места на данных за день и месяц может значительно отличаться.
Ох, на самом деле, сложный вопрос. Если уже заговорили о VM, то это действительно хорошее решение. Однако не стоит забывать о нюансах, которые важно понимать. Далее, стоит оценить, насколько существенны для вас эти особенности и сделать выбор.
Во-вторых, VM применяет собственный формат хранения данных, и на данный момент существует возможность перехода на VM, но обратной миграции нет.
В-третьих, VM формально шардирует данные, но фактически не поддерживает механизм решардирования. Другими словами, если у вас есть кластер из 3 vm-storage, вы не можете отключить один vm-storage и на его месте запустить новый, более мощный (а затем проделать то же самое с остальными), на новые vm-storage будут записываться только новые данные, а старые не перенесутся.
В-четвертых, в Mimir долгосрочное хранилище отделено (это S3), что делает систему более гибкой.
С учетом этих нюансов, мы сделали выбор в пользу Mimir.
Привет. Я бы добавил в этот список еще Prom++. Который в разы эффективнее чем Prometheus и VM по ресурсам.
Не совсем понял, почему:
Зачем прикладывать ca и при этом скипать валидацию сертификата?
А еще, не понятно, что за токен используется и кто и как его проверяет.
Да, а еще и opensource:)
Для Prometheus есть Deckhouse Prom++ не просто форк, а еще и неплохо оптимизированный по памяти (ест меньше vm) :)
Спасибо!)
Привет. Да, такие планы есть. Думаю, в следующем релизе CSE успеем добавить.
Есть несколько причин, по которым мы не выбрали VictoriaMetrics.
Во-первых, при выборе решения для мониторинга мы руководствовались ключевым требованием — унификация стека как для in-cluster мониторинга, так и для централизованного хранения метрик с множества кластеров. Да, у VictoriaMetrics есть кластерный режим, который позволяет это реализовать, но он не поддерживает решардирование данных — а это для нас критически важно.
Во-вторых, степень распространённости решения. VictoriaMetrics используется значительно меньшим числом компаний по сравнению с Prometheus. Это означает меньшую зрелость сообщества, меньшее количество готовых решений и потенциально более высокие риски при масштабировании или развитии системы.
В-третьих, VictoriaMetrics использует собственный формат хранения данных. Переход на него возможен, но обратная совместимость отсутствует. Мы рассматриваем это как существенный недостаток. При проектировании системы мы стремились обеспечить максимальную совместимость с Prometheus, а в тех случаях, где это невозможно, создать инструменты, позволяющие безболезненно переключаться между решениями в обе стороны.
Во-первых, InfluxDB это БД, а Prometheus это система мониторинга и сравнение было бы не честным. И да, не конкурент.
Привет. А можете рассказать какие именно фишки виктории вы используете?
Да, это одна из причин.
Приключения потянули на целый доклад, скоро мы его опубликуем:)
Такая возможность уже есть. Вы можете заменить образ Prometheus на образ Deckhouse Prom++ с docker hub
Это уже есть. В Prometheus и Prom++ одинаковый формат блоков, есть отличия только в WAL. Для wal уже есть конвертер, в обе стороны. Подробней написано в github
Нет, на данный момент не планируется.
Нет, а зачем? Расскажите свой кейс, возможно сможем что-то посоветовать.
Монолит, так же как и Prometheus. При этом, есть в планах доработать еще и mimir (аналог cortex от grafana).
Однозначно да. Мы выложили его под лицензией Apache2. Его можно запускать как в виде бинарных файлов, так и с помощью Prometheus Operator или просто в Docker контейнере.
Не совсем так. В общем случае метрики за которыми приходит Prometheus, выглядит следующим образом:
Да, там есть кусочек, который выглядит как json, но это строка. Так же, там есть методанные, которые в чистом виде строки.
С другой стороны, если посмотреть в документацию Prometheus, в Exposition formats, то там единственный поддерживаемый content-type: plain/text.
Вот тут можно посмотреть: https://github.com/prometheus/docs/blob/main/content/docs/instrumenting/exposition_formats.md.
Из того, что я знаю, раньше были такие подходы, но сейчас данных не осталось даже в документации.
Да, вы правы, это непростая задача, но при систематическом подходе она не требует много времени. Мы периодически выполняем такие работы в рамках наших продуктов, включая Deckhouse Kubernetes Platform, и мы точно знаем, о чём говорим :)
Здесь всё не так однозначно: лейблы зачастую не нужны для дашбордов и алертов, но при расследовании инцидентов они оказываются крайне полезными. Я бы даже сказал, что такой подход больше вредит, чем помогает.
Недавно придумал удачный пример из реальной жизни, который объясняет суть. Представьте, что вы производите чашки и упаковываете их партиями по 100 штук. В одну коробку помещается ровно 100 чашек, но все они должны быть одной модели. При высоком churn вы сделали 100 разных моделей чашек, и для каждой понадобилась отдельная коробка — в итоге у вас 100 коробок, и для доставки потребуется целая "Газель". А при churn, равном 0, вы выпустили 100 одинаковых чашек, и все они поместились в одну коробку — для доставки достаточно будет даже съездить на метро.
Exemplar - это возможность связать метрики, логи и трейсы. Например, это можно сделать на основе trace ID. Пример: у вас есть метрика (Prometheus) количества HTTP-запросов. И к каждому запросу, у которого код ответа 500, вы хотите прикрепить exemplar. За период между скрейпами у вас было 3 запроса с кодом 500. Тогда метрики будут иметь примерно следующий вид:
В этом случае при просмотре метрик, например, в Grafana и при правильной настройке всех необходимых data sources, вы сможете сразу из метрик просмотреть соответствующий спан трейсов и логи.
Также важно понимать, что возможности по хранению exemplars ограничены, и неправильно прикреплять их к каждому событию. При этом, логика добавления exemplars остаётся на ответственности разработчика (того, кто генерирует метрики).
Еще, можете почитать, например эту статью: https://vbehar.medium.com/using-prometheus-exemplars-to-jump-from-metrics-to-traces-in-grafana-249e721d4192
Если мы сравниваем одну и туже систему, то ответ будет – никогда. Если сравниваем разные системы, то зависит от систем. Мое замечание заключалось в том, что если сравниваешь производительность двух систем и одна хранит данные на локальном SSD, а вторая хранит данные в S3 с letensy 1 сек, то вторая будет заведомо в проигрышной позиции.
У нас нет такой информации, мы никогда не замеряли это. И это не супер просто посчитать, так как нет данных по количеству точек в mimir.
В общем, что бы ответить на все эти вопросы, мы думаем сделать обширный тест, продолжительностью несколько недель, с замерами на разных этапах и красивыми картинками, и конечно же, опубликовать результаты.
Да, вы правы, я упустил дату статьи.
На тот момент, когда мы принимали решение, Mimir еще не существовал, и мы выбирали между Victoria Metrics и Cortex. В процессе мы изучили документацию, провели различные тесты, включая нагрузочные, и изучили кодовую базу основных претендентов. При сопоставимых результатах по скорости ответа и записи, и потреблению ресурсов для нас решающим фактором стало отсутствие механизма решардирования данных в Victoria Metrics.
Недостаточно, там не указаны значения для задержки для запросв и размера канала, хотя и говорится об использовании Google Cloud Storage. В случае с Mimir – S3 это ключевой компонент, аналогично дискам victoria metrics. Согласись, что есть разница в производительности при тестировании VM на SSD или HDD?
Нет, смотрите, для обеспечения высокой доступности данных необходимо их хранить в нескольких копиях. В случае с VM данные записываются на несколько vmStorage, а в случае с Mimir - на несколько ingester. Важный момент заключается в том, что данные, записанные в несколько vmStorage, остаются там навсегда, тогда как ingester выгружает их в S3, после чего происходит дедубликация данных (три блока сливаются в один). Чтобы обеспечить высокую доступность данных, необходима репликация на уровне хранения в S3. Поскольку мы используем собственный S3, вопрос репликации остается актуальным для нас. В итоге, для хранения 3 ТБ метрик в S3 мы используем 3,5 ТБ дискового пространства с учетом трехкратной репликации.
Да, но есть нюансы. Как я писал выше, данные в VM хранятся на локальных дисках, и там архитектурно невозможен горизонтальный мердж, то есть объединение нескольких одинаковых блоков в один. Возможен только вертикальный мердж данных по времени.
* п3 В Vm данные хранятся на дисках vmStorage.
Привет! Это отличная статья, и ребята проделали большую работу. Но всегда есть нюансы. Мы еще не проводили детальный анализ статьи, но есть пара моментов, которые делают ее не так однозначной:
Во-первых, они используют версию 2.2.0, хотя актуальная версия - 2.8.0. Версия 2.4 внесла существенные изменения, которые, по нашим замерам, сокращают потребление ресурсов на 30-40%.
В статье отсутствует информация об использовании S3, который является ключевым компонентом и сильно влияет на производительность.
В Mimir данные хранятся на дисках vmStorage, а в Mimir используется S3. Например, при использовании replication factor 3, в Mimir для хранения 3,5 Тб метрик требуется всего 3 Тб дискового пространства. Это основано на реальных данных нашего проекта, где мы используем Ceph S3 с replication factor 3.
В статье проводится бенчмарк в течение одних суток, но вряд ли Mimir и Victoriametrics используются для хранения данных такого маленького периода. Кроме того, учитывая многоуровневый merge данных в Mimir, реальное потребление места на данных за день и месяц может значительно отличаться.
Ох, на самом деле, сложный вопрос. Если уже заговорили о VM, то это действительно хорошее решение. Однако не стоит забывать о нюансах, которые важно понимать. Далее, стоит оценить, насколько существенны для вас эти особенности и сделать выбор.
Во-первых, VM использует упрощенную модель хранения данных. Подробнее об этом можно прочитать здесь: https://www.robustperception.io/evaluating-performance-and-correctness/.
Во-вторых, VM применяет собственный формат хранения данных, и на данный момент существует возможность перехода на VM, но обратной миграции нет.
В-третьих, VM формально шардирует данные, но фактически не поддерживает механизм решардирования. Другими словами, если у вас есть кластер из 3 vm-storage, вы не можете отключить один vm-storage и на его месте запустить новый, более мощный (а затем проделать то же самое с остальными), на новые vm-storage будут записываться только новые данные, а старые не перенесутся.
В-четвертых, в Mimir долгосрочное хранилище отделено (это S3), что делает систему более гибкой.
С учетом этих нюансов, мы сделали выбор в пользу Mimir.