My<cod/>.net
Какой подход лучше в журналировании-файлы или БД?
Хорошо, вот сценарий. У меня есть утилита, которая обрабатывает тонны записей и вводит информацию в базу данных соответственно.
Он работает на этих записях в многопоточных пакетах. Каждый такой пакет записывается в один и тот же файл журнала для создания рабочего процесса trace для каждой записи. Потенциально, мы могли бы сделать около миллиона записей журнала в день.
Должен ли этот журнал быть внесен в базу данных, находящуюся на другом сервере? Рассмотрения:
- Очевидным недостатком записи нескольких потоков в один и тот же файл журнала является то, что сообщения журнала перемешиваются между собой. В базе данных они могут быть сгруппированы по коду пакета.
- Производительность-что бы замедлить пакетную обработку больше? запись в локальный файл или отправка данных журнала в базу данных на другом сервере в той же сети. Теоретически, файл журнала быстрее, но есть ли здесь gotcha?
Существуют ли какие-либо оптимизации, которые могут быть сделаны на любом подходе?
Спасибо.
Интересный вопрос, если вы решите войти в базу данных, где вы регистрируете ошибки подключения к базе данных?
Если я регистрируюсь в базе данных, у меня всегда есть вторичное местоположение журнала (файл, журнал событий и т. д.) На случай ошибок связи. Это действительно облегчает диагностику проблем позже.
Одна вещь, которая приходит на ум, заключается в том, что вы можете записать каждый поток в свой собственный файл журнала, а затем выполнить ежедневный пакетный запуск, чтобы объединить их.
Если вы регистрируетесь в базе данных, вам, вероятно, нужно сделать некоторую настройку и оптимизацию, особенно если DB будет по сети. По крайней мере, вам нужно будет повторно использовать соединения DB.
Кроме того, есть ли у вас какие-либо конкретные потребности, чтобы иметь журнал в базе данных? Если все, что вам нужно, это "grep", то я не думаю, что вы получите много, войдя в базу данных.
Я второй другие ответы здесь, зависит от того, что вы делаете с данными .
У нас есть два сценария здесь:
Большинство журналов-это DB, так как пользователи admin для продуктов, которые мы создаем, должны иметь возможность просматривать их в своем милом маленьком приложении со всеми колокольчиками и свистками.
Мы регистрируем всю нашу диагностику и отладочную информацию в файл. У нас нет необходимости в действительно "prettifying" it и TBH, мы даже не часто нуждаемся в этом, поэтому мы просто регистрируем и архивируем большую часть.
Я бы сказал, что если пользователь что-то делает с ним, то войдите в DB, если это для вас, то файла, вероятно, будет достаточно.
Не уверен, что это поможет, но есть также утилита под названием Microsoft LogParser , которую вы можете предположительно использовать для анализа текстовых файлов журналов и использовать их как базу данных. С сайта:
Лог-парсер является мощным, универсальным инструмент, обеспечивающий универсальный запрос доступ к текстовым данным, таким как журнал файлы, XML файлов и CSV файлов, как а также основные источники данных по Windows® операционная система, например Журнал событий, реестр, файл система и Active Directory®. Вы скажите парсеру журнала, какую информацию вы нужно и как вы хотите его обработать. Результаты вашего запроса могут быть пользовательский формат в текстовом выводе, или они могут быть сохранены для большего количества специальные цели, такие как SQL, SYSLOG, или диаграмма. Большинство программного обеспечения предназначена для выполните ограниченное количество специальные задачи. Лог-парсер есть различный... количество способов, которыми он может быть ограничен только потребностями и воображение пользователя. То мир-это ваша база данных с журналом Синтаксический анализатор.
Я не использовал программу сам, но это кажется довольно интересным!
Или как насчет входа в очередь? Таким образом, вы можете переключать опросники всякий раз, когда вам нравится входить в разные вещи. Это делает такие вещи, как прокрутка и архивация файлов журналов очень легко. Это также приятно, потому что вы можете добавить опросники, которые регистрируют разные вещи, например:
- средство опроса, которое ищет сообщения об ошибках и отправляет их в вашу учетную запись FogBugz
- средство опроса, которое ищет нарушения прав доступа ('x пытался получить доступ /foo/y/bar.html') к файлу 'hacking attempts'
- и т.д.
База данных-так как вы упомянули несколько потоков. Синхронизация, а также фильтрованный поиск - это мои причины для моего ответа.
Посмотрите, есть ли у вас проблемы с производительностью, прежде чем переключиться на файлы
"Knuth: Premature optimization is the root of all evil" дальше я в этой книге не продвинулся... :)
Существуют способы обойти ограничения ведения журнала файлов.
Вы всегда можете начать каждую запись журнала С какого-то идентификатора потока и grep из отдельных идентификаторов потока. Или другой файл журнала для каждого потока.
Я вошел в базу данных в прошлом, в отдельном потоке с более низким приоритетом. Я должен сказать, что запрос очень ценен, когда вы пытаетесь выяснить, что пошло не так.
Я думаю, что это сильно зависит от того, что вы делаете с файлами журнала после этого.
Из двух операций запись в файл журнала будет выполняться быстрее-особенно если вы предлагаете запись в базу данных на другом сервере.
Однако, если вы затем пытаетесь обрабатывать и искать файлы журналов на регулярной основе, то лучшим местом для этого будет база данных.
Если вы используете структуру ведения журнала, такую как log4net, они часто предоставляют простые способы перенаправления ввода в файл или базу данных на основе файла конфигурации.
Мне нравится ответ Гая. Поместите все операторы журнала в очередь threadsafe, а затем обработайте их оттуда. Для DB вы можете собрать их в пакет, скажем, 100 операторов журнала в одном пакете, а для файла вы можете просто передать их в файл, когда они попадут в очередь.
Файл или БД? Как говорят многие другие; это зависит от того, для чего вам нужен файл журнала.