Victoria metrics что это

Обновлено: 05.07.2024

fast, cost-effective and scalable time series database

VictoriaMetrics is a fast, cost-effective and scalable time-series database. It can be used as long-term remote storage for Prometheus.

Другие пакеты, относящиеся к victoria-metrics

dep: adduser добавление и удаление пользователей и групп
dep: libc6 (>= 2.14) [amd64] библиотека GNU C: динамически подключаемые библиотеки
также виртуальный пакет, предоставляемый libc6-udeb dep: libc6 (>= 2.17) [arm64, ppc64el] dep: libc6 (>= 2.27) [riscv64] dep: libc6 (>= 2.29) [ppc64] dep: libc6 (>= 2.4) [не amd64, arm64, ppc64, ppc64el, riscv64]
dep: libgcc-s1 (>= 3.4) [ppc64] вспомогательная библиотека GCC
dep: libgo16 [ppc64] Runtime library for GNU Go applications
dep: libzstd1 (>= 1.4.0) быстрый алгоритм сжатия без потерь

Загрузка victoria-metrics

Загрузить для всех доступных архитектур

Архитектура	Версия	Размер пакета	В установленном виде	Файлы
amd64	1.53.1+ds-1+b5	20 616,0 Кб	79 452,0 Кб	[список файлов]
arm64	1.53.1+ds-1+b5	17 047,0 Кб	73 378,0 Кб	[список файлов]
armel	1.53.1+ds-1+b5	17 510,9 Кб	65 889,0 Кб	[список файлов]
armhf	1.53.1+ds-1+b5	17 491,5 Кб	65 669,0 Кб	[список файлов]
i386	1.53.1+ds-1+b5	18 914,8 Кб	66 358,0 Кб	[список файлов]
mips64el	1.53.1+ds-1+b5	16 396,1 Кб	80 164,0 Кб	[список файлов]
mipsel	1.53.1+ds-1+b5	15 955,7 Кб	74 493,0 Кб	[список файлов]
ppc64 (неофициальный перенос)	1.53.1+ds-1+b1	10 742,2 Кб	79 112,0 Кб	[список файлов]
ppc64el	1.53.1+ds-1+b5	16 425,4 Кб	74 348,0 Кб	[список файлов]
riscv64 (неофициальный перенос)	1.53.1+ds-1+b3	16 868,8 Кб	70 783,0 Кб	[список файлов]
s390x	1.53.1+ds-1+b5	18 427,8 Кб	77 338,0 Кб	[список файлов]

Эта страница также доступна на следующих языках (Как установить язык по умолчанию):

VictoriaMetrics - проект для долгосрочного хранения метрик Prometheus, InfluxDB, OpenTSDB, Graphite [Источник 1] .

Содержание

Назначение

Сначала необходимо понять, что такое Prometheus. Prometheus — это база данных временных рядов. Это система мониторинга, которая собирает метрики с заданных целей и сохраняет их в локальное хранилище. Prometheus умеет записывать метрики в удаленное хранилище, умеет генерировать alert'ы и recording rules. Prometheus мониторит самые разные системы: серверы, базы данных, отдельные виртуальные машины. Однако у Prometheus есть ряд проблем:

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

Для решения этих проблем при использовании Prometheus и используется VictoriaMetrics.

Кластерная версия

VictoriaMetrics - это быстрая, экономичная и масштабируемая база данных временных рядов. Его можно использовать в качестве долгосрочного удаленного хранилища для хранения метрик Prometheus, InfluxDB, OpenTSDB, Graphite. У VictoriaMetrics есть две версии - одноузловая и кластерная [Источник 3] . Рекомендуется использовать версию с одним узлом вместо версии кластера для скорости загрузки менее миллиона точек данных в секунду. Версия с одним узлом прекрасно масштабируется в зависимости от количества ядер ЦП, ОЗУ и доступного дискового пространства. Версия с одним узлом проще в настройке и эксплуатации по сравнению с версией кластера, поэтому разработчик советует подумать дважды, прежде чем придерживаться версии кластера.

Архитектура и особенности кластерной версии:

VM storage-хранит данные
VM insert-проксирует полученные данные в сегменты хранилища виртуальных машин с помощью последовательного хэширования
VM select-выполняет входящие запросы с использованием данных из хранилища виртуальной машины

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

Не так давно мы серьезно обновили стек инструментов, которые используют наши системные администраторы в повседневной работе, и готовы поделиться списком. Этому предшествовали годы использования различных решений, которые также не стояли на месте и развивались параллельно нашей работе — как в хорошую, так и в плохую, на наш взгляд, сторону. В этой статье я разберу тулсет, который сформировался у нас на начало 2021 года, расскажу, чем он хорош, и объясню плюсы и минусы его альтернатив.

Для кого пригодится?

Традиционно, снова вернемся к базовым определениям: кого можно назвать системным администратором и кого считаем им мы в NGENIX. В прошлом году я рассказывал, чем занимаются каждый день наши ребята, а также порефлексировал на тему путей карьерного развития системного администратора и о том, почему его не стоит путать с эникейщиком.

Поэтому набор инструментов, которые инженеры используют каждый день, прежде всего связан с коммуникацией в команде и с заказчиком, c мониторингом состояния веб-ресурса, системой алертов об отклонениях в работе администрируемых систем — словом, со всем, что поможет настроить самый полный «центр управления полетами» и иметь представление о том, как работают веб-ресурсы в реальном времени и где им нужно помочь.

Автоматизация хелпдеска

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

Zendesk

Мы используем Zendesk — это, наверное, один из самых знаменитых SaaS-хелпдесков среди систем обработки обращений клиентов. Zendesk имеет интуитивный интерфейс, очень широкие возможности интеграции, поддерживает REST, JSON, RSS, email, различные виджеты. Заказчик может создать тикет через почту, веб-интерфейс или через другие каналы — например, есть удобная интеграция с Telegram. Мы также интегрировали Zendesk с нашей системой мониторинга для соблюдения SLA, а также телефонией.

Альтернатива: Jira Service Desk

Функционально нативный хелпдеск Jira практически идентичен Zendesk. Это онлайн-сервис обработки тикетов от Atlassian, который предлагает огромное количество настроек и интеграций, а также большие возможности для масштабирования. Выбирая между JIRA Service Desk и Zendesk, скорее всего, вам стоит обратить внимание на простоту интеграции с имеющимися инструментами, потому что миграция может быть долгой и сложной, что очень неудобно, если вы живете в мире жесткого SLA.

Мониторинг

Это важнейшая часть нашего воркфлоу: служба сопровождения и технической поддержки должна иметь полное и наглядное представление о том, что происходит с системами клиентов и нашей собственной инфраструктурой, а также получать своевременные уведомления об инцидентах и состоянии систем. В конце прошлого года мы провели ревизию инструментов мониторинга: выросло количество систем и ПО, которые нужно мониторить; из-за роста нагрузки пришло время разделиться на несколько команд; требовалось более точно и быстро реагировать на инциденты.

Cube Dev , Удалённо , От 8000 $

Инструменты мониторинга, которые мы использовали раньше, в этих условиях нам уже не подходили: отслеживать изменения стало сложнее, на новых объемах вскрылись ограничения, обусловленные легаси-системами, возникла потребность в более гибком алертинге. После того, как мы сменили стек инструментов, мы смогли унифицировать работу трех составляющих системы мониторинга (сбор данных, их визуализацию в графики и дэшборды, алерты), избавились таким образом от большой доли легаси, получили больше прозрачности, масштабируемости, воспроизводимости.

Мониторинг: сбор данных

Мы используем в работе 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

База данных для логирования

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 больше не общаемся столь регулярно, но временами ностальгируем — даже стикерпак запилили. Кто в теме — пользуйте =)

Добрый день, меня зовут Николай Храмчихин. Сегодня я расскажу о vmagent ’е, нашем комбайне для мониторинга .

В ответ на все эти проблемы был разработан vmagent как легковесная замена Prometheus .

Помимо этого он может фильтровать собранные метрики . Есть определенный набор правил, по которым это можно сделать, и модифицировать имена метрик с их лейблами.

Конечно же он может сохранять метрики в удаленное хранилище, как это делал Prometheus , по remote_write -протоколу. С его помощью можно настроить репликацию в несколько хранилищ, главное, чтобы они понимали протокол. Например, можно записывать в VictoriaMetrics , в vmagent , в Cortex и в некоторые другие удаленные хранилища. При недоступности хранилища vmagent не теряет метрики, у него есть дисковый буфер (на каждое удаленное хранилище отдельный).

Самое главное: он использует небольшое количество ресурсов CPU и оперативной памяти . Конечно же, он легко устанавливается: у него всего один исполняемый файл без внешних зависимостей.

Помимо этого, у vmagent есть дополнительные фичи. Это, в первую очередь, кластеризация . Можно разделить таргеты между разными vmagent ’ами при помощи простой конфигурации. Это бывает полезно, когда не хватает ресурсов одного vmagent ’a для сбора метрик, либо можно таким образом распределить точки отказа: если одна виртуальная машина с vmagent ’ом вышла из строя, можно продолжить собирать часть метрик со второй машины. Соответственно, достаточно указать количество агентов в кластере и каждому из них присвоить уникальный номер.

Где кластеризация, там уже может быть и репликация . И да, vmagent умеет в репликацию. Настроив replication factor , можно собирать несколько метрик с разных таргетов.

Список принимаемых форматов метрик:

Та самая фильтрация метрик, о которой я хотел рассказать. Она осуществляется с помощью Prometheus-compatible relabeling , то есть поддерживается весь тот синтаксис, который предоставляет Prometheus для релейблинга . Можно фильтровать по имени метрики, по значению тэгов (лейблов) и по регулярным выражениям. Модифицировать можно с тем же совместимым с Prometheus -форматом. Можно переименовать метрики, добавить новые лейблы, изменить или удалить их.

Где может происходить фильтрация и модификация метрик? В vmagent’е она может происходить практически везде . Можно настроить в конфигурационном файле на уровне relable_configs , в этом случае релейбелинг будет применяться, когда vmagent определяет таргеты, получая список таргетов от Kubernetes ’а.

Во время сбора метрик можно настроить metric_relabel_configs . На этом этапе уже не будут доступны металейблы от Kubernetes ’а. Это нужно делать немного заранее. Перед записью в remote storage тоже можно делать релейбелинг, как для каждого хранилища, так и глобально для всех. И да, релейбелинг работает как для push-метрик, так и для pull.

О других возможностях vmagent ’a. Он может ограничивать скорость записи метрик в удаленное хранилище . Настраивается это для каждого хранилища отдельно или глобально для всех. Это бывает полезно, когда удаленное хранилище недоступно, vmagent забуферизировал метрики, и ему нужно записать большое количество метрик в удаленное хранилище, что может его перегрузить. В данном случае можно ограничить количество записываемых метрик в секунду.

Для настройки алертинга, если вы используете его вместе с Prometheus , можно запустить vmalert , он понимает алерты в Prometheus -совместимом формате и умеет отправлять их в Alertmanager .

Также vmagent можно использовать для репликации между несколькими ЦОДами для обеспечения отказоустойчивости. Можно сконфигурировать несколько -remoteWrite.url ’ов, и, соответственно, между ЦОДами будут реплицироваться данные.

Фильтрация и запись определенных метрик в разные хранилища. Да, один из популярных вопросов, как сделать в VictoriaMetrics разное время хранения разных метрик (retention) в зависимости от лейбла. У нас есть открытый issue, как это сделать на уровне одной базы данных, но сейчас это можно реализовать, запустив две разных VictoriaMetrics с разным временем хранения и добавив для одной из них фильтр, который будет сохранять метрики только с определенным лейблом. А в другую БД писать все метрики. Сверху можно поставить какой-нибудь Promxy или что-то подобное, чтобы он опрашивал две VictoriaMetrics и уже показывал результат в Grafan ’е.

Также можно переводить метрики в “человекочитаемый” формат. Если странный экспортер отдает метрики вот в таком странном формате “ foo_temp ”, с помощью трансформации и релейблинга сделать более приемлемый формат с понятной температурой и названием компании.

Какие у нас планы на будущее? Это поддержка statsd и DogStatsD -протоколов. И мы очень хотели бы разработать новый протокол передачи данных между vmagent и VictoriaMetrics , который потреблял бы гораздо меньше пропускную способность и ее было бы удобнее эксплуатировать в таких случаях, как кассы и спутники. И мы всегда готовы реализовать ваши фичи.

pull и push модели для сбора метрик
Фильтрация и редактирование метрик
Репликация
Буферизация на диск при отсутствии связи с удаленным хранилищем
Простота использования
Легковесность
Open Source

ВОПРОСЫ К СПИКЕРУ:

Читайте также: