Поговорим о том, какие уровни мониторинга бывают и что стоит измерять и анализировать в IT-проектах.

Зачем нужен мониторинг и что это такое

Случается, что серверы падают и программы ломаются. Это неизбежно. Случайный баг, скачок напряжения в сети, сбои в подаче электричества — всё это может вызывать поломки.

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

От обоих типов проблем спасает мониторинг — это постоянный сбор и анализ различных параметров поведения системы. С его помощью можно описать и измерить в числовом выражении каждый важный аспект проекта.

Начнем снизу: мониторинг оборудования

Что бы вы ни запускали — у вас всё равно будут серверы в дата-центре, а у них есть определенные параметры производительности. Эти показатели надо мониторить на каждом сервере, обслуживающем ваших клиентов:

  • нагрузка на процессор;
  • свободное место в оперативной памяти;
  • свободное место на жестком диске;
  • нагрузка на сеть;
  • нагрузка на жесткий диск — количество операций на запись и чтение;
  • количество задач, запущенных на исполнение.

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

А именно:

  • Нагрузка близка к критической, ваше железо готово уйти в отказ (пора масштабироваться!).
  • Выкатили новую версию кода и как-то быстро закончилась память (или «нас взломали!»).
  • Ничего не выкатывали, но после очередной рекламной кампании пришло очень много клиентов и скоро всё упадет.

Для анализа поведения серверов в самом простом виде можно использовать штатные средства контроля по типу htop. Более гибкое и масштабируемое решение — Zabbix — он уже умеет анализировать основные параметры целого кластера серверов и собирать их в одной панели. Такое решение требует настройки со стороны квалифицированного администратора.

Пользователи контейнерных систем могут использовать для мониторинга штатный Kubernetes Dashboard — инструмент поставляется вместе с Kubernetes практически по умолчанию.

Поднимаемся выше: мониторинг состояния приложений

Допустим, мониторинг серверов у нас есть и они выглядят адекватно. Памяти много, нагрузка на процессор — незначительная. Наверное, всё хорошо организовано, клиентов немного, всё работает как часы? Может быть. Или всё упало, программы не запущены, клиенты не могут попасть на сервер и выполнить запросы? Тоже может быть.

Какой из вариантов правильный — подскажут метрики приложений.

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

  • Количество запросов в единицу времени: час, секунду, день, минуту — зависит от обилия трафика в вашей программе.
  • Количество активных пользователей в системе в единицу времени.
  • Количество различных записей в СУБД — в целом и новых в единицу времени.
  • Количество ошибок, которые вы успешно отловили и зарегистрировали.

У вас в системе 100 активных пользователей, они генерируют 1 000 запросов в минуту и у них случается 1 ошибка в час? Допустим, что всё хорошо. У вас в системе 3 активных пользователя, они генерируют 10 000 запросов в минуту и ловят 5 000 ошибок? Наверное, стоит начать беспокоиться. Даже если метрики нагрузки на процессор и диски в порядке.

Для мониторинга на этом уровне подойдет специализированная СУБД — Prometheus, Graphite, InfluxDB. С установкой самой базы данных проблем не будет, а вот посчитать и пробросить нужные метрики в базу — для этого понадобятся усилия программистов.

Для удобства анализа ко всем этим базам лучше всего подключить Grafana — графический инструмент для отображения статистики и метрик.

На платформе Mail.ru Cloud Solutions для приложений предоставляется встроенная система мониторинга состояния серверов и приложений, а для Kubernetes предусмотрен мониторинг на базе Prometheus и Grafana, позволяющий отслеживать доступность сервисов.

Есть еще специфические системы отлова ошибок в коде — они могут вовремя оповестить программистов о сбойной ситуации. Иногда этого вполне достаточно для базовой диагностики проблем. Хороший пример такой системы — Sentry.

Третий уровень: мониторинг бизнес-метрик

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

  • Сколько пользователей зарегистрировано в системе и сколько пользуется приложением раз в день/неделю/месяц?
  • Какой процент людей после регистрации умудряется дойти до формы оплаты и оплатить подписку на ваши услуги? Сколько они платят?
  • Как люди пользуются вашими услугами? Какие фичи используют почти все, а какие — единицы клиентов?
  • Как много денег вы зарабатываете на вашей программе? Сколько человек оплатили подписку? Какие средние и медианные чеки на клиента? Какова общая выручка и прибыль?

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

Минимально здесь можно обойтись Google Analytics — базовые конверсии и переходы можно смотреть в готовых системах анализа пользовательского поведения. Более глубокое понимание ситуации потребует четкой и слаженной работы администраторов, программистов и ребят из отдела аналитики — они смогут правильно реализовать и посчитать тонкие поведенческие аспекты. Например, зависимость выручки от A/B-тестов на бэкенде.

Дьявол в деталях: мониторинг событий

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

Допустим, мы знаем, что конверсия из зарегистрированного пользователя в платящего — 1%. То есть один человек из 100 начинает платить за услуги. А если до совершения покупки эти клиенты посещают в среднем 30 экранов приложения и вынуждены сделать больше 300 кликов? Ясно, что сценарий оплаты работает неправильно — люди должны приходить к оплате за 3 экрана и 8 кликов!

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

Попал на экран? Записали! Кликнул? Записали! Проскролил экран до самого низа и потом вернулся обратно — записали!

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

Для сбора статистики на этом уровне можно сперва ограничиться системами клиентской аналитики, вроде уже знакомой Google Analytics. Но готовые системы, как правило, не дают полного понимания поведения клиентов в приложении, поэтому к ним часто добавляют самописные системы трекинга пользовательских активностей.

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