Сбор и отправка APM-трейсов из разных сервисов

В больших продуктах архитектура редко бывает однородной. У Sports.ru за 25+ лет под капотом оказались десятки Go-микросервисов рядом с крупными Perl- и PHP-монолитами. Всё это нужно мониторить, искать узкие места, собирать метрики — и делать это стабильно.
Официальных APM-агентов хватает не для всех языков, а существующие для PHP/Perl оказались слишком ограниченными. Поэтому команда решила построить собственный APM-прокси — единый сервис для сбора, буферизации и отправки трейсов.

Разбираем, зачем он понадобился и как устроен.
🧩 Проблема: разные агенты → разные ограничения
Elastic APM даёт мощный трейсинг, но:
Go-агент умеет батчить события в фоне — очередь, буфер, воркеры.
PHP-агент живёт только в рамках запроса. Один запрос = одна отправка → тысячи мелких HTTP-пакетов → нагрузка на APM-сервер.
Perl-агента нет вообще — монолит остаётся слепым.

В PHP и Perl невозможно получить внутренние метрики агента: переполнение очередей, потерянные события, время отправки.

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

🚀 Решение: APM-прокси как универсальная точка сбора
Команда спроектировала отдельный сервис apm-sender на Go:
принимает NDJSON-пейлоады от любых клиентов (монолиты/микросервисы);
валидирует и складывает их в канал;
отвечает клиенту сразу — без ожидания обработки;
в фоне батчит и отправляет данные в APM-сервер.
Это дало главное: клиентские сервисы больше не занимаются отправкой, очередями и оптимизацией трафика — логика вынесена в один компонент.

⚙️ Что внутри: каналы, воркеры и Circuit Breaker
1) Два уровня воркеров
Первый канал всегда доступен для записи — нагрузка клиентов не блокируется.
Второй канал — накопитель, откуда воркеры отправляют данные в APM.
2) Circuit Breaker
Когда APM-сервер начинает тормозить или отвечает ошибками:
отправка автоматически блокируется на несколько секунд;
сообщения копятся в буфере;
сервер «прощупывается» периодически;
когда он оклемался — отправка возобновляется.
Так прокси не штурмует APM-сервер лишними запросами и не теряет трейсы.

📊 Метрики и контроль
APM-прокси собирает то, чего не умели агенты Perl/PHP:
🔸 размер буфера;
🔸 время блокировок;
🔸 объём входящего/исходящего трафика;
🔸 статистику ошибок APM-сервера;
🔸 нагрузку в разрезе клиентов.

Это позволило:
найти клиентов, отправлявших гигантские payload’ы с лишними спанами;
оптимально настроить воркеры и размеры буферов;
корректно сконфигурировать сам APM-сервер.

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

🔗 Хабр

Библиотека пхпшника