Советую попробовать VictoriaMetrics. Она потребляет до 10 раз меньше памяти по сравнению с InfluxDB при работе с большим количеством активных рядов - см. соответствующий бенчмарк. Она поддерживает намного более вменяемый язык запросов для временных рядов по сравнению с InfluxQL и Flux - он называется MetricsQL, и является обратно-совместимым с PromQL - языком запросов в Prometheus. Также VictoriaMetrics не использует экстраполяцию при подсчете increase() и rate(), в отличие от Prometheus. Это значит, что результаты вычислений будут всегда точными. См. соответствующую статью.
Когда выходит из строя одна из storage node и кластер сильно утилизирован, то он какое-то время может не справляться с нагрузкой, потому что нужно зарегистрировать временные ряды на других storage nodes. Такое бывает, мы с этим работаем. Надеюсь, что все в будущем будет хорошо.
Эта проблема бывает только при условии, если в кластере недостаточно свободных ресурсов для быстрой регистрации новых временных рядов, "переехавших" с вышедшей из строя storage node на оставшиеся в живых storage nodes. Поэтому, чтобы избежать этой проблемы, нужно оставить в кластере достаточно свободных ресурсов (CPU, RAM). См. https://docs.victoriametrics.com/Cluster-VictoriaMetrics.html#capacity-planning
Кстати, я сейчас храню относительно много (~2млн в минуту, всего в истории триллион или около того) Graphite метрик напрямую в Кликхаусе.
2 миллиона метрик в минуту — это 33 тысячи метрик в секунду. Single-node VictoriaMetrics должна переварить такую нагрузку на самом слабом компе с одним ядром CPU. Single-node VictoriaMetrics успешно используют для production нагрузок по записи в более миллион метрик в секунду — см. https://victoriametrics.github.io/CaseStudies.html, в базе при этом хранится более 10 триллионов точек.
Будут ли какие-либо преимущества от перехода на VM в этом случае?
Данные, полученные по Graphite протоколу, можно запрашивать с помощью стандартного датасорса для Prometheus в Grafana — см. https://victoriametrics.github.io/#grafana-setup. При этом в одном запросе можно использовать данные, полученные по разным протоколам — например, по Graphite и Prometheus remote_write.
Может быть, уменьшится потребление ресурсов по сравнению с ClickHouse.
Ну, как видно система довольно фичастая и скейлится почти бесконечно, так что, как мне кажется, это оправданно. Но, согласен, конфиг у него огромен.
Количество фич и масштабирование не должно усложнять настройку и сопровождение сервиса. Например, у VictoriaMetrics тоже много разных фич, и она отлично масштабируется как вертикально (при переходе на более мощное железо), так и горизонтально — есть production инсталляции кластерной версии VictoriaMetrics с сотней vmstorage инстансов. При этом VM намного проще в настройке и сопровождении по сравнению с Cortex.
Строго говоря никто не мешает запустить один инстанс Cortex и всё будет работать безо всяких внешних зависимостей.
Да, только, насколько я помню, single-node Cortex не предназначен для использования в production, в отличие от VictoriaMetrics.
Тоже немного странно, с репликацией Ingester ничего не потеряется даже если один из них сдохнет полностью невосстановимо. При просто перезагрузке он накатит WAL и поедет дальше.
Раз уж пошел диалог с разработчиком — расскажите, а чем вообще вызвано такое архитектурное решение? Зачем искусственно ограничивать размер поиска?
Параметр -search.maxUniqueTimeseries нужен для того, чтобы предотвратить повышенное потребление ресурсов либо даже падение с out of memory ошибкой, если кто-то решит отправить аналог select * from table в VictoriaMetrics — {__name__!=""}. Большинство пользователей никогда не узнают про существование этого параметра, т.к. значение по умолчанию покрывает основные области применения VictoriaMetrics. Остальной небольшой части пользователей обычно хватает пары минут, чтобы настроить оптимальное для них значение -search.maxUniqueTimeseries после того, как они обнаружат соответствующее сообщение об ошибке в логах.
Спасибо за интересную статью! Видно, что Cortex не очень прост в установке, раз на это выделена половина статьи :)
Вроде идея хорошая, автор взял Кликхаус MergeTree за основу, но выглядит как изобретение велосипеда немного.
Можете более развернуто рассказать, почему вы считаете, что VictoriaMetrics выглядит как изобретение велосипеда?
Плюс, он пытается уместить в одном продукте Graphite/Prometheus/InfluxDB/OpenTSDB и еще кучу всего. Учитывая что модель данных у тех же Graphite и Prometheus несколько разная — мне кажется что это не очень хорошая идея.
Если VictoriaMetrics поддерживает загрузку данных по разным протоколам, то это не значит, что нужно использовать одновременно все эти протоколы. Если вы собираете метрики только с помощью Prometheus, то просто записывайте их в VictoriaMetrics по remote_write протоколу таким же образом, как делаете это при записи метрик в Cortex. Кстати, Prometheus позволяет записывать метрики одновременно в несколько удаленных хранилищ. Поэтому можете попробовать VictoriaMetrics параллельно с Cortex на одних и тех же данных, чтобы затем можно было сравнить их по таким параметрам, как:
Удобство разворачивания, настройки и сопровождения.
Потребление ресурсов (CPU, RAM, disk IO, disk space).
Расходы на инфраструктуру (не забудьте сюда включить стоимость API операций для S3).
VM плохо справляется с объемными запросами. Например, мы собираем с помощью postgresql_exporter данные из pg_stat_activity по кверям, и агрегирующие запросы нормально отрабатывают в прометее, но ломаются в VM с cannot find tag filter matching less than 300001 time series; either increase -search.maxUniqueTimeseries or use more specific tag filters
Попробуйте запустить вм с опцией командной строки -search.maxUniqueTimeseries=1000000, как указно в сообщении об ошибке.
У нас (не исключаю, что дело в кривизне рук, но это не точно) VM плохо переживала рестарты (после обновления например) — приходилось сбрасывать кэши и приседать по-всякому, чтобы она начала отдавать нормально метрики;
Странно — за последний год не слышал от пользователей нареканий по поводу проблем с рестартами в вм. Какая версия вм у вас? Рекомендуется периодически обновляться до последней, т.к. там могут быть исправлены всякие баги.
Насчет рестартов — вм может спокойно пережить любые рестарты без порчи данных, в т.ч. kill -9, hardware reset и "на хосте внезапно пропало питание". В худшем случае могут быть потеряны данные, добавленные в вм за последние несколько секунд. Прометеус же обычно теряет до двух часов последних данных либо не может стартануть и падает с OOM после некорректного завершения работы.
Ну и разница в языках запросов иногда стреляет в ногу, несколько раз уже разработчики приходили с вопросами «почему у меня об VM борда в графане нормально работает, а об прометей нет», приходится объяснять.
Различия между MetricsQL и PromQL описаны вот тут.
Какая СУБД импользуется для хранения телеметрии, собранной с датчиков? Смотрели в сторону VictoriaMetrics? Она позволяет очень эффективно хранить и обрабатывать большие объемы телеметрии (десятки и сотни триллионов показаний с сотен миллионов датчиков).
Некоторые проблемы могут возникнуть при недостаточном понимании базовых принципов работы ClickHouse. Эти принципы достаточно просты в понимании. Поэтому в большинстве случаев проблем с эксплуатацией ClickHouse не должно возникнуть. Например, мы в свое время удачно переключились с postgresql на ClickHouse для хранения и анализа статистики по крупной рекламной сети с 200 миллиардов просмотров в сутки. В результате удалось сократить на порядок расходы на хранение и анализ этих данных. См. подробности в https://medium.com/faun/victoriametrics-creating-the-best-remote-storage-for-prometheus-5d92d66787ac
Подтверждаю, что ClickHouse — крутая аналитическая БД, которая отлично масштабируется как вертикально (переезд на более мощное железо), так и горизонтально (добавление нод в кластер). Конечно, при ее использовании могут возникать некоторые проблемы. Особенно, если не до конца понимать базовых принципов работы этой БД и неправильно спроектировать схему таблиц для хранения данных и отправлять в нее "кривые" запросы, потребляющие все доступные ресурсы (память, disk IO, CPU) в течение длительного времени.
Благодаря ClickHouse появилась такая time series БД, как VictoriaMetrics. Она использует базовые идеи из ClickHouse для достижения максимальной эффективности и производительности — см. подробности в этой статье.
Так было обнаружено, что блоки записи в WAL очень плотно сгруппированы, размер большинства лежал в диапазоне 2200-2400 байт
Не означает ли это повышенный износ SSD (aka wear leveling), где размер блока, который может быть атомарно записан (aka erase block size), обычно находится в диапазоне от 512КБ до нескольких МБ? Т.е. на каждую 2КБ запись SSD приходится перезаписывать 512КБ данных?
Продублирую ссылку на всю историю багов из прошлого комментария, так как она похоже осталась незамеченной.
Активная разработка VictoriaMetrics ведется около года, примерно с мая-июня 2019, а зарегистрированных issue с лейблом «bug» больше 100. При этом продукт ничего нового не реализует, просто копирует и пересматривается подход в уже существующем Prometheus, а так же некие слои интеграции с другими TSDB.
Вот именно эта статистика пока и не очень двигает на уверенность что продукт «готов».
В целом согласен с этими пояснениями. Есть несколько замечаний:
Количество закрытых багов за год не говорит о качестве продукта. Оно может говорить только о нарастающей популярности продукта — люди находят баги в corner cases, а также о том, что VictoriaMetrics разрабатывается "в открытую" без попыток скрыть баги.
Первое что смущает именно архитектурно — это размазывание мониторинга по множеству сервисов. По мне, так мониторинг должен быть максимально надежным. А проще всего обеспечивать надежную работу сервиса(Prometheus) когда минимум компонентов.
У VictoriaMetrics есть single-node версия и кластерная версия. Single-node версия запускается из одного бинарника. Она включает в себя функциональность всех компонентов кластерной версии — vminsert, vmselect и vmstorage. Также она включает в себя функциональность vmagent по сбору Prometheus-compatible метрик (т.е. ей можно передать конфиг прометеуса в параметре -promscrape.config, чтобы заменить функциональность прометеуса для сбора метрик — см. эту документацию ). В будущем планируется интегрировать туда фукнциональность vmalert.
Если пройтись именно по issue, то особенно печалят:
Data lost when one of HA prometheus shutdown
VM count differs from prometheus
Если внимательно прочесть переписку по этим issues, то можно заметить, что там описываются специфические случаи использования VictoriaMetrics, которые решаются путем перезапуска VictoriaMetrics с правильным набором аргументов командной строки.
И подобных багов достаточно много
Хотелось бы увидеть ссылки на баги, чтобы не быть голословным.
Анализируя все что описал, желание использовать VictoriaMetrics не пропадает, но как и с MS продуктами, вышел релиз, дождись SP1 и можно использовать, я бы подождал следующего major-релиза.
Это не совсем правильная стратегия, т.к. в major-релизах обычно добавляется какая-нибудь новая функциональность, которая может что-нибудь поломать. Поэтому правильнее обновляться при выходе minor-релизов, т.к. в них обычно исправляются баги и вносятся мелкие улучшения, которые вряд ли что-то могут поломать.
Для этого критерия я бы выбрал PostgreSQL с расширением timescaledb. Во первых — потому что я специализируюсь по СУБД PostgreSQL, во вторых — это действительно SQL, в третьих — мне вполне достаточно того уровня сжатия который может предоставить timescaledb для секций.
TimescaleDB хороша в двух случаях:
когда нужно делать запросы поверх временных рядов, попутно обогащая их реляционными данными из соседних таблиц;
когда нужно делать сложные запросы, которые нельзя выразить с помощью PromQL или MetricsQL.
Оба случая встречаются достаточно редко. Для остальных случаев PromQL подходит намного лучше, т.к. длина и сложность типичного PromQL запроса намного меньше по сравнению с длиной и сложностью аналогичного запроса, построенного с помощью SQL. См. пример в начале этой статьи.
Хороший доклад по Prometheus. Видно, что ему уже несколько лет, т.к. экосистема Prometheus постоянно развивается. Сейчас есть большой выбор дополнительных средств вокруг Prometheus для его масштабирования и долгосрочного хранения метрик. Например, vmagent решает проблему выбора между pull и push, проблему одновременного сбора метрик по разным протоколам (graphite, opentsdb, influx, csv), а также проблему с повышенным потреблением памяти при сборе большого количества метрик, а VictoriaMetrics — проблему с масштабированием и долговременным хранением метрик.
В докладе упомянуто про агрегацию данных на лету во время запросов, но не хватает информации о специализированном языке запросов в Prometheus — PromQL, который намного удобнее других яхыков запросов для работы с временными рядами. См., например, этот вводный пост про PromQL, чтобы иметь представление, насколько promql удобнее, чем sql, influxql или flux для типичных запросов в мониторинге.
Советую попробовать VictoriaMetrics. Она потребляет до 10 раз меньше памяти по сравнению с InfluxDB при работе с большим количеством активных рядов - см. соответствующий бенчмарк. Она поддерживает намного более вменяемый язык запросов для временных рядов по сравнению с InfluxQL и Flux - он называется MetricsQL, и является обратно-совместимым с PromQL - языком запросов в Prometheus. Также VictoriaMetrics не использует экстраполяцию при подсчете increase() и rate(), в отличие от Prometheus. Это значит, что результаты вычислений будут всегда точными. См. соответствующую статью.
Вот тут есть подробности по поводу обработки NaN в VictoriaMetrics - https://medium.com/@romanhavronenko/victoriametrics-promql-compliance-d4318203f51e
Эта проблема бывает только при условии, если в кластере недостаточно свободных ресурсов для быстрой регистрации новых временных рядов, "переехавших" с вышедшей из строя storage node на оставшиеся в живых storage nodes. Поэтому, чтобы избежать этой проблемы, нужно оставить в кластере достаточно свободных ресурсов (CPU, RAM). См. https://docs.victoriametrics.com/Cluster-VictoriaMetrics.html#capacity-planning
См. https://prometheus.io/docs/prometheus/latest/configuration/configuration/#kubernetes_sd_config
VictoriaMetrics может сама собирать метрики, как Prometheus - см. https://docs.victoriametrics.com/#how-to-scrape-prometheus-exporters-such-as-node-exporter
А не пробовали использовать VictoriaMetrics вместо Prometheus? Туда можно отправлять данные в разных форматах в т.ч. и в формате Prometheus text exposition. И там есть удобная OHLC функция.
2 миллиона метрик в минуту — это 33 тысячи метрик в секунду. Single-node VictoriaMetrics должна переварить такую нагрузку на самом слабом компе с одним ядром CPU. Single-node VictoriaMetrics успешно используют для production нагрузок по записи в более миллион метрик в секунду — см. https://victoriametrics.github.io/CaseStudies.html, в базе при этом хранится более 10 триллионов точек.
Скорее всего, будут следующие преимущества:
Количество фич и масштабирование не должно усложнять настройку и сопровождение сервиса. Например, у VictoriaMetrics тоже много разных фич, и она отлично масштабируется как вертикально (при переходе на более мощное железо), так и горизонтально — есть production инсталляции кластерной версии VictoriaMetrics с сотней vmstorage инстансов. При этом VM намного проще в настройке и сопровождении по сравнению с Cortex.
Да, только, насколько я помню, single-node Cortex не предназначен для использования в production, в отличие от VictoriaMetrics.
Если Cortex использует реализацию WAL из Prometheus, то это может приводить к различным проблемам вроде OOM crash loop, data loss и too long data recovery. См. https://valyala.medium.com/wal-usage-looks-broken-in-modern-time-series-databases-b62a627ab704
Согласен — Cortex не стоит на месте и постоянно развивается )
Параметр
-search.maxUniqueTimeseriesнужен для того, чтобы предотвратить повышенное потребление ресурсов либо даже падение с out of memory ошибкой, если кто-то решит отправить аналогselect * from tableв VictoriaMetrics —{__name__!=""}. Большинство пользователей никогда не узнают про существование этого параметра, т.к. значение по умолчанию покрывает основные области применения VictoriaMetrics. Остальной небольшой части пользователей обычно хватает пары минут, чтобы настроить оптимальное для них значение-search.maxUniqueTimeseriesпосле того, как они обнаружат соответствующее сообщение об ошибке в логах.Спасибо за интересную статью! Видно, что Cortex не очень прост в установке, раз на это выделена половина статьи :)
Можете более развернуто рассказать, почему вы считаете, что VictoriaMetrics выглядит как изобретение велосипеда?
Если VictoriaMetrics поддерживает загрузку данных по разным протоколам, то это не значит, что нужно использовать одновременно все эти протоколы. Если вы собираете метрики только с помощью Prometheus, то просто записывайте их в VictoriaMetrics по remote_write протоколу таким же образом, как делаете это при записи метрик в Cortex. Кстати, Prometheus позволяет записывать метрики одновременно в несколько удаленных хранилищ. Поэтому можете попробовать VictoriaMetrics параллельно с Cortex на одних и тех же данных, чтобы затем можно было сравнить их по таким параметрам, как:
Еще можете почитать https://victoriametrics.github.io/FAQ.html#what-is-the-difference-between-victoriametrics-and-cortex
Попробуйте запустить вм с опцией командной строки
-search.maxUniqueTimeseries=1000000, как указно в сообщении об ошибке.Странно — за последний год не слышал от пользователей нареканий по поводу проблем с рестартами в вм. Какая версия вм у вас? Рекомендуется периодически обновляться до последней, т.к. там могут быть исправлены всякие баги.
Насчет рестартов — вм может спокойно пережить любые рестарты без порчи данных, в т.ч.
kill -9, hardware reset и "на хосте внезапно пропало питание". В худшем случае могут быть потеряны данные, добавленные в вм за последние несколько секунд. Прометеус же обычно теряет до двух часов последних данных либо не может стартануть и падает с OOM после некорректного завершения работы.Различия между MetricsQL и PromQL описаны вот тут.
Также метрики можно пушить напрямую в VictoriaMetrics или в vmagent.
Какая СУБД импользуется для хранения телеметрии, собранной с датчиков? Смотрели в сторону VictoriaMetrics? Она позволяет очень эффективно хранить и обрабатывать большие объемы телеметрии (десятки и сотни триллионов показаний с сотен миллионов датчиков).
А почему нет ни слова о VictoriaMetrics? Она проще в настройке и сопровождении по сравнению с Thanos и Cortex, а также требует намного меньше ресурсов (cpu, ram, disk space) по сравнению с Thanos и Cortex. См. https://github.com/VictoriaMetrics/VictoriaMetrics/wiki/CaseStudies
Некоторые проблемы могут возникнуть при недостаточном понимании базовых принципов работы ClickHouse. Эти принципы достаточно просты в понимании. Поэтому в большинстве случаев проблем с эксплуатацией ClickHouse не должно возникнуть. Например, мы в свое время удачно переключились с postgresql на ClickHouse для хранения и анализа статистики по крупной рекламной сети с 200 миллиардов просмотров в сутки. В результате удалось сократить на порядок расходы на хранение и анализ этих данных. См. подробности в https://medium.com/faun/victoriametrics-creating-the-best-remote-storage-for-prometheus-5d92d66787ac
Подтверждаю, что ClickHouse — крутая аналитическая БД, которая отлично масштабируется как вертикально (переезд на более мощное железо), так и горизонтально (добавление нод в кластер). Конечно, при ее использовании могут возникать некоторые проблемы. Особенно, если не до конца понимать базовых принципов работы этой БД и неправильно спроектировать схему таблиц для хранения данных и отправлять в нее "кривые" запросы, потребляющие все доступные ресурсы (память, disk IO, CPU) в течение длительного времени.
Благодаря ClickHouse появилась такая time series БД, как VictoriaMetrics. Она использует базовые идеи из ClickHouse для достижения максимальной эффективности и производительности — см. подробности в этой статье.
Не означает ли это повышенный износ SSD (aka wear leveling), где размер блока, который может быть атомарно записан (aka erase block size), обычно находится в диапазоне от 512КБ до нескольких МБ? Т.е. на каждую 2КБ запись SSD приходится перезаписывать 512КБ данных?
В целом согласен с этими пояснениями. Есть несколько замечаний:
VictoriaMetrics активно разрабатывается с января 2018 года. Первый публичный анонс был осенью 2018 года. В мае 2019 года были открыты исходники.
Количество закрытых багов за год не говорит о качестве продукта. Оно может говорить только о нарастающей популярности продукта — люди находят баги в corner cases, а также о том, что VictoriaMetrics разрабатывается "в открытую" без попыток скрыть баги.
Если бы количество багов в проекте указывало на нестабильность продукта, то я сомневаюсь, что вы бы пользовались Consul'ом с более 3000 закрытых багов и более 500 открытых багов или Prometheus'ом с 3000 закрытых багов и более 250 открытых багов.
По поводу стабильности продукта советую ознакомиться с отзывами пользователей VictoriaMetrics.
У VictoriaMetrics есть single-node версия и кластерная версия. Single-node версия запускается из одного бинарника. Она включает в себя функциональность всех компонентов кластерной версии — vminsert, vmselect и vmstorage. Также она включает в себя функциональность vmagent по сбору Prometheus-compatible метрик (т.е. ей можно передать конфиг прометеуса в параметре
-promscrape.config, чтобы заменить функциональность прометеуса для сбора метрик — см. эту документацию ). В будущем планируется интегрировать туда фукнциональность vmalert.Если внимательно прочесть переписку по этим issues, то можно заметить, что там описываются специфические случаи использования VictoriaMetrics, которые решаются путем перезапуска VictoriaMetrics с правильным набором аргументов командной строки.
Хотелось бы увидеть ссылки на баги, чтобы не быть голословным.
Это не совсем правильная стратегия, т.к. в major-релизах обычно добавляется какая-нибудь новая функциональность, которая может что-нибудь поломать. Поэтому правильнее обновляться при выходе minor-релизов, т.к. в них обычно исправляются баги и вносятся мелкие улучшения, которые вряд ли что-то могут поломать.
TimescaleDB хороша в двух случаях:
Оба случая встречаются достаточно редко. Для остальных случаев PromQL подходит намного лучше, т.к. длина и сложность типичного PromQL запроса намного меньше по сравнению с длиной и сложностью аналогичного запроса, построенного с помощью SQL. См. пример в начале этой статьи.
Хороший доклад по Prometheus. Видно, что ему уже несколько лет, т.к. экосистема Prometheus постоянно развивается. Сейчас есть большой выбор дополнительных средств вокруг Prometheus для его масштабирования и долгосрочного хранения метрик. Например, vmagent решает проблему выбора между pull и push, проблему одновременного сбора метрик по разным протоколам (graphite, opentsdb, influx, csv), а также проблему с повышенным потреблением памяти при сборе большого количества метрик, а VictoriaMetrics — проблему с масштабированием и долговременным хранением метрик.
В докладе упомянуто про агрегацию данных на лету во время запросов, но не хватает информации о специализированном языке запросов в Prometheus — PromQL, который намного удобнее других яхыков запросов для работы с временными рядами. См., например, этот вводный пост про PromQL, чтобы иметь представление, насколько promql удобнее, чем sql, influxql или flux для типичных запросов в мониторинге.