Мониторинг микросервисов: разделяй и властвуй
Когда продукт — это сеть взаимосвязанных сервисов с большим количеством внешних зависимостей, то ответ на простой вопрос «Наш продукт работает или что-то сломалось?» и далее поиск неисправностей и узких мест превращается в нетривиальную задачу.
Моя команда разрабатывает продукт, состоящий из десятка сервисов примерно с 50 внешними зависимостями. Практически каждый сервис — это распределенная система. В том числе это означает, что сервис может работать для одних клиентов, но быть недоступен для других. Кроме того, мы предпочитаем узнавать о любых потенциальных проблемах с продуктом как можно раньше и обязательно раньше наших клиентов.
Известный принцип «разделяй и властвуй» помог нам в решении задачи мониторинга нашего продукта. Перейдя от анализа и мониторинга системы в целом к мониторингу отдельных сервисов, мы получили набор простых моделей для сервисов и внешних зависимостей. А зная состояние каждого сервиса в системе, было просто вернуться к определению состояния системы в целом.
Photo by Krists Luhaers
Основные принципы
Мы ведем постоянный мониторинг состояния нашего продукта. Для отслеживания работы внутренних частей продукта мы используем проактивный мониторинг: сервисы генерируют телеметрию, которая накапливается в общем хранилище. Данные из этого хранилища используются для оценки стабильности отдельных компонентов и системы в целом, а также для выявления предвестников проблем до того, как эти проблемы становятся критическими для функционирования системы.
Дополнительно мы поставили перед собой цель: инженеры должны быть в состоянии определить причины неисправностей без доступа к серверам. В результате наши сервисы производят огромное количество телеметрии, и это порождает еще одну проблему: как из всего многообразия данных выбрать то, что действительно покажет нам стабильность сервисов и поможет определить зарождающиеся проблемы.
Учитывая размеры системы и все ограничения, а также применение правила «разделяй и властвуй» к решению подобных задач, мы определили 3 основных принципа мониторинга:
- Каждый сервис имеет Service Level Agreement (SLA — соглашение о качестве сервиса).
- Каждый экземпляр каждого сервиса отслеживает поток входящих запросов и параметры реакции на них.
- Каждый экземпляр каждого сервиса отслеживает поток исходящих запросов к другим сервисам и параметры их реакции на эти запросы.
Кроме того, каждый экземпляр любого сервиса умеет диагностировать собственную стабильность, а также производит достаточное количество телеметрии для анализа его внутреннего состояния. Другими словами, владельцы любого сервиса имеют четкое понимание внутреннего состояния любого экземпляра этого сервиса, но при этом они могут позволить себе мало что знать о состоянии внешних зависимостей для их сервиса.
SLA — соглашение о качестве сервиса
Давайте сфокусируем внимание на одном сервисе, а все остальные будем рассматривать как внешние зависимости, даже если они разрабатываются теми же людьми.
Пользователи этого сервиса хотят знать, что они могут ожидать от него в разрезе производительности и доступности: сколько запросов может быть обработано за секунду, в течение какого времени сервис может быть недоступен и как долго обрабатывается один запрос. Обычно производительность и доступность может быть описана достаточно ограниченным набором параметров, и, что важно, они могут быть применены ко всем остальным сервисам.
Эти параметры называются Service Level Indicators (SLI — параметры качества сервиса). Wikipedia приводит достаточно хорошее описание SLI. Существует несколько популярных комбинаций этих параметров, они собраны на этом слайде.
После того как определены параметры качества и собраны метрики для них, необходимо определить диапазоны допустимых значения этих параметров. Бизнес может выставить ограничения на допустимые значения этих параметров, отталкиваясь от характеристик конкурирующих продуктов на рынке. В любом случае необходимо выполнить 2 операции: анализируя исторические данные, определить «нормальный уровень», а далее решить, какие отклонения являются допустимыми, учитывая свойства сервиса и требования бизнеса.
Имея допустимые интервалы для параметров производительности и доступности, мы определяем Service Level Objective (SLO — измеримые характеристика сервиса). Больше про SLO можно прочитать на Wikipedia. Примеры SLO: сервис должен быть доступен 99,9% времени в течение года, в 95% случаев время ответа должно быть не более 300 миллисекунд. Сохраняя запас между декларируемыми SLO и реальными характеристиками системы, мы оставляем себе возможность заранее определить негативные тренды в поведении системы и отреагировать на них.
Следующий шаг — это определение Service Level Agreement (SLA — соглашение о качестве сервиса). Wikipedia содержит неплохую статью о SLA.
Имея стабильный API и SLA, а также пройдя нагрузочное тестирование для подтверждения реальности наших оценок, наш сервис готов к работе.
Важно отметить, что когда все сервисы в цепочке вызовов имеют свои SLA, то и для продукта в целом можно определить SLA более точно. А это уже часть нашего контракта с клиентами.
Мониторинг входящего потока
Система мониторинга постоянно следит за тем, как используется сервис и как он реагирует на нагрузку.
SLA — это двустороннее соглашение, и обе стороны должны соблюдать свои обязанности. Мы доверяем пользователям нашего сервиса в том, что они будут придерживаться параметров соглашения, но всякое случается. Так что некоторая защита нашему сервису не помешает.
Каждый экземпляр сервиса отслеживает соблюдение параметров качества. Например, эти параметры определены как частота входящих запросов (запросы в секунду) и время ответа на них. Собранные метрики передаются от каждого экземпляра сервиса в централизованное хранилище, где автоматически проводится анализ, придерживаются ли клиенты и сервис параметров соглашения. Если входящий поток начинает превышать граничные значения, то сервис может начать отказывать в обслуживании некоторым запросам (конечно же, мы связываемся с клиентами, прежде чем что-то предпринять). С другой стороны, если время ответа начинает превышать граничные значения без одновременного увеличения входящего потока, то это уже сигнал для нас начать анализ проблемы.
Мы называем это «мониторингом входящего потока», потому что метрики описывают входящие запросы и реакцию на них.
Мониторинг исходящего потока
Другой важный поток запросов, который мы отслеживаем, — исходящий поток: запросы, генерируемые экземплярами нашего сервиса ко внешним сервисам и параметры их реакции на эти запросы.
Сервисы существуют не в вакууме, часто они зависят от других сервисов: базы данных, очереди сообщений, кеши и т. п. Эта часть межсервисного взаимодействия также требует защиты, чтобы лучше быть готовой к неожиданностям.
Когда экземпляр нашего сервиса отправляет запрос к внешнему сервису, мы записываем метрики, определенные как SLI этого внешнего сервиса. Так как метрики описывают поток исходящих запросов, генерируемых нашим сервисом — мы называем это «мониторинг исходящего потока».
Мониторинг исходящего потока может показаться чрезмерным усложнением, однако он позволяет нам решить несколько важнейших задач:
- мы не зависим от качества мониторинга внешнего сервиса, если мы регистрируем нарушение соглашения с их стороны — мы можем им об этом сообщить,
- мы не должны знать о деталях реализации внешнего сервиса, а можем опираться исключительно на наше соглашение,
- мы знаем, когда внешний сервис не работает именно для нас, проблемы других клиентов этого сервиса нас не должны особо беспокоить,
- при наличии полной картины исходящих и входящих потоков между сервисами появляется возможность статистического анализа потоков данных на уровне компании.
Выводы
Комбинация из SLA, мониторинга входящих и исходящих потоков дает нам:
- возможность построения системы мониторинга для распределенной системы, состоящей из набора сервисов, с внешними зависимостями;
- возможность скрывать сложность отдельных сервисов в составе системы путем описания их несколькими простыми характеристиками;
- хорошее понимание потоков данных в системе;
- возможность быстро определять сервис или экземпляр сервиса, вызывающий нестабильность системы, просто следуя по цепочке нарушений SLA;
- возможность владельцам сервиса фокусироваться на собственном сервисе, оперируя ограниченным набором данных об окружении.
Данная модель мониторинга позволяет проводить статистический анализ системы. Для отслеживания сквозного прохождения отдельных запросов необходимо добавить распределенную трассировку.
Кстати, эту статью вы также можете прочитать на английском.
