У вас есть 3 варианта:
Файл журнала - хороший вариант, который я на самом деле предпочитаю использовать, потому что могу легко разбираться с записями и просматривать их. Я даже делаю каталоги для файлов журнала в следующем формате AppName \ YYYY \ MM \ DD \ yourfile.log, чтобы я мог видеть, как все выглядело в определенный день (в некоторых случаях были годы регистрации). Потоки не проблема. Вы можете сделать это потокобезопасным. Это довольно безопасный метод, потому что у вас почти всегда будет доступ к записи на диск, если ваш диск не заполнен, что может обрабатывать один из других параметров.
База данных - тоже хорошо, потому что вы можете легко запросить ее. По моему мнению, он имеет большую вероятность сбоя и не должен использоваться для первичной регистрации. Если ваша БД выходит из строя, возникают проблемы, которые вызывают исключение, где бы вы ее сохранили? Ваша БД может отставать и получать тайм-ауты и т. Д. Это также может повлиять на производительность вашей БД в зависимости от того, сколько вы ведете журналирование.
Журнал системных событий - отлично подходит для 1, 2 или обоих. Журнал событий почти всегда будет доступен, и это то, что использует Windows (при условии сервера Windows), так что это очень безопасно. Вы также можете создавать исключения для приложений, чтобы отфильтровать все специфичные для Windows вещи, о которых вам не нужно беспокоиться. Однако в нем хранится только определенная сумма, поэтому ваша история может быть короткой, в зависимости от того, сколько там добавлено, поэтому вам может потребоваться способ экспорта этих данных по расписанию.
Большинство моих приложений используют комбинацию 1 и 2. Мы развернули собственную регистрацию, и она хорошо сработала для нас, но есть несколько замечательных библиотек, которые могут помочь с этим. У нас также есть встроенный инструмент, позволяющий отслеживать журналы событий сервера для наших конкретных элементов и по возможности уведомлять нужных людей на основе определенных критериев. Он настроен как процесс извлечения с другого сервера, поэтому даже если у сервера есть проблемы, из-за которых он не может отправить уведомление, сервер мониторинга должен в конечном итоге получить данные и выполнить правильное уведомление.
Ключом, в зависимости от того, насколько важным является ведение журнала для вас и вашего приложения, является избыточность. Если вы идете по маршруту БД, есть резервная копия. Если вы идете по маршруту файла, сделайте резервную копию. В большинстве случаев регистрация может быть неудачной в определенных случаях, поэтому важно иметь более одного способа хранения необходимой вам информации. Это сэкономило мне массу времени на выяснение проблем, когда по какой-либо причине один из методов журналирования не удался.