Сбор и отправка 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-сервер снизилась и стала прогнозируемой;
исчезла необходимость поддерживать разрозненные агенты;
появилось единое место для анализа, расширения и оптимизации трейсинга;
команда получила прозрачность потоков и быстро нашла проблемы, которые раньше были невидимы.
🔗 Хабр
Библиотека пхпшника
В больших продуктах архитектура редко бывает однородной. У 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-сервер снизилась и стала прогнозируемой;
исчезла необходимость поддерживать разрозненные агенты;
появилось единое место для анализа, расширения и оптимизации трейсинга;
команда получила прозрачность потоков и быстро нашла проблемы, которые раньше были невидимы.
🔗 Хабр
Библиотека пхпшника
❤1
🧠 Лайфхак: кешируйте config и routes в Laravel для максимальной скорости
⚙️ Что даёт кеширование
🔄 При кешировании конфигурации — все файлы из
🚀 При кешировании маршрутов — все определения роутов компилируются в один файл. При запросе Laravel сразу загружает этот кеш, вместо повторного парсинга маршрутов.
Это значительно снижает накладные расходы на загрузку конфигураций и роутов, ускоряя старт приложения и уменьшая время обработки запросов.
🧰 Как включить кеш
Если вы внесли изменения в конфиги или роуты — перед новым запуском надо очистить и пересоздать кеш:
И потом снова:
✅ Когда это разумно использовать
- ✅ В production или staging-средах, когда структура проекта стабильна, конфиги и маршруты уже настроены.
- ✅ В проектах с большим количеством конфигураций и маршрутов — там выигрыш по скорости особенно заметен.
⚠️ На что нужно обратить внимание
- ❗ Если вы используете closure-роуты (анонимные функции) — кеш маршрутов не будет работать корректно. Для кеша маршрутов нужно, чтобы все роуты были описаны через контроллеры.
- ❗ После изменений в конфигурациях или .env — не забудьте пересоздать кеш: иначе Laravel может продолжить использовать старые значения.
- ⚙️ В рабочем (dev) окружении: кеш может мешать быстрому тестированию изменений, поэтому часто кеш отключают на время разработки.
🔄 Как включить кеширование в процесс деплоя / CI/CD
- Добавьте команды
- После деплоя — проверьте, что кеш актуален, особенно если были изменения конфигов или роутов
Библиотека пхпшника
⚙️ Что даёт кеширование
🔄 При кешировании конфигурации — все файлы из
config/ (и .env) объединяются в один — Laravel не читает и не парсит множество отдельных файлов при каждом запросе. 🚀 При кешировании маршрутов — все определения роутов компилируются в один файл. При запросе Laravel сразу загружает этот кеш, вместо повторного парсинга маршрутов.
Это значительно снижает накладные расходы на загрузку конфигураций и роутов, ускоряя старт приложения и уменьшая время обработки запросов.
🧰 Как включить кеш
php artisan config:cache #кеширует конфигурацию
php artisan route:cache #кеширует маршруты
Если вы внесли изменения в конфиги или роуты — перед новым запуском надо очистить и пересоздать кеш:
php artisan config:clear
php artisan route:clear
И потом снова:
php artisan config:cache
php artisan route:cache
✅ Когда это разумно использовать
- ✅ В production или staging-средах, когда структура проекта стабильна, конфиги и маршруты уже настроены.
- ✅ В проектах с большим количеством конфигураций и маршрутов — там выигрыш по скорости особенно заметен.
⚠️ На что нужно обратить внимание
- ❗ Если вы используете closure-роуты (анонимные функции) — кеш маршрутов не будет работать корректно. Для кеша маршрутов нужно, чтобы все роуты были описаны через контроллеры.
- ❗ После изменений в конфигурациях или .env — не забудьте пересоздать кеш: иначе Laravel может продолжить использовать старые значения.
- ⚙️ В рабочем (dev) окружении: кеш может мешать быстрому тестированию изменений, поэтому часто кеш отключают на время разработки.
🔄 Как включить кеширование в процесс деплоя / CI/CD
- Добавьте команды
config:cache и route:cache в скрипт деплоя — при выкладке на production они будут выполняться автоматически.- После деплоя — проверьте, что кеш актуален, особенно если были изменения конфигов или роутов
Библиотека пхпшника
❤5👍3
🤖 ChatGPT выключен, а работа идёт как обычно
В мире разработки всё чаще говорят про AI, который помогает писать код быстрее и качественнее. Однако, встречаются примеры, когда выключение Copilot не приводит к заметным потерям в работе.
Возможно, скиллы и понимание задач дают больше, чем автодополнение от AI.
💬 Как думаете не отвлекают ли эти ИИ? Или всё-таки с ними куда лучше?
🔸 AI-агенты для DS-специалистов
🔸 Получить консультацию менеджера
🔸 Сайт Академии 🔸 Сайт Proglib
🐸 Библиотека пхпшника
В мире разработки всё чаще говорят про AI, который помогает писать код быстрее и качественнее. Однако, встречаются примеры, когда выключение Copilot не приводит к заметным потерям в работе.
Возможно, скиллы и понимание задач дают больше, чем автодополнение от AI.
🔸 AI-агенты для DS-специалистов
🔸 Получить консультацию менеджера
🔸 Сайт Академии 🔸 Сайт Proglib
Please open Telegram to view this post
VIEW IN TELEGRAM
💬Знаете ли вы, что вы можете использовать
Библиотека пхпшника
#vardump
scan в Laravel для разбора строки, введенной в коллекцию, в соответствии с форматом, поддерживаемым встроенной функцией PHP sscanf? 🚀Библиотека пхпшника
#vardump
PHP жив, а твоя карьера?
Шутка. PHP будет жить вечно. Но расширять кругозор полезно всегда. Математика и ML — это то, что отличает инженера от кодера.
Залетай на наш курс с живыми вебинарами. Мы объясняем сложные вещи просто.
Что будет:
— Матрицы и векторы (это как массивы, только с суперсилой);
— Линейная регрессия (научимся предсказывать данные);
— SVD-разложение (сделаем свою рекомендалку).
Практика на Python, но математика везде одинаковая.
Успевай до 9 декабря:
👉 https://clc.to/LojFzw
Шутка. PHP будет жить вечно. Но расширять кругозор полезно всегда. Математика и ML — это то, что отличает инженера от кодера.
Залетай на наш курс с живыми вебинарами. Мы объясняем сложные вещи просто.
Что будет:
— Матрицы и векторы (это как массивы, только с суперсилой);
— Линейная регрессия (научимся предсказывать данные);
— SVD-разложение (сделаем свою рекомендалку).
Практика на Python, но математика везде одинаковая.
Успевай до 9 декабря:
👉 https://clc.to/LojFzw
🥱5👍1
💬 Ежемесячная ветка PHP-разработчиков — декабрьское обновление
Продолжаем традицию — открываем новую декабрьскую ветку 👇
Что можно приносить сюда сейчас:
🧩 свежие фрагменты кода, которые вызывают вопросы или гордость
🔍 кейсы из продакшена: узкие места, memory leaks, странности с очередями
🛠️ pet-projects, библиотеки, пакеты: покажите, что сделали за месяц
🧠 вопросы по DDD, микросервисам, тестированию, CI/CD
⚙️ опыт миграции на PHP 8.3/8.4, проблемы совместимости, нюансы производительности
Вы можете прийти с сырым прототипом или сложной продакшен-архитектурой — здесь всегда найдётся человек, который подскажет, куда копать.
Пусть эта ветка остаётся местом для профессионального диалога, где ценят практику, инженерное мышление и точные решения ❤️
👇 Делитесь вашими обновлениями, задачами и победами за последний месяц!
Библиотека пхпшника
Продолжаем традицию — открываем новую декабрьскую ветку 👇
Что можно приносить сюда сейчас:
🧩 свежие фрагменты кода, которые вызывают вопросы или гордость
🔍 кейсы из продакшена: узкие места, memory leaks, странности с очередями
🛠️ pet-projects, библиотеки, пакеты: покажите, что сделали за месяц
🧠 вопросы по DDD, микросервисам, тестированию, CI/CD
⚙️ опыт миграции на PHP 8.3/8.4, проблемы совместимости, нюансы производительности
Вы можете прийти с сырым прототипом или сложной продакшен-архитектурой — здесь всегда найдётся человек, который подскажет, куда копать.
Пусть эта ветка остаётся местом для профессионального диалога, где ценят практику, инженерное мышление и точные решения ❤️
👇 Делитесь вашими обновлениями, задачами и победами за последний месяц!
Библиотека пхпшника
💻 Подборка новостей по PHP за неделю:
🔹 Laravel 12.40.2 — очередь теперь можно приостанавливать на заданное число секунд. Это развитие функции из 12.40, где появилась возможность ставить очередь на паузу и возобновлять её без ограничения по времени.
🔹 Mailviews (Early Access) — запущен ранний доступ к инструменту для создания адаптивных, стабильных e-mail-шаблонов без мучительной ручной верстки и бесконечных проверок в разных клиентах.
🔹 Symfony 7.4.0 — релиз новой стабильной версии с заметными улучшениями. В серии «New in Symfony 7.4» доступны разборы ключевых возможностей.
🔹 Symfony 24–30 ноября — выпущены финальные Symfony 7.4.0 и 8.0.0. Прошла SymfonyCon Amsterdam 2025, опубликованы Black Friday-скидки экосистемы.
Библиотека пхпшника
#свежак
🔹 Laravel 12.40.2 — очередь теперь можно приостанавливать на заданное число секунд. Это развитие функции из 12.40, где появилась возможность ставить очередь на паузу и возобновлять её без ограничения по времени.
🔹 Mailviews (Early Access) — запущен ранний доступ к инструменту для создания адаптивных, стабильных e-mail-шаблонов без мучительной ручной верстки и бесконечных проверок в разных клиентах.
🔹 Symfony 7.4.0 — релиз новой стабильной версии с заметными улучшениями. В серии «New in Symfony 7.4» доступны разборы ключевых возможностей.
🔹 Symfony 24–30 ноября — выпущены финальные Symfony 7.4.0 и 8.0.0. Прошла SymfonyCon Amsterdam 2025, опубликованы Black Friday-скидки экосистемы.
Библиотека пхпшника
#свежак
👍1
💡Совет по Laravel: Привязка моделей в Form Request
Привязка моделей к маршрутам позволяет вставлять экземпляры моделей непосредственно в маршруты. Обычно она используется в контроллере, но знаете ли вы, что можно получить доступ к экземпляру модели и в запросе формы?
Библиотека пхпшника
#vardump
Привязка моделей к маршрутам позволяет вставлять экземпляры моделей непосредственно в маршруты. Обычно она используется в контроллере, но знаете ли вы, что можно получить доступ к экземпляру модели и в запросе формы?
Библиотека пхпшника
#vardump
👍1
📈 Почему память в PHP-воркерах только растёт — и это нормально
Если вы переходите с PHP-FPM на RoadRunner, Laravel Queue или Symfony Messenger — вы увидите один и тот же эффект:
Память растёт ступеньками и никогда не падает.
40 → 200 → 350 МБ… и так до перезапуска.
Unset, GC, collect_cycles() — не помогают.
Это не утечка. Это архитектура PHP.
🧬 Почему так происходит
PHP использует Zend Memory Manager:
он выделяет память крупными чанками (2–4 МБ) и не отдаёт их ОС назад, даже если внутри всё освобождено.
Каждый пик — новый baseline.
Обработали 100k записей → память выросла → процесс будет держать этот объём до конца жизни.
🔥 Что вызывает «разбухание»
ORM
большой файл в
накопление массивов
сложные eager-loading графы ORM
🛠 Как проектировать правильно
✔️ Стриминг вместо коллекций:
или:
✔️ Doctrine:
✔️ Изоляция тяжёлых операций в функцию — память освобождается при выходе из scope.
✔️ Ротация воркеров — обязательна:
Laravel:
RoadRunner:
Messenger:
📌 Выводы
🔸 Память в долгоживущем PHP-процессе не уменьшится сама по себе.
🔸 Проектируйте под пиковое потребление.
🔸Используйте стриминг, чанки, detach().
🔸 Регулярно перезапускайте воркеры.
🔗 Medium
🐸 Библиотека пхпшника
Если вы переходите с PHP-FPM на RoadRunner, Laravel Queue или Symfony Messenger — вы увидите один и тот же эффект:
Память растёт ступеньками и никогда не падает.
40 → 200 → 350 МБ… и так до перезапуска.
Unset, GC, collect_cycles() — не помогают.
Это не утечка. Это архитектура PHP.
🧬 Почему так происходит
PHP использует Zend Memory Manager:
он выделяет память крупными чанками (2–4 МБ) и не отдаёт их ОС назад, даже если внутри всё освобождено.
Каждый пик — новый baseline.
Обработали 100k записей → память выросла → процесс будет держать этот объём до конца жизни.
🔥 Что вызывает «разбухание»
ORM
->all() или ->get() на десятки тысяч записейбольшой файл в
file_get_contents()накопление массивов
сложные eager-loading графы ORM
🛠 Как проектировать правильно
✔️ Стриминг вместо коллекций:
User::lazy()->each(fn($u) => processUser($u));
или:
Record::chunk(100, function ($rows) {
foreach ($rows as $r) processRecord($r);
});✔️ Doctrine:
foreach ($q->toIterable() as $u) {
process($u);
$em->detach($u);
}✔️ Изоляция тяжёлых операций в функцию — память освобождается при выходе из scope.
✔️ Ротация воркеров — обязательна:
Laravel:
php artisan queue:work --max-jobs=1000
RoadRunner:
pool:
max_jobs: 1000
Messenger:
messenger:consume --limit=1000
📌 Выводы
🔸 Память в долгоживущем PHP-процессе не уменьшится сама по себе.
🔸 Проектируйте под пиковое потребление.
🔸Используйте стриминг, чанки, detach().
🔸 Регулярно перезапускайте воркеры.
Please open Telegram to view this post
VIEW IN TELEGRAM
👍12❤4
Forwarded from Библиотека задач по PHP | тесты, код, задания
❤2