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

Ответ 1

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

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

Ответ 2

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

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

Ответ 3

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

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

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 асинхронно. Поэтому я заявляю об этом:) Мне это просто не нужно. Например, как это сделать, вы можете проверить "Ультра быстрый ASP.NET" Ричарда Киессига.

Ответ 4

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

Ответ 5

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

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

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

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

Удачи!

Ответ 6

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