регистрации приложений с использованием сериализации объектов

Question

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

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

Я знаю, что log4net и similair решение имеет DB appenders. Но как насчет дебютирующего БД? И большие объекты?

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

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

Answer 1

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

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

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

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