victoria metrics что это
Инструменты для работы «системного администратора на максималках»
Авторизуйтесь
Инструменты для работы «системного администратора на максималках»
директор по клиентскому сервису NGENIX
Не так давно мы серьезно обновили стек инструментов, которые используют наши системные администраторы в повседневной работе, и готовы поделиться списком. Этому предшествовали годы использования различных решений, которые также не стояли на месте и развивались параллельно нашей работе — как в хорошую, так и в плохую, на наш взгляд, сторону. В этой статье я разберу тулсет, который сформировался у нас на начало 2021 года, расскажу, чем он хорош, и объясню плюсы и минусы его альтернатив.
Для кого пригодится?
Традиционно, снова вернемся к базовым определениям: кого можно назвать системным администратором и кого считаем им мы в NGENIX. В прошлом году я рассказывал, чем занимаются каждый день наши ребята, а также порефлексировал на тему путей карьерного развития системного администратора и о том, почему его не стоит путать с эникейщиком.
Главное в работе системного администратора — сделать так, чтобы все работало у заказчика, будь он внутренним или внешним. На hh.ru наши вакансии, связанные с клиентским сервисом, называются «Системный администратор», но при этом наши специалисты администрируют крупнейшие веб-ресурсы, подобные Wink, ozon.ru или goods.ru. Мы называем наших системных администраторов инженерами облачных сервисов. Это такие «сисадмины на максималках», и типичная сисадминская мантра «сделать так, чтобы все работало» — их важнейший KPI, потому что сбои или инциденты напрямую влияют на деньги, бизнес, сон и карьеру заказчика.
Поэтому набор инструментов, которые инженеры используют каждый день, прежде всего связан с коммуникацией в команде и с заказчиком, c мониторингом состояния веб-ресурса, системой алертов об отклонениях в работе администрируемых систем — словом, со всем, что поможет настроить самый полный «центр управления полетами» и иметь представление о том, как работают веб-ресурсы в реальном времени и где им нужно помочь.
Автоматизация хелпдеска
Если вы работаете с высоконагруженными сервисами, крупными веб-ресурсами, критически важными системами, процесс поступления тикетов обязан быть максимально автоматизированным, потому что хаосу здесь не место.
Zendesk
Мы используем Zendesk — это, наверное, один из самых знаменитых SaaS-хелпдесков среди систем обработки обращений клиентов. Zendesk имеет интуитивный интерфейс, очень широкие возможности интеграции, поддерживает REST, JSON, RSS, email, различные виджеты. Заказчик может создать тикет через почту, веб-интерфейс или через другие каналы — например, есть удобная интеграция с Telegram. Мы также интегрировали Zendesk с нашей системой мониторинга для соблюдения SLA, а также телефонией.
Альтернатива: Jira Service Desk
Функционально нативный хелпдеск Jira практически идентичен Zendesk. Это онлайн-сервис обработки тикетов от Atlassian, который предлагает огромное количество настроек и интеграций, а также большие возможности для масштабирования. Выбирая между JIRA Service Desk и Zendesk, скорее всего, вам стоит обратить внимание на простоту интеграции с имеющимися инструментами, потому что миграция может быть долгой и сложной, что очень неудобно, если вы живете в мире жесткого SLA.
Мониторинг
Это важнейшая часть нашего воркфлоу: служба сопровождения и технической поддержки должна иметь полное и наглядное представление о том, что происходит с системами клиентов и нашей собственной инфраструктурой, а также получать своевременные уведомления об инцидентах и состоянии систем. В конце прошлого года мы провели ревизию инструментов мониторинга: выросло количество систем и ПО, которые нужно мониторить; из-за роста нагрузки пришло время разделиться на несколько команд; требовалось более точно и быстро реагировать на инциденты.
25–26 ноября, Москва и онлайн, От 24 000 до 52 000 ₽
Инструменты мониторинга, которые мы использовали раньше, в этих условиях нам уже не подходили: отслеживать изменения стало сложнее, на новых объемах вскрылись ограничения, обусловленные легаси-системами, возникла потребность в более гибком алертинге. После того, как мы сменили стек инструментов, мы смогли унифицировать работу трех составляющих системы мониторинга (сбор данных, их визуализацию в графики и дэшборды, алерты), избавились таким образом от большой доли легаси, получили больше прозрачности, масштабируемости, воспроизводимости.
Мониторинг: сбор данных
Мы используем в работе Prometheus — систему мониторинга высококардинальных метрик, которая помогает системным администраторам собирать данные о текущих параметрах систем и сервисов в удобном виде и настраивать оповещения для получения уведомлений об отклонениях. Однако у него есть некоторые критические для нас архитектурные ограничения: он не позволяет длительно хранить данные, сложен в масштабировании и потребляет много системных ресурсов. Поэтому нужно дополнительное решение для хранения данных, собранных Prometheus.
Victoria Metrics
Victoria metrics — решение для мониторинга на базе открытого кода с расширенным функционалом и возможностями масштабирования как вертикально, так и горизонтально. Victoria metrics умеет долго хранить метрики, как и многие другие инструменты, но при этом быстро обрабатывает их, не требуя больших вычислительных ресурсов, что важно при высокой нагрузке на системы. Именно рост нагрузки выявил ограничения Zabbix в качестве хранилища данных Prometheus, но Victoria Metrics решала их задачи разом, экономя при этом ресурсы.
Альтернативы: Thanos, Graphite, Influx, Zabbix
Мы долгое время полагались на комбинацию Prometheus и Zabbix, но ограничения Zabbix в плане производительности заставили нас поискать альтернативы. Сами мы рассматривали очевидный выбор — Thanos, но технологически он был намного сложнее Victoria Metrics, и в итоге мы выбрали последнее.
Мониторинг: визуализация данных
Grafana предоставляет интерфейс работы с графиками, обновляемыми в режиме real-time — пользователь системы может настроить себе удобную «приборную панель», используя различные виды графиков (используя уже разработанные сообществом или собственные дашборды) — это особенно важно, если нужно мониторить большое количество параметров — в нашем случае это, например, параметры работы сервисов заказчика: количество запросов, их статус, время ответа и т.п. Де-факто это стандарт отрасли, даже добавить нечего.
Мониторинг: алертинг
Alertmanager+Alerta
Alertmanager — это часть стека Prometheus для управления потоками алертов, которое мы продолжаем использовать. В дополнение к нему у нас появилась Alerta — удобное решение для отображения алертов и управления уведомлениями. Быстро устанавливается и легко масштабируется по мере роста требований и объемов. Она также гибко интегрируется с современными системами, предоставляющими свои специфичные метрики — например, netdata, Sensu, Pingdom и другими. Также можно разграничить уведомления для заказчиков и наших инженеров, которые работают с несколькими проектами. У Alerta удобный WebUI, который мы уже оценили: раньше мы использовали самописную php-страницу, которая выдергивала данные из Zabbix.
Альтернатива: Zabbix
Zabbix — довольно популярная система мониторинга. Она универсальная, но сложно масштабируемая и негибкая, как и любой «старый» инструмент с высокой долей легаси и технического долга. До недавнего времени мы использовали Zabbix, но, к сожалению, его коснулась судьба многих известных ИТ-инструментов: изначально крутое решение активно развивается силами комьюнити, со временем растет, усложняется, становится неповоротливым, потребляет больше ресурсов, чем аналоги. И вот уже новые фичи внедряются медленней, а юзабилити у более молодых и резвых конкурентов не в пример лучше. В новых версиях разработчик старается исправить это, но мы предпочли не дожидаться, а перейти на Alerta, когда интенсивность работы выросла с нагрузкой.
База данных для логирования
Clickhouse
Clickhouse — это колоночная база данных для хранения логов. Если логи структурированы, с ней очень удобно работать через SQL-подобный синтаксис — любые нужные данные, в том числе для работы нашей аналитики трафика в реальном времени, предоставляются в удобном виде и очень быстро (а скорость для нас критически важна). Благодаря высокой производительности и гибкости можно посмотреть на наши данные под любым углом и, например, быстро проанализировать критический инцидент. Удобно, просто интегрировать — иными словами, стильно, модно, молодежно.
Альтернатива: Elastic Search, Hadoop
Всем в сообществе известные базы данных — но в нашем случае (логирование клиентских сервисов) по производительности они сильно отстают от Clickhouse — в частности, Hadoop, от которого мы отказались.
Таск-трекинг
Это также стандарт отрасли, который изначально создавался под идеологию работы ИТ-бизнеса, и здесь даже трудно предложить сопоставимые альтернативы. Jira — невероятно гибкий инструмент, у него бесчисленное количество плагинов, широкие возможности интеграции «из коробки» с практически всеми известными инструментами, и каждый год появляются новые, что повышает ценность Jira в отрасли еще больше. Маленькие команды могут использовать более доступную версию, большие компании могут позволить себе более дорогую лицензию и расширить функциональность. Другими словами — Jira объединяет =)
Конечно, есть множество платных, бесплатных, условно бесплатных альтернатив, их можно допиливать, дописывать, страдать в процессе, но это не для нас. И не для вас, если вы приоритизируете свой продукт и клиентский сервис.
Управление знаниями
Confluence
Также стандарт отрасли в качестве инструмента хранения и систематизации базы знаний — в Confluence мы описываем и разбираем инциденты, фиксируем решения. Confluence очень проста в управлении, в то время как многие автономные инструменты требуют наработки определенных знаний в настройке и эксплуатации. За что еще можно любить Confluence? За отличную и интуитивную систему управления версиями, которая упрощает внутреннюю документацию, а также за удобную навигацию и возможность интеграции с многочисленными плагинами.
Альтернатива: Notion
Notion в качестве wiki обладает обширными возможностями: можно работать с документами, управлять проектами, вести базы знаний, хранить базы данных. Клиент Notion работает быстро, есть некоторые преимущества по сравнению с Confluence — например, маркдауны, подсветка кода. Для нас удобнее было пользоваться продуктами Atlassian, но каждый делает свой выбор.
Коммуникация в команде
Здесь можно поломать много копий. Что удобнее — Slack или Basecamp? Лучше созваниваться в Teams или Zoom? Однозначного ответа на эти вопросы нет, и здесь особенно трудно посоветовать что-то конкретное, поэтому выбирайте сердцем.
Slack
Мы выбрали Slack для внутренней коммуникации, настроили нужные нам интеграции с другими системами — в среде ИТ и разработки Slack очень популярен, поэтому интегрировать можно много чего. В канал команды в Slack приходят важные алерты: например, о только что сформированном тикете. Через простые команды можно начать срочный звонок в Зуме, создать тикет, получать уведомления по инцидентам и многому другому. Классно — честно, мы были очень рады, когда переехали из Teams в Slack.
Альтернатива: Telegram
До этого мы активно использовали Telegram в службе сопровождения: общались в мессенжере как между собой, так и с заказчиками, применяли бота для срочных клиентских обращений. Все-таки как продукт разработки Telegram можно вполне смело поставить рядом со Slack — постоянно добавляются улучшения и новые фичи, которые делают жизнь легче. С переездом в Slack мы решили унифицировать все каналы коммуникации в команде и в Telegram больше не общаемся столь регулярно, но временами ностальгируем — даже стикерпак запилили. Кто в теме — пользуйте =)
Выбираем хранилище данных для Prometheus: Thanos vs VictoriaMetrics
Всем привет. Ниже представлена расшифровка доклада с Big Monitoring Meetup 4.
Prometheus – система мониторинга различных систем и сервисов, с помощью которой системные администраторы могут собирать информацию о текущих параметрах систем и настраивать оповещения для получения уведомлений об отклонениях в работе систем.
В докладе будет сравнение Thanos и VictoriaMetrics — проектов для долгосрочного хранения метрик Prometheus.
Сначала расскажу про Prometheus. Это система мониторинга, которая собирает метрики с заданных target’ов и сохраняет их в локальное хранилище. Prometheus умеет записывать метрики в удаленное хранилище, умеет генерировать alert’ы и recording rules.
Ограничения 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, который сравнительно дешевый.
Для Thanos кластера нужно оплачивать сервера для Compact, Store Gateway, Query компонентов, которые требует много памяти, ЦПУ для больших объемов данных.
Для VictoriaMetrics нужны сервера для компонентов: либо Single-nod либо для кластерных компонентов, которые в отличие от Thanos компонентов, требует намного меньше ЦПУ, ОЗУ — соответственно будет дешевле.
У Thanos пример внедрения — это Gitlab. Gitlab полностью работает на Thanos. Но там не все так гладко. Если посмотреть по их issues, то можно увидеть что у них постоянно возникают какие-то операционные проблемы с Thanos: не хватает памяти для Store Gateway либо Query компонентов. Им постоянно приходится увеличивать объем памяти.
Из-за этого увеличиваются расходы на решение этих проблем.
Второе внедрение, которое может быть более успешное — это компания Improbable, которые начали разработку Thanos. Они опубликовали исходники Thanos. Improbable — компания, которая занимается разработкой игровых движков.
У VictoriaMetrics публичные примеры внедрения это:
А дальше пошли ноунейм компании, которые я не могу назвать сейчас. Они не дали согласие.
Выводы.
VictoriaMetrics и Thanos решают похожие задачи, но разными способами: