Русский
Русский
English
Статистика
Реклама

Victoriametrics

Перевод Высокопроизводительный TSDB benchmark VictoriaMetrics vs TimescaleDB vs InfluxDB

26.06.2020 12:10:59 | Автор: admin

VictoriaMetrics, TimescaleDB и InfluxDB были сравнены в предыдущей статье по набору данных с миллиардом точек данных, принадлежащих 40K уникальным временным рядам.


Несколько лет назад была эпоха Zabbix. Каждый bare metal сервер имел не более нескольких показателей использование процессора, использование оперативной памяти, использование диска и использование сети. Таким образом метрики с тысяч серверов могут поместиться в 40 тысяч уникальных временных рядов, а Zabbix может использовать MySQL в качестве бэкенда для данных временных рядов :)


В настоящее время один node_exporter с конфигурациями по умолчанию предоставляет более 500 метрик на среднем хосте. Существует множество экспортеров для различных баз данных, веб-серверов, аппаратных систем и т. д. Все они предоставляют множество полезных показателей. Все больше и больше приложений начинают выставлять различные показатели на себя. Существует Kubernetes с кластерами и pod-ами, раскрывающими множество метрик. Это приводит к тому, что серверы выставляют тысячи уникальных метрик на хост. Таким образом, уникальный временной ряд 40K больше не является высокой мощностью. Он становится мейнстримом, который должен быть легко обработан любой современной TSDB на одном сервере.


Что такое большое количество уникальных временных рядов на данный момент? Наверное, 400К или 4М? Или 40м? Давайте сравним современные TSDBs с этими цифрами.


Установка бенчмарка


TSBS это отличный инструмент бенчмаркинга для TSDBs. Он позволяет генерировать произвольное количество метрик, передавая необходимое количество временных рядов, разделенных на 10 флаг -scale (бывший -scale-var). 10 это количество измерений (метрик), генерируемых на каждом хосте, сервере. Следующие наборы данных были созданы с помощью TSBS для бенчмарка:


  • 400K уникальный временной ряд, 60 секунд интервал между точками данных, данные охватывают полные 3 дня, ~1.7B общее количество точек данных.


  • 4M уникальный временной ряд, интервал 600 секунд, данные охватывают полные 3 дня, ~1.7B общее количество точек данных.


  • 40M уникальный временной ряд, интервал 1 час, данные охватывают полные 3 дня, ~2.8 B общее количество точек данных.



Клиент и сервер были запущены на выделенных экземплярах n1-standard-16 в облаке Google. Эти экземпляры имели следующие конфигурации:


  • vCPUs: 16


  • ОЗУ: 60 ГБ


  • Хранение: стандартный жесткий диск емкостью 1 ТБ. Он обеспечивает пропускную способность чтения/записи 120 Мбит/с, 750 операций чтения в секунду и 1,5К операций записи в секунду.



TSDBs были извлечены из официальных образов docker и запущены в docker со следующими конфигурациями:


  • VictoriaMetrics:


    docker run -it --rm -v /mnt/disks/storage/vmetrics-data:/victoria-metrics-data -p 8080:8080 valyala/victoria-metrics
    

  • Значения InfluxDB (- e необходимы для поддержки высокой мощности. Подробности смотрите в документации):


    docker run -it --rm -p 8086:8086 \-e INFLUXDB_DATA_MAX_VALUES_PER_TAG=4000000 \-e INFLUXDB_DATA_CACHE_MAX_MEMORY_SIZE=100g \-e INFLUXDB_DATA_MAX_SERIES_PER_DATABASE=0 \-v /mnt/disks/storage/influx-data:/var/lib/influxdb influxdb
    

  • TimescaleDB (конфигурация была принята из этого файла):



MEM=`free -m | grep "Mem" | awk {print $7}`let "SHARED=$MEM/4"let "CACHE=2*$MEM/3"let "WORK=($MEM-$SHARED)/30"let "MAINT=$MEM/16"let "WAL=$MEM/16"docker run -it  rm -p 5432:5432 \--shm-size=${SHARED}MB \-v /mnt/disks/storage/timescaledb-data:/var/lib/postgresql/data \timescale/timescaledb:latest-pg10 postgres \-cmax_wal_size=${WAL}MB \-clog_line_prefix="%m [%p]: [%x] %u@%d" \-clogging_collector=off \-csynchronous_commit=off \-cshared_buffers=${SHARED}MB \-ceffective_cache_size=${CACHE}MB \-cwork_mem=${WORK}MB \-cmaintenance_work_mem=${MAINT}MB \-cmax_files_per_process=100

Загрузчик данных был запущен с 16 параллельными потоками.


Эта статья содержит только результаты для контрольных показателей вставки. Результаты выборочного бенчмарка будут опубликованы в отдельной статье.


400К уникальных временных рядов


Давайте начнем с простых элементов 400К. Результаты бенчмарка:


  • VictoriaMetrics: 2,6М точек данных в секунду; использование оперативной памяти: 3 ГБ; окончательный размер данных на диске: 965 МБ


  • InfluxDB: 1.2M точек данных в секунду; использование оперативной памяти: 8.5 GB; окончательный размер данных на диске: 1.6 GB


  • Timescale: 849K точек данных в секунду; использование оперативной памяти: 2,5 ГБ; окончательный размер данных на диске: 50 ГБ



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


Ниже приведены графики использования процессора (CPU) для каждого из TSDBs во время бенчмарка:



Выше скриншот: VictoriaMetrics Загрузка CPU при тесте вставки для уникальной метрики 400K.



Выше скриншот: InfluxDB Загрузка CPU при тесте вставки для уникальной метрики 400K.



Выше скриншот: TimescaleDB Загрузка CPU при тесте вставки для уникальной метрики 400K.


VictoriaMetrics использует все доступные vCPUs, в то время как InfluxDB недостаточно использует ~2 из 16 vCPUs.


Timescale использует только 3-4 из 16 vCPUs. Высокие доли iowait и system на TimescaleDB графике временных масштабов указывают на узкое место в подсистеме ввода-вывода (I/O). Давайте посмотрим на графики использования пропускной способности диска:



Выше скриншот: VictoriaMetrics Использование пропускной способности диска при тесте вставки для уникальных показателей 400K.



Выше скриншот: InfluxDB Использование пропускной способности диска при тесте вставки для уникальных показателей 400K.



Выше скриншот: TimescaleDB Использование пропускной способности диска при тесте вставки для уникальных показателей 400K.


VictoriaMetrics записывает данные со скоростью 20 Мбит/с с пиками до 45 Мбит/с. Пики соответствуют большим частичным слияниям в дереве LSM.


InfluxDB записывает данные со скоростью 160 МБ/с, в то время как 1 ТБ диск должен быть ограничен пропускной способностью записи 120 МБ/с.


TimescaleDB ограничена пропускной способностью записи 120 Мбит/с, но иногда она нарушает этот предел и достигает 220 Мбит/с в пиковых значениях. Эти пики соответствуют провалам недостаточной загрузки процессора на предыдущем графике.


Давайте посмотрим на графики использования ввода-вывода (I/O):



Выше скриншот: VictoriaMetrics Использование ввода-вывода при тесте вставки для 400K уникальных метрик.



Выше скриншот: InfluxDB Использование ввода-вывода при тесте вставки для 400K уникальных метрик.



Выше скриншот: TimescaleDB Использование ввода-вывода при тесте вставки для 400K уникальных метрик.


Теперь ясно, что TimescaleDB достигает предела ввода-вывода, поэтому он не может использовать оставшиеся 12 vCPUs.


4M уникальные временные ряды


4M временные ряды выглядят немного вызывающе. Но наши конкуренты успешно сдают этот экзамен. Результаты бенчмарка:


  • VictoriaMetrics: 2,2М точек данных в секунду; использование оперативной памяти: 6 ГБ; окончательный размер данных на диске: 3 ГБ.


  • InfluxDB: 330К точек данных в секунду; использование оперативной памяти: 20,5 ГБ; окончательный размер данных на диске: 18,4 ГБ.


  • TimescaleDB: 480K точек данных в секунду; использование оперативной памяти: 2,5 ГБ; окончательный размер данных на диске: 52 ГБ.



Производительность InfluxDB упала с 1,2 млн точек данных в секунду для 400К временного ряда до 330 тыс. точек данных в секунду для 4M временного ряда. Это значительная потеря производительности по сравнению с другими конкурентами. Давайте посмотрим на графики использования процессора, чтобы понять первопричину этой потери:



Выше скриншот: VictoriaMetrics Использование CPU при тесте вставки для уникального временного ряда 4M.



Выше скриншот: InfluxDB Использование CPU при тесте вставки для уникального временного ряда 4M.



Выше скриншот: TimescaleDB Использование CPU при тесте вставки для уникального временного ряда 4M.


VictoriaMetrics использует почти всю мощность процессора (CPU). Снижение в конце соответствует оставшимся LSM слияниям после вставки всех данных.


InfluxDB использует только 8 из 16 vCPUs, в то время как TimsecaleDB использует 4 из 16 vCPUs. Что общего у их графиков? Высокая доля iowait, что, опять же, указывает на узкое место ввода-вывода.


TimescaleDB имеет высокую долю system. Полагаем, что высокая мощность привела ко многим системным вызовам или ко многим minor page faults.


Давайте посмотрим на графики пропускной способности диска:



Выше скриншот: VictoriaMetrics Использование полосы пропускания диска для вставки 4M уникальных метрик.



Выше скриншот: InfluxDB Использование полосы пропускания диска для вставки 4M уникальных метрик.



Выше скриншот: TimescaleDB Использование полосы пропускания диска для вставки 4M уникальных метрик.


VictoriaMetrics достигали предела 120 МБ/с в пик, в то время как средняя скорость записи составляла 40 МБ/с. Вероятно, во время пика было выполнено несколько тяжелых слияний LSM.


InfluxDB снова выжимает среднюю пропускную способность записи 200 МБ/с с пиками до 340 МБ/с на диске с ограничением записи 120 МБ/с :)


TimescaleDB больше не ограничена диском. Похоже, что он ограничен чем-то еще, связанным с высокой долей системной загрузки CPU.


Давайте посмотрим на графики использования IO:



Выше скриншот: VictoriaMetrics Использование ввода-вывода во время теста вставки для уникального временного ряда 4M.



Выше скриншот: InfluxDB Использование ввода-вывода во время теста вставки для уникального временного ряда 4M.



Выше скриншот: TimescaleDB Использование ввода-вывода во время теста вставки для уникального временного ряда 4M.


Графики использования IO повторяют графики использования полосы пропускания диска InfluxDB ограничен IO, в то время как VictoriaMetrics и TimescaleDB имеют запасные ресурсы ввода-вывода IO.


40М уникальные тайм серии


40М уникальные временные ряды были слишком большими для InfluxDB :(


Результаты бечмарка:


  • VictoriaMetrics: 1,7М точек данных в секунду; использование оперативной памяти: 29 ГБ; использование дискового пространства: 17 ГБ.


  • InfluxDB: не закончил, потому что для этого требовалось более 60 ГБ оперативной памяти.


  • TimescaleDB: 330К точек данных в секунду, использование оперативной памяти: 2,5 ГБ; использование дискового пространства: 84GB.



TimescaleDB показывает исключительно низкое и стабильное использование оперативной памяти 2,5 ГБ столько же, сколько и для уникальных метрик 4M и 400K.


VictoriaMetrics медленно увеличивались со скоростью 100 тысяч точек данных в секунду, пока не были обработаны все 40М метрических имен с метками. Затем он достиг устойчивой скорости вставки 1,5-2,0М точек данных в секунду, так что конечный результат составил 1,7М точек данных в секунду.


Графики для 40М уникальных временных рядов аналогичны графикам для 4М уникальных временных рядов, поэтому давайте их пропустим.


Выводы


  • Современные TSDBs способны обрабатывать вставки для миллионов уникальных временных рядов на одном сервере. В следующей статье мы проверим, насколько хорошо TSDBs выполняет выбор по миллионам уникальных временных рядов.


  • Недостаточная загрузка процессора обычно указывает на узкое место ввода-вывода. Кроме того, это может указывать на слишком грубую блокировку, когда одновременно может работать только несколько потоков.


  • Узкое место ввода-вывода действительно существует, особенно в хранилищах без SSD, таких как виртуализированные блочные устройства облачных провайдеров.


  • VictoriaMetrics обеспечивает наилучшую оптимизацию для медленных хранилищ с низким уровнем ввода-вывода. Он обеспечивает наилучшую скорость и наилучшую степень сжатия.



Загрузите односерверный образ VictoriaMetrics и попробуйте его на своих данных. Соответствующий статический двоичный файл доступен на GitHub.


Подробнее о VictoriaMetrics читайте в этой статье.


Обновление: опубликована статья, сравнивающая производительность вставки VictoriaMetrics с InfluxDB с воспроизводимыми результатами.


Обновление#2: Читайте также статью о вертикальной масштабируемости VictoriaMetrics vs InfluxDB vs TimescaleDB.


Обновление #3: VictoriaMetrics теперь с открытым исходным кодом!


Телеграм чат: https://t.me/VictoriaMetrics_ru1

Подробнее..

Перевод Prometheus и VictoriaMetrics отказоустойчивая инфраструктура для хранения метрик

08.12.2020 14:22:23 | Автор: admin

В статье мой коллега Luca Carboni, DevOps Engineer из амстердамского офиса Miro, рассказывает, как выглядит наша инфраструктура для хранения метрик. Все компоненты в ней соответствуют принципам высокой доступности (High Availability) и отказоустойчивости (Fault Tolerance), имеют чёткую специализацию, могут хранить данные долгое время и оптимальны с точки зрения затрат.

Стек, о котором пойдёт речь: Prometheus, Alertmanager, Pushgateway, Blackbox exporter, Grafana и VictoriaMetrics.

Настройка High Availability и Fault Tolerance для Prometheus

Сервер Prometheus может использовать механизм federation, чтобы собирать метрики с других серверов Prometheus. Он хорошо работает, если вам нужно открыть часть метрик инструментам вроде Grafana или нужно собрать в одном месте метрики разного типа: например, бизнес-метрики и сервисные метрики с разных серверов.

Такой подход широко применяется, но не соответствует принципам высокой доступности и отказоустойчивости. Мы работаем лишь с частью метрик, а если один из серверов Prometheus перестанет отвечать, то данные за этот период собраны не будут.

Готового встроенного решения этой проблемы не существует, но для её решения не обязательно настраивать сложные кластеры и придумывать сложные стратегии взаимодействия серверов. Достаточно продублировать конфигурационный файл (prometheus.yml) на двух серверах, чтобы они собирали одни и те же метрики одинаковым способом. При этом сервер A будет дополнительно мониторить сервер B и наоборот.

Старый добрый принцип избыточности прост в реализации и надежён. Если мы добавим к нему инструмент IaC (инфраструктура как код) вроде Terraform и систему управления конфигурациями (CM) вроде Ansible, то этой избыточностью будет легко управлять и легко её поддерживать. При этом можно не дублировать большой и дорогой сервер, проще дублировать маленькие серверы и хранить на них только краткосрочные метрики. К тому же, небольшие серверы проще воссоздавать.Alertmanager, Pushgateway, Blackbox, экспортёры

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

Alertmanager может работать в кластерной конфигурации, умеет дедуплицировать данные с разных серверов Prometheus и может связываться с другими копиями Alertmanager, чтобы не отправлять несколько одинаковых оповещений. Поэтому можно установить по одной копии Alertmanager на оба сервера, которые мы продублировали: Prometheus A и Prometheus B. И не забываем про инструменты IaC и CM, чтобы управлять конфигурацией Alertmanager при помощи кода.

Экспортёры устанавливаются на конкретные системы-источники метрик, их дублировать не нужно. Единственное, что нужно сделать разрешить серверам Prometheus A и Prometheus B подключаться к ним.

С Pushgateway простым дублированием сервером не обойтись, потому что мы получим дуплицирование данных. В этом случае нам нужно иметь единую точку для приёма метрик. Для достижения высокой доступности и отказоустойчивости можно продублировать Pushgateway и настроить DNS Failover или балансировщик, чтобы при отказе одного сервера все запросы шли на другой (конфигурация active/passive). Таким образом у нас будет единая точка доступа для всех процессов, несмотря на наличие нескольких серверов.

Blackbox мы также можем продублировать для серверов Prometheus A и Prometheus B.

Итого, у нас есть два сервера Prometheus, две копии Alertmanager, связанные друг с другом, два Pushgateway в конфигурации active/passive и два Blackbox. Высокая доступность и отказоустойчивость достигнуты.

Нет особого смысла использовать только эти копии для сбора всех метрик сервиса. Сервис может быть расположен на нескольких VPC (Virtual Private Cloud), которые могут находиться в разных регионах, принадлежать разным аккаунтам и провайдерам. У вас даже могут быть собственные серверы. В этих случаях копии станут очень большими, а значит их станет сложнее чинить. Распространённая практика достижения высокой доступности и отказоустойчивости здесь иметь отдельный набор приложений для каждой части инфраструктуры. Принципы разделения инфраструктуры на части зависят от ваших потребностей, настроек сети и безопасности, доверия между командами и так далее.

В итоге мы имеем относительно небольшие копии Prometheus, продублированные вместе со всеми компонентами, упомянутыми выше. У нас есть код, который может их быстро воссоздать. И нам не страшен выход из строя одного компонента в каждой группе. Это определенно лучше плана "скрестить пальцы и надеяться, что ничего не упадёт".

VictoriaMetrics для долгосрочного хранения данных

Мы настроили Prometheus и его экосистему для достижения высокой доступности и отказоустойчивости. У нас есть несколько небольших групп Prometheus со связанными компонентами, каждая из которых решает задачи в своей части инфраструктуры. Это отлично работает для хранения данных в краткосрочном периоде. Для решения большинства задач нам достаточно хранения метрик в течение 10 дней. Что делать, если нужно хранить данные дольше? Например, когда требуется найти связь между разными периодами неделями или месяцами. Prometheus может работать с долгосрочными данными, но стоимость этого будет очень высокой из-за того, что инструменту требуется иметь к ним быстрый доступ.

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

В этой статье я не буду сравнивать инструменты между собой, расскажу только про наш опыт работы с VictoriaMetrics.

Настройка кластерной версии

VictoriaMetrics доступен в двух версиях: обычная всё-в-одном (single-node version) и кластерная (cluster version). В обычной версии все компоненты объединены в одно приложение, поэтому инструмент проще настраивать, но масштабировать можно только вертикально. Кластерная версия разбита на отдельные компоненты, каждый из которых можно масштабировать вертикально и горизонтально.

Обычная версия хорошее и стабильное решение. Но мы любим всё усложнять (хех), поэтому выбрали кластерную версию.

Кластерная версия VictoriaMetrics состоит из трёх основных компонентов: vmstorage (хранение данных), vminsert (запись данных в хранилище) и vmselect (выборка данных из хранилища). В таком виде инструмент получается очень гибким, vminsert и vmselect выступают как своего рода прокси.

У vminsert есть множество полезных настраиваемых параметров. Для целей этой статьи важно то, что его можно продублировать любое количество раз и поставить перед этими копиями балансировщик нагрузки, чтобы иметь единую точку приёма данных. У vminsert нет состояния (stateless), поэтому с ним легко работать, легко дублировать, его удобно использовать в неизменяемых инфраструктурах и при автоматическом масштабировании.

Самые важные параметры, которые нужно указать для vminsert это адреса хранилищ (storageNode) и количество хранилищ, на которые нужно реплицировать данные (replicationFactor=N, где N количество копий vmstorage). Но кто будет слать данные на балансировщик перед vminsert? Это будет делать Prometheus, если мы укажем адрес балансировщика в настройках remote_write.

vmstorage пожалуй, самый важный компонент VictoriaMetrics. В отличие от vminsert и vmselect, vmstorage имеет состояние (stateful), и каждая его копия ничего не знает о других копиях. Каждый запущенный vmstorage считает себя изолированным компонентом, он оптимизирован для облачных хранилищ с большим временем отклика (IO latency) и небольшим количеством операций в секунду (IOPS), что делает его существенно дешевле того способа хранения данных, который использует Prometheus.

Самые важные настройки vmstorage:

  • storageDataPath путь на диске, по которому будут храниться данные;

  • retentionPeriod срок хранения данных;

  • dedup.minScrapeInterval настройка дедупликации (считать дубликатами те записи, разница между временными метками которых меньше указанного значения).

У каждой копии vmstorage свои данные, но благодаря параметру replicationFactor, который мы указали для vminsert, одни и те же данные будут отсылаться в несколько (N) хранилищ.

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

vmselect отвечает за выборку данных из хранилищ. Его легко дублировать, перед созданными копиями тоже можно поставить балансировщик нагрузки, чтобы иметь один адрес для приёма запросов. Через этот балансировщик можно получить доступ ко всем данным, которые были собраны с нескольких групп Prometheus, и эти данные будут доступны столько времени, сколько вам нужно. Основным потребителем этих данных, скорее всего, будет Grafana. Как и vminsert, vmselect можно использовать при автоматическом масштабировании.

Настройка высокой доступности и отказоустойчивости для Grafana

Grafana умеет работать как с метриками, которые собирает Prometheus, так и с метриками, которые хранятся в VictoriaMetrics. Это возможно благодаря тому, что VictoriaMetrics поддерживает кроме собственного языка запросов (MetricsQL) ещё и PromQL, используемый Prometheus. Попробуем достичь высокой доступности и отказоустойчивости для Grafana.

По умолчанию Grafana использует SQLite для хранения состояния. SQLite удобен для разработки, отлично подходит для мобильных приложений, но не очень хорош для отказоустойчивости и высокой доступности. Для этих целей лучше использовать обычную СУБД. Например, мы можем развернуть PostgreSQL на Amazon RDS, который использует технологию Multi-AZ для обеспечения доступности, и это решит нашу главную проблему.

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

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

Дальше остаётся соединить Grafana с VictoriaMetrics а точнее, с балансировщиком перед vmselect, указав Prometheus в качестве источника данных. На этом нашу инфраструктуру для мониторинга можно считать завершённой.

***

Теперь все компоненты инфраструктуры соответствуют принципам высокой доступности и отказоустойчивости, имеют чёткую специализацию, могут хранить данные долгое время и оптимальны с точки зрения затрат. Если мы захотим хранить данные ещё дольше, мы можем по расписанию автоматически делать снимки vmstorage и отправлять их в хранилище, совместимое с Amazon S3.

Это всё, что касается метрик. Нам ещё нужна система работы с логами, но это уже совсем другая история.

Список инструментов:

Оригинал статьи в англоязычном блоге Miro.

Подробнее..

Перевод Как в Smarkets улучшили мониторинг для своих Kubernetes-кластеров

17.11.2020 10:12:56 | Автор: admin
Прим. перев.: автор этой статьи ведущий инженер по инфраструктуре в Smarkets, что позиционирует себя как одну из самых прибыльных [по доходам на каждого сотрудника] компаний в Европе. Работая с большой и чувствительной к мониторингу инфраструктурой на базе Kubernetes, инженеры компании нашли своё счастье с VictoriaMetrics, которая помогла им решить проблемы с Prometheus, возникшие после добавления новых K8s-кластеров.

Мониторинг внутренних endpoint'ов и API Kubernetes может быть проблематичным, особенно если стоит задача использовать автоматизированную инфраструктуру как сервис. Мы в Smarkets еще не достигли этой цели, но, к счастью, уже довольно близки к ней. Я надеюсь, что наш опыт в этой области поможет и другим реализовать нечто подобное.

Мы всегда мечтали о том, чтобы разработчики прямо из коробки получали возможность мониторинга для любого приложения или сервиса. До перехода на Kubernetes эта задача выполнялась либо с помощью метрик Prometheus, либо с помощью statsd, который пересылал статистику на базовый хост, где она конвертировалась в метрики Prometheus. Наращивая применение Kubernetes, мы начали разделять кластеры, и нам захотелось сделать так, чтобы разработчики могли экспортировать метрики напрямую в Prometheus через аннотации к сервисам. Увы, эти метрики были доступны только внутри кластера, то есть их нельзя было собирать глобально.

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

Отправная точка


Для метрик, связанных с Kubernetes, мы используем два сервиса, предоставляющих метрики:

  • kube-state-metrics генерирует метрики для объектов Kubernetes на основе информации от API-серверов K8s;
  • kube-eagle экспортирует метрики Prometheus для podов: их request'ы, limit'ы, использование.

Можно (и в течение некоторого времени мы делали это) выставлять сервисы с метриками за пределы кластера или открывать прокси-подключение к API, однако оба варианты не были идеальны, поскольку замедляли работу и не обеспечивали должную независимость и безопасность систем.

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



Проблемы


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

При анализе 2-часового блока Prometheus:

  • 1,3 млн метрик;
  • 383 имени лейблов;
  • максимальная кардинальность на метрику 662 000 (больше всего проблем именно из-за этого).

Столь высокая кардинальность преимущественно связана с выставлением наружу таймеров statsd, включающих HTTP-пути. Мы знаем, что подобная реализация не идеальна, однако эти метрики используются для отслеживания критических ошибок в канареечных развертываниях.

В спокойное время собиралось около 40 000 метрик в секунду, однако их число могло вырастать до 180 000 в отсутствии каких-либо проблем.

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

Другая проблема состояла в том, что в условиях, когда на каждом экземпляре Prometheus хранились данные за три месяца, время запуска (WAL replay) оказывалось очень высоким, и это обычно приводило к тому, что тот же самый запрос направлялся на второй экземпляр Prometheus и ронял уже его.

Чтобы устранить эти проблемы, мы внедрили Thanos и Trickster:

  • Thanos позволил хранить меньше данных в Prometheus и сократил число инцидентов, вызванных чрезмерным использованием памяти. Рядом с контейнером Prometheus Thanos запускает sidecar-контейнер, который складирует блоки данных в S3, где их затем сжимает thanos-compact. Таким образом, с помощью Thanos'а было реализовано долгосрочное хранение данных за пределами Prometheus.
  • Trickster, со своей стороны, выступил обратным прокси и кэшем для баз данных временных рядов. Он позволил нам закэшировать до 99,53% всех запросов. Большинство запросов поступает от панелей мониторинга, запущенных на рабочих станциях/ТВ, от пользователей с открытыми контрольными панелями и от алертов. Прокси, способный выдавать только дельту во временных рядах, отлично подходит для подобной нагрузки.



У нас также начали возникать проблемы при сборе kube-state-metrics из-за пределов кластера. Как вы помните, частенько приходилось обрабатывать до 180 000 метрик в секунду, а сбор тормозил уже при выставлении 40 000 метрик в единственном ingressе kube-state-metrics. У нас установлен целевой 10-секундный интервал для сбора метрик, а в периоды высокой нагрузки этот SLA часто нарушался удаленным сбором kube-state-metrics или kube-eagle.

Варианты


Размышляя над тем, как улучшить архитектуру, мы рассмотрели три различных варианта:

  1. Prometheus + Cortex (https://github.com/cortexproject/cortex);
  2. Prometheus + Thanos Receive (https://thanos.io);
  3. Prometheus + VictoriaMetrics (https://github.com/VictoriaMetrics/VictoriaMetrics).

Подробную информацию о них и сравнение характеристик можно найти в интернете. В нашем конкретном случае (и после тестов на данных с высокой кардинальностью) явным победителем оказалась VictoriaMetrics.

Решение


Prometheus


Пытаясь улучшить описанную выше архитектуру, мы решили изолировать каждый кластер Kubernetes как отдельную сущность и сделать Prometheus его частью. Теперь любой новый кластер идет со включенным из коробки мониторингом и метриками, доступными в глобальных dashboard'ах (Grafana). Для этого сервисы kube-eagle, kube-state-metrics и Prometheus были интегрированы в кластеры Kubernetes. Затем Prometheus конфигурировался с помощью внешних лейблов, идентифицирующих кластер, а remote_write указывал на insert в VictoriaMetrics (см. ниже).

VictoriaMetrics


База данных временных рядов VictoriaMetrics реализует протоколы Graphite, Prometheus, OpenTSDB и Influx. Она не только поддерживает PromQL, но и дополняет его новыми функциями и шаблонами, позволяя избежать рефакторинга запросов Grafana. Кроме того, ее производительность просто потрясает.

Мы развернули VictoriaMetrics в режиме кластера и разбили на три отдельных компонента:

1. VictoriaMetrics storage (vmstorage)


Этот компонент отвечает за хранение данных, импортированных vminsert. Мы ограничились тремя репликами этого компонента, объединенными в StatefulSet Kubernetes.

./vmstorage-prod \        -retentionPeriod 3 \        -storageDataPath /data \        -http.shutdownDelay 30s \        -dedup.minScrapeInterval 10s \        -http.maxGracefulShutdownDuration 30s

VictoriaMetrics insert (vminsert)


Этот компонент получает данные от deployment'ов с Prometheus и переправляет их в vmstorage. Параметр replicationFactor=2 реплицирует данные на два из трех серверов. Таким образом, если один из экземпляров vmstorage испытывает проблемы или перезапускается, все равно остается одна доступная копия данных.

./vminsert-prod \        -storageNode=vmstorage-0:8400 \        -storageNode=vmstorage-1:8400 \        -storageNode=vmstorage-2:8400 \        -replicationFactor=2

VictoriaMetrics select (vmselect)


Принимает PromQL-запросы от Grafana (Trickster) и запрашивает исходные данные из vmstorage. В настоящее время у нас выключен кэш (search.disableCache), поскольку в архитектуре присутствует Trickster, который и отвечает за кэширование; поэтому надо, чтобы vmselect всегда извлекал последние полные данные.

/vmselect-prod \        -storageNode=vmstorage-0:8400 \        -storageNode=vmstorage-1:8400 \        -storageNode=vmstorage-2:8400 \        -dedup.minScrapeInterval=10s \        -search.disableCache \        -search.maxQueryDuration 30s

Общая картина


Текущая реализация выглядит следующим образом:



Примечания к схеме:

  • Production-кластер и кластеры со вспомогательными сервисами более не хранят данные мониторинга. Цель данного конкретного изменения состояла в том, чтобы ограничить глобальную функцию кластеров K8s и предотвратить каскадные отказы. В случае выхода из строя какого-либо кластера важно иметь доступ к метрикам и логам, которые помогут установить суть проблемы. Совместная работа сервисов в одних и тех же кластерах повышала вероятность каскадных отказов и затрудняла диагностику первопричины сбоя.
  • Каждый deployment в составе кластера K8s идет вместе с локальным Prometheus'ом, который собирает исключительно внутренние метрики и отправляет их в VictoriaMetrics insert в инфраструктурном кластере Kubernetes.
  • В инфраструктурном кластере Kubernetes работают два deployment'а с Prometheus, выполняющие разные функции. Вообще говоря, подобная схема не была строго обязательной, однако она придала процессу мониторинга Kubernetes необходимую согласованность, так что любые изменения теперь автоматически и единообразно применяются ко всем кластерам. Global Prometheus теперь отвечает только за сбор метрик с экземпляров EC2, с colocation-хостинга и любых других не-Kubernetes-сущностей.

Заключение


Ниже приведены метрики, которые в настоящее время обрабатывает VictoriaMetrics (итоговые данные за две недели, на графиках показан промежуток в два дня):



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

Это отличный показатель, но есть еще несколько моментов, которые мы планируем улучшить в ближайшие месяцы:

  • Снизить кардинальность метрик, улучшив интеграцию statsd.
  • Сравнить кэширование в Trickster и VictoriaMetrics нужно оценить влияние каждого решения на эффективность и производительность. Есть подозрение, что от Trickster можно вообще отказаться, ничего не потеряв.
  • Превратить Prometheus в stateless-сервис пока он работает как stateful, однако для этого нет особых причин. Мы до сих пор используем лейблы на основе постоянного сетевого имени, предоставляемого StatefulSet'ом, так что об этом придется помнить (как и о pod disruption budgets).
  • Оценить работу vmagent компонента VictoriaMetrics для сбора метрик с Prometheus-совместимых exporter'ов. Учитывая, что на данный момент наш Prometheus только этим и занимается, это перспективное направление для улучшения. В будущем vmagent позволит полностью отказаться от Prometheus (его бенчмарки выглядят многообещающе!).

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

P.S. от переводчика


Читайте также в нашем блоге:

Подробнее..

PgSCV экспортер метрик для PostgreSQL

27.05.2021 12:14:32 | Автор: admin

Всем привет. В этом посте я расскажу про pgSCV - новый экспортер метрик для PostgreSQL (и не только), чем он так хорош и какие проблемы решает.

Наверняка все кто используют Prometheus и PostgreSQL сталкивались и с postgres_exporter. Этот экспортер довольно легко запуститьи начать им пользоваться. Также у него есть возможности для расширения, на основе своего запроса можно описать метрики иснимать их. Если есть хорошие знания о том как устроена постгресовая статистика можно собрать довольнобольшое количество метрик. Но как известно кроме метрик самого Postgres, еще желательно собирать метрики системы, а если винфраструктуре есть вспомогательные сервисы, например пулеры соединений (pgbouncer, odyssey и т.п.), то и с них также нужно сниматьметрики. Выходит что нужно поставить еще экспортеров.

В pgSCV я постарался решить обе этих проблемы.

Решение первое. pgSCV сразу умеет снимать очень большое количество метрик с PostgreSQL без необходимости дополнительной настройки. На мой взгляд это сильно облегчает задачу первоначального запуска. Вместо траты времени на написание кастомной конфигурации для съема дополнительных метрик их сразу можно получить из коробки. Возможности конфигурации кастомных метрик также присутствует. Возникает резонный вопрос - а что если метрик слишком много и не все они нужны? В таком случае, можно отключить сбор метрик или ограничить список БД с которых требуется снимать метрики.

Второе решение. На данный момент pgSCV умеет снимать метрики с системы, PostgreSQL и Pgbouncer. Для этого он автоматически ищет эти сервисы и начинает собирать с них метрики. Очевидно что для сбора метрик с сетевых служб нужны реквизиты для подключения. Съем метрик не ограничивается только локальными службами. При желании можно указать сбор метрик и с сервисов размещенных на других узлах.

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

curl -O -L https://github.com/weaponry/pgscv/releases/download/v0.5.0/pgscv_0.5.0_linux_amd64.tar.gztar xvzf pgscv_0.5.0_linux_amd64.tar.gzcat << EOF > pgscv.yamldefaults:    postgres_username: "monitoring"    postgres_password: "supersecretpassword"EOF./pgscv --config-file pgscv.yaml

После запуска можно открыть вторую консоль и с помощью curl -s 127.0.0.1:9890/metrics получить список метрик.

Отмечу, что pgSCV создавался для нужд Weaponry (проект по мониторингу PostgreSQL и всего вокруг него), теперь pgSCV на мой взгляд стабилизировался и мне не стыдно его показать.

На этом всё, спасибо за внимание! Если есть идеи, пожелания или нашлись баги, то пишите в discussions или issues. Напоследок немного ссылок:

Подробнее..

Категории

Последние комментарии

  • Имя: Макс
    24.08.2022 | 11:28
    Я разраб в IT компании, работаю на арбитражную команду. Мы работаем с приламы и сайтами, при работе замечаются постоянные баны и лаги. Пацаны посоветовали сервис по анализу исходного кода,https://app Подробнее..
  • Имя: 9055410337
    20.08.2022 | 17:41
    поможем пишите в телеграм Подробнее..
  • Имя: sabbat
    17.08.2022 | 20:42
    Охренеть.. это просто шикарная статья, феноменально круто. Большое спасибо за разбор! Надеюсь как-нибудь с тобой связаться для обсуждений чего-либо) Подробнее..
  • Имя: Мария
    09.08.2022 | 14:44
    Добрый день. Если обладаете такой информацией, то подскажите, пожалуйста, где можно найти много-много материала по Yggdrasil и его уязвимостях для написания диплома? Благодарю. Подробнее..
© 2006-2024, personeltest.ru