какие уровни бывают и что стоит измерять


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

Для чего нужен мониторинг и что же все-таки это такое

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

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

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

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

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

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

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

А конкретно:

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

Для анализа поведения серверов в самом ординарном виде можно употреблять штатные средства контроля по типу 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.

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

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

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

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

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


Ваш комментарий

Ваш адрес email не будет опубликован.

Для отправки комментария, поставьте отметку, что разрешаете сбор и обработку ваших персональных данных . Политика конфиденциальности

Этот сайт использует Akismet для борьбы со спамом. Узнайте как обрабатываются ваши данные комментариев.