Функциональные мониторинги в Яндексе

    Мониторите ли вы свои сервисы в продакшене? Чья у вас это зона ответственности?

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

    Началось все, конечно же, с автотестов для регрессионного тестирования. Эти автотесты также запускались после релиза в продакшен для проверки работоспособности сервиса в боевых условиях. Тот факт, что запущенные в продакшене регрессионные тесты иногда находят баги, заставил нас задуматься.

    Что же это и зачем


    Почему функциональные тесты, написанные для регрессионного тестирования и успешно отработавшие в тестинге, находят проблемы в продакшене?
    Мы выявили несколько причин:

    • Отличия конфигурации тестовой среды от продакшена.
    • Проблемы с внутренними или внешними поставщиками данных.
    • «Железные» проблемы, отразившиеся на функциональности.
    • Проблемы, проявляющиеся со временем и/или под специфичной нагрузкой.


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

    Поставщики данных


    Хороший пример страницы, зависящей от поставщиков данных, – это главная страница Яндекса.
    Погода и Новости, Афиша и Телепрограмма, даже фото дня с саджестом поиска – это данные от внешних и внутренних поставщиков.
    Например, в Архангельске блок Афиши однажды выглядел так:
    image
    Тогда как в Мурманске все было в порядке
    image

    Это произошло потому, что поставщик не прислал данные для Архангельска (или не обновился импорт на нашей стороне). Иногда эта проблема носит разовый характер, а в некоторых случаях могут быть сформулированы KPI по проценту доступных данных и их свежести.

    «Железные» проблемы


    В работе наших сервисов важную роль играет их отказоустойчивость и производительность. Поэтому команды создают сервисы с распределенной архитектурой и механизмами балансировки нагрузки. Выход из строя отдельных «железок», как правило, не сказывается на пользователях, однако масштабные проблемы с дата-центрами или маршрутизацией между ними бывают заметны в конечных интерфейсах.
    Отслеживать связь «железных» проблем и функциональности как раз и позволяют функциональные мониторинги, дополняющие в этой работе системные мониторинги.
    Например, в Яндекс.Директе был случай, когда медленно «погибающий» сервер стал причиной постепенной деградации сервиса, и недоступности его из некоторых регионов. Функциональный мониторинг в данном случае послужил триггером для экстренного расследования и выявления корня проблемы.
    Другой интересный пример — это учения, которые проводятся у нас в компании. Во время учений умышленно отключается один из дата-центров, чтобы убедиться, что это не скажется на работоспособности сервисов, и вовремя выявить возможные проблемы. Отключение одного дата-центра не наносит ущерб сервисам, а отслеживать ситуацию во время таких отключений помогают и функциональные мониторинги.

    Деградация сервиса с течением времени


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

    Итак, функциональные мониторинги – это функциональные автотесты, «заточенные» на поиск определенных проблем и постоянно запускаемые в продакшене.

    Что внутри


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

    Для предотвращения ложных срабатываний наша система, реализованная на основе фреймворка Apache Camel, позволяет агрегировать несколько последовательных результатов от одного теста в одно событие. Например, можно настроить фильтрацию 3 из 5, которая позволит нотифицировать о поломке только в случае, если тест выдал ошибку 3 раза в 5 последовательных запусках (аналогично можно задать, например, фильтрацию 2 из 2 или убрать фильтрацию – 1 из 1). При этом важно и то, как часто запускается тест, чтобы задержка при такой фильтрации была приемлемой.

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

    Рецепт


    Идея функциональных мониторингов очень проста, и такие мониторинги бывают очень эффективны в работе.
    Рецепт приготовления:
    1. Проанализировать, какие части вашего сервиса могут ломаться в продакшене и почему.
    2. Написать (или отобрать из имеющихся) автотесты на эту функциональность.
    3. Запускать эти тесты в продакшене так часто, как вам нужно и как позволяют системы запуска тестов.
    4. Обрабатывать результаты и нотифицировать о поломках, сравнивать с другими источниками информации о жизни сервиса.

    PS: Уже давно нас занимает вопрос, насколько распространена идея функциональных мониторингов и как она применяется в других компаниях. Кто-то говорит о таком подходе, как о само собой разумеющемся, кто-то, узнав, решает реализовать у себя, а кто-то считает такие мониторинги лишними при наличии системных мониторингов.
    А как вы отслеживаете состояние ваших сервисов в продакшене, какие инструменты и их сочетания используете?
    • +13
    • 7,5k
    • 4
    Поделиться публикацией
    AdBlock похитил этот баннер, но баннеры не зубы — отрастут

    Подробнее
    Реклама
    Комментарии 4
    • 0
      Друзья-коллеги подсказывают что существует понятие Synthetic monitoring, хотя не похоже что термин основательно укоренился.
      Также в статьях есть такие ключевые слова как Top Down monitoring и Real user monitoring
      Про опыт в различных проектах и компаниях было бы очень интересно прочитать в комментах.
      • 0
        Очень хороший и правильный пост. Функциональное тестирование в контексте мониторинга «правильности работы» — обязательная часть любого крупного проекта или сервиса. Я уже в третьей компании за свою карьеру ввожу тестирование именно в таком контексте. Кстати, позволю себе немного пропиариться, похожую услугу мы предлагаем в составе нашего сервиса www.trackfort.com/
        • 0
          Занятно, что в интернете в основном и встречаются по этой теме SaaS предложения. При этом, если на сервисе есть автотесты и есть кому их писать, то сделать такую систему у себя не представляется слишком уж сложной задачей.

          Так или иначе основные интересные вопросы — это
          1. Выбор функциональности для мониторинга, не все имеет смысл мониторить
          2. Работа с большим потоком результатов и их фильтрация
          3. Интеграция информации от таких мониторингов в общую картину
          Ну и, как я уже писал ранее, интересно как такой вид проверок приживается в различных командах разработки и как дополняет/конкурирует с более низкоуровневыми мониторингами
          • 0
            Мы используем Selenium-тесты для проверки работоспособности нашего сервиса.

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

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

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