12.4к
0
0
Скопировать ссылку
Telegram
WhatsApp
Vkontakte
Одноклассники
Назад

Как выбрать правильные инструменты в мониторинге и учиться на чужих ошибках

Время чтения 2 минуты
Нет времени читать?
Скопировать ссылку
Telegram
WhatsApp
Vkontakte
Одноклассники
12.4к
0
0
Нет времени читать?
Скопировать ссылку
Telegram
WhatsApp
Vkontakte
Одноклассники

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

Меня зовут Ахмад Боков, и я разработчик с 2015 года. Сначала я был линейным программистом, затем стал тимлидом, дорос до руководителя разработки и открыл студию «Искусство автоматизации» в 2018 году. В нашей компании мы сделали более 100 проектов — это микросервисы, чистый бэкенд, API, чат-боты. Всё это надо мониторить. 

Как выбрать правильные инструменты в мониторинге и учиться на чужих ошибках

У меня был большой опыт работы на проектах, связанных с критической инфраструктурой, где падение было недопустимо. Это не сайты с шортсами, которые могут позволить себе «полежать», а госпроекты, которые должны стабильно работать даже под постоянной стрессовой нагрузкой. Если случалось что-то экстраординарное, то мы должны были об этом узнать раньше всех.

Такие требования и сформировали мое мировоззрение в области мониторинга. Я обеспечивал инфраструктуру и в качестве разработчика, и в качестве руководителя службы второй линии поддержки. К тому же я окончил Московский авиационный институт. Там учат авиации, где тоже нет права на ошибку. В общем, как видите, я парень, замороченный на теме мониторинга. 

Из чего складывается мониторинг?

Мониторинг — не явный процесс. Мы вспоминаем о нем, когда что-то идет не так. Если происходит сбой, мы сразу спрашиваем: «А где был мониторинг? Почему не среагировали?»

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

Другая популярная ошибка — когда при создании проекта пишут ТЗ с основными этапами: разработать и протестировать проект, а потом запустить. Вот между «протестировать» и «запустить» должна быть постановка проекта на мониторинг. Более того, у вас должно быть конкретно прописано, что вы будете мониторить. И без решения этой задачи нельзя приступать к следующему бизнес-процессу.

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

Что обязательно надо мониторить и как настроить алерты?

URL, веб-адрес проекта

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

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

Контроль места на диске

Бывают такие случаи, что проект запущен, всё вроде отлично, а потом — бах! — логи сожрали всё место. Классика жанра.

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

Если бы мы не настроили алерт, то после переполнения диска система встала бы на 2–3 часа — пострадал бы бизнес.

Проверка сервера на ресурсы

Контроль памяти, ЦП — то, что является показателем нагрузки. Скажем, у вас на сервере есть сайт, где проходит голосование на звание «Лучший комик года». Туда могут зайти два человека или 500 посетителей, и проблем не возникнет. Но если зайдут пять тысяч, то всё дружно может упасть. А этот мониторинг обеспечивает контроль показаний самого сервера.

SSL-сертификаты

Срок действия этих сертификатов может подойти к концу, и пользователь просто увидит «Ваше соединение не защищено». Мало кто из пользователей будет искать скрытую кнопку «Все равно открыть сайт», большинство просто закроет страницу и уйдет. Годность SSL-сертификатов надо регулярно проверять.

Ошибки внутри браузера (на стороне JavaScript)

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

Веб уже давно стал сложнее, чем HTML-страница с JS-скриптом на 100 строк, ведь нужно выполнять валидацию форм, анимацию интерфейсов, отправлять данные на сервер. Буквально на каждой кнопке сложного интерфейса что-то может пойти не так. Самое примечательное, что до сервера, где сосредоточены основные силы мониторинга, информация об ошибке попросту может не дойти. Очевидно, нужно контролировать и мониторить выполнение JavaScript в браузере.

Мы мониторим события JavaScript с помощью сервиса Sentry. Достойной замены пока не нашли.

Мониторинг бизнес-точек

Это мониторинг, который обеспечивает проверку выполнения бизнес-функции вашего проекта.

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

Другой пример — у вас формируются отчеты по выгрузке товаров с маркетплейса. Тогда вы настраиваете систему таким образом, чтобы получать алерт, если у вас нет папки сформированных отчетов с файлами за сегодня. Отчет может не сформироваться по множественным причинам — например, потому что лежит FTP-сервер или база данных. В результате вы будете уверены, что сервис работает, делает это под нагрузкой и реально выполняет свою функцию.

Чтобы мониторить бизнес-функционал, мы создаем специальный handler в коде. Если он ловит ошибки при выполнении программы, мы получаем информацию об этом в Телеграм. Это более глубокий мониторинг на уровне выполнения программы. 

При настройке алертов анализируйте бизнес-процессы конкретного клиента. Скажем, есть нормальное значение для сервиса проведения конкурса — 300 загрузок в час. Но вдруг этот показатель падает до 10. На первый взгляд это неуловимое событие. Вроде система работает, но что-то идет не так. Если поставить алерт на подобную аномалию, то можно будет отловить какой-то баг: отвалился микросервис или недоступен другой элемент. 

Главный лайфхак по настройке алертов к определенному сервису — задать вопрос: «А что для нас страшная ситуация?»

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

Так как большинство наших проектов написаны на стеке Java, мы используем дружественный языку стек технологий Elastic Logstash Kibana (ELK).

Особенности мониторинга в эпоху санкций

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

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

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

Как мы мониторим закрытые системы

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

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

Существует несколько вариантов. Первый — вы можете развернуть подсистему мониторинга непосредственно в контуре заказчика. Другой вариант — можно выступить в качестве второй линии поддержки. В этом случае, конечно, проактивный мониторинг вы не сможете обеспечить, но будете работать по тикетам.

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

Наша эволюция: почему нам не нужен слон в посудной лавке

Выбирая инструменты мониторинга, мы прошли несколько этапов.

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

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

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

Тогда мы прошли по пути упрощения и обратили внимание на зарубежный сервис UptimeRobot. 

Проект позволял нам мониторить по URL, отправлял алерты в мессенджеры, пуши на телефон, в приложение и на почту. Но потом мы поняли, что вырастаем из этого инструмента.

Затем мы обратились к серверному open-source решению Uptime Kuma. Такое решение подходит тем, у кого не микросервисная архитектура, а монолит. Это может быть небольшой портал или мобильное приложение. И все это помещается максимум на 2–3 серверах. 

Дашборд сервиса Uptime Kuma
Пример страницы проекта в сервисе Uptime Kuma

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

Пример алертов от телеграм-бота

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

Заключение

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

Если вы задумались о внедрении процесса мониторинга для вашего IT-проекта, используйте этот чек-лист для быстрого старта:

✅ Есть мониторинг доступности внешних точек системы (статус 200).

✅ Есть контроль места на диске.

✅ Настроен алерт в Телеграм или на почту для ситуации, если диск заполнен на 80%.

✅ Есть мониторинг загрузки оперативной памяти и ресурсов процессора.

✅ Срок действия SSL-сертификатов проверяется автоматически.

✅ Есть мониторинг ошибки на стороне фронтенда и бэкенда.

✅ Есть регулярная задача по изучению логов и ошибок.

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

✅ Есть бизнес-алерты на случай, если ПО не выполняет бизнес-задачи.

Всем аптайма 99,(9)!

Комментарии0
Тоже интересно
Комментировать
Поделиться
Скопировать ссылку
Telegram
WhatsApp
Vkontakte
Одноклассники