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

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

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

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

Таким образом, вы получаете преимущества обоих методов.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

я думаю, что обращается к большинству проблем, выраженных в другом месте. Это - весь вопрос реализации. Но если бы я остановился здесь, то это все еще был бы случай "не намного хуже", и это - плохая причина пойти проблема настроить вход DB. То, что я любил об этом, - то, что это позволило нам делать [приблизительно 111] новые вещи , который будет намного тяжелее относиться к плоским файлам.