Есть ли причина не всегда регистрировать трассировки стека?

Question

Сегодня в нашем приложении возникла неприятная проблема, в результате которой возникло исключение ArrayIndexOutOfBounds. Типом исключения было почти все, что было зарегистрировано, что довольно бесполезно (но, о дорогое приложение, мы все еще любим тебя, в основном). Я повторно развернул приложение с изменением, которое регистрирует трассировку стека при обработке исключений (и сразу нашел основную причину проблемы), и удивился, почему никто другой не сделал этого раньше. Вы обычно регистрируете трассировку стека и есть ли причина, по которой вы этого не сделаете?

Бонусные баллы, если вы можете объяснить (почему, а не как) обоснование необходимости прыгать по кругу в Java, чтобы получить строковое представление трассировки стека!

Answer 1

• Некоторые журналы могут содержать конфиденциальные данные, средства журналов не обязательно являются достаточно безопасными для отслеживания этих данных в процессе производства.

• Регистрация большого количества данных может привести к слишком большому количествуинформация, т.е. вообще никакой информации для сисадминов.Если их журналы заполнены отладочными сообщениями, они не смогут распознавать подозрительные шаблоны.(Несколько лет назад я видел систему, регистрирующую все системные вызовы по соображениям безопасности. Было так много журналов, что никто не видел, когда некоторые непривилегированные пользователи начали становиться пользователем root.)

Лучшая вещь дляделать, чтобы регистрировать все с соответствующими уровнями журналов, и иметь возможность устанавливать уровни журналов в рабочей среде (по крайней мере, в Java это не большая проблема).

Answer 2

Пожалуйста, смотрите эти вопросы также

Вход в Java и в целом: лучшие практики?

Рекомендации по ведению журнала Java из нескольких потоков?

Важные вещи для рассмотрения

1. Обработка конфиденциальных данных
2. Сжатие сообщений об исключениях и отправка их соответствующим исправителям
3. Регистрация того, что требуется. Потому что его лесозаготовка дорогая с точки зрения пространства и время

Answer 3

Я обычно веду журнал трассировки стека, потому что он содержит информацию для устранения неполадок / устранения неполадки. Это лучшая идея рядом с мини-дампом и часто приводит к решению просто путем проверки кода и выявления проблемы.

Кстати, я согласен с sibidiba в отношении потенциального раскрытия информации о внутренних компонентах вашего приложения, которые предоставляет полный стек: имена функций, а также последовательность вызовов стека могут многое рассказать образованному читателю. По этой причине некоторые продукты регистрируют только адрес символа в стеке и полагаются на разработчиков, чтобы преобразовать адрес в имя из внутренних pdbs.

Но я считаю, что запись текста в файлы, содержащие 1 строку ошибки и 14 строк стека, очень затрудняет навигацию по журналам ошибок. Это также вызывает проблемы в приложениях с высокой степенью параллелизма, поскольку блокировка файла журнала сохраняется дольше (или, что еще хуже, файлы журнала чередуются). Много раз сталкиваясь с этими проблемами самостоятельно, наряду с другими проблемами, связанными с поддержкой и устранением неполадок при развертывании моих собственных приложений, я фактически создал службу для регистрации ошибок на bugcollect.com . При разработке политик сбора ошибок я решил каждый раз собирать дампы стека и использовать стеки как часть ключей сегмента (для группировки ошибок, которые происходят в одном и том же стеке, в одно и то же поле).

Answer 4

Для нас это очень просто: если возникает непредвиденное исключение, мы регистрируем трассировку стека вместе с максимально возможным сообщением сообщения.

Я предполагаю, что разработчик, который написал оригинальный код в вопросе, просто не был достаточно опытным, чтобы понять, что этого недостаточно только с помощью сообщения. Я тоже так думал, однажды.

Причина, по которой сложно получить трассировку стека в виде строки, заключается в том, что в JRE нет StringPrintWriter - я считаю, что они думают, что они предоставляют много ортогональных строительных блоков, которые затем объединяются по мере необходимости. , Вы должны собрать необходимый PrintWriter самостоятельно.

Answer 5

Ограничения на ведение журнала часто проталкиваются, когда разработчики ведут слишком либеральную регистрацию, и системные администраторы обнаруживают, что приложение, однажды загруженное в производственную нагрузку, разбивает и заполняет HD огромными файлами журнала. Тогда может быть трудно убедить их в том, что вы видели ошибку ваших путей и достаточно сократили журналирование (или скорректировали уровни журнала), но действительно нуждаются в этих оставшихся записях журнала.

Answer 6

То, что я часто видел, - это запись в коде исключения, подобного этому:

LOG.error (бывший);

Поскольку log4j принимает Object в качестве первого аргумента, он регистрирует строковое представление Exception, которое часто является только именем класса. Обычно это просто недосмотр со стороны разработчика. Лучше войти и ошибка, как это:

LOG.error ("foo случилось", ex);

.. так что при правильной настройке каркас ведения журнала будет записывать трассировку стека.

Answer 7

Бонусные баллы, если вы можете объяснить (почему, не как) обоснование наличия прыгать обручи в Java, чтобы получить строку представление трассировки стека!

Разве вы не должны просто записать бросаемый объект вместо того, чтобы проходить через обручи для печати трассировки стека? Например: log.error («Не удалось развернуть!», Ex). При наличии броска Log4J напечатает как сообщение об ошибке, полученное с помощью getMessage (), так и трассировку стека.