В этой статье рассмотрим один из вариантов модульного стека мониторинга для 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? Ну, во-первых, это просто красиво. ©
К тому же 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), в основном из-за ожидаемого компактного хранения метрик и большей распространенности в сравнении с остальными вариантами.
Итак, попытка «номер раз» — 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.
Вот им я и воспользовался. Нагрузка на дисковую подсистему при смене Whisper на Clickhouse снизилась сразу на порядок (!) и в дальнейшем практически не возрастала (по показателю Write IOPS) при добавлении новых метрик/хостов. По умолчанию Сlickhouse, graphite-clickhouse и carbon-clickhouse пишут в собственные логи очень много информации, поэтому простое изменение уровня логирования в этих компонентах снизило нагрузку на дисковую подсистему еще вдвое. С этой же целью disk bufferдля carbon-clickhouseбыл вынесен на tmpfs. Война за iops’ы была бесповоротно выиграна — теперь вся система мониторинга могла спокойно жить даже на неспешном NL HDD (ниже приведена нагрузка хоста c данным стеком мониторинга, пилотное развертывание — метрики собираются менее чем со 100 хостов).
Также весь стек после небольшой настройки параметров обходился разумным объемом RAM.
Ниже дан пример настройки многоуровневой data retention policy, которая позволяет хранить данные с несколькими уровнями детализации весьма длительный период — до полугода и данные для построения трендов — по истечении полугода.
| Precision | Age |
| 10 second | 24 hours |
| 120 second | 1 months |
| 10 minutes | 6 months |
| 8 hours | ∞* |
*По умолчанию, данный стек не предусматривает границ последнего периода хранения, в отличие от первоначального варианта с Whisper.
При этом, так как у Netdata есть собственный встроенный веб-интерфейс (поддерживает разграничение доступа по IP ACL, если этого недостаточно — предлагается использовать стороннее ПО с расширенными возможностями авторизации, nginx например), то в случае необходимости нагрузку с детализацией в 1 с можно посмотреть в онлайне непосредственно с нужного сервера (все метрики, доступные Netdata).
Зачем вообще так часто снимать метрики? Может, просто раз в 5 мин, как это делают многие системы мониторинга? Для наглядности ниже представлена одна и та же утилита, но с разным уровнем precision; очевидно, что детализацию желательно использовать меньше, чем продолжительность события, которое мы хотим увидеть на итоговом графике; также стоит учитывать и используемый тип агрегирования метрики.
При этом приходится искать баланс/компромисс между высоким уровнем детализации и требуемым местом для хранения.
Какой в итоге необходим объем для хранения метрик в случае с ClickHouse? Для сравнения ниже данные по другим DBMS.
| Приложение/DBMS | Байт на числовой элемент данных |
| Zabbix (MariaDB) | 90 байт |
| OpenTSDB | |
| Whisper (Graphite) | 12 байт |
| InfluxDB | |
| m3db | 1,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.
Для хранения собственных данных 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).
Именно так выглядел один из первых автомобилей (электромобиль) разработки Фердинанда Порше на выставке в Париже 1900 года.