Что мы говорим богу смерти? Мониторинг бэкенда

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

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

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

Как мониторить всё и вся?

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

Развертывание таких мониторингов требует:

1. Настройки кластера серверов для приложений мониторинга. Сюда входят серверы с СУБД для хранения событий мониторинга, серверы сбора информации (они агрегируют входящие потоки событий из разных участков вашей системы) и серверы с веб-интерфейсами для работы с результатами наблюдений.
2. Настройка агентов мониторинга. Агенты — маленькие программы, которые умеют отслеживать состояния серверов, каналов связи и других программ. Есть даже агенты мониторинга, которые следят за другими агентами мониторинга, чтобы не было ситуации, когда наблюдатель сдох и не смог сообщить о сбое в сборщик событий.

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

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

Но, как говорил Козьма Прутков, иногда лучше перебдеть, чем недобдеть!

Мониторинг ошибок приложений

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

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

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

Один из лидеров на рынке таких сервисов сегодня – система мониторинга Sentry, которая позволяет собирать отчеты об ошибках не только с бэкенда, но и из JavaScript-приложений в браузерах пользователей.

Мониторинги ошибок приложений для ленивых

Ещё одна хорошая новость. Для того, чтобы упростить ввод в бой сервисов по отлову ошибок, на рынке появились продукты, которые делают процесс сбора отчетов о проблемах совершенно элементарным.

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

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

Мониторинг доступности

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

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

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

«Уповайте на бога, но порох держите сухим»

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

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