Atlassian перестроила свою платформу метрик вокруг OpenTelemetry Collector, не требуя от команд сервисов на первом этапе менять способ отправки метрик. Вместо удаления старого конвейера и последующей перенастройки тысяч сервисов компания сохранила интерфейс StatsD через UDP, постепенно заменяя расположенные за ним уровни агрегации, обработки и маршрутизации.
На протяжении большей части последнего десятилетия предыдущая платформа основывалась на gostatsd — разрабатываемом Atlassian приложении StatsD с открытым исходным кодом, которое работало как сайдкар-агент на хостах и как уровень агрегации на другом конце. Платформа обрабатывала метрики примерно со 100 тысяч хостов, распределённых по 14 регионам, при целевом уровне обслуживания 99,95% и низкой задержке.
Замена движка при сохранении контракта
Команды Atlassian пришли к выводу, что перенастройка каждого сервиса на использование OpenTelemetry SDK до изменения инфраструктуры стала бы многолетним процессом и создала бы риск потери данных, от которых зависят оповещения. Поэтому интерфейс платформы отделили от её внутренних компонентов: сервисы продолжили обращаться к тому же адресу и использовать формат StatsD, а внутренние уровни заменили специализированными дистрибутивами OpenTelemetry Collector.
Архитектура включала четыре независимых этапа: сбор, приём, агрегацию и маршрутизацию. Уровень сбора также сделали способным одновременно принимать StatsD и OTLP. Благодаря этому миграцию можно было начать без обязательной замены клиентских библиотек командами, одновременно открыв путь для метрик, изначально созданных с помощью OpenTelemetry.
Что изменилось на практике?
На этапе сбора сайдкар-агент gostatsd заменили дистрибутивом OpenTelemetry Collector, ранее использовавшимся командой трассировки, сохранив прежнее поведение приложений. Это позволило объединить метрики и трассировку в одном сайдкар-агенте вместо запуска двух агентов на каждом хосте.
Atlassian утверждает, что такое объединение снизило потребление CPU в среднем примерно на 3,9% для каждого сервиса среди наиболее затратных сервисов Micros, что соответствует снижению примерно на 30% стоимости сайдкар-агентов во всём парке. Также был добавлен приёмник OTLP, чтобы уровень сбора мог принимать метрики OpenTelemetry и напрямую перенаправлять их.
На этапе приёма основная проблема была связана с состоянием временных рядов. Каждую точку данных, относящуюся к одному и тому же ряду, необходимо было отправлять одному агрегатору. Старая система через внутренний агент под названием nomad использовала шардирование на основе пары «сервис и среда». Однако различия в размерах сервисов приводили к появлению перегруженных и слабо используемых агрегаторов.
Atlassian решила эту проблему с помощью компонента loadbalancingexporter из репозитория OpenTelemetry, используя шардирование по streamID, то есть по идентификатору отдельного временного ряда. Такой подход позволил распределить данные крупного сервиса между группой агрегаторов, сохранив один ряд на одном и том же агрегаторе. В результате распределение CPU между агрегаторами стало более равномерным, улучшилась способность к автоматическому масштабированию, а количество предупреждений о высокой нагрузке снизилось.
Сокращение данных и затрат на уровне агрегации
Уровень агрегации обрабатывает около 4,8 миллиарда точек данных в минуту, но хранит лишь около 220 миллионов точек, то есть сокращает объём примерно на 96%. Поскольку большинство метрик используют delta temporality, а предыдущие компоненты не агрегировали эти дельты способом, которого ожидали пользователи, Atlassian разработала специальный процессор для агрегации дельт метрик и опубликовала его как открытый исходный код в рамках atlassian-labs.
После перехода уровню агрегации требовалось примерно вдвое меньше CPU, чем раньше. Источник связывает это улучшение с несколькими факторами, включая отказ от разбора формата gostatsd, более равномерное распределение нагрузки и использование улучшений сообщества OpenTelemetry.
На последнем этапе специализированный внутренний маршрутизатор заменили не имеющим состояния дистрибутивом Collector, который компания назвала metrics-gateway. Этот дистрибутив использует upstream-экспортеры для отправки данных в несколько мест назначения, таких как SignalFx и S3, а также поддерживает повторные попытки, очереди и управление обратным давлением. Согласно заявленной архитектуре, добавление нового места назначения становится изменением конфигурации, а не отдельным интеграционным проектом.
Уроки постепенной миграции
- Начинайте с подходящих команд: Atlassian выбрала среды разработки и тестирования, а также сервисы, которые сильнее всего страдали от проблем, чтобы получить ранние отзывы в менее чувствительном масштабе.
- Постоянно наблюдайте за производственной средой: Профилирование под производственными нагрузками показало поведение и стоимость компонентов, которые не удавалось выявить с помощью небольших тестов или искусственных бенчмарков.
- Сохраняйте операционную симметрию: Поскольку миграция может продолжаться месяцами или годами при параллельной работе обеих систем, компания рекомендовала по возможности сохранять общие инструменты и операционные процедуры.
- Расширяйте охват поэтапно: Процесс развертывания использовал постепенно увеличивающиеся доли: сначала 1%, затем 10% и 50%, вплоть до 100%, при этом проблемы проверялись в менее чувствительных сервисах до перехода к критически важным путям.
Почему этот подход важен?
Этот опыт показывает, что внедрение нового стандарта в инфраструктуре не обязательно требует одновременного изменения интерфейсов всех потребителей. Сохранение внешнего контракта превратило миграцию из организационного проекта, охватывающего все команды, в проект под руководством инфраструктурной платформы, постепенно открывая возможности для OTLP и компонентов OpenTelemetry.
Atlassian указывает, что gostatsd и nomad вместе составляли около 38% запросов CPU в кластерах метрик, тогда как на один nomad приходилось около 13% всех ресурсов. Поэтому эффект перехода заключается не только в унификации инструментов: он также связан с удалением дорогих специализированных компонентов и сокращением числа частей, требующих внутреннего обслуживания.
При этом это не означает, что миграция завершена на уровне инструментирования сервисов. Следующий шаг, о котором сообщила компания, — перенос самих инструментов инструментирования на OpenTelemetry SDK и постепенный отказ от клиентов Datadog и DogStatsD, а также от внутренних библиотек StatsD, которые всё ещё используются. Результаты производительности и приведённые здесь цифры описывают опыт Atlassian в её среде и не гарантируют, что те же значения будут получены в каждой системе мониторинга.