Мониторите ли вы свои сервисы в продакшене? Чья у вас это зона ответственности?
Часто, когда речь заходит о мониторингах, приходят на ум серверные разработчики, системные администраторы и DBA, которые должны следить за очередями обработки данных, наличием свободного места на дисках, за жизнеспособностью отдельных хостов и нагрузкой.
Такие мониторинги действительно дают много информации о сервисе, но далеко не всегда показывают, как сервис работает для реального пользователя. Поэтому, в качестве дополнения к системным мониторингам, мы создали в Яндексе систему функциональных мониторингов, отслеживающих состояние сервиса через конечные интерфейсы – через то, как приложение выглядит и работает в браузере, и то, как оно работает на уровне API.
Что же такое функциональные мониторинги в нашем понимании? Чтобы лучше это понять, давайте посмотрим на то, как все развивалось.
Началось все, конечно же, с автотестов для регрессионного тестирования. Эти автотесты также запускались после релиза в продакшен для проверки работоспособности сервиса в боевых условиях. Тот факт, что запущенные в продакшене регрессионные тесты иногда находят баги, заставил нас задуматься.
Что же это и зачем
Почему функциональные тесты, написанные для регрессионного тестирования и успешно отработавшие в тестинге, находят проблемы в продакшене?
Мы выявили несколько причин:
- Отличия конфигурации тестовой среды от продакшена.
- Проблемы с внутренними или внешними поставщиками данных.
- «Железные» проблемы, отразившиеся на функциональности.
- Проблемы, проявляющиеся со временем и/или под специфичной нагрузкой.
Если такие тесты могут находить проблемы, мы решили, что нужно попробовать запускать их регулярно в продакшене и мониторить состояние сервисов.
Давайте поподробнее рассмотрим проблемы и задачи, с решением которых могут помочь функциональные мониторинги.
Поставщики данных
Хороший пример страницы, зависящей от поставщиков данных, – это главная страница Яндекса.
Погода и Новости, Афиша и Телепрограмма, даже фото дня с саджестом поиска – это данные от внешних и внутренних поставщиков.
Например, в Архангельске блок Афиши однажды выглядел так:
Тогда как в Мурманске все было в порядке
Это произошло потому, что поставщик не прислал данные для Архангельска (или не обновился импорт на нашей стороне). Иногда эта проблема носит разовый характер, а в некоторых случаях могут быть сформулированы KPI по проценту доступных данных и их свежести.
«Железные» проблемы
В работе наших сервисов важную роль играет их отказоустойчивость и производительность. Поэтому команды создают сервисы с распределенной архитектурой и механизмами балансировки нагрузки. Выход из строя отдельных «железок», как правило, не сказывается на пользователях, однако масштабные проблемы с дата-центрами или маршрутизацией между ними бывают заметны в конечных интерфейсах.
Отслеживать связь «железных» проблем и функциональности как раз и позволяют функциональные мониторинги, дополняющие в этой работе системные мониторинги.
Например, в Яндекс.Директе был случай, когда медленно «погибающий» сервер стал причиной постепенной деградации сервиса, и недоступности его из некоторых регионов. Функциональный мониторинг в данном случае послужил триггером для экстренного расследования и выявления корня проблемы.
Другой интересный пример — это учения, которые проводятся у нас в компании. Во время учений умышленно отключается один из дата-центров, чтобы убедиться, что это не скажется на работоспособности сервисов, и вовремя выявить возможные проблемы. Отключение одного дата-центра не наносит ущерб сервисам, а отслеживать ситуацию во время таких отключений помогают и функциональные мониторинги.
Деградация сервиса с течением времени
Реальные условия эксплуатации приложения в продакшене иногда создают непредвиденные ситуации. Причиной проблем может быть непредвиденное сочетание объема, продолжительности и типа нагрузки или же, например, накопление системных ошибок, не выявленных на стадии тестирования. Причиной также могут послужить ошибки в настройке инфраструктуры, приводящие к замедлению системы или выходу ее из строя.
Если такие проблемы не удается выявить на стадии тестирования, необходимо быстро распознать их, если они произойдут в продакшене. И здесь системные и функциональные мониторинги могут, дополняя друг друга, находить проблемы и сообщать о них.
Итак, функциональные мониторинги – это функциональные автотесты, «заточенные» на поиск определенных проблем и постоянно запускаемые в продакшене.
Что внутри
Есть и вторая составляющая функциональных мониторингов – то, как обрабатывается поток результатов.
Большой поток результатов, приходящих от постоянно запускающихся в продакшене тестов, необходимо упорядочивать и фильтровать. Необходимо своевременно сообщать о проблемах и в тоже время минимизировать ложные срабатывания. Также возникает задача интеграции информации от функциональных мониторингов в общую систему оценки работоспособности сервиса.
Для предотвращения ложных срабатываний наша система, реализованная на основе фреймворка Apache Camel, позволяет агрегировать несколько последовательных результатов от одного теста в одно событие. Например, можно настроить фильтрацию 3 из 5, которая позволит нотифицировать о поломке только в случае, если тест выдал ошибку 3 раза в 5 последовательных запусках (аналогично можно задать, например, фильтрацию 2 из 2 или убрать фильтрацию – 1 из 1). При этом важно и то, как часто запускается тест, чтобы задержка при такой фильтрации была приемлемой.
На разных проектах потребители этих мониторингов разные: где-то результаты мониторингов замыкаются на тестировщиков, об отдельных мониторингах интересно знать менеджерам, где-то результаты интегрируются в общую систему.
Рецепт
Идея функциональных мониторингов очень проста, и такие мониторинги бывают очень эффективны в работе.
Рецепт приготовления:
1. Проанализировать, какие части вашего сервиса могут ломаться в продакшене и почему.
2. Написать (или отобрать из имеющихся) автотесты на эту функциональность.
3. Запускать эти тесты в продакшене так часто, как вам нужно и как позволяют системы запуска тестов.
4. Обрабатывать результаты и нотифицировать о поломках, сравнивать с другими источниками информации о жизни сервиса.
PS: Уже давно нас занимает вопрос, насколько распространена идея функциональных мониторингов и как она применяется в других компаниях. Кто-то говорит о таком подходе, как о само собой разумеющемся, кто-то, узнав, решает реализовать у себя, а кто-то считает такие мониторинги лишними при наличии системных мониторингов.
А как вы отслеживаете состояние ваших сервисов в продакшене, какие инструменты и их сочетания используете?
Автор: lev_sha
