Оценить полезность: полуавтоматический анализ core-файлов
разработчики просто читают письма с backtrace-амиу вас в продакшене сборка с отладочными символами?
Я бы делал так:
В продакшене полноценная стрипнутая релизная сборка, при падении корка ретрейсится скриптом уже с отладочными символами, из корки экстрагируется бэктрейс, информация о тредах, локалсы и прочая отладочная инфа — как это делает, например, apport. Бэктрейс проверяется на наличие в багтрекере и при необходимости автоматом заводится тикет. Если есть закрытый с подходящим бэктрейсом — он переоткрывается и в него прикрепляется свежак.
у вас в продакшене сборка с отладочными символами?Это плохо?
Мне показалось это неоптимальным: смотреть глазами эту кучу писемУ вас столько корок на продакшне? o_O
Это плохо?Скорость запуска падает, плюс разница в занимаемом месте иногда может быть существенной. Я не знаю, какой у ТС продакшен, иногда бывает на машине по 50 разных экземпляров программы крутится, это уже на гигабайты счёт может идти.
можно же debug-символы отдельно хранить
Работает программа собранная под продакшн, но еще ставится пакет с debug-info
у вас в продакшене сборка с отладочными символами?
За сутки со всех установок набирается 57 штук.
У вас столько корок на продакшне? o_O
Для обработки миллиона запросов в сутки вроде не так много, да и клиенты не жалуются.
А вот чтобы самим понимать качество продукта, да и на то, чтобы глазами смотреть и не упустить новую корку, для этих целей этого много.
Попробую переформулировать свой вопрос:
на ваш взгляд, возможны ли такие ситуации, где Apport или ABRT — из пушки по воробьям, а вот подобный набор скриптов решал бы задачу?
Если такие ситуации есть, то чего не хватает именно моим скриптам, чтобы вы применяли их в своей практике?
Стоит ли их сделать более общими, с большим функционалом и большим количество настроек или наоборот имеет смысл их заточить под конкретный функционал, но так чтобы с минимальными настройками, по принципу установил и все само заработало?
Или это вообще местечковое решение, а если хочется пользы в этом направлении, то надо читать исходники Apport или ABRT и помогать этим уже зрелым проектам?
Ну и сюда же вопрос: а какие еще решения есть для этой задачи: анализа coredump-ов? Кто чем пользуется?
на ваш взгляд, возможны ли такие ситуации, где Apport или ABRT — из пушки по воробьям, а вот подобный набор скриптов решал бы задачу?
Если такие ситуации есть, то чего не хватает именно моим скриптам, чтобы вы применяли их в своей практике?
Стоит ли их сделать более общими, с большим функционалом и большим количество настроек или наоборот имеет смысл их заточить под конкретный функционал, но так чтобы с минимальными настройками, по принципу установил и все само заработало?
Или это вообще местечковое решение, а если хочется пользы в этом направлении, то надо читать исходники Apport или ABRT и помогать этим уже зрелым проектам?
Ну и сюда же вопрос: а какие еще решения есть для этой задачи: анализа coredump-ов? Кто чем пользуется?
на мой взгляд было бы интересней тулзу, которая могла бы получить корку на вход и сделать из нее стектрейс
нагуглить подобное мне в свое время не удалось, равно как и похачить gdb, чтобы он принимал корку на вход (он там иногда делает seek назад, а отлавливать такое равносильно записи дампа)
нагуглить подобное мне в свое время не удалось, равно как и похачить gdb, чтобы он принимал корку на вход (он там иногда делает seek назад, а отлавливать такое равносильно записи дампа)
Я не очень понял, что именно не удается.
Получить trace из core, ну в моем коде это есть, примерно так:
Или чтобы без записи core-файла?
Тут можно в core_pattern записать "|/path/to/script" и в этот скрипт корка придет на stdin, дальше что хочешь с ней, то и делай. (http://lwn.net/Articles/280959/)
Получить trace из core, ну в моем коде это есть, примерно так:
gdb -se "$BIN_PATH" -c "$corefile" \
-n -batch-silent \
-ex "set logging file $backtrace" \
-ex 'set logging overwrite on' -ex 'set logging on' \
-ex 'where' \
2> /dev/null
Или чтобы без записи core-файла?
Тут можно в core_pattern записать "|/path/to/script" и в этот скрипт корка придет на stdin, дальше что хочешь с ней, то и делай. (http://lwn.net/Articles/280959/)
да, проблема без записи (и без хранения в оперативке - ее тупо не хватит)
UPD и, например, подсунуть корку gdb через pipe тоже не получается (у меня не получилось, по крайней мере). и через подсунутые "свои" read и т.п. тоже, т.к. он читает файл не последовательно
UPD и, например, подсунуть корку gdb через pipe тоже не получается (у меня не получилось, по крайней мере). и через подсунутые "свои" read и т.п. тоже, т.к. он читает файл не последовательно
можно же debug-символы отдельно хранитьМожно. Например, у разработчиков. Если их всё равно детачить, зачем их раскидывать на все продакшен-машины, усложняя деплой? Особенно если, например, выкладка идёт не какими-нибудь деб-пакетами, а статически собранными бинарниками.
Оставить комментарий
Sharp
По работе возникла задача написать скрипт для отправки backtrace-ов из coredump-ов по e-mail: продукт бывает падает на продакшене, поэтому чтобы не копировать все core файлы, разработчики просто читают письма с backtrace-ами, и если какой-то интересен, то просят скопировать core-файл для дальнейшего анализа.Мне показалось это неоптимальным: смотреть глазами эту кучу писем, и я дописал еще пару скриптов: первый выделяет из backtrace-а последовательность вызовов, и тем самым получает некоторый отпечаток этого backtrace-а. А второй скрипт проверяет каждый новый отпечаток по некоторой базе уже известных отпечатков на факт: это новая бага, или уже известная нам.
В результате получилось что-то такое:
http://bitbucket.org/fedor_dikarev/coredump-analysis
Собственно вопрос: на ваш взгляд, это что-то полезное? имеет смысл это улучшать в данном "масштабе" — как набор скриптов и база в виде каталогов?
Или все что проще RedHat-овского ABRT особой пользы не принесет?