[Monitoring] Мониторинг: что/куда/зачем?

Привет, %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 алертов за сутки), то люди (белковые ублюдки) могут проглядеть/пропустить/пролюбить/не заметить важное сообщение от мониторинга, а следовательно не среагировать вовремя на факап, прод ляжет, админу прилетит пистон, он с горя напьётся и уволится.

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

Полезные видосы по теме:

  1. UPTIMEDAY 2017-04-08 — Илья Аблеев / Badoo — Как устроен мониторинг в Badoo — YouTube
  2. Автодискавери в мониторинге: как надёжно обеспечить полноту мониторинга // Николай Сивко, okmeter.io — YouTube
  3. UPTIMEDAY 2017-04-08 — Николай Сивко / Okmeter — Типовое внедрение мониторинга — YouTube

Вывод: о том, на что надо реагировать здесь и сейчас кричим "Алярма!", в остальных случаях просто держим "лампочку" горящей на дашборде.

Итого

А итоги тут довольно простые: мониторинг дело индивидуальное, важное и не очень сложное. Многие компании проходят в плане мониторинга через следующие этапы:

  • Нет мониторинга;
  • nodeping/worldping (доступность сайтиков снаружи – из тырнета);
  • Базовый мониторинг инфраструктуры (CPU/RAM/Disk space/etc);
  • Мониторинг приложения (как себя чувствует приложение в конкретный промежуток времени);
  • Перенасыщение метриками (собираются абсолютно все метрики, которые можно собрать/придумать);
  • Чистка алертов/метрик (когда админы начинают спать по 2-3 часа в сутки — начинают думать о чем можно не кричать, а что и вовсе не надо);

На этом всё! А если остались вопросы, то велкам в ЧАТ: SysOps.