Версия сайта для слабовидящих
В этой статье для обучения дата-инженеров и архитекторов распределенных систем рассмотрим, что такое наблюдаемость, как ее измерить и при чем здесь стандарт OpenTelemetry. А в качестве примера разберем, как французский маркетплейс Cdiscount управляет почти 1000 микросервисов в кластере Kubernetes с Apache Kafka, Jaeger, Elasticsearch и OpenTelemetry.
Наблюдаемость распределенной системы: стандарт OpenTelemetry и инструментальные средства
Термин «наблюдаемость» пришел в разработку ПО из области технического управления и, по сути, означает возможность понимать состояние системы в любой момент времени, включая обнаружение сбоев и прочих инцидентов с прослеживаемостью причин их возникновения. В случае программной системы наблюдаемость обеспечивается через непрерывный мониторинг метрик, логово и трассировок. Дадим определение этим понятиям:
- Метрики – это числовые представления агрегированного состояния за определенный период времени;
- Логи — структурированные, удобочитаемые представления событий;
- Трассировки — набор метаданных, которые можно связать с жизненным циклом отдельного объекта в системе, такого как запрос или транзакция.
В случае распределенных систем хранения и аналитики больших данных наблюдаемость необходима, поскольку обычно они состоят из множества взаимосвязанных компонентов и играют важную роль для реализации оперативных и стратегических бизнес-задач. Например, французский маркетплейс Cdiscount с 10-летней историей насчитывает огромное количество пользователей, для поддержки которых активно используется современная Big Data инфраструктура. Она включает практически 900 микросервисов в кластере Kubernetes на почти 30 000 ЦП. Чтобы вычислить результат, запрос, клиент или система пересекают несколько контейнеров. Для обеспечения бизнес-требований доступность всей платформы держится на уровне 99,99%, поэтому все инциденты должны быть точно и быстро идентифицированы, а также устранены. Для этого используется система мониторинга и оповещения на базе Apache Kafka, Jaeger и OpenTelemetry.
Напомним, OpenTelemetry – это современный стандарт распределенной трассировки и мониторинга, который появился в 2019 году как объединение ранее существовавших стандартов OpenTracing и OpenCensus. OpenTelemetry предоставляет SDK для ручного и автоматического подключения к различным сервисам и СУБД, чтобы собрать их метрики и трассировки через коллектор, который запускается отдельным приложением либо контейнером в пользовательскую инфраструктуру. В качестве сервера трейсинга для OpenTelemetry часто используется Jaeger – open-source система мониторинга и трассировки распределенных микросервисных систем от Uber. Jaeger поддерживает потоковую стратегию развертывания в Kubernetes благодаря интеграции с Apache Kafka, Kafka, которая выступает в качестве middleware и находится между коллектором, что получает трассировки от агентов и прогоняет их по конвейеру обработки, и хранилищем, где хранятся сами трассировки. Именно такая архитектура и выбрана инженерами Cdiscount.
Каждый микросервис по отдельности предоставляет метрики и логи, которые сообщают о состоянии его работоспособности, вызывают оповещения и позволяют проводить отладку при возникновении инцидента. Однако каскад множества вызовов между различными контейнерами не позволяет сразу точно определить, какой компонент на самом деле стоит за инцидентом, т.к. все сервисы, приводящие к проблеме, вызывают предупреждения одновременно. Это увеличивает время поиска решения и исправления проблемы. Поэтому инженеры Cdiscount решили перенастроить распределенные трассировки так, чтобы выделить все микросервисы, через которые проходит пользовательский запрос, и увидеть время, которое запрос проводит в коде приложения каждого компонента.
Трассировка показывает путь данных или выполнения через систему и определяется одним идентификатором и по крайней мере одним диапазоном. Она включает в себя название операции, время начала и продолжительность. Как мы уже отметили выше, популярным средством трассировки является Jaeger, отлично совместимый со стандартом OpenTelemetry. Jaeger используется в качестве серверной части для хранения трассировок, а OpenTelemetry распространяет и обогащает их. Роль хранилища часто выполняет NoSQL-СУБД Elasticsearch, которая поддерживает быструю индексацию документов и нечеткий поиск по тексту. В Cdiscount весь этот стек развернут в Kubernetes с помощью Helm Chart, а для CI/CD применяется Azure DevOps. Как все это работает, рассмотрим далее.
Архитектура и принципы работы системы мониторинга микросервисов
Jaeger получает трассировки, поступающие от приложений, подтверждает их, индексирует, делает выборки, а затем отправляет в Kafka. Выборка означает, что сохраняется только часть трассировок, и они могут обрабатываться как на сервере, так и на стороне клиента. Необходимо найти баланс между использованием дискового пространства и обнаружением слабых сигналов: большой объем хранимых трассировок стоит денег, но помогает находить редкие проблемы. Поэтому инженеры Cdiscount решили настроить выборку на стороне сервера, чтобы иметь единую стратегию для всей платформы. Одной из стратегий работы с выборкой является ограничение скорости, что позволяет установить определенное количество трассировок в секунду. Например, 20 означает, что Jaeger сохранит первые 20 трассировок в секунду для конкретного сервиса, а другие трассировки в пределах этого промежутка времени игнорируются. По истечении секунды счетчик сбрасывается на 0. Но этот метод хранения может внести статистическую погрешность, сохраняя только начальные трассировки каждого временного периода, поэтому данная стратегия была отброшена.
Вместо ограничения скорости был выбрана вероятностная стратегия, где задается процент трассировок, которые необходимо сохранить. Например, значение 20% означает, что Jaeger сохранит только примерно 2 трассировки из каждых 10 полученных. Выбор трассировок для сохранения выполняется в случайном порядке, что позволяет эффективно получать выборку трассировок всех возможных типов. Установив глобальную вероятностную стратегию, которая применяется по умолчанию, можно задать исключения для определенных сервисов и конечных точек, где нужно сохранить 100% всех трассировок. Так можно регулировать процент сохраняемых трассировок для каждого сервиса. Например, если сервис оставляет мало трассировок, можно увеличить процент сохраняемых следов для этой службы. И, наоборот, если сервис оставляет слишком много трассировок, можно снизить процент сохранений без ущерба для других существующих сервисов. Поскольку в системе Cdiscount насчитывается более 2000 приложений, в целом создается и собирается очень большое количество трассировок. Чтобы сохранить их, используется Apache Kafka. А приемник Jaeger потребляет их из Kafka и отправляет в Elasticsearch, где и сохраняются трассировки.
Срок хранения в Elasticsearch установлен на неделю, т.к. хранить трассировки дольше этого времени нецелесообразно, поскольку они в основном используются для отладки. Метрики уже используются для мониторинга задержки микросервисов. Для просмотра трассировок и их поиска используется Jaeger Query с наглядным GUI.
В качестве средства визуализации в Cdiscount выбрана Grafana – open-source система визуализации системных метрик. Источником данных для нее является бэкенд Jaeger. Преимущества использования Grafana для просмотра трассировок заключаются в аутентификации и корреляции между логами, трассировками и метриками, а также наличие единого интерфейса для просмотра всех этих данных.
Таким образом, используя шаблонную комбинацию Apache Kafka, Jaeger, Elasticsearch и OpenTelemetry дата-инженеры маркетплейс Cdiscount смогли улучшить наблюдаемость своей микросервисной платформы, а также повысить точность и скорость обнаружения инцидентов с учетом корреляции сигналов разных типов: метрик, логов и трассировок.
Читайте в нашей новой статье про применение Apache Kafka к проблеме параллелизма распределенных микросервисов.
Больше практических кейсов по построению комплексной дата-архитектуры и эффективной эксплуатации Apache Kafka для потоковой аналитики больших данных вы узнаете на специализированных курсах в нашем лицензированном учебном центре обучения и повышения квалификации для разработчиков, менеджеров, архитекторов, инженеров, администраторов, Data Scientist’ов и аналитиков Big Data в Москве:
Источники
