Мониторинг в еком-проекте. С чего начать

Эта статья призвана рассказать об азах использования систем мониторинга в еком-проектах с точки зрения практической пользы.

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

Онлайн-торговля — непрерывное взаимодействие с покупателем в нескольких воронках. Одна из воронок — это сайт или мобильное приложение, то есть то место, где проходит непосредственно процесс выбора товара и его покупка. Мониторинг в данном случае — глаза и уши этой воронки. Владелец бизнеса и компания-разработчик проекта должны точно понимать (а лучше еще и контролировать), что и в какой момент происходит в системе и какой опыт при этом возникает у пользователя. Комплексы мониторинга делают решение этой задачи возможным.

Для наглядности поделим все системы на 3 класса:

1. Мониторинг инфраструктуры следит за серверами и всеми системами, отвечающими за физическое и виртуальное размещение проекта.
2. Мониторинг приложения — следит непосредственно за состоянием нашего сайта, приложения или его конкретных сервисов.
3. Мониторинг пользовательского поведения — собирает данные о действиях пользователей. К нему можно также отнести общепринятые сервисы аналитики, такие как Google Analytics и Яндекс.Метрика.

Сегодня более подробно остановимся на использовании первых двух.

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

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

Такие услуги могут предоставлять:

• Сами дата-центры (в качестве опции при размещении).
• Специализированные на системах мониторинга и аналогичных продуктах компании (чаще всего являются реселлерами продуктов крупных вендоров).
• Внешние интеграторы, занимающиеся разработкой и/или поддержкой самого еком-проекта.

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

Важно отметить, что при размещении в ДЦ инфраструктурный мониторинг чаще всего входит в «джентльменский набор» услуг. Это стоит обязательно выяснить и получить доступы к панели управления. Во многих случаях (особенно, в небольших проектах) систем, предоставляемых в таком формате, вполне хватит для того, чтобы получать базовую информацию и не тратиться на установку и лицензии отдельных сервисов.

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

Любой еком динамичен и требует масштабирования, а значит, необходимо постоянно отслеживать, как система выдерживает растущие нагрузки. Авария на уровне инфраструктуры почти всегда означает цепную реакцию и отказ всего остального. Логично, что еще более важной задачей, чем отслеживание, является предупреждение потенциальных угроз. Делается это с помощью настройки специальных триггеров — при наступлении определенного события (например, на диске осталось менее 20% свободного пространства) система генерирует соответствующий алерт. Он, в свою очередь, направляется команде по любым выбранным каналам (к примеру, удобно использовать для этого ботов в Телеграм). Аналогично работают и сообщения о том, что все в порядке и система вернулась в штатный режим. Алерты могут иметь разный уровень критичности и заблаговременно подсветить большинство потенциальных проблем. Общее число триггеров может измеряться десятками, а иногда и сотнями событий. Здесь лучше руководствоваться принципом - чем больше знаем, тем лучше.

Часто этот класс решений называют APM (application performance monitoring). Здесь мы уже видим показатели самого приложения — то, насколько быстро работает бэкэнд, база данных, какие транзакции наиболее тяжеловесны:

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

Важнейший показатель, который измеряет APM и на который стоит обращать внимание — APDEX®.

Апдекс — общепринятый формат определения индекса производительности любого приложения. Формируется он из совокупности множества тех самых показателей, которые вы видите на диаграммах и графиках в APM. Простым языком — это индикатор того, насколько пользователь удовлетворен при работе с вашей системой по шкале от 0 до 100. Хорошим отраслевым стандартом считаются значения APDEX выше 85. То, что ниже 75 уже требует пристального внимания. Важно отметить, что APDEX это универсальное понятие для любых информационных систем, поэтому корректно настраивать шкалу его измерения нужно исходя из типа проекта. К примеру, одни и те же показатели для пользователей публичной части интернет-магазина и служебного ПО, вроде 1С, будут отличаться.

Стоит отметить, что рынок систем мониторинга довольно обширный — каждый вендор старается охватить максимальное количество сегментов — от потребностей частных лиц до энтерпрайз-систем для корпораций. При этом разработчик также пытается выпустить решения для всех видов мониторинга. Иногда это может быть один всеобъемлющий продукт, который обещает «все-в-одном», кто-то, напротив, позиционирует разные продукты под разные нужды. Так, иногда функции систем мониторинга инфраструктуры и приложений часто смешиваются.

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

• Zabbix + Grafana - для мониторинга инфраструктуры. Zabbix — это непосредственно сама система сбора метрик (кстати, отечественная разработка), а Grafana обеспечивает удобное (и, кстати, красивое) их отображение. Opensource.
• New Relic APM — для мониторинга приложения. Есть как бесплатные версии с ограничениями (но вполне подойдут для небольших и средних проектов или на старте), так и корпоративные тарифы. Плюс огромное количество плагинов и способов расширить горизонты мониторинга.

Также рекомендуем обратить внимание на:

• Monit — для начала и простых проектов.
• Atatus — как хорошую альтернативу New Relic.
• Продукты от Solarwind и Nagios — как комплексные системы для разных задач.
• Dynatrace — как Enterprise решения.

Выбор конкретной системы мониторинга не так важен, как само ее наличие. Что важно запомнить и использовать на практике:

• Внедрить мониторинг сразу при запуске екома.
• Выбирать конкретные системы.
• Настроить систему алертов так, чтобы увидеть не только аварию, но и предшествующие ей проблемы (загрузка процессора, место на диске, просроченный сертификат).
• Регулярно проверять апдекс. Он не менее важен, чем конверсия.

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

Автор материала: Антон Порохня

#мониторинг #apdex #zabbix #grafana #newrelic