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

Question

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

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

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

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

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

Answer 1

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

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

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

Answer 2

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

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

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

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

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

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

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

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

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

Answer 3

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

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

Answer 4

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

Answer 5

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

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

Answer 6

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

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

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

Answer 7

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

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

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

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

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

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

Answer 8

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

Answer 9

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

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

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

Answer 10

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

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

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

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

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

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

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

Answer 11

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

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