InfluxDB хорош, но лучше все-таки использовать VictoriaMetrics. Она быстрее, жрет намного меньше памяти, меньше глючит и поддерживает нормальный язык запросов — MetricsQL, обратно совместимый с PromQL, который подходит намного лучше для типичных запросов по временным рядам, чем InfluxQL и Flux. Например, попробуйте на Flux создать запрос, складывающий два fields из разных measurements. Если что, то в PromQL это выглядит как a + b.
Да, это простое и хорошее решение, которое работает в большинстве случаев. Оно может оказаться медленнее, чем использование map для удаления дублей, если размер слайса будет большим (например, миллион элементов и больше). Сортировка требует O(n*ln(n)) операций, где n — размер слайса, а хэшмэп — O(n) операций, т.е. при больших n хэшмэп будет выигрывать по скорости. Недостаток удаление дублей с помощью хэшмепа — он требует больше памяти и работает медленнее при небольшом количестве элементов в слайсе.
Расскажите, как поместить все компоненты Thanos, включая Thanos Sidecars, в один K8S кластер, если у вас много Prometheus'ов раскиданы по разным датацентрам?
У нас были похожие проблемы, они исчезли после перехода на remote write.
Лишь показывает что вы не представляете как масштабировать Thanos. Зачем тогда упоминать его? Там кстати и шардировать можно.
Расскажите подробнее, как масштабировать Thanos, и сравните сложность масштабирования Thanos с масштабированием VictoriaMetrics. Про шардирование тоже расскажите, не забывая про открытые баги, связанные с шардированием.
Вы видимо не понимаете что именно делает thanos-compact. Компакшн файлов — это лишь малая часть, основная часть — это downsampling. Создаются усреднения для ренджей 5m и 1h, где каждая точка по сути содержит 5 значений (min, max, sum, count, avg) чтобы все функции продолжали работать на усредненных данных корректно. Далее когда вы делаете query за большой диапазон времени (например за месяц, год) thanos-store использует эти посчитанные данные. Т.е. raw данные не используются, даже если они у вас есть за годы назад. И основная отличительная черта Thanos — что можно настроить retention и хранить raw только за последние 2 недели, а 1h — бесконечно, что очень дешево на S3-IA.
Представьте ситуцию когда у вас несколько регионов в AWS. Вы можете в каждом регионе иметь свой prometheus который пишет данные в локальный S3. Вы приходите из центральной графаны за мизерным обьемом тех точек графиков на которые вы смотрите (ответы на PromQL запросы), а основные гигабайты остаются лежать локально. А в случае remote-write вы бы все время передавали эти гигабайты со всех регионов, без разницы смотрит на них кто-либо или нет, и платили за траффик.
Хороший пример. Такую же схему можно реализовать и на основе VictoriaMetrics — данные в каждом регионе записываются в локальный экземпляр VictoriaMetrics, для global querying view используем Promxy поверх всех экземпляров VictoriaMetrics.
https://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."
"This shows that Prometheus is faster in all cases, by ~2.0-4.4x."
Тогда уж стоит упомянуть и другой доклад с PromCon 2019, где говорится о проблемах VictoriaMetrics с ребалансом и потерей данных при rolling-reboot (нет auto-heal)
Для организации записи/чтения в краткосрочное/долгосрочное хранилище можно поднять несколько инстансов ВМ с разными -retentionPeriod, и настроить переливку данных из одного в другое с помощью федерации. В общем случае данные рекомендуется хранить в одном долговременном хранилище — ВМ автоматически оптимизирует доступ к недавно записанным данным — они кэшируются в ОЗУ — в то время, как старые данные доступны с диска.
Если вы собираетесь добавлять тэги в ваши метрики, то советую посмотреть на VictoriaMetrics. Она поддерживает заливку данных по Graphite plaintext протоколу с поддержкой тэгов. Кроме этого, в нее можно записывать данные из Prometheus по remote_write API, из Telegraf'а по Influx line protocol и из OpenTSDB-агентов.
Было бы интересно посмотреть на результаты VictoriaMetrics для ваших данных. Возможно, вам придется отключить кэширование ответов с помощью опции -search.disableCache на время тестирования, т.к. оно не очень дружит с добавлением данных из прошлого aka back-filling. Если ваш тест пишет данные с текущими timestamp'ами, тогда эта опция не нужна.
Также было бы интересно узнать, сколько места занимают данные на диске после окончания записи.
Кстати, netdata научилась записывать данные по Prometheus remote write протоколу — github.com/netdata/netdata/issues/5619. Это означает, что netdata может записывать данные в любой remote storage для Prometheus, в т.ч. и VictoriaMetrics. При этом сам Prometheus в данной схеме не нужен.
Если вам нравится Zabbix, то советую посмотреть на Glaber — https://glaber.io/. Это забббикс с правильным хранилищем метрик
InfluxDB хорош, но лучше все-таки использовать VictoriaMetrics. Она быстрее, жрет намного меньше памяти, меньше глючит и поддерживает нормальный язык запросов — MetricsQL, обратно совместимый с PromQL, который подходит намного лучше для типичных запросов по временным рядам, чем InfluxQL и Flux. Например, попробуйте на Flux создать запрос, складывающий два fields из разных measurements. Если что, то в PromQL это выглядит как
a + b.Спасибо за дашборд!
Вот хорошая статья по promql — https://medium.com/@valyala/promql-tutorial-for-beginners-9ab455142085
Вот ссылка на видео этого доклада — https://youtu.be/MZ5P21j_HLE
Вот ссылка на слайды — https://docs.google.com/presentation/d/1k7OjHvxTHA7669MFwsNTCx8hII-a8lNvpmQetLxmrEU/edit?usp=sharing
Да, это простое и хорошее решение, которое работает в большинстве случаев. Оно может оказаться медленнее, чем использование
mapдля удаления дублей, если размер слайса будет большим (например, миллион элементов и больше). Сортировка требуетO(n*ln(n))операций, гдеn— размер слайса, а хэшмэп —O(n)операций, т.е. при большихnхэшмэп будет выигрывать по скорости. Недостаток удаление дублей с помощью хэшмепа — он требует больше памяти и работает медленнее при небольшом количестве элементов в слайсе.Расскажите, как поместить все компоненты Thanos, включая Thanos Sidecars, в один K8S кластер, если у вас много Prometheus'ов раскиданы по разным датацентрам?
Неужели это решило проблемы с нехваткой оперативной памяти в Thanos Store Gateway?
Расскажите подробнее, как масштабировать Thanos, и сравните сложность масштабирования Thanos с масштабированием VictoriaMetrics. Про шардирование тоже расскажите, не забывая про открытые баги, связанные с шардированием.
Даунсемплинг в Thanos сложно назвать решением, готовым к production — см. открытые баги по даунсемплингу в Thanos.
У Thanos receiver есть небольшая проблемка — он не production-read.
Хороший пример. Такую же схему можно реализовать и на основе VictoriaMetrics — данные в каждом регионе записываются в локальный экземпляр VictoriaMetrics, для global querying view используем Promxy поверх всех экземпляров VictoriaMetrics.
Рекомендую почитать ответ на эту статью — https://medium.com/@valyala/evaluating-performance-and-correctness-victoriametrics-response-e27315627e87 .
Не могу найти в этом докладе упоминания про проблемы с потерей данных при rolling update. Кластер VictoriaMetrics поддерживает rolling update всех компонент без потери данных.
ОК, заходим на страницу issues для Thanos и видим там такие интересные открытые баги:
Теперь заходим на issues для VictoriaMetrics и сравниваем.
Спасибо за хорошие вопросы. Вот ответы на них:
-retentionPeriod, и настроить переливку данных из одного в другое с помощью федерации. В общем случае данные рекомендуется хранить в одном долговременном хранилище — ВМ автоматически оптимизирует доступ к недавно записанным данным — они кэшируются в ОЗУ — в то время, как старые данные доступны с диска.Если вы собираетесь добавлять тэги в ваши метрики, то советую посмотреть на VictoriaMetrics. Она поддерживает заливку данных по Graphite plaintext протоколу с поддержкой тэгов. Кроме этого, в нее можно записывать данные из Prometheus по remote_write API, из Telegraf'а по Influx line protocol и из OpenTSDB-агентов.
Было бы интересно посмотреть на результаты VictoriaMetrics для ваших данных. Возможно, вам придется отключить кэширование ответов с помощью опции
-search.disableCacheна время тестирования, т.к. оно не очень дружит с добавлением данных из прошлого aka back-filling. Если ваш тест пишет данные с текущими timestamp'ами, тогда эта опция не нужна.Также было бы интересно узнать, сколько места занимают данные на диске после окончания записи.
См. сравнение производительности на наборе данных из бенчмарка tsbs — https://medium.com/@valyala/measuring-vertical-scalability-for-time-series-databases-in-google-cloud-92550d78d8ae .
Можете попробовать хранить данные в VictoriaMetrics вместо InfluxDB:
/api/v1/export. См. https://medium.com/@valyala/analyzing-prometheus-data-with-external-tools-5f3e5e147639 .Вот тут можно почитать дополнительный материал по VictoriaMetrics — https://github.com/VictoriaMetrics/VictoriaMetrics/wiki/Articles