Где написать журнал для приложения Windows

Question

У меня есть приложение .NET Windows, которое развертывается через ClickOnce на веб-сервер. Примерно 100 пользователей в любое время, все расположены по центру. Я использую log4net для входа в приложение, но у меня возникли проблемы с получением лучшего места для размещения журнала.

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

Есть ли у кого-нибудь опыт регистрации в приложении Windows, развернутом в корпоративной среде? Любые предложения о том, где я могу поместить журнал, чтобы он был (1) быстрым, (2) надежным и (3) доступным?

Answer 1

Проблема с регистрацией базы данных - это не скорость: это надежность. Вы регистрируетесь, когда дела идут не так, и если что-то идет не так, шансы недоступной БД не в вашу пользу.

Как правило, вы хотите написать локальный текстовый файл и где-то еще, как сетевой ресурс или БД. Если у вас проблемы с IO/speed, вы можете использовать текстовый файл в качестве буфера и записывать журналы в разрешенный ресурс партиями. Затем вы периодически очищаете локальные журналы резервного копирования.

Answer 2

Что относительно папки ApplicationData? В Vista, что будет что-то вроде этого:

C: \ Users \ Ray \ AppData \ Local \ MyCompanyName

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

Answer 3

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

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

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

Answer 4

log4net поддерживает database appenders для некоторых основных баз данных. Это может быть лучшей альтернативой, если у вас имеется подходящая база данных. Подходите с осторожностью, однако, потому что это может снизить надежность вашего приложения, если оно не управляется правильно.

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

<appender name="BufferingForwardingAppender" type="log4net.Appender.BufferingForwardingAppender"> 
<bufferSize value="1024" /> 
<lossy value="true" /> 
<evaluator type="log4net.Core.LevelEvaluator"> 
    <threshold value="ERROR"/> 
</evaluator> 
<appender-ref ref="DatabaseAppender" /> 

Answer 5

Вы могли бы попробовать где-нибудь в папке CommonAppData - т.е. CommonAppData \ YourAppName \ Logs - при условии, что вы обеспечиваете ограничения на размер и/или периодические ыборкы. Люди используются для периодической очистки временных папок, но с осторожностью относятся к началу работы с CommonAppData, AppData или LocalAppData.

Запись в любом месте, кроме здесь или в Temp, рано или поздно приведет к возникновению проблем с Vista и выше.

Если журналы не являются жизненно важными, то есть если незаменимые данные не будут потеряны, если кто-то удалит журнал, я обязательно поеду на подпапку в Temp и у вас будет отдельное задание планировщика заданий. Это наименее болезненное место.

Answer 6

Я использовал log4net с базами данных ms sql. Как правило, я размещаю их выделенным db на другом сервере, если это возможно. Таким образом, если есть проблемы с сервером приложений или db, я не теряю регистрацию.

Скорость никогда не была проблемой.

Answer 7

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

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

Если вы хотите написать в журнал событий, это довольно прямо вперед:

http://support.microsoft.com/kb/307024

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

Answer 8

В наших приложениях мы log4net и используем общий файл журнала для всех наших пользователей, в каталоге CommonAppData (C: \ Documents and Settings \ All Users \ Application Data \ Company \ Product). В этом случае наш установщик должен вручную установить разрешения для файла каталога и журнала, чтобы все пользователи могли получить к нему доступ, разрешения по умолчанию предназначены только для пользователя, устанавливающего приложение.

Мы также регистрируем необработанные исключения (когда можем) в журнал событий с использованием обработчика исключений верхнего уровня (с использованием реализации, аналогичной: http://www.wintellect.com/cs/blogs/jclark/archive/2005/03/30/simple-main.aspx). Мы используем журнал событий, поскольку все ставки отключены от состояния открытых файловых потоков. Опять же, наш установщик должен настроить источник журнала событий в журнале событий приложения.

Если вы используете журнал событий, убедитесь, что ваш журнал очень минимален. Если вы регистрируете множество событий, так как журнал событий может быть заполнен довольно быстро, а политика по умолчанию для XP - это, чтобы журнал событий начинал отбрасывать события, если журнал заполнен, а размер по умолчанию относительно невелик (512 КБ, и только перезаписывать события старше 7 дней).