�ݺ�ߣ

Editor's Notes

• #2: Добрый вечер, коллеги Сегодня будет короткий доклад из серии "и так тоже можно". А расскажу я про функциональный мониторинг.  Вообще википедия настаивает на том, что Мониторинг это непрерывный процесс наблюдения и регистрации параметров объекта, в сравнении с заданными критериями. Ну, звучит вроде разумно, давайте с этой стартовой точки и начнем
• #3: С моей точки зрение мониторинг в нашей области можно разделить на 2 большие группы – технический мониторинг (это когда мы наблюдаем за потреблением памяти, например или на уровне приложения за количеством запросов, попаданием в кеш или временем ответа) И бизнес мониторинг. Это когда мы отслеживаем критичные параметры для конкретного бизнеса. Например, для интернет магазина это может быть количество заказов Обычно такой мониторинг работает по факту случившегося события – зарегистрировался новый пользователь – посчитали
• #4: Но иногда нам ждать совершенно не хочется и проще всего нужное событие инициировать. Например, притвориться пользователем и положить товар в корзину. Для этого мы написали по сути подвид бизнес мониторинга и назвали его функциональным мониторингом Немного предыстории – у нас есть довольно любопытная особенность – компания не так давно перестала быть стартапом-стартапом и стала двигаться в сторону разумной формализации. Поэтому так исторически сложилось, что на нашем пре-продакшене (стейджинге) одновременно могут что-то делать примерно 500 человек +- и тестировать около 60 микросервисов. Релизы у нас частые, так что держать эту среду рабочей довольно интересное развлечение. Что бы упростить себе жизнь мы написали первую версию мониторинга как раз для стейджингов Получилось сразу несколько хороших вещей – мы быстро понимаем, работают ли стейджинги в принципе и можно ли стартовать регрессию; можно показать дашборд в графане менеджеру, который может, например, помочь с ускорением починки. Ну и заодно это такая иллюстрация то, где застряла новая фича и почти понятно кто виноват (на самом деле нет, но не важно) Был период, когда нам это прямо очень сильно помогало Кроме стеджингов у нас есть ещё совершенно прекрасные тестовые среды для проверки конкретной задачи. Они создаются по требованию и уничтожаются когда уже не нужны. При запуске второй версии этих шоурумов мы адаптировали мониторинг для проверки их базовой работоспособности (к сожалению, это нельзя было понять из технического мониторинга). Это очень сильно нам помогло в борьбе за их стабильность и адекватность. За несколько месяцев стабильность тестовых сред выросла с 30% до 80%+ и продолжает там держаться
• #5: Давайте немного поговорим о реализации мониторинга В целом есть два основных вида: push мониторинг – это когда у нас есть специальное место и мы по какому-то событию кладем в него данные И pull мониторинг – это когда у нас есть специальная страница где мы метрики показываем, а за ними уже приходят те, кому это больше всего нужно Применительно к нашей ситуации – мы запускаем проверки функционала по расписанию и держим специально выставленный сервис с метриками
• #6: Если говорить про наш случай, но в общем-то проблема выбора инструментов была для нас, её решили и мы просто воспользовались тем, чем есть У нас уже докеризация идет полным ходом + сервера линуксовые + изоляции на этом уровне нам вполне достаточно Питон и селениум у нас уже для тестов Графана и Прометей уже используются для мониторинга Прометей – агрегатор метрик. Эффективное хранение и обработка больших объемов Графана – для отображения и показа разной аналитики В общем-то всё опенсорс Ифлюксдб у нас появился можно сказать внезапно. Прометей вообще считает, что пуш мониторинг это какой-то антипаттерн и нечего, делайте нормально. Вообще у них есть pushgateway, но нам он не подошел.
• #7: Давайте немного поговорим про реализацию этих прекрасных идей В целом при текущем уровне развития его очень просто собрать из готовых кубиков. Я бы даже сказала невероятно просто и сделать это может любой кто может написать хоть один тест Проверки вам конечно придется написать самостоятельно, но вся обвязка укладывается буквально в 30 строчек на питоне В принципе достаточно питона и prometheus-client Мы используем Schedule для запуска по расписанию И Retrying чтобы перехватывать определенные типы ошибок и перезапускать сценарии (это про устойчивость)
• #8: Вариант написан по доброй традиции для google.com
• #9: И он рабочий, я проверяла!