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