Безусловно, для highload систем можно и нужно разработать более продвинутые решения отправки метрик - вроде ваших низкоуровневых перехватчиков. Я так понимаю этот способ в основном для проектов на C++ - или для однопоточного PHP тоже подойдет (например как extension)? Зона действительно богатая для оптимизации, недаром у нас уже 3 варианта SDK, на подходе ещё несколько. Перебираем варианты передачи с минимальным влиянием на живой PHP fpm процесс и скорость обработки запросов. Зачастую это компромисс между удобством подключения в разных проектах, оверхедом производительности, гибкостью и простотой реализации/контроля/поддержки.
Файлы (pipe либо папка) лишь как буфер для передачи в клик - один из простейших для реализации вариантов. С правильной настройкой уже и тут оверхед на запись всего несколько мс. Но и это пока не используем, проще всего настроить оказалось open telemetry collector - с ним и живём. Да, это занимает до десятка мс, зато не надо париться с файловой системой и состоянием гонки. Решили оставить пока так, метрики отправляем после ответа пользователю, поэтому это время лишь чуть задерживает fpm-процесс в пуле, пока для обработки новых запросов есть другие свободные процессы - вообще не проблема.
Сильно в оптимизацию не залазили, текущих вариантов пока хватает для небольшого проекта с ~130к ежедневных запросов. Если попробовать покрутить дальше (без прямого сканирования процесса fpm) в качестве буфера юзать например posix shared memory с параллельно работающим демоном. Также рассматриваем вариант с UDP либо TCP-сокетом и буферизирующим демоном на той же машине. Не то что это было бы необходимо для проекта, больше в качестве интереса - а как далеко можно зайти в скорости отправки метрик. Ну и другим командам поможет определиться с вариантом SDK если будут подключать проекты с большей нагрузкой.
Datalens выглядит красиво, надо попробовать, спасибо за рекомендацию. Похоже действительно использование связки графана+самописные SQL запросы является велосипедом. Хотя и не то чтобы разработка новых дашбордов занимает кучу времени, сами SQL запросы пишутся быстро, дольше настраивать панели и параметры отображения.
В сетевых вариантах кстати можно задействовать UDP - если сетевая инфраструктура позволяет и не страшно потерять некий % запросов (ещё компромисс). И fpm разгрузит и можно например промежуточные состояния тоже с небольшой задержкой отправить (поможет не потерять метрики при крашах).
Отправка метрик интересная тема обсудить. Действительно, пока что уникального решения не нашли - то тут то там приходится идти на компромисс. Во второй части (уже опубликована) привожу несколько вариантов и их субьективное сравнение по нашему проекту. Среди основных подходов это либо запись в файл (быстрая запись в несколько мс, но могут быть проблемы ФС + нужно наладить механизм блокировок) либо по сети (отправка в десятки мс, но могут быть проблемы сети + дольше передача) либо в кэш-сервис (что тоже файлы либо сеть, хоть и его можно на той же машине расположить). Ну и да, любой метод отправки требует таймаута чтобы не повесить систему (у себя выяснили немного позже чем хотелось бы =)).
Согласен насчет рисков замедления работы при неполадках с каналом передачи метрик. Думаю будет полезно снимать отдельную метрику "время отправки метрик". Правда - в тот же набор не засунуть, придётся писать потом - например в файл + считывать своим воркером/демоном. Тогда можно будет настроить отдельный мониторинг с алёртами для контроля именно системы мониторинга. Тут главное не уйти в рекурсию (мониторинг мониторинга мониторинга...).
Отправка после ответа пользователю тоже не идеальный вариант. Это лучше чем заниматься отправкой до ответа, однако, и как вы отметили, это все ещё доп нагрузка на fpm; также не защищено если случится остановка процесса (мимо register_shutdown_function) и метрики никуда не уедут. Есть ещё идея (альтернатива pipe-файлу) использовать общую ячейку памяти (POSIX shared memory) с демоном - который будет читать метрики несколько раз в процессе обработки. Тут же и запись fpm-ом должна быть ещё быстрее чем файлы. Но такую непростую систему придется отдельно и проектировать и поддерживать, дополнительная сложность синхронизировать и контролировать ячейки при высокой concurrency. Эту тему возможно стоит покрутить для мониторинга highload проектов.
Безусловно, для highload систем можно и нужно разработать более продвинутые решения отправки метрик - вроде ваших низкоуровневых перехватчиков. Я так понимаю этот способ в основном для проектов на C++ - или для однопоточного PHP тоже подойдет (например как extension)? Зона действительно богатая для оптимизации, недаром у нас уже 3 варианта SDK, на подходе ещё несколько. Перебираем варианты передачи с минимальным влиянием на живой PHP fpm процесс и скорость обработки запросов. Зачастую это компромисс между удобством подключения в разных проектах, оверхедом производительности, гибкостью и простотой реализации/контроля/поддержки.
Файлы (pipe либо папка) лишь как буфер для передачи в клик - один из простейших для реализации вариантов. С правильной настройкой уже и тут оверхед на запись всего несколько мс. Но и это пока не используем, проще всего настроить оказалось open telemetry collector - с ним и живём. Да, это занимает до десятка мс, зато не надо париться с файловой системой и состоянием гонки. Решили оставить пока так, метрики отправляем после ответа пользователю, поэтому это время лишь чуть задерживает fpm-процесс в пуле, пока для обработки новых запросов есть другие свободные процессы - вообще не проблема.
Сильно в оптимизацию не залазили, текущих вариантов пока хватает для небольшого проекта с ~130к ежедневных запросов. Если попробовать покрутить дальше (без прямого сканирования процесса fpm) в качестве буфера юзать например posix shared memory с параллельно работающим демоном. Также рассматриваем вариант с UDP либо TCP-сокетом и буферизирующим демоном на той же машине. Не то что это было бы необходимо для проекта, больше в качестве интереса - а как далеко можно зайти в скорости отправки метрик. Ну и другим командам поможет определиться с вариантом SDK если будут подключать проекты с большей нагрузкой.
Datalens выглядит красиво, надо попробовать, спасибо за рекомендацию. Похоже действительно использование связки графана+самописные SQL запросы является велосипедом. Хотя и не то чтобы разработка новых дашбордов занимает кучу времени, сами SQL запросы пишутся быстро, дольше настраивать панели и параметры отображения.
В сетевых вариантах кстати можно задействовать UDP - если сетевая инфраструктура позволяет и не страшно потерять некий % запросов (ещё компромисс). И fpm разгрузит и можно например промежуточные состояния тоже с небольшой задержкой отправить (поможет не потерять метрики при крашах).
Отправка метрик интересная тема обсудить. Действительно, пока что уникального решения не нашли - то тут то там приходится идти на компромисс. Во второй части (уже опубликована) привожу несколько вариантов и их субьективное сравнение по нашему проекту. Среди основных подходов это либо запись в файл (быстрая запись в несколько мс, но могут быть проблемы ФС + нужно наладить механизм блокировок) либо по сети (отправка в десятки мс, но могут быть проблемы сети + дольше передача) либо в кэш-сервис (что тоже файлы либо сеть, хоть и его можно на той же машине расположить). Ну и да, любой метод отправки требует таймаута чтобы не повесить систему (у себя выяснили немного позже чем хотелось бы =)).
Согласен насчет рисков замедления работы при неполадках с каналом передачи метрик. Думаю будет полезно снимать отдельную метрику "время отправки метрик". Правда - в тот же набор не засунуть, придётся писать потом - например в файл + считывать своим воркером/демоном. Тогда можно будет настроить отдельный мониторинг с алёртами для контроля именно системы мониторинга. Тут главное не уйти в рекурсию (мониторинг мониторинга мониторинга...).
Отправка после ответа пользователю тоже не идеальный вариант. Это лучше чем заниматься отправкой до ответа, однако, и как вы отметили, это все ещё доп нагрузка на fpm; также не защищено если случится остановка процесса (мимо register_shutdown_function) и метрики никуда не уедут. Есть ещё идея (альтернатива pipe-файлу) использовать общую ячейку памяти (POSIX shared memory) с демоном - который будет читать метрики несколько раз в процессе обработки. Тут же и запись fpm-ом должна быть ещё быстрее чем файлы. Но такую непростую систему придется отдельно и проектировать и поддерживать, дополнительная сложность синхронизировать и контролировать ячейки при высокой concurrency. Эту тему возможно стоит покрутить для мониторинга highload проектов.