А почему бы не писать в БД? Вопросы по многопроцессности отпали бы сами собой.
P.S. А для ASP.NET вообще есть родной health monitoring.

netivan МСУ нахрена базу таким г засорять? С файлами куда удобнее записал = заархивировал и тд.
С таким же успехом я могу сказать - зачем файловую систему засорять?
Во-вторых, плюс БД - транзакционность и отказоустойчивость.
В-третьих, если инфа - это "г", то зачем тогда логировать?

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

netivanКакая разница отдельная база или нет, если она на одном дисковом массиве.
Включаем голову = бэкапы быстрее будут отрабатывать.

Боевая база - 100 Гб
База под логи - 1 Тб

Комментарии требуются?

netivanпроблема не в размере. Тему закрывайте.
Arm79 - попробую найти что за фрейм под логи :).
Вы суть-то уловили, почему лучше логировать в отдельную базу или еще раз дать пояснения?

netivanМСУ, я не нуждался в этих пояснениях как ты не поймешь.
А это что за высер?

netivanКакая разница отдельная база или нет, если она на одном дисковом массиве

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

Arm79hVosttДа, база лучше текста.
Плюсы есть, но есть и минусы. Самый главный минус - скорость. Запись в файл всяко быстрее будет.
Наоборот, в базу быстрее. Про уровни изоляции транзакций кому писал? Какой нах файл...

Arm79МСУпропущено...

Наоборот, в базу быстрее. Про уровни изоляции транзакций кому писал? Какой нах файл...
Да ну, ерунда. Несколько сот обращений в секунду - большая нагрузка на БД.
И какие проблемы с бд? Переварит, не переживай. А файл загнется.

Arm79Предположим, работает какой-нибудь сетевой сервис. И нужно лог писать о его состоянии. И тут отвалилась сеть. Естественно, посыпятся ошибки, но записаться в Бд уже не смогут, ибо сеть отвалилась :-)
Так БД может крутиться локально :) Более того, есть embedded database если что. И даже если отлетела сеть, то какая уже разница, бизнес данные всё-равно уже не доступны, как работать пользователю с ресурсом? Да и сетевые вопросы должны траблшутить сетевики, а не твой файлик на сайте. Не нужно пытаться решить все проблемы мира одним способом, это неправильно.

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

Arm79Да и заводить отдельный сервер для БД логов (не базу, а сервер) дело очень гемморойное в плане бюрократии. Особенно когда в организации что-то типа HP OVO. Какое там, даже SMTP для оповещения об ошибках на почту не дали.
Всё зависит от задачи. Сервер или просто БД.

Arm79МСУТак БД может крутиться локально :)
Не может. Ибо нагруженный сервис. А если речь идет не о централизованном хранилище логов, а о embedded - я вообще не вижу разницы с файлом :-)
1. Поднятие инстанса БД чисто под логи много ресурсов не сожрет. Горизонтальное масштабирование тебе в помощь.
2. Ты не видишь разницу embedded database и текстового файлика? Ну это к доктору :)

Arm79МСУИ даже если отлетела сеть, то какая уже разница, бизнес данные всё-равно уже не доступны, как работать пользователю с ресурсом?
Сервер может иметь и не одну сетевую карточку :-)
С каких это пор сетевая карточка стала сетью сервера? :)

Arm79МСУА какие проблемы? Десятки и сотни терабайт вообще без проблем крутятся тем же скулем.
Дело не в возможностях скуля, а в том, что терабайты серверного диска в каком-нить SAN оченна дорогие. И лицензия на сервер тоже. Может, по отдельности каждый из факторов и не оказывает критического влияния, но их совокупность (ну и бизнес-необходимость) заставляли меня отказываться от этого.
Ну так не о цене говорим, а о возможностях. Если бизнес готов в это инвестировать, то какие проблемы? Если заказчик не хочет оплачивать сервера и ресурсы, то о чем можно говорить. Пусть идёт пасёт коз. Если нужны логи и их много, нужно выделять под это определенную инфраструктуру. А с "файликом" можно пойти на поле коз смешить.

Arm79МСУИ как ты будешь в этом случае смотреться со своим файликом? Особенно, когда нужно поднять какую-то информацию по определенному условию.
Легко и непринужденно. ротация логов - и нет файликов терабайтного размера. + regex поверх него. Речь же идет не об онлайне.
Сколько лет будет выполняться regex по файлику террабайтного объема? Ты смеешься? И сколько будет выполняться поиск по таблицам с нужными индексами.

Arm79МСУВсё зависит от задачи. Сервер или просто БД.
У меня именно сервер, тк никто не разрешил бы на боевой сервер ставить базу логов, которая iops-ы бы отнимала от боя.
Ну знаешь ли, разрешил или не разрешил. Мы с тобой не про разрешения дискутируем.