Debug in production

grigori

( ͡° ͜ʖ ͡°)
Команда форума
hi, all!
Какие есть решения для сбора трейсов с дампами в проде?
В проекте есть сервис на 20-летнем легаси, владение кодом невозможно, разрезание идет, но до него еще надо дожить, и ехать в будущее надо по уши в грязи, потому что очень хочется.
Надо как-то грамотно дебажить в проде. Например, собирать трейсы с вызовов в определенных точках вместе с данными.
Что-то вроде пинбы, но с параметрами вызова методов, или xhrprof, но без тормозов.

Инстансов штук 10, надо аггрегировать. Писать в логи на диск не хочется чтобы не бить по io. Хорошо бы писать в локального демона по udp, и из него собирать в центре.

Админ подняли Elastic Application Performance, но я с ним не работал. Все on-premises, железо свое. Может, есть еще какие варианты?
 

MiksIr

miksir@home:~$
xhrprof => tideways
с тормозами конечно, но полный стектрейс можно получать по запросу, а в фоновом режиме - лишь всякие базы и тп
ну вышеуказанный ньюрелик, но он больше про метрики, чем про дебаг, те стектрейсы тоже делает, но вроде только медленных запросов
совсем без оверхедов - это нужен семплирующий профилировщик, есть phpspy но не пользовался
 

WMix

герр M:)ller
Партнер клуба
просто повторять через очередь http-запросы на полную копию аппликации со включенным xdebug
 

grigori

( ͡° ͜ʖ ͡°)
Команда форума
tideways и phpspy на первый взгляд - то, что надо, спасибо

просто повторять через очередь http-запросы на полную копию аппликации со включенным xdebug
в принципе, тут надо не полный дамп всех вызовов всех процедур, а конкретные места трейсить

а куда писать, где хранить? просто дампы на диске - как искать нужный запрос? хранить надо где-то месяц, пока от клиентов через поддержку дойдет инцидент,
надо посчитать, сколько на это надо дисков
 
Последнее редактирование:

MiksIr

miksir@home:~$
Не, ну для расследования инцидентов, это другая песня, это нужно обкладываться логами во всех местах и по ним уже пытаться решить проблему. Писать трейс на каждый запрос и хранить их месяц, что бы потом разобраться в проблеме - имхо, это утопия. Как минимум это сильно замедлит работу кода. А если снимать "каждый н-ый запрос" или семплирующий профайлер - это дает понимание происходящего, узких мест и тп, но разобраться как все работало для запроса "новый заказ" у васи 5 дней назад - ну никак не поможет.
 

grigori

( ͡° ͜ʖ ͡°)
Команда форума
я понимаю, но у меня не web

у меня асинхронные воркеры на шине, которые по очереди переваривают данные из промышленных контроллеров - перегоняют из проприетарного формата в xml, обсчитывают, пишут в базы, длинный такой flow по шине, скорость не то чтобы безразлична, но железо свое, удвоить количество воркеров легко, приложение тут не узкое место совсем

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

MiksIr

miksir@home:~$
Трейсинг всего - тут не х2, боюсь, тут поболее будет, хотя зависит от кода - чем больше мелких функций, тем больще оверхед.
 

grigori

( ͡° ͜ʖ ͡°)
Команда форума
Трейсинг всего - тут не х2, боюсь, тут поболее будет, хотя зависит от кода - чем больше мелких функций, тем больще оверхед.
давай еще раз напишу нефункциональные требования: данные идут по шине, десяток воркеров последовательно, по очереди берут данные, пишут в базу, в файлы, валидируют xsd и гоняют xsl-трансформации, а клиенты получают аггрегированные данные,
нефункциональное требование по скорости прохождения по всему пищеводу - минуты

я ожидаю, что увеличение времени работы самого php добавит пару процентов
 

MiksIr

miksir@home:~$
я ожидаю, что увеличение времени работы самого php добавит пару процентов
Как говорится, проще проверить, чем спорить. Поставить профилировщик на один из воркеров и посмотреть среднее время по джобам.
Мне кажется, что руками проставить логи - будет работать очевиднее
 

grigori

( ͡° ͜ʖ ͡°)
Команда форума
да руками-то уже в логи пишут, я подумал, вдруг что-то поудобнее существует
 
Сверху