Является ли запись файлов журнала сервера в базу данных хорошей идеей?

Question

Прочитав статью на эту тему от O'Reilly , я хотел спросить Stack Overflow, что они думают по этому поводу.

Answer 1

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

(Кстати, убедитесь, что в вашей таблице журнала базы данных есть столбец «с какой машины пришло событие журнала» - очень удобно!)

Answer 2

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

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

Answer 3

Вход в БД, если вы можете, и это не замедляет работу вашей БД:)

Это намного быстрее найти что-либо в БД, чем в лог-файлах. Особенно если подумать заранее, что тебе понадобится. Вход в БД позволяет вам запрашивать таблицу журнала следующим образом:

select * from logs
where log_name = 'wcf' and log_level = 'error'

тогда после того, как вы найдете ошибку, вы сможете увидеть весь путь, который привел к этой ошибке

select * from logs
where contextId = 'what you get from previous select' order by timestamp

Как вы получите эту информацию, если войдете в нее в текстовых файлах?

Edit: Как предположил JonSkeet, этот ответ был бы лучше, если бы я заявил, что следует рассмотреть возможность ведения журналирования в db асинхронно. Итак, я заявляю об этом :) Мне просто это не нужно. Например, как это сделать, вы можете проверить «Ultra Fast ASP.NET» Ричарда Киссига.

Answer 4

Если база данных является производственной базой данных, это ужасная идея. У вас будет проблемы с резервным копированием, репликацией, восстановлением. Как больше памяти для самой БД, реплики, если таковые имеются, и резервные копии. Больше времени на настройку и восстановление репликации, больше времени на проверку резервных копий, больше времени на восстановление БД из резервных копий.

Answer 5

Думаете о правильно настроенной базе данных, которая использует оперативную память для чтения и записи? Это намного быстрее, чем запись на диск, и не представляет собой узкое место дискового ввода-вывода, которое вы видите при обслуживании большого количества клиентов, которое возникает, когда потоки начинают блокироваться из-за того, что ОС говорит им ждать ожидающих выполнения потоков, использующих все доступные операции ввода-вывода. ручки.

У меня нет тестов для подтверждения этих данных, хотя мое последнее приложение работает с журналированием базы данных. Это будет иметь отказоустойчивость, как указано в одном из этих ответов. Если соединение с базой данных не может быть создано, создайте локальную базу данных (возможно, h2?) И напишите об этом. Затем мы можем периодически проверять соединение с базой данных, чтобы восстановить соединение, вывести локальную базу данных и отправить ее в удаленную базу данных.

Это можно сделать в нерабочее время, если у вас нет сайта H-A.

Когда-нибудь в будущем я надеюсь разработать тесты, чтобы продемонстрировать свою точку зрения.

Удачи!

Answer 6

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