×Закрыть

Развертывание стека мониторинга Linux-серверов и приложений с Netdata

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

Выбор компонентов

На этапе выбора рассматривались преимущественно free/opensource-компоненты, не требующие приобретения лицензий. Такие распространенные решения, как Zabbix, Nagios, Icinga и т. д., не произвели достаточного впечатления, чтобы на них останавливать свой выбор. В частности, собственные dashboards таких систем по гибкости и информативности ожидаемо отставали на фоне такого лидера, как Grafana. Популярный Zabbix в качестве database management system (DBMS) использовал SQL-базу, по умолчанию — MySQL (MariaDB), в данной роли неспособную конкурировать с точки зрения производительности и эффективности с какой-нибудь специализированной time series database (TSDB).

Всё в том же Zabbix, к примеру, нет возможности «из коробки» полноценно мониторить дисковые операции на хосте. К этим и другим актуальным метрикам часто необходимо добавлять сторонние плагины, что по ресурсоемкости развертывания из-за «допиливания напильником» приближает его к фреймворкам для мониторинга (Sensu), обладающим значительно большей гибкостью. Как итог, некоторые коробочные решения фактически таковыми не являются, теряя свое главное преимущество.

Таким образом, отбросив монолитные решения, нужно было определиться с компонентами для нашей будущей модульной системы мониторинга. В частности, с агентами, которые будут собирать и передавать метрики. Первым был опробован telegraf, но он вызвал энтузиазма не больше, чем Zabbix, и захотелось посмотреть что-то другое. Этим другим в конечном итоге оказалась Netdata.

Почему именно Netdata? Ну, во-первых, это просто красиво. ©

Смотрите demo.

К тому же Netdata не только metric collector (по умолчанию выдающий сразу порядка ~1К метрик c хоста, обнаруживаемых через autodiscovery) с высокой детализацией (precision — 1 с), но и автономная система мониторинга, с собственной in-memory TSDB (разумеется, на крайне ограниченный период времени, по умолчанию это 1+ ч, тогда данные занимают порядка ~20MB RAM; дополнительно можно добиться ~60% экономии RAM при использовании механизма Memory Deduplication Kernel Same Page Merging или просто KSM, если активировать KSM в ядре Linux), визуализацией метрик и системой оповещений. И нет, при этом Netdata не требует для запуска никаких чудовищных ресурсов на хосте. Хотя у тех, кто работает с embedded/IoT с крайне ограниченными вычислительными ресурсами, возможно, будет и противоположное мнение, так что всё в этом мире относительно. Разработчики позиционируют Netdata, в частности, как «убийцу утилит консольного мониторинга».

Имеется масса преднастроенных алертов, в том числе с использованием предсказания на основании трендов. Например, кроме классических на процент занятого места, учитывается disk fill rate, на основании которого высчитывается предполагаемый out of disk space time; если он менее 48 ч — warning alert, менее 24 ч — уровень повышается до critical alert.

В списке поддерживаемых ОС — исключительно Linux, FreeBSD и Mac OS. На текущий момент, вероятно, это самый большой недостаток Netdata. Но, с другой стороны, для других ОС всегда можно использовать просто другого агента. Оставалось только реализовать для Netdata централизованное долговременное хранение метрик, чем я дальше и занялся.

Хранение метрик

Среди многочисленных поддерживаемых вариантов backend (Graphite, KairosDB, Blueflood, InfluxDB...) сначала была выбрана такая TSDB, как InfluxDB (Netdata поддерживает ее в формате/по протоколу openTSDB), в основном из-за ожидаемого компактного хранения метрик и большей распространенности в сравнении с остальными вариантами.

Image source

Итак, попытка «номер раз» — NetData -> InfluxDB -> Grafana. На которой сразу же пришлось столкнуться с не совсем удобной интеграцией между InfluxDB и Grafana. Данное сочетание кардинально уступает Graphite -> Grafana по доступным математическим функциям, при построении dashboard. Так как в случае с InfluxDB предвиделись и другие сложности, решение было выбрано кардинальное — посмотреть альтернативные варианты DBMS.

Шаг назад, или NetData -> Graphite -> Grafana

В данном стеке доступно существенно больше операций с метриками при построении dashboard. Также были найдены готовые dashboards для подобного стека, которые после небольших косметических изменений заработали, что существенно сократило затраты времени на построение собственных с нуля. Но что теперь не так? Graphite по умолчанию использует для долговременного хранения TSDB Whisper. Она очень проста и удобна, но то, как она хранит данные (одна метрика — один файл), порождает огромное количество IOPS на запись. Причем в моем случае, даже если записывать не все метрики (а хранить все 1К + метрик с хоста накладно даже для TSDB), а выборочно — по фильтру, и интервал увеличить с 1 с до 10 с и более, все равно количество iops оказалось неприемлемым. Метрики всего лишь с 5 хостов уже создавали более 500 (!) iops на запись в базе Whisper.

Такая нагрузка была не по плечу уже единичному HDD, а в случае с масштабированием хотя бы на 100+ хостов (рост нагрузки ожидался при этом практически линейный...), уже было бы недостаточно и просто SSD, потребовался бы all-flash array. Использовать подобное оборудование для данных целей было просто абсурдно — используемая в Graphite по умолчанию TSDB однозначно требовала замены (странно, что разработчики Graphite не сделали до сих пор этот шаг сами, оставив его на откуп пользователям). Из многих доступных вариантов, включая все тот же InfluxDB, был сделан выбор в пользу такой column-oriented DBMS, как Clickhouse. Ранее это была внутренняя разработка Yandex, но теперь это полностью opensource-продукт (Apache License 2.0). Для Clickhouse доступна кластеризация, в отличие от InfluxDB, у которого кластеризация только в платной версии.

Для интеграции ClickHouse с Graphite есть уже готовый стек — Graphite cluster backend with ClickHouse support.

Image source

Вот им я и воспользовался. Нагрузка на дисковую подсистему при смене Whisper на Clickhouse снизилась сразу на порядок (!) и в дальнейшем практически не возрастала (по показателю Write IOPS) при добавлении новых метрик/хостов. По умолчанию Сlickhouse, graphite-clickhouse и carbon-clickhouse пишут в собственные логи очень много информации, поэтому простое изменение уровня логирования в этих компонентах снизило нагрузку на дисковую подсистему еще вдвое. С этой же целью disk buffer для carbon-clickhouse был вынесен на tmpfs. Война за iops’ы была бесповоротно выиграна — теперь вся система мониторинга могла спокойно жить даже на неспешном NL HDD (ниже приведена нагрузка хоста c данным стеком мониторинга, пилотное развертывание — метрики собираются менее чем со 100 хостов).

Также весь стек после небольшой настройки параметров обходился разумным объемом RAM.

Ниже дан пример настройки многоуровневой data retention policy, которая позволяет хранить данные с несколькими уровнями детализации весьма длительный период — до полугода и данные для построения трендов — по истечении полугода.

PrecisionAge
10 second24 hours
120 second1 months
10 minutes6 months
8 hours∞*

*По умолчанию, данный стек не предусматривает границ последнего периода хранения, в отличие от первоначального варианта с Whisper.

При этом, так как у Netdata есть собственный встроенный веб-интерфейс (поддерживает разграничение доступа по IP ACL, если этого недостаточно — предлагается использовать стороннее ПО с расширенными возможностями авторизации, nginx например), то в случае необходимости нагрузку с детализацией в 1 с можно посмотреть в онлайне непосредственно с нужного сервера (все метрики, доступные Netdata).

Зачем вообще так часто снимать метрики? Может, просто раз в 5 мин, как это делают многие системы мониторинга? Для наглядности ниже представлена одна и та же утилита, но с разным уровнем precision; очевидно, что детализацию желательно использовать меньше, чем продолжительность события, которое мы хотим увидеть на итоговом графике; также стоит учитывать и используемый тип агрегирования метрики.

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

Какой в итоге необходим объем для хранения метрик в случае с ClickHouse? Для сравнения ниже данные по другим DBMS.

Приложение/DBMSБайт на числовой элемент данных
Zabbix (MariaDB)90 байт
OpenTSDB12–39 байт
Whisper (Graphite)12 байт
InfluxDB2–3 байта
m3db1,4 байта

У меня получилось в текущем environment для Clickhouse:

~ 4 байта на точку при использовании указанной выше по тексту data retention policy (для лучшей эффективности использовался такой традиционный «hack», как зануление поля timestamp*);
и ~2.8 байта на точку, если не использовать data retention policy (но тогда пришлось бы или ухудшить precision, или сильно ограничить время хранения, ну или просто выделить очень много дискового пространства).

*Пример: alter table graphite update Timestamp=0 where Timestamp!=0;

То есть эффективность хранения данных для развернутой системы мониторинга при использовании ClickHouse близка к таковой у InfluxDB (обе DBMS используют сжатие данных) и в 23 раза эффективнее в сравнении с Zabbix (MariaDB). Что очень неплохо, хотя, как видно из списка выше, есть DBMS, хранящие данные еще более компактно.

Работа с алертами

Следующий этап — где агрегировать, хранить и отправлять дальше алерты от Netdata? Из списка поддерживаемых Netdata-систем я выбрал Alerta.

Image source

Для хранения собственных данных Alerta поддерживает такие DBMS, как MongoDB или PostgreSQL, на выбор. Я выбрал MongoDB, как более простую. Alerta умеет дедуплицировать/агрегировать приходящие алерты, что крайне полезно перед дальнейшей отправкой в мессенджеры или другие каналы оповещения. Поддерживаются теги, два дефолтных значения, Development и Production, можно изменить/расширить любыми собственными наименованиями environment. Отправку heartbeat с хостов реализуем отдельно, через cron напрямую в Alerta, а время запуска слегка рандомизируем в используемом скрипте, чтобы избежать пиковых «штормов»**.

**Пример: /usr/bin/sleep $[RANDOM\%30] ; /usr/bin/curl -XPOST <alerta server>/api/heartbeat -H ’Authorization: Key <authorization key>’ -H ’Content-type: application/json’ -d ’{"origin":"","tags":["environment:test"],"timeout«:120}’

В итоге приходим к следующей HLD-схеме стека мониторинга из Netdata, Graphite (Clickhouse), Grafana и Alerta.

Так как в развернутом стеке все метрики за разные периоды хранятся в одном и том же табличном пространстве ClickHouse, то в dashboard Grafana достаточно выбрать интересующий период; в случае же с InfluxDB пришлось бы дополнительно выбирать разные datasources, из-за другого механизма реализации data retention policy.

А выбор Grafana для построения dashboards позволяет использовать в последних метрики из других систем мониторинга / других вычислительных платформ (в том числе выводить на один график).

Послесловие

«Все началось с того, что я огляделся по сторонам и, не увидев автомобиля своей мечты, решил сконструировать его сам» (Ferdinand Porsche).

Image source

Именно так выглядел один из первых автомобилей (электромобиль) разработки Фердинанда Порше на выставке в Париже 1900 года.

LinkedIn

29 комментариев

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

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

да ладно? для любого сервиса актуально, особенно онлайнового
тем более, если инцидент или около того, все хотят видеть — «а как сейчас?»
я ещё поверю, если к примеру, система непродуктивная и на ней стресс-тест прогнали, а результаты решили как-нибудь потом посмотреть :-) (знаю таких)
или вопрос был о том, так ли необходимо, реализованное в Netdata обновление метрик раз в секунду? так это обычная практика для популярных консольных утилит, но они все ни столько метрик не умеют, ни в таком виде как Netdata

Я имею в виду обычный процесс мониторинга с классическим 5-и минутным интервалом
Зачем чаще?

то есть — не читали :-)
а там картинка даже есть именно на такой случай, нагрузка от джобов, которые стартуют раз в 5 минут (или любой другой нерегулярной нагрузки с пиками утилизации) на 5 минутном интервале размажется до «средней температуры по больнице, включая реанимацию и морг»
и с точки зрения статистики на этом интервале все будет как бы хорошо, а с точки зрения конечных пользователей итерактивного приложения — может оказаться совершенно неприемлемо из-за чудовищного 30 секундного фриза, во время этих 5 минут (из-за 100% утилизации на 30 сек)
а если брать не среднее, а пиковое в этом интервале — то тоже график утилизации будет не достоверен

Читал. И по этому прошу пару кейсов про эти мифические джобы.

так пока люди не начнут измерять с интервалом, точнее чем 5минут, они и будут для них мифическими
и сами будут порождать другие популярные мифы, что когда на CPU нагрузка 80% — то «Изя уже все», вместо того, чтобы запустить NMON и увидеть пики утилизации к 100%, рост очереди и блокировки

кроме как геймдева

платежные системы (у них совершенно нездоровые требования к виртуализации именно из-за желания избежать проблем с нагрузкой), VoIP (Netdata кстати из коробки за CPU jitter следит) и , как ранее я уже говорил, любой онлайновый сервис

У каких именно платежных систем? Если мы о стандарте PCI-DSS то там требования очень просты — нельзя использовать виртуалку из-за возможности сделать снапшот с работающими процессами и через снапшот раскрыть важные данные.

У каких именно платежных систем?

у любых требования — размещение только на дедикейт вычислительных ресурсах

Если мы о стандарте PCI-DSS

я не именно о нем

нельзя использовать виртуалку

нет там такого запрета — хоть в публичном облаке
но в случае виртуализации, сертификацию обязана проходить вся используемая платформа — у вендоров даже есть готовые конвергентные решения для этого, которые сразу PCI-DSS compliance

Мы ушли от темы. Где в платежных системах нужен такой мониторинг. Кроме как биржевой бот — никаких идей нет.

такой — это какой?

Мониторинг в реалтайме — пару примеров из практики

пару примеров из практики

примеров чего?
зачем люди используют top? hmon? nmon? iostat? mpstat? ...
когда ответ на вопрос про состояние метрики на экране и его не нужно ждать 5-15минут?

Честно говоря не знаю зачем в 2019 этим ещё пользуются, когда можно добавить в приложении отправку сигнала при rps/sla по которой наскейлится ещё парочка.

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

сотни таких приложений в виде бинарных файлов, непосредственно к которым ты уже ничего не добавишь
все равно нужны системные метрики

Но зачем? Допустим метрики показывают что у бинарника оверюз по памяти при работе с криптографией (реальный кейс). Какая принципиальная разница между снятием этого показателя пять раз в минуту и раз в пять минут (условно)? Мы же не можем повлиять на этот бинарник.

hedge funds / banking ... була задача де використовувалось знімання метрик кожних 200ms
drill ... власне вже давно не роблять вертикальні дирки, зараз бури це щось типу поїзда який їздить під землею в різних напрямках (метрики порядка 60 мс)
всяка телеметрія з різного обладнання
а для чого використовують всякі rtos ? і чи потрібні там метрики в реальному часі ?

hedge funds / banking ... була задача де використовувалось знімання метрик кожних 200ms

А можно уточнить для чего?

Это конечно интересно, только судя по тому, как пилят Grafana — они сейчас на пике популярности в компании с Prometheus. По размерам метрик посмотрите сюда medium.com/...​toriametrics-e31a41ae2893

Ну и еще несколько сравнений у автора есть. + InfluxDB если не платная версия то особо не имеет смысла, ровно как и TimescaleDB в бесплатной версии, а вешать на себя узды вендорлока не все готовы.

понятно, что Prometheus претендует на первое место среди подобных систем мониторинга, но насколько я знаю, он изначально short term (все равно чем-то нужно дополнять), ресурсы прилично ест и порог входа достаточно высокий (где-то видел шарж на эту тему — про зайдем в Prometheus на 5 минут)
так что я для себя решил, что Prometheus это наверно хорошо и возможно — да, но точно не сейчас
по крайней мере, пока в инфраструктуре не появятся контейнеры
VictoriaMetrics — коммерческий продукт, а не OSS, со всеми вытекающими

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

А что касается Prometheus — если ты работаешь в этом направлении, то порог входа не высок, стоит посмотреть несколько видео «how to» с примерами. К слову — я по примеру написал свой экспортер для Memcached, почти не имея знаний в python, в сравнении с zabbix,nagios, icinga2, то это делается намного проще, нежели искать костыли для этих 3х. Что касается Netdata — сказать не могу, дела пока не имел.

Там чтения документации на 4 часа и часа 2 два на эксперименты. После этого в Prometheus нет ничего сложного. Главное понять архитектуру и концепции управления.

Prometheus жрал ресурсы до выхода версии 2.0 в 2017 году. Теперь он работает довольно шустро и неплохо жмет данные по сравнению с другими решениями. Prometheus поддерживает большое количество внешних long-term хранилищ, из которых можно подобрать наиболее подходящее. Я, конечно же, рекомендую бесплатную single-node VictoriaMetrics, т.к. она масштабируется намного лучше по сравнению с InfluxDB и TimescaleDB.

Главные различия между Prometheus и Graphite:
— pull vs push. Я предпочитаю pull-модель, т.к. она позволяет сразу же ответить на вопросы: «что мы мониторим?» и «что из того, что мы мониторим, сейчас не работает?»
— PromQL vs Graphite query language. Я предпочитаю PromQL, т.к. с помощью него проще строить графики, зависящие от многих временных рядов, и он четко отделен от графического представления результатов запроса.

Я, конечно же, рекомендую бесплатную single-node VictoriaMetrics

другая рекомендация выглядела бы крайне неожиданно :-)
но, насколько я вижу, интеграция Prometheus и VictoriaMetrics исключительно односторонняя (к слову, в перспективе изменения не предвидятся?)

VictoriaMetrics: write

и для long term поэтому придется совершенно отдельный стек собирать
при том, что есть варианты с двухсторонней интеграцией, например

InfluxDB: read and write
M3DB: read and write

и последний тоже очень хорошо жмет данные (без понятия правда как там с производительностью)

pull vs push. Я предпочитаю pull-модель

у каждой модели свои преимущества и недостатки
blog.sflow.com/...​2012/08/push-vs-pull.html
для мониторинга я предпочел push-модель
лучше будут гибридные решения
собственно то, что я использую, тоже в какой-то мере можно считать гибридным решением — развертывание/настройка агентов через pull (ansible), а непосредственно мониторинг — push

но, насколько я вижу, интеграция Prometheus и VictoriaMetrics исключительно односторонняя (к слову, в перспективе изменения не предвидятся?)

Prometheus может только записывать данные в VictoriaMetrics, но не может считывать. Это сделано специально по следующим причинам:

  • Высокая ресурсоемкость Prometheus remote read API для чтения данных из remote storage. Это API требует передачи всех данных в сыром виде из remote storage для последующего выполнения PromQL запросов на стороне Prometheus’а
  • Разработчики Prometheus предполагают, что remote storage может вернуть только данные, которые попали туда только через этот инстанс Prometheus, исключая данные с других инстансов Prometheus. Иначе Prometheus может выдавать некорректные результаты запросов. Это делает невозможным одну из основных «фишек» remote storage — global querying view, когда в одном запросе могут участвовать данные, собранные из нескольких Prometheus’ов.
Поэтому я бы советовал с осторожностью относиться к remote storage решениям, декларирующим поддержку Prometheus remote read API. Скорее всего, поддержка записи и чтения Prometheus данных в этих решениях добавлена просто «для галочки» и вряд ли подходит для production.

Как же решена проблема чтения данных из VictoriaMetrics? Она поддерживает PromQL со всем Prometheus querying API, плюс дополнительные улучшения. Благодаря этому достаточно заменить лишь hostname в url’е к Prometheus datasource в Grafana, чтобы переключить все графики в Grafana с Prometheus на VictoriaMetrics.
Многие другие remote storage решения не поддерживают PromQL, поэтому для них придется переписывать запросы ко всем графикам на языке, предоставляемом соответствующим решением.

и последний тоже очень хорошо жмет данные (без понятия правда как там с производительностью)

Вы сами тестировали, насколько хорошо жмет данные M3? Или где-то прочитали? Если прочитали, то скиньте, пожалуйста, ссылку — интересно посмотреть.

Вы сами тестировали, насколько хорошо жмет данные M3? Или где-то прочитали? Если прочитали, то скиньте, пожалуйста, ссылку — интересно посмотреть.

вряд ли они будут новыми
docs.google.com/...​2NJjjtKkN3SbLI/edit#gid=0
docs.google.com/...​4a-IuZv4fXDHxM/edit#gid=0
сам не тестировал
P.S. если кто из читателей слышит впервые о M3DB — eng.uber.com/m3

лучше будут гибридные решения
собственно то, что я использую, тоже в какой-то мере можно считать гибридным решением — развертывание/настройка агентов через pull (ansible), а непосредственно мониторинг — push

Push-модель может подойти только для короткоживущих процессов или worker pool процессов, обычно используемых в скриптовых языках вроде PHP, Python, node.js и Perl, т.к. процесс вместе с данными по метрикам может не успеть дожить до момента, пока их соберет Prometheus. В этом случае лучше пушить метрики в statsd-подобный сервис, (например, в statsd_exporter), а уже оттуда забирать их с помощью Prometheus.

Для долгоживущих процессов лучше подходит обычный экспорт метрик в Prometheus-формате с помощью специальных библиотек под любые языки программирования. Для Go я рекомендую использовать github.com/VictoriaMetrics/metrics, т.к. она проще в использовании по сравнению со стандартной либой.

p.s. VictoriaMetrics поддерживает прием метрик не только из Prometheus, но и с агентов, отдающих метрики в Graphite-формате, InfluxDB-формате и OpenTSDB-формате

Интересно но имхо сложно как то. Сколько у вас хостов на мониторинге ? На мониторинге только дедики — виртуалки или еще есть облачные сервисы ?

перебирать компоненты, с которыми ты ранее никогда не работал, в поисках подходящих, да — нельзя сказать что было просто (из-за слишком высокого фактора неопределенности), а когда уже сформирован целевой стек, то в его развертывании и сопровождении нет ничего сложного, я б сказал бы, что он даже в чем то проще все того же Zabbix-а
у меня все on premise (VM/baremetal), разные вычислительные архитектуры, стораджи и т.д.
так что то, что на картинке — на самом деле только часть из используемого комплекса систем мониторинга

Подписаться на комментарии