Comments 8
Спасибо за пост. Смотрели ли вы Victoriametrics?
Да, глядел когда рассматривал варианты, но архитектура мне почему-то на тот момент не очень понравилась. Вроде идея хорошая, автор взял Кликхаус MergeTree за основу, но выглядит как изобретение велосипеда немного.
Плюс, он пытается уместить в одном продукте Graphite/Prometheus/InfluxDB/OpenTSDB и еще кучу всего. Учитывая что модель данных у тех же Graphite и Prometheus несколько разная — мне кажется что это не очень хорошая идея.
Спасибо за интересную статью! Видно, что 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).
- Скорость выполнения запросов.
Еще можете почитать https://victoriametrics.github.io/FAQ.html#what-is-the-difference-between-victoriametrics-and-cortex
Привет.
Можете более развернуто рассказать, почему вы считаете, что VictoriaMetrics выглядит как изобретение велосипеда?
Я, если честно, плотно ваш продукт не изучал, каюсь — пробежался поверхностно с год назад, когда выбирал решение, по гитхабу. Просто создалось такое ощущение в процессе изучения. Ну и умозрительно поддержка нескольких разных форматов, которые местами сильно разные, показалась переусложнением.
Кстати, я сейчас храню относительно много (~2млн в минуту, всего в истории триллион или около того) Graphite метрик напрямую в Кликхаусе. Будут ли какие-либо преимущества от перехода на VM в этом случае?
Попробую развернуть при случае — возможно в новых проектах пригодится.
Видно, что Cortex не очень прост в установке, раз на это выделена половина статьи :)
Ну, как видно система довольно фичастая и скейлится почти бесконечно, так что, как мне кажется, это оправданно. Но, согласен, конфиг у него огромен.
Еще можете почитать https://victoriametrics.github.io/FAQ.html#what-is-the-difference-between-victoriametrics-and-cortex
...
VictoriaMetrics provides production-ready single-node solution, which is much easier to setup and operate than Cortex cluster.
Строго говоря никто не мешает запустить один инстанс Cortex и всё будет работать безо всяких внешних зависимостей.
Cortex may lose up to 12 hours of recent data on Ingestor failure — see the corresponding docs. VictoriaMetrics may lose only a few seconds of recent data, which isn’t synced to persistent storage yet. See this article for details.
Тоже немного странно, с репликацией Ingester ничего не потеряется даже если один из них сдохнет полностью невосстановимо. При просто перезагрузке он накатит WAL и поедет дальше.
Так что может пора поправить FAQ ;)
ЗЫ:
Спасибо за fasthttp — вот его я юзаю много и плотно :)
Кстати, я сейчас храню относительно много (~2млн в минуту, всего в истории триллион или около того) Graphite метрик напрямую в Кликхаусе.
2 миллиона метрик в минуту — это 33 тысячи метрик в секунду. Single-node VictoriaMetrics должна переварить такую нагрузку на самом слабом компе с одним ядром CPU. Single-node VictoriaMetrics успешно используют для production нагрузок по записи в более миллион метрик в секунду — см. https://victoriametrics.github.io/CaseStudies.html, в базе при этом хранится более 10 триллионов точек.
Будут ли какие-либо преимущества от перехода на VM в этом случае?
Скорее всего, будут следующие преимущества:
- Упростится настройка и сопровождение — достаточно настроить single-node VM для получения метрик по протоколу Graphite — это делается с помощью одной опции при запуске VM. См. https://victoriametrics.github.io/#how-to-send-data-from-graphite-compatible-agents-such-as-statsd
- Данные, полученные по 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 и поедет дальше.
Если 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
Так что может пора поправить FAQ ;)
Согласен — Cortex не стоит на месте и постоянно развивается )
Интересный пост, спасибо. А что по недостаткам?
Остальным отвечает HTTP 202 Accepted и отправляет в /dev/null всё что они прислали
просто прелестно...
Cortex и не только: распределённый Prometheus