Привет, %username%! Поговорим о такой безумно важной вещи как мониторинг! Постараемся ответить на некоторые вопросы связанные с мониторингом инфраструктуры и приложений.
Определения
Для начала определимся что есть что:
- Мониторинг инфраструктуры – это сбор метрик описывающих состояние вашей IT-инфраструктуры;
- Метрика – это конкретная характеристика, показывающая текущее состояние по определенному параметру (пример: количество одновременных подключений);
- Сервер мониторинга – ПО, которое выполняет агрегацию, хранение, пересчет данных по метрикам;
- Агент мониторинга – ПО, которое выполняет сбор метрик с хоста, который подлежит мониторингу, а так же отправку данных на сервер мониторинга;
Вроде бы всё довольно просто выглядит: мониторинг – это сбор показателей системы (инфраструктуры) в реальном времени (ровно на столько, на сколько это возможно - об этом чуть ниже).
Инструменты
На рынке уже давно устоялись такие замечательные инструементы как Zabbix, Prometheus, Nagios, OpenNMS, Cacti, Netdata. Обзор данных продуктов я делать не буду, т.к. этой информации предостаточно на просторах паутины. Главное что необходимо знать о системах мониторинга, это то как они работают (в общих чертах).
Модели работы
Собственно две основные (ибо кмк являются уже стандартом де-факто для всей отрасли) системы мониторинга – Zabbix и Prometheus – могут работать в двух режимах (по двум моделям): Push и Pull.
- Push-модель – когда сервер мониторинга ожидает подключений от агентов для получения метрик;
- Pull-модель – когда сервер мониторинга сам подключается к агентам мониторинга и забирает данные;
Все довольно просто: выбор модели работы необходимо делать исходя из того, чего вы хотите и что вы можете. Например (пусть будет Zabbix):
У вас есть 10 серверов в приватной сети и без белых IP, а так же отсутствует возможность настроить хоть какой-то NAT (пробросить порты до агентов). А сервер мониторинга у вас отдельный (пусть стоит где-то у хостера) и он не имеет прямой связи с данными 10-ю серверами, которые вы хотите мониторить.
В данном кейсе ваш выбор очевидет – вам подходит только Push-модель. Вам необходимо будет добавить все хосты в мониторинг, указать им в качестве IP тот адрес который они имеют в приватной сети, порт оставить по дефолту, а в качестве шаблонов выбирать те, которые используют активного агента. В этом случае у вас будет агент подключаться к серверу и отдавать метрики.
Данную схему можно немного доработать – у Zabbix есть такая вещь как Zabbix-Proxy, а у Prometheus – Pushgateway. Данные сервисы в некоторых ситуациях помогут исправить картину мира. Например:
Возьмем ту же картину мира, что и в прошлом примере, и добавим туда еще один сервер, на котором развернем Zabbix-Proxy, а хосты в самом Zabbix (в веб-интерфейсе), привязываем к Zabbix-Proxy. После чего можем привязывать шаблоны с обычными агентами.
Что мониторить?
Теперь попробуем определиться что именно мы хотим мониторить? Какие метрики нам нужны? Тут все так же просто – начнем по порядку снизу вверх:
- Аппаратные метрики – все то, на чем крутится ваша ОСь (даже если у вас виртуализация – собрайте метрики виртуализации);
- Метрики ОС – чем занимается ваша ОСь (CPU/RAM/Disks/Network);
- Метрики сервисов – метрики всего того, что обеспечивает доступность приложения (Nginx/Apache/Redis/MySQL/PostgreSQL);
- Метрики приложения – все метрики вашего приложения (тот же PHP/NodeJS). Сразу оговорюсь - тут без ваших разработчиков никак. Пусть дают конкретные ручки, которые будет дергать мониторинг. А сразу имеет смысл мониторить количество запущенных процессов (Кэп), количество потребляемой процессом памяти (мы так узнали, что у нас текла NodeJS по памяти, а пока разрабы не придумали как решить проблему - мы рестартовали демон каждые 20-30 минут);
- Метрики смежных сервисов – метрики всего того, с чем взаимодействует ваше приложение (внешние/внутренние интеграции - сторонние API, 1C);
Собственно говоря список не такой уж и большой, но при желании его так же можно расширять под себя и пихать туда всё, что захочется видеть.
Как часто собирать метрики?
Я выше упомянул о том, что такое мониториг, а так же сказал, что он должен быть real time ровно на столько, на сколько это возможно реализовать. В чем собственно проблема, может спросить абсолютно любой. А проблема довольно простая и очевидная. Я как админ хочу знать, что моя инфратруктура жива и с ней все в порядке. Любой неочень разраб, да и недалекий начальник - а-ля бигбосс - скажет: а давай собирать метрики раз в секунду! С одной стороны это выглядит вполне логично! И в идеальном мире я бы так и делал, но как всегда есть одно “НО”.
Начну с примера: у нас есть средний сайтик средней компании со средней посещаемостью 10 человек в месяц. Этот сайтик показывает картинку с котиком, каждый раз разную как только любой пользователь открывает главную страничку сайта. Пусть у нас будет средний PHP+MySQL+Nginx. Все это добро крутится на простеньком сервере (не будем называть характеристики для упрощения картины мира).
Мы преспокойно можем дергать с него метрики раз в секунду. Нагрузки как таковой нету, а следовательно сервер бОльшую часть времени занят ничем. Только вот незадача: наши шикарные маркетологи/пиращики/продажники (я не разбираюсь в сортах не технического персонала, так что извиняйте) ударно поработали и вот у нас на сайт стало прилетать 100k хомячков в час. И вот теперь нам категорически важно получать данные как можно оперативнее, только вот очередное “НО” выходит на сцену.
Мы, как было сказано бигбоссом, настроили сбор метрик раз в секунду. Метрики к нам в мониторинг летят и в целом все не плохо, только мы видим по мониторингу что наш “агент мониторинга” жрет приличное количество ресурсов (CPU/RAM/Disk IO/Network in/out). Вот прям неприлично много, а еще хомячки начали жаловаться, что котиков не видят (а мы как компания получаем за это денег). Из чего мы делаем вывод: наш сервер занят не работой (не добычей бабла), а сбором метрик о своем состоянии.
Вот тут-то мы и начинаем крутить параметры частоты опроса метрик. Где это действительно важно/нужно оставляем 1s, а там где и потерпеть можно – ставим 1/2/5/10m.
Собственно вывод из этого простой: частота сбора метрик – это баланс между актуальностью информации и нагрузкой на систему.
Алерты
Я в своей практике не первый раз сталкиваюсь с ситуацией, когда есть мониторинг, а вот алерты от него присылаются на email. А как не многие знают, в доставке сообщений электронной почты могут быть задержки до нескольких суток.
Как следствие, первое что я делаю – настраиваю алерты по “более оперативным” каналам (читай телеграм). Некоторые компании используют свои внутренние порталы на базе того же “Битрикс24”, но как правило этот портал стоит в офисе и в случае падения интернета в офисе никто об это не узнает вовремя.
Алерты это в принципе хорошо и важно, без этого никак. Но вот когда их становится категорически много (на одной из прошлых работ Zabbix генерировал от 3k до 12k алертов за сутки), то люди (белковые ублюдки) могут проглядеть/пропустить/пролюбить/не заметить важное сообщение от мониторинга, а следовательно не среагировать вовремя на факап, прод ляжет, админу прилетит пистон, он с горя напьётся и уволится.
Суть алертов должна сводиться к тому, что на них должны реагировать. Как следствие: алертить надо о том, на что требуется сиюминутная реакция.
Полезные видосы по теме:
Вывод: о том, на что надо реагировать здесь и сейчас кричим “Алярма!”, в остальных случаях просто держим “лампочку” горящей на дашборде.
Итого
А итоги тут довольно простые: мониторинг дело индивидуальное, важное и не очень сложное. Многие компании проходят в плане мониторинга через следующие этапы:
- Нет мониторинга;
- nodeping/worldping (доступность сайтиков снаружи – из тырнета);
- Базовый мониторинг инфраструктуры (CPU/RAM/Disk space/etc);
- Мониторинг приложения (как себя чувствует приложение в конкретный промежуток времени);
- Перенасыщение метриками (собираются абсолютно все метрики, которые можно собрать/придумать);
- Чистка алертов/метрик (когда админы начинают спать по 2-3 часа в сутки - начинают думать о чем можно не кричать, а что и вовсе не надо);
Если у тебя есть вопросы, комментарии и/или замечания – заходи в чат, а так же подписывайся на канал.