Что вы думаете о сохранении трассировки стека в специальной таблице журнала?

Question

Предположим, у вас есть специальная таблица журнала вашего приложения.

Что вы думаете о создании поля BLOB для возможной трассировки стека?

Регистрация ведется и в файл, но читать текстовый файл не так удобно, более того, база данных более «доступна».

Answer 1

Двойное ведение журнала звучит как ... ну, двойное ведение журнала. Накладные расходы. Если вам нужен доступ к журналам через базу данных, я бы предпочел использовать / написать инструмент, который может при необходимости импортировать журналы в отдельную базу данных. Или сделать их доступными с помощью других средств. Один из известных мне инструментов - Splunk, но он дорогой, и я уверен, что есть и другие.

Answer 2

Что если трассировка стека происходит из-за сбоя соединения с базой данных? Некоторые вещи должны быть как можно более низкими и простыми. Кроме того, я не понимаю, почему база данных должна быть более или менее доступной, чем общий файловый ресурс или учетная запись ssh.

Answer 3

Почему? Или, по крайней мере, если вы собираетесь это сделать, почему поле Blob?

Если бы я реализовал что-то подобное, я бы разделил исключения на отдельные StackTraceElements и сохранил их в правильной таблице. Со временем и множеством сбоев вы можете получить интересную статистику о характере риска и качестве в вашем приложении.

Answer 4

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

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