Какой подход к логированию лучше - файлы или БД?

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

Здесь у нас есть два сценария:

1. Большая часть журналов ведется в БД, поскольку пользователи-администраторы продуктов, которые мы создаем, должны иметь возможность просматривать их в своем милом маленьком приложении со всеми прибамбасами.

2. Мы записываем всю нашу диагностическую и отладочную информацию в файл. У нас нет необходимости действительно «приукрашивать» его и TBH, он нам даже не часто нужен, поэтому мы просто регистрируем и архивируем по большей части.

Я бы сказал, что если пользователь что-то с ним делает, то войдите в БД, если это для вас, то файла, вероятно, будет достаточно.

Интересный вопрос, если вы решите войти в базу данных, где вы регистрируете ошибки подключения к базе данных?

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

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

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

Кроме того, есть ли у вас какие-либо особые потребности в базе данных журнала? Если все, что вам нужно, это "grep", то я не думаю, что вы много выиграете, войдя в базу данных.

Не уверен, поможет ли это, но есть также утилита под названием Microsoft LogParser, который вы предположительно можете использовать для анализа текстовых файлов журнала и использования их, как если бы они были базой данных. С сайта:

Анализатор журналов — это мощный, универсальный инструмент, обеспечивающий универсальный доступ к текстовым данным, таким как файлы журналов, файлы XML и файлы CSV, а также к ключевым источникам данных в операционной системе Windows®, таким как журнал событий, реестр, файловая система и Active Directory®. Вы сообщаете Log Parser, какая информация вам нужна и как вы хотите ее обработать. Результаты вашего запроса могут быть отформатированы в текстовом формате или сохранены в более специализированных целях, таких как SQL, SYSLOG или диаграмма. Большинство программ предназначено для выполнения ограниченного числа конкретных задач. Log Parser отличается... количество способов его использования ограничено только потребностями и воображением пользователя. Мир — это ваша база данных с Log Parser.

Я сам не использовал программу, но она кажется довольно интересной!

Или как насчет входа в очередь? Таким образом, вы можете переключать средства опроса всякий раз, когда хотите войти в разные вещи. Это делает такие вещи, как перенос и архивирование файлов журналов, очень простыми. Это также хорошо, потому что вы можете добавить поллеры, которые регистрируют разные вещи, например:

• опросчик, который ищет сообщения об ошибках и публикует их в вашей учетной записи FogBugz
• опросчик, который ищет нарушения доступа («x пытался получить доступ к /foo/y/bar.html») к файлу «попыток взлома»
• и т.п.

База данных - поскольку вы упомянули несколько потоков. Синхронизация, а также отфильтрованное извлечение — вот причины, по которым я дал свой ответ.
Проверьте, есть ли у вас проблемы с производительностью, прежде чем принимать решение о переключении на файлы
«Кнут: Преждевременная оптимизация — корень всех зол». дальше в этой книге не продвинешься... :)

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

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

Раньше я регистрировался в базе данных в отдельном потоке с более низким приоритетом. Должен сказать, возможность запросов очень ценна, когда вы пытаетесь выяснить, что пошло не так.

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

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

Из двух операций запись в файл журнала будет быстрее - тем более, что вы предлагаете запись в базу данных на другом сервере.

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

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

Мне нравится ответ Гая. Поместите все операторы журнала в потокобезопасную очередь, а затем обработайте их оттуда. Для БД вы можете группировать их, скажем, 100 операторов журнала в одном пакете, а для файла вы можете просто передавать их в файл по мере их поступления в очередь.

Файл или БД? Как говорят многие другие; это зависит от того, для чего вам нужен файл журнала.