Мониторинг состояния приложений
Давайте представим, что у нас есть мониторинг серверов, и выглядит он вполне адекватно: и памяти много, и нагрузка на процессор незначительна. Но это еще далеко не все, ведь если сегодня оборудование неплохо организовано и работает как часы, то завтра можно столкнуться с ситуацией, когда все упало, программы не запущены, а ваши клиенты не могут попасть на сервер. Чтобы такой ситуации не допустить, требуется мониторинг состояния приложений.
У любого программного приложения должны существовать параметры, по которым админы и разработчики понимают, что приложение работает, и в нем происходят определенные процессы. При этом каждая программа имеет свои параметры. Как вы уже, наверное, догадались, речь идет о метриках приложений.
Ниже представлены примеры, позволяющие понять, какие именно метрики можно использовать для мониторинга состояния приложения: • число запросов в единицу времени: час, день, минута, секунда — все зависит от объема трафика; • число активных юзеров в системе в единицу времени; • число разных записей в СУБД — как записей в целом, так и новых записей в единицу времени; • число успешно отловленных и зарегистрированных ошибок.
Представим, что у вас в системе сотня-две активных пользователей, генерирующих тысячу запросов в минуту, причем случается всего одна ошибка в час. Вроде бы не страшно. А если три активных пользователя, генерирующих 10 000 запросов/мин. и получающих 5 000 ошибок? Пожалуй, уже можно забеспокоиться, причем даже в том случае, если метрики нагрузки на диски и процессор в порядке.
Для мониторинга на таком уровне подойдет специализированная СУБД, например: — Prometheus, — Graphite, — InfluxDB.
С инсталляцией самой БД проблем не будет, а вот чтобы посчитать и пробросить необходимые метрики в базу, придется попотеть, то есть потребуются усилия специалистов.
Для повышения удобства анализа к этим базам желательно подключить графический инструмент для отображения метрики и статистики — Grafana.
Существуют и другие специфические системы отлова ошибок в программном коде — они позволяют вовремя оповестить разработчиков о ситуации, которая может привести к сбою. Порой этого более чем достаточно для базовой диагностики проблем. Один из примеров такой системы — Sentry.
Статья подготовлена по материалам блога MCS.Mail.ru.
