Виктор Ерёмченко. Ключевые метрики стабильности,или Как мы мониторим аналитическую платформу в Авито

Специалист, отвечающий за стабильность платформы в Авито, представил доклад, посвященный ключевым метрикам стабильности и методам мониторинга аналитической платформы. Основная задача платформы заключается в получении, обработке и предоставлении данных пользователям. В основе системы лежат три движка: Vertica, ClickHouse и Trina. При этом Vertica играет наиболее массивную роль, храня основную часть данных.

Платформа оперирует объемом данных, превышающим один петабайт, полученным от различных сервисов и баз данных, включая PostgreSQL, MySQL и MongoDB, а также из Kafka Stream. Ежедневно более 300 аналитиков используют эти данные, генерируя суммарно более миллиона SQL-запросов к платформе.

Существуют четкие ожидания по готовности данных: критичные данные должны быть доступны к 9:00 утра, важные — к 10:00, а все остальные — к 12:00. Поскольку это аналитическая платформа, данные загружаются с задержкой в один день (день -1). Однако, несмотря на это, в некоторых случаях пользователи сообщали об отсутствии данных, хотя внутренние метрики системы не фиксировали проблем.

Для решения проблемы были выбраны две основные метрики: время готовности данных и доступность компонентов. Время готовности измеряется как простой платформы, если данные не готовы к установленному сроку (например, 30 минут задержки приравниваются к 30 минутам недоступности). Доступность компонентов касается возможности аналитиков выполнять запросы к хранилищам.

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

Первоначальный расчет этих метрик показал серьезные проблемы: за квартал было зафиксировано суммарно 240 часов отставания данных и около 40 часов недоступности Vertica, основного компонента хранения.

Для сбора метрик первоначально использовались общедоступные инструменты Авито, такие как Grafana, данные о выполнении приложений и внутренняя информация Vertica. Были сформулированы требования к новой системе: переиспользование существующих компонентов, гибкость в написании кастомных метрик и долгое хранение данных. В итоге выбор пал на ClickHouse для хранения и Vector для обработки.

Vector выполняет роль сборщика (скрепера) и форматировщика метрик, приводя их в нужный вид и обогащая. Он также может генерировать кастомные метрики. Дополнительно Vector дублирует метрики в Grafana, вписываясь в существующую архитектуру.

При мониторинге доступности Vertica, которая является отказоустойчивой базой, падение одной ноды переключает нагрузку на реплику. Однако это может влиять на загрузку данных и SQL-запросы. Системная таблица Vertica для проверки статуса нод может отвечать долго под высокой нагрузкой, вызывая ложные срабатывания (false positives) алертов.

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

Другой проблемой является потребление памяти пользовательскими функциями, написанными на Python, которые могут быть неоптимальными. Когда срабатывает киллер и убивает процесс из-за высокого потребления памяти, это также убивает Vertica. Vector используется для обогащения метрики потребления памяти, добавляя номер сессии, что позволяет дежурному выполнить команду `kill session` и решить проблему вручную, хотя полное автоматическое решение в этом кейсе не было принято.

При падении ноды Vertica пропадают локальные временные таблицы, что приводит к падению загрузок или расчетов витрин, влияя на время готовности данных. Возникает дилемма: исправлять отказоустойчивость на стороне базы данных или на стороне приложения. Выбран подход повышения отказоустойчивости самого приложения.

Каждая ошибка обрабатывается индивидуально: для одних требуется перезапуск этапа загрузки или сброс сессии, для других — перезапуск всего потока расчета витрины. Приложение было доработано так, чтобы при падении ноды базы данных все отрабатывалось автоматически, что минимизировало влияние на время готовности. Около 40% инцидентов было связано с падением нод до внесения изменений.

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

В результате предпринятых мер удалось добиться значительного улучшения показателей. На основном кластере Vertica время даунтайма было сведено к нулю, хотя падения отдельных нод все еще происходят. На втором кластере, с которым работают пользователи, наблюдается частичная деградация из-за неоптимальных запросов, которые могут завалить весь кластер.

Помимо повышения устойчивости приложений, была проведена миграция части данных в Trina, что позволило освободить ресурсы Vertica для оставшихся расчетов. Это привело к снижению общего числа инцидентов и сокращению времени расчета. Отставание данных снизилось с 240 часов до 150 часов за квартал, при целевом показателе в 120 часов.

В планах развития — создание единой точки входа для пользователей, отображающей статус платформы и метрики готовности, чтобы исключить обращение пользователей в чаты с вопросами о статусе данных. Также планируется анализ рискованных запросов на ранних стадиях, чтобы отбивать их до начала выполнения на Vertica.

В секции вопросов обсуждался жизненный цикл метрик. Метрики, добавленные командой, выводятся из эксплуатации, если они становятся неактуальными, чтобы сократить потребление ресурсов ClickHouse. Например, логи Vertica (до 500 ГБ в день) хранятся не более 3 месяцев, так как этого достаточно для расследования инцидентов.

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