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

Question

После прочтения статья на эту тему от О'Рейли, Я хотел спросить 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

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

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

Answer 4

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

Answer 5

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

Answer 6

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

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

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

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

Удачи!