Ведение журнала приложения с сериализацией объекта

Я реализую ведение журнала в приложении веб-службы со следующими требованиями:

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

Я знаю, что решения log4net и similair имеют дополнения к БД. А как насчет отложенной записи БД? А большие объекты?

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

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


logging log4net audit-logging enterprise-library
person Vitaliy    schedule 13.05.2015    source источник

Ответы (1)


arrow_upward
1
arrow_downward

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

Отредактировано:

  1. log должен храниться в базе данных (Да, для этого вы можете использовать их DB Listener)
  2. журнал должен быть машиночитаемым (каждый бит информации должен храниться в отдельном столбце) (Да, есть стандартные свойства, которые сохраняются для каждого сообщения, плюс вы можете определить свои собственные, используя расширенные свойства, которые также сохраняются к БД и другим слушателям, таким как Live Viewer и т. д.)
  3. log должен быть расширяемым (клиентский код может указывать информацию, которая будет идти в конкретный столбец в базе данных) должен иметь возможность передавать большой объект из клиентского кода в базу данных (сериализация) (Да, это из коробки. Вы можете настроить, что свойства, которые вы хотите сохранить в БД с помощью простой конфигурации. Пользовательские объекты автоматически сериализуются в журналах (или БД в вашем случае), поскольку RI использует формат структуры для ведения журнала)
  4. не должны снижать производительность (операции записи в БД должны выполняться в отдельном потоке) (Да. Все действия по ведению журнала отправляются слушателям через отдельный рабочий поток, чтобы не влиять на производительность основного приложения)
  5. Только Live Viewer может получать 80 000 сообщений в секунду.
  6. Объем оперативной памяти невелик, так как большинство сообщений кэшируются на жестком диске
  7. Имеет возможности автоматического сохранения / автоматической очистки.
  8. Можно легко использовать фреймворки NLog, Log4net, EntLib, Common Logging для сопоставления с RI Framework (однако вы потеряете возможность регистрировать подробные сведения, такие как наборы данных, коллекции и т. Д.).

введите описание изображения здесь

ОТКАЗ ОТ ОТВЕТСТВЕННОСТИ: Я не работаю напрямую в ReflectSoftware, но я один из основных разработчиков, которые помогают создавать ReflectInsight. Моя основная цель - помочь любому с их потребностями в структуре ведения журнала и отвечать только на вопросы stackoverflow, которые применимы в этом отношении.

person code5    schedule 13.05.2015
comment
С первого взгляда я действительно не могу понять, почему это лучше, чем простой log4net. И поддерживает ли он что-нибудь, что я перечислил выше? - person Vitaliy; 13.05.2015