Ведение журнала * Business * Events - использовать каркас ведения журнала?

Question

Что-то здесь не подходит мне, и поэтому я хотел бы услышать мнение сообщества - возможно, я подхожу к этому неправильно ...

В: Уместно ли использовать традиционные инфраструктуры ведения журналов инфраструктуры (например, log4net) для регистрации бизнес-событий ?

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

xx:xx Customer A purchased widget B.
xx:xx Widget B was dispatched from warehouse.
xx:xx Customer B payment declined.

Большинство традиционных инфраструктурных каркасов имеют уровни событий примерно так:

FATAL
ERROR
WARN
INFO
DEBUG

Конечно, эти сообщения не вписываются в это. Лучшим описанием будет ИНФО, но, конечно, это важные события, и ИНФО имеет очень низкое значение.

Мне бы все равно хотелось это как «журнал» (например, я не хочу извлекать это из своих бизнес-объектов каждый раз, когда хочу это увидеть)

Мне кажется, у меня есть два варианта:

1) Используйте фреймворк, такой как log4net, и просто определите для этого специальный регистратор (и живите с тем фактом, что он не выглядит правильным).

2) Предоставьте сервис для выполнения этого, который не зависит от традиционных сервисов регистрации.

Я склоняюсь к 2. Что еще кто-нибудь делал в подобных ситуациях?

Спасибо!

Answer 1

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

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

- НТН, Дасти

Answer 2

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

Следовательно, требования к качеству обслуживания совершенно иные. нужен собственный API.

Первоначально, конечно, это переводится в журнал, но в будущем может перейти к надежному обмену сообщениями или БД.

Answer 3

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

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

По сути, # 2 в вашем вопросе.

Answer 4

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

В частности, в этом случае я бы чувствовал, что традиционные каркасы журналирования не подходят, потому что когда дело доходит до данных, к которым вы, возможно, позже захотите обращаться в рамках каркасов журналирования приложений, вы сможете делать вещи, которые на самом деле не имеют смысла, для Например, вы можете изменить место отправки журнала на основе файла app.config (что бесполезно, если вы попытаетесь прочитать его из другого места).

Тем не менее, если инфраструктура ведения журнала позволяет вам уже делать именно то, что вы хотите, то нет ничего постыдного в том, чтобы просто использовать инфраструктуру ведения журнала в качестве своей реализации и сэкономить свои усилия:

class TransactionLogger
{
    public void Log (Message message)
    {
        MyLoggingFramework.Log(message.string, etc...);
    }
}

Answer 5

Вот похожий пост - мой. Структура ведения журнала аудита и управления исключениями.

Answer 6

Извлечение DiALog: Распределенная модель для сбора информации о происхождении и аудите Помимо распределенного аспекта, вы можете использовать принцип субъект-предикат-объект для записи деловых событий. А потом реконструировать определенные тропы.

Answer 7

вы можете использовать его, но вам нужно программное обеспечение для мониторинга деловой активности и обработки событий. Вдобавок ко всему, IBM WebSphere Business Monitor предоставляет эту возможность. Он обрабатывает общее базовое событие (реализация IBM стандарта формата веб-событий для распределенного управления веб-службами), а затем получает эти данные и создает информационные панели бизнес-активности.

Answer 8

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

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

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

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