Выбираем хранилище данных для Prometheus: Thanos vs VictoriaMetrics

    Всем привет. Ниже представлена расшифровка доклада с Big Monitoring Meetup 4.


    Prometheus – система мониторинга различных систем и сервисов, с помощью которой системные администраторы могут собирать информацию о текущих параметрах систем и настраивать оповещения для получения уведомлений об отклонениях в работе систем.


    В докладе будет сравнение Thanos и VictoriaMetrics — проектов для долгосрочного хранения метрик Prometheus.





    Сначала расскажу про Prometheus. Это система мониторинга, которая собирает метрики с заданных target'ов и сохраняет их в локальное хранилище. Prometheus умеет записывать метрики в удаленное хранилище, умеет генерировать alert'ы и recording rules.



    Ограничения Prometheus:


    • У него нет global query view. Это когда у вас есть несколько независимых экземпляров prometheus. Они собирают метрики. И вы хотите сделать запрос поверх всех этих метрик, собранных с разных экземпляров prometheus. Prometheus это не позволяет.
    • У prometheus производительность ограничена только одним сервером. Prometheus автоматически не может масштабироваться на несколько серверов. Вы только можете вручную разделить ваши target'ы между несколькими Prometheus'ами.
    • Объем метрик в Prometheus ограничен только одним сервером по той же причине, по которой он автоматически не может автоматически масштабироваться на несколько серверов.
    • В Prometheus не так-то просто организовать сохранность данных.


    Решения этих проблем/задач?


    Решения такие:



    Все эти решения для удаленного хранения данных, собранных Prometheus. Они решают проблему remote storage с предыдущего слайда по разному. В данной презентации я расскажу только про первые два решения: Thanos и VictoriaMetrics.


    Впервые информация про Thanos появилась по этой ссылке. Там описана архитектура Thanos и как он работает.



    Thanos берет данные, которая сохранил Prometheus на локальный диск, и копируют их в S3, в GCS либо в другой object storage.



    Таким образом Thanos обеспечивает global query view. Вы можете запрашивать данные, сохраненные в object storage c нескольких экземпляров Prometheus.



    Thanos поддерживает PromQL и Prometheus querying API.



    Thanos использует код Prometheus для хранения данных.



    Thanos разрабатывает те же разработчики, что и Prometheus.


    Про VictoriaMetrics. Вот ссылка, где мы впервые рассказали про VictoriaMetrics.



    VictoriaMetrics получает данные с нескольких prometheus по remote write API протоколу, поддерживаемым Prometheus.



    VictoriaMetrics обеспечивает global query view, так как несколько экземпляров Prometheus могут записывать данные в одну VictoriaMetrics. Соответственно, вы можете сделать запросы по этим всем данным.



    VictoriaMetrics также поддерживает, как и Thanos — PromQL и Prometheus querying API.



    В отличие от Thanos, исходный код VictoriaMetrics написан с нуля и оптимизирован по скорости и потребляемым ресурсам.



    VictoriaMetrics в отличие от Thanos, масштабируется как вертикально так и горизонтально. Есть Single-node версия, которая масштабируется вертикально. Вы можете начать с одного процессора и 1 ГБ памяти и постепенно расти до сотни процессоров и 1ТБ памяти. VictoriaMetrics умеет использовать все эти ресурсы. Ее производительность вырастет примерно в 100 раз по сравнению с 1-ядерной системой.



    История Thanos началась в ноябре 2017 года, когда появился первый публичный коммит. До этого Thanos разрабатывался внутри компании improbable.io.



    В июне 2019 года был знаковый релиз 0.5.0, в котором убрали gossip протокол. Eго убрали из Thanos, потому что он себя показал не с лучшей стороны. Часто кластер Thanos неправильно работал, неправильно подключались к нему ноды из-за gossip протокола. Поэтому решили его оттуда убрать. Я считаю, что это правильное решение.



    В том же июне 2019 года они отправили заявку номер 256 в Cloud Native Computing Foundation.



    И через пару месяцев Thanos приняли в Cloud Native Computing Foundation, в которую входит Prometheus, Kubernetes и другие популярное проекты.



    В январе 2018 года началась разработка VictoriaMetrics.



    В сентябре 2018 я впервые публично упомянул про VictoriaMetrics.



    В декабре 2018 года опубликовали Single-node версию.



    В мае 2019 были опубликованы исходники как Single-node, так и кластерной версии.



    В июне 2019, также как Thanos, мы подали заявку в CNCF foundation под номером 255. Мы подали заявку на один день раньше, чем подал заявку Thanos.



    Но, к сожалению, нас до сих пор не приняли туда. Нужна помощь комьюнити.



    Рассмотрим самые главные слайды, показывающие архитектуру Thanos и VictoriaMetrics.



    Начнем с Thanos. Желтые компоненты — это компоненты Prometheus. Все остальное — это компоненты Thanos. Начнем с самого главного компонента. Thanos Sidecar — это компонент, который устанавливается рядом с каждым Prometheus. Он занимается тем, что загружает данные Prometheus из локального storage в S3 либо в другой Object Storage.


    Есть еще такой компонент, как Thanos Store Gateway, который умеет считывать эти данные c Object Storage при входящих запросах от Thanos Query. Thanos Query реализует PromQL и Prometheus API. То есть снаружи он выглядит как Prometheus. Принимает запросы PromQL, отправляет их в Thanos Store Gateway, Thanos Store Gateway достает нужные данные из Object Storage, отправляет их назад.


    Но у нас в Object Storage хранятся данные без последний двух часов из-за особенности реализации Thanos Sidecar, который не может закачать последние два часа в Object Storage S3, так как для этих двух часов Prometheus еще не создал файлы в локальном хранилище.


    Как же это решили обойти? Thanos Query кроме, запросов в Thanos Store Gateway, отправляет параллельно запросы еще в каждый Thanos Sidecar, который находятся рядом с Prometheus.


    А Thanos Sidecar, в свою очередь, проксирует запросы дальше в Prometheus, и достает данные за последние два часа.


    Кроме этих компонент, есть еще опциональный компонент, без которого Thanos будет плохо себя чувствовать. Это Thanos Compact, который занимается слиянием мелких файлов на Object Storage в более крупные файлы, которые были загружены сюда Thanos Sidecar'ами. Thanos Sidecar загружает туда файлы с данными за два часа. Эти файлы, если их не сливать в более крупные файлы, то их количество может вырастить очень существенно. Чем больше таких файлов, тем больше нужно памяти для Thanos Store Gateway, тем больше нужно ресурсов для передачи данных по сети, метаданных. Работа Thanos Store Gateway становится неэффективной. Поэтому нужно обязательно запускать Thanos Compact, который сливает мелкие файлы в более крупные, чтобы таких файлов было меньше и чтобы уменьшить overhead на Thanos Store Gateway.


    Есть еще такой компонент как Thanos Ruler. Он выполняет Prometheus alerting rules и может вычислять Prometheus recording rules, для того чтобы записывать данные снова в Object Storage. Но этот компонент не рекомендуется использовать, т.к. он склонен возвращать неполные данные.


    Вот такая схема простая у Thanos.



    Теперь сравним со схемой VictoriaMetrics.


    У VictoriaMetrics есть 2 версии: Single-node и кластерная версия. Single-node работает на одном компьютере. В Single-node нет этих компонентов, просто один бинарник. Этот бинарник на слайде выглядит вот этим квадратом. Все, что находится внутри квадрата — это содержимое бинарного файла для Single-node версии. Вам необязательно про него знать. Просто запускаете бинарник — и все у нас работает.


    Кластерная версия сложнее. Внутри нее находится три разных компонента: vmselect, vminsert и vmstorage. Из их названия должно быть понятно, чем каждый из них занимается. Insert компонент принимает данные в разных форматах: из Prometheus remote write API, Influx line протокола, Graphite протокола и из OpenTSDB протокола. Insert компонент принимает их, парсит и распределяет между имеющимися storage компонентами, где данные уже сохраняется. Select компонент, в свою очередь, принимает PromQL запросы. Он реализует PromQL, а также Prometheus querying API, и он может быть использован, как замена Prometheus в Grafana или других Prometheus API клиентах. Select принимает promql запрос, парсит его, считывает необходимые данные для выполнение этого запроса из storage нод, процессит эти данные и возвращает ответ.



    Сравним сложность установки Thanos и VictoriaMetrics.



    Начнем с Thanos. Перед тем, как начать работать с Thanos, нужно создать bucket в Object Storage, такой как S3 или GCS, чтобы Thanos Sidecar мог туда записывать данные.



    Потом для каждого Prometheus нужно установить Thanos Sidecar. Перед этим нужно не забыть отключить data compaction в Prometheus. Data compaction периодически сжимает данные в локальном хранилище Prometheus для того, чтобы уменьшить потребление ресурсов.


    Когда вы устанавливаете Thanos Sidecar к вашим Prometheus'ам, вы должны отключить этот data compaction, потому что Thanos Sidecar не умеет нормально работать при включенном data compaction. Это означает, что ваш Prometheus начинает сохранять данные блоками по два часа и перестает сливать эти блоки в более крупные. Соответственно, если вы делаете запросы, которые превышают длительность за последние два часа, то они будут не настолько эффективно работать, по сравнению с тем, как могли бы работать, если был бы включен data compaction.



    Поэтому Thanos рекомендует уменьшать время хранения данныех (data retention) в локальном storage до 6-8 часов, чтобы снизить этот overhead большого количества мелких блоков.


    После того как вы установили Thanos Sidecar, вы должны для каждого Object Storage Bucket установить два компонента. Это Thanos Compactor и Thanos Store Gateway.



    После этого нужно установить Thanos Query и настроить его, чтобы он умел подключаться ко всем Thanos Store Gateway, которые у вас есть, а также умел подключатся ко всем Thanos Sidecar.


    Тут может быть небольшая проблемка.



    Вам нужно настроить надежное и защищенное подключение от Thanos Query к этим компонентам. И если у вас Prometheus'ы находятся в разных дата-центрах, либо в разных VPC, то к ним запрещены подключения извне. Но для работы Thanos Query вам нужно как-то настроить подключение туда, и вы должны придумать способ.


    Если у вас таких дата-центров много, то, соответственно, снижается надежность всей системы. Так как Thanos Query должен постоянно держать подключения ко всем Thanos Sidecar, расположеных в разных дата-центрах. При каждом входящем запросе он будет направлять запросы на все Thanos Sidecar. Если соединение прервется, то вы получите либо не полный набор данных, либо получите ответ "кластер не работает".



    В VictoriaMetrics все немного проще. Для Single-node версии достаточно просто запустить один бинарник и все работает.



    В кластерной на версии достаточно запустить все вышеупомянутые три типа компонентов в любом необходимом вам количестве, либо использовать helm chart для автоматизации запуска компонентов в Kubernetes. Мы еще планируем сделать Kubernetes оператор. Helm chart не покрывает некоторые кейсы, и позволяет вам выстрелить ногу. Например, он позволяет уменьшить количество storage node, что приведет к потере данных.



    После того, как вы запустили один бинарник либо кластерную версию, вам достаточно добавить в конфиг Prometheus настройку для remote write url, чтобы он начал записывать данных параллельно в локальный storage и в remote storage. Как вы заметили, такая конфигурация должна работать намного надежнее по сравнению с конфигурацией Thanos. Нам не нужно держать подключение от VictoriaMetrics ко всем Prometheus'ам, потому что Prometheus'ы сами подключаются к VictoriaMetrics и передают данные.



    Рассмотрим сопровождение Thanos и VictoriaMetrics.



    У Thanos нужно следить за Sidecar, чтобы они не прекращали загрузку данных в Object Storage. Они могут прекратить эту загрузку данных вследствие ошибок загрузки, например у вас временно прервалась сетевое соединение с Object Storage, либо Object Storage временно стал недоступен. Thanos Sidecar в этот момент заметит это, сообщит об ошибке, может свалиться и после этого перестать работать. Если вы не будете его мониторить, то у вас перестанут передаваться данные в Object Storage. Если пройдет время retention (6-8 часов рекомендованное), то вы будете терять данные, которые не попали в Object Storage.



    Thanos сompactor-ы могут перестать работать из-за race'ов с Sidecar. Сompactor-ы берут данные с Object Storage и сливают их в более крупные куски данных. Так как сompactor-ы не синхронизированы с Sidecar'ами, то может произойти вот что: Sidecar не успел еще дописать блок, Compactor решает, что этот блок полностью записан. Compactor начинает его считывать. Он считывает блок не в полном виде и перестает работать. См. подробности тут.



    Store Gateway может отдавать неконсистентные данные из-за race'ов между Compactor'ом и Sidecar'ами. Тут такая же штука, потому что Store Gateway никак не синхронизирован с Compactor'ами и Sidecar'ами. Соответственно, могут возникать состояние гонок, когда Store Gateway не видит часть данных, либо видит лишние данные.



    Query компонент в Thanos по умолчанию отдает частичный результат, если некоторые Sidecar-ы либо Store Gateway не доступны в данный момент. Вы получите часть данных, и даже не будет знать, что получили не все данные. Это он работает так по умолчанию. В похожей ситуации VictoriaMetrics возвращает помеченные данные как частичные.



    В отличие от Thanos, VictoriaMetrics редко теряет данные. Даже если прервалось подключение от Prometheus к VictoriaMetrics, то не проблема, так как Prometheus продолжается записывать поступающие новые данные в Write Ahead Log, размер которого равен 2 часам. Если вы в течении двух часов восстановите подключение к VictoriaMetrics, то данные не потеряются. Prometheus умеет дописывать данные после восстановления подключения к VictoriaMetrics.



    В отличие от Thanos, который записывает данные в object storage только спустя два часа, Prometheus автоматически реплицирует данные по remote write протоколу в remote storage, такой как VictoriaMetrics. Вам не страшна потеря local storage в Prometheus. Если он вдруг потерял local storage, то вы худшем случае потеряете последние секунды данных, которые не успели записаться в remote storage.



    Kubernetes автоматически управляет кластером в отличие от Thanos. Все компоненты Thanos сложно поместить в один Kubernetes кластер, в отличие от кластерных компонент VictoriaMetrics.



    У VictoriaMetrics очень простое обновление на новую версию. Просто останавливаете VictoriaMetrics, обновляете бинарники и запускаете. При остановке через SIGINT сигнал все бинарники VictoriaMetrics делают gracefull shutdown. Они правильно сохраняют нужные данные, правильно закрывают входящие соединения, чтобы ничего не потерять. Поэтому вы ничего не потеряете при обновлении.



    У VictoriaMetrics очень просто расширять кластер. Просто добавляете необходимые компоненты и продолжаете работать.



    Про подводные камни в Thanos и VictoriaMetrics.



    У Thanos следующие подводные камни. Prometheus должен хранить данные за последние два часа. Если они потеряются, вы их полностью потеряете, так как они еще не успели записаться в Object Storage, такой как S3.



    Store Gateway компонент и сompactor компонент может требовать много памяти для работы с большим Object Storage, если там хранится много мелких файлов. Чем больше количество и объем файлов, тем больше требуется оперативной памяти Store Gateway и сompactor для хранения метаинформации. У Thanos много issues по поводу того, что Store Gateway и сompactor падают при средних объемов записанных данных.



    Thanos рекламируется, что он может скейлиться бесконечно на количество ваших Prometheus. На самом деле это неправда. Так как все запросы идут через Query компонент, который должен параллельно опросить все Store Gateway компоненты и все Sidecar компоненты, вытянуть оттуда данные и потом их препроцессить. Очевидно что скорость запросов ограничена самым медленным слабым звеном, самым медленным Store Gateway либо самым медленным Sidecar.


    Эти компоненты могут быть неравномерно нагружены. Например, у вас есть Prometheus, который собирает миллионы метрик в секунду. И есть Prometheus, в котором собирается тысячи метрик в секунду. Prometheus, в котором собираются миллионы метрик в секунду, намного сильнее загружает сервер, на котором он работает. Соответственно Sidecar там работает медленнее. И вообще все там медленно работает. И Query компонент будет очень медленно оттуда данные вытягивать. Соответственно производительность вашего всего кластера будет ограничена этим медленным Sidecar.



    По умолчанию Thanos отдает частичное данные, если некоторые Sidecar'ы и либо Store Gateway недоступны. Например, если у вас Sidecar'ы раскиданы по всему миру в разных дата-центрах, то вероятность разрыва соединения и недоступности компонентов сильно возрастает. Соответственно, в большинстве случаев вы будете получать частичные данные, даже не зная об этом.



    У VictoriaMetrics тоже есть подводные камни. Первый подводный камень — это опция, которая ограничивает объём оперативной памяти, используемой под кеш VictoriaMetrics. По умолчанию она равна 60% оперативной памяти на машине, где VictoriaMetrics запущена либо 60% ОЗУ пода VictoriaMetrics в Kubernetes.


    Если неправильно поменять это значение, то можно угробить производительность VictoriaMetrics. Например, если установить слишком низкое значение, то данные могут перестать помещаться в кеш VictoriaMetrics. Из-за это ей придется делать лишнюю работу и нагружать процессор с диском. Если вы сделаете эту опцию слишком большой, то это повышает, во-первых, вероятность того, что VictoriaMetrics будет вылетать с ошибкой out of memory, и, во-вторых, это будет приводить к тому, что в операционной системе будет оставаться очень мало оперативной памяти для файлового кэша. А VictoriaMetrics полагается на файловый кэш для производительности. Если его недостаточно, то может сильно увеличиться нагрузка на диск. Поэтому совет: не менять параметр без крайней необходимости.



    Вторая опция. Это retentionPeriod — период, который по умолчанию выставлен в 1 месяц. Это время, в течение которого VictoriaMetrics хранит данные. По истечении этого срока VictoriaMetrics данные удаляет.


    Многие запускают VictoriaMetrics без этого параметра, записывают данные в течение месяца. А потом спрашивают: почему данные пропали за предыдущий месяц? Потому что retentionPeriod по умолчанию равен 1 месяц. Поэтому нужно знать и устанавливать правильный retentionPeriod.



    Пройдемся по уникальных возможностям.



    У Thanos есть такая фича, как downsampling: 5-минутные и часовые интервалы, которые зачастую неправильно работают. Если погуглить и посмотреть их issue на github, там очень много issues, связанных с этим downsampling, что он иногда неправильно работает, либо работает не так, как ожидают пользователи.



    У Thanos есть дедупликация данных для Prometheus HA pairs. Когда два Prometheus'а собирают одни и те же метрики с одних и тех же target'в и Thanos их складывает в Object Storage. Thanos умеет правильно дедуплицировать эти данные, в отличие от VictoriaMetrics.



    У Thanos есть alert компонент, который был на схеме Thanos. Но его не рекомендуется использовать в production.



    У Thanos преимущество, что код у Thanos и у Prometheus — общий. Thanos и Prometheus разработан одними и теми же разработчиками. При улучшениях в Thanos либо Prometheus выигрывает другая сторона.



    У VictoriaMetrics главная фича это — MetricsQL. Это расширенния VictoriaMetrics для PromQL, про которые я рассказывал на предыдущем big monitoring metup.



    VictoriaMetrics поддерживает заливку данных по множеству разных протоколов. VictoriaMetrics не только может принимать данные от Prometheus, но и по протоколам Influx, OpenTSDB и Graphite.



    Данные VictoriaMetrics занимают обычные намного меньше места по сравнению с Thanos и Prometheus.


    Если записывать реальные данные, то пользователи говорят о 2-5 кратном уменьшение размера данных на диске по сравнению с Prometheus и Thanos.



    Еще одно преимущество VictoriaMetrics — она оптимизирована под скорость.



    Пройдемся по стоимости инфраструктуры.



    Одно из преимуществ Thanos в том, что он сохраняет данные в object storage, который сравнительно дешевый.


    При сохранении данных в object storage, вы должны оплачивать операции запись и чтения данных ($10 за миллион операций). Когда вы записываете данные в object storage, вы оплачиваете расходы вашего хостинга на загрузку данных в интернет, если ваш кластер находится не в AWS — там бесплатно. Когда вы считываете данные, вы оплачиваете от $10 до $230 за 1ТБ. Это может быть существенно, если вы часто запрашиваете исторические данные из Thanos кластера.



    Для Thanos кластера нужно оплачивать сервера для Compact, Store Gateway, Query компонентов, которые требует много памяти, ЦПУ для больших объемов данных.



    У VictoriaMetrics расходы такие. Если хранить данные на GCE HDD дисках, то выходит $40 за 1ТБ. Для VictoriaMetrics достаточно обычных HDD дисков, не нужны никакие SSD, которые стоят раз в пять дороже. VictoriaMetrics оптимизирована под HDD.



    Для VictoriaMetrics нужны сервера для компонентов: либо Single-nod либо для кластерных компонентов, которые в отличие от Thanos компонентов, требует намного меньше ЦПУ, ОЗУ — соответственно будет дешевле.



    Примеры внедрения.



    У Thanos пример внедрения — это Gitlab. Gitlab полностью работает на Thanos. Но там не все так гладко. Если посмотреть по их issues, то можно увидеть что у них постоянно возникают какие-то операционные проблемы с Thanos: не хватает памяти для Store Gateway либо Query компонентов. Им постоянно приходится увеличивать объем памяти.


    Из-за этого увеличиваются расходы на решение этих проблем.


    Второе внедрение, которое может быть более успешное — это компания Improbable, которые начали разработку Thanos. Они опубликовали исходники Thanos. Improbable — компания, которая занимается разработкой игровых движков.



    У VictoriaMetrics публичные примеры внедрения это:


    • wix.com конструктор сайтов
    • Adidas внедряет VictoriaMetrics и даже сделал доклад на последнем PromCon 2019
    • TrafficStars — ad network
    • Seznam.cz — популярный чешский поисковик.

    А дальше пошли ноунейм компании, которые я не могу назвать сейчас. Они не дали согласие.


    • Один крупный разработчик игр. Крупнее, чем им Improbable.
    • Крупный разработчик графического ПО.
    • Крупный российский банк.
    • Европейский производитель ветряных турбин, который успешно протестировал VictoriaMetrics. Этот производитель внедряет VictoriaMetrics для мониторинга данных, полученных с ветряных турбин со скоростью 50 сэмплов в секунду на каждый датчик. В каждой ветряной турбине по несколько сотен датчиков. У них несколько сотен ветряных турбин.
    • Российские авиалинии, которые хотят внедрить VictoriaMetrics, но все никак не могут. Мы с ними на стадии договора.

    Выводы.


    VictoriaMetrics и Thanos решают похожие задачи, но разными способами:


    • Global query view
    • горизонтальное масштабирование
    • произвольный retention


    Спасибо.


    Ждем вас на нашем telegram канале.


    Только зарегистрированные пользователи могут участвовать в опросе. Войдите, пожалуйста.

    Что вы используете в качестве long term storage для Prometheus?

    • 32,5%Thanos13
    • 2,5%Cortex1
    • 2,5%M3DB1
    • 47,5%VictoriaMetrics19
    • 15,0%другое6

    Похожие публикации

    Средняя зарплата в IT

    113 000 ₽/мес.
    Средняя зарплата по всем IT-специализациям на основании 5 091 анкеты, за 2-ое пол. 2020 года Узнать свою зарплату
    AdBlock похитил этот баннер, но баннеры не зубы — отрастут

    Подробнее
    Реклама

    Комментарии 9

      +5
      мы тоже у себя тестируем, в ограниченный прод запустили маленький под-проект. выбрали по большей части изза вкусностей как раз расширеного QL, даже багу там нашли )) в итоге одна виктория заменила самописный сервис и базу мускуля на почти террабайт. финансовые данные, могу только сказать пока что
        +3
        Поэтому Thanos рекомендует уменьшать время хранения данныех (data retention) в локальном storage до 6-8 часов, чтобы снизить этот overhead большого количества мелких блоков.
        Thanos Sidecar в этот момент заметит это, сообщит об ошибке, может свалиться и после этого перестать работать.
        Store Gateway может отдавать неконсистентные данные из-за race'ов между Compactor'ом и Sidecar'ами.
        Все компоненты Thanos сложно поместить в один Kubernetes кластер, в отличие от кластерных компонент VictoriaMetrics.
        В отличие от Thanos, VictoriaMetrics редко теряет данные.

        Очень жалко выглядит когда в рекламной статье пишут голословно про проблемы конкурента. Приводите ссылки на issue или не упоминайте вообще.


        Часто кластер Thanos неправильно работал, неправильно подключались к нему ноды из-за gossip протокола. Поэтому решили его оттуда убрать. Я считаю, что это правильное решение.

        Это было минорное изменение версии 0.5, которое было запланировано за несколько версий до. Т.к к тому времени большинство уже пользовалось sd_file и sd_dns.


        VictoriaMetrics в отличие от Thanos, масштабируется как вертикально так и горизонтально.

        Лишь показывает что вы не представляете как масштабировать Thanos. Зачем тогда упоминать его? Там кстати и шардировать можно.


        Это Thanos Compact, который занимается слиянием мелких файлов
        Эти файлы, если их не сливать в более крупные файлы, то их количество может вырастить очень существенно.

        Вы видимо не понимаете что именно делает thanos-compact. Компакшн файлов — это лишь малая часть, основная часть — это downsampling. Создаются усреднения для ренджей 5m и 1h, где каждая точка по сути содержит 5 значений (min, max, sum, count, avg) чтобы все функции продолжали работать на усредненных данных корректно. Далее когда вы делаете query за большой диапазон времени (например за месяц, год) thanos-store использует эти посчитанные данные. Т.е. raw данные не используются, даже если они у вас есть за годы назад. И основная отличительная черта Thanos — что можно настроить retention и хранить raw только за последние 2 недели, а 1h — бесконечно, что очень дешево на S3-IA.


        Перед тем, как начать работать с Thanos, нужно создать storage bucket в Object Storage, такой как S3 или GCS, чтобы Thanos sidecar мог туда записывать данные.

        Если мы говорим про легкость сетапа — S3 вовсе не обязателен для начала работы с Thanos и получения global-view из нескольких прометеев.


        Нам не нужно держать подключение от VictoriaMetrics ко всем Prometheus'ам, потому что Prometheus'ы сами подключаются к VictoriaMetrics и передают данные.

        Большинство минусов которые вы описываете не относятся к сравнению Thanos или VictoriaMetrics, a являются сравнением схем remote-write и thanos-sidecar. При этом Thanos так же поддерживает remote-write Т.е. он может так же стоять в центре и получать данные, как и VictoriaMetrics и m3db.
        Но его отличительная черта, что он так же позволяет локализовать данные и не посылать их в единое место. И все равно иметь global-view и long term storage при этом. Представьте ситуцию когда у вас несколько регионов в AWS. Вы можете в каждом регионе иметь свой prometheus который пишет данные в локальный S3. Вы приходите из центральной графаны за мизерным обьемом тех точек графиков на которые вы смотрите (ответы на PromQL запросы), а основные гигабайты остаются лежать локально. А в случае remote-write вы бы все время передавали эти гигабайты со всех регионов, без разницы смотрит на них кто-либо или нет, и платили за траффик.


        Если записывать реальные данные, то пользователи говорят о 2-5 кратном уменьшение размера данных на диске по сравнению с Prometheus и Thanos.

        Очевидно вы пытаетесь сказать про "уменьшение размера данных" не принимая в расчет downsampling с retention, который ваш продукт не умеет в отличии от Thanos и m3db.


        В отличие от Thanos, исходный код 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."


        Adidas внедряет VictoriaMetrics и даже сделал доклад на последнем PromCon 2019

        Тогда уж стоит упомянуть и другой доклад с PromCon 2019, где говорится о проблемах VictoriaMetrics с ребалансом и потерей данных при rolling-reboot (нет auto-heal). Для сравнения в Thanos всегда можно перегенировать 5m,1h опять по raw данным. m3db поддерживает rebalance.


        К сожалению доклад выполнен в худших маркетинговых традициях, которые в технической среде сразу приводят к нелюбви к продукту. Даже удивительно, что он сделан СТО.
        Я предложил бы вам больше рассказывать про детали своего продукта, а не хаять конкурента опыта с которым вы не имеете.
        image

          +3
          Очень жалко выглядит когда в рекламной статье пишут голословно про проблемы конкурента. Приводите ссылки на 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. Пример КХ показывает, что система может быть крайне жизнеспособной и производительной и без этой фичи.

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

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

            –1

            Грязный маркетинг — неотъемлимая часть продвижения VM, это их основная фишка же

              0
                0
                Лишь показывает что вы не представляете как масштабировать 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.

                Даунсемплинг в Thanos сложно назвать решением, готовым к production — см. открытые баги по даунсемплингу в Thanos.


                При этом Thanos так же поддерживает remote-write Т.е. он может так же стоять в центре и получать данные, как и VictoriaMetrics и m3db.

                У Thanos receiver есть небольшая проблемка — он не production-read.


                Представьте ситуцию когда у вас несколько регионов в 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."

                Рекомендую почитать ответ на эту статью — https://medium.com/@valyala/evaluating-performance-and-correctness-victoriametrics-response-e27315627e87 .


                Тогда уж стоит упомянуть и другой доклад с PromCon 2019, где говорится о проблемах VictoriaMetrics с ребалансом и потерей данных при rolling-reboot (нет auto-heal)

                Не могу найти в этом докладе упоминания про проблемы с потерей данных при rolling update. Кластер VictoriaMetrics поддерживает rolling update всех компонент без потери данных.

                  0
                  хорошее замечание, я не такой спец по обоим продуктам, но по самому тексту можно уже понять предвзятость или если хотите определенную симпатию к одному продукту и антипатию к другому.
                  +1
                  Все компоненты Thanos сложно поместить в один Kubernetes кластер, в отличие от кластерных компонент VictoriaMetrics

                  https://github.com/thanos-io/kube-thanos/.


                  Если посмотреть по их issues, то можно увидеть что у них постоянно возникают какие-то операционные проблемы с Thanos

                  У нас были похожие проблемы, они исчезли после перехода на remote write.


                  С одной стороны я рад что соревнуются два open source проекта, но печально что методы в этой борьбе остались те же — рекламные статьи о преимуществах без сравнительных графиков и отзывах клиентов

                Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

                Самое читаемое