Использование SQL Server для регистрации приложений. За и против?

Question

У меня есть многопользовательское приложение, которое хранит централизованный лог-файл для активности. Прямо сейчас эта запись идет в текстовых файлах примерно на 10-50 МБ / день. Текстовые файлы ежедневно меняются регистратором, и мы сохраняем последние 4-5 дней. Старше нас это не интересует.

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

(Это строго журнал приложения. Ведение журнала безопасности хранится в другом месте.)

Но когда их читают, они чувствуют боль в заднице. Погибать 10 МБ текстовых файлов не очень интересно даже с Perl: поля (идентификатор транзакции, идентификатор пользователя и т. Д.) В файле полезны, но только текст. Сообщения пишутся последовательно, по одному за раз, поэтому все чередующиеся действия смешиваются при попытке выполнить определенную транзакцию или пользователя.

Я ищу мысли по теме. Кто-нибудь делал логирование на уровне приложения с базой данных SQL и понравилось? Ненавидели это?

Answer 1

Я думаю, что вход в базу данных напрямую - плохая идея, и я бы ее избегал.

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

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

С другой стороны, для успешного входа на сервер SQL потребуется, чтобы намного больше компонентов работало правильно, и будет намного больше возможных ситуаций с ошибками, когда вы не сможете записать нужную информацию просто потому, что сама лог-инфраструктура не будет работать. И что-то худшее: сбой в процедуре журнала (например, повреждение базы данных или взаимоблокировка), вероятно, повлияет на производительность приложения, и тогда вы столкнетесь с ситуацией, когда вторичный компонент не позволяет приложению выполнить его основную функцию. 1007 *

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

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

Answer 2

Мы использовали базу данных журналов на моей последней работе, и это было здорово.

У нас были хранимые процедуры, которые выкладывали бы обзоры общего состояния системы для различных показателей, которые я мог загрузить с веб-страницы. Мы также могли бы быстро выплеснуть трассировку для данного приложения за определенный период, и, если бы я захотел, было легко получить его в виде текстового файла, если вы действительно любите grep-файлы.

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

Я думаю, что это решает большинство проблем, высказанных в других местах. Это все вопрос реализации. Но если я остановлюсь здесь, это все равно будет «не намного хуже», и это плохая причина, чтобы заняться настройкой ведения журнала БД. Что мне понравилось в этом, так это то, что он позволял нам делать новые вещи , которые было бы намного сложнее делать с плоскими файлами.

Было четыре основных улучшения по сравнению с файлами. Первый - это системные обзоры, которые я уже упоминал. Вторым, и, что самое важное, я считаю, была проверка на предмет отсутствия в сообщениях каких-либо приложений, в которых мы обычно ожидаем их найти. Подобные вещи почти невозможно обнаружить в традиционной регистрации файлов, если вы не проводите много времени каждый день, просматривая ошеломляющие журналы для приложений, которые просто говорят вам, что все хорошо в 99% случаев. Удивительно, как освобождает представление, чтобы показать отсутствующие записи журнала. В большинстве дней нам вообще не нужно было просматривать большинство файлов журнала ... что-то, что было бы опасно и безответственно без базы данных.

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

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

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

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

Answer 3

Да, мы делаем это здесь, и я не могу этого вынести. Одна из проблем, с которыми мы сталкиваемся здесь, - если есть проблема с базой данных (подключение, повреждение и т. Д.), Все журналы останавливаются. Моя другая большая проблема с этим состоит в том, что трудно проследить, чтобы отследить проблемы. У нас также есть проблемы с тем, что журналы таблиц занимают слишком много места, и нам приходится беспокоиться об их усечении, когда мы перемещаем базы данных, потому что наши журналы очень большие.

Я думаю, что это неуклюжий по сравнению с файлами журналов. Мне трудно увидеть «большую картину», хранящуюся в базе данных. Я признаю, что я человек из файла журнала, мне нравится возможность открывать текстовый файл и просматривать его (regex) вместо использования sql для поиска чего-либо.

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

Answer 4

Ранее мы использовали централизованное ведение журнала SQL Server, и, как упоминалось в предыдущем сообщении, самая большая проблема заключалась в том, что прерывание соединения с базой данных означало бы прерывание ведения журнала. Я фактически закончил тем, что добавил добавление подпрограммы очередей в журнал, который сначала попытался бы использовать БД, и записать в физический файл, если это не удалось. Вам просто нужно добавить к этой подпрограмме код, который при успешном ведении журнала в БД будет проверять, есть ли какие-либо другие записи в очереди локально, и записывать их тоже.

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

Answer 5

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

Как только вы получите все, что вас интересует, входя в нужные вам столбцы, гораздо проще отслеживать последовательные действия чего-либо, если вы сможете выделить его по столбцам. Например, если у вас был процесс «ввода», вы обычно регистрируете все, когда текст «процесс ввода» помещается в столбец «logtype» или «process». Затем, когда у вас возникают проблемы с «процессом ввода», оператор WHERE в этом столбце изолирует все процессы ввода.

Answer 6

мы делаем это в нашей организации в больших объемах с SQL Server. По моему мнению, запись в базу данных лучше благодаря возможностям поиска и фильтрации. Производительность данных от 10 до 50 МБ и сохранение их только в течение 5 дней не влияет на ваше приложение. Отслеживание транзакций и пользователей будет очень легко сравнить с отслеживанием из текстового файла, так как вы можете фильтровать по транзакции или пользователю.

Вы говорите, что файлы читаются редко. Итак, решите, стоит ли тратить время на разработку среды ведения журнала? Рассчитайте свое время, потраченное на поиск журналов по файлам журналов за год, по сравнению со временем, которое потребуется для написания кода и тестирования. Если на поиск журналов тратится 1 час или более в день, лучше выгрузить журналы в базу данных. Что может резко сократить время, затрачиваемое на решение проблем.

Если вы тратите меньше часа, вы можете использовать некоторые инструменты текстового поиска, такие как "SRSearch", который я использовал, это отличный инструмент для поиска по нескольким файлам в папке и выдачи результатов в небольших фрагментах ("как Результаты поиска Google "), где вы нажимаете, чтобы открыть файл с интересующим результатом. Также доступны другие инструменты текстового поиска. Если среда Windows, то у вас есть Microsoft LogParser, также бесплатный бесплатный инструмент, где вы можете запросить свой файл как базу данных, если файл записан в определенном формате.

Answer 7

Я прочитал все ответы, и они великолепны. Но в компании, в которой я работал, из-за нескольких ограничений и аудита обязательно входил в базу данных. В любом случае, у нас было несколько способов войти в систему, и решение было установить конвейер, где наши программисты могли бы подключиться к конвейеру и войти в базу данных, файл, консоль или даже переслать журнал в порт, который будет использоваться другими приложениями. Этот конвейер не прерывает нормальный процесс, и сохранение файла журнала в то же время, когда вы входите в базу данных, гарантирует, что вы редко потеряете строку. Я предлагаю вам изучить дальнейшее log4net, что это здорово для этого.

http://logging.apache.org/log4net/

Answer 8

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

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

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

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

4. Отдельные небольшие файлы журналов можно легко сжать и перенести, не влияя на работу сервера. Раньше у нас были журналы размером в сотню ГБ данных в базе данных. Перемещение таких больших баз данных между серверами становится большой проблемой, особенно из-за того, что при этом вы должны выключить сервер баз данных. Я хочу сказать, что обслуживание становится настоящей болью в тот день, когда вы начинаете перемещать большие базы данных.

5. Запись в файлы журналов в целом выполняется намного быстрее, чем запись в БД. Не стоит недооценивать скорость файла ввода-вывода вашей операционной системы.

6. Файлы журналов - отстой, только если вы неправильно структурировали свои журналы. Возможно, вам придется использовать дополнительные инструменты, и вам даже может понадобиться разработать свои собственные, чтобы помочь в их обработке, но в конце концов это будет стоить.

Answer 9

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

Answer 10

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

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

При этом вы получаете преимущества обоих методов.