Служебная шина Oracle с BigData

У меня нет большого опыта работы с Oracle Service Bus, я пытаюсь разработать решение для ведения журнала с помощью BigData.

Как я читал, журнал по умолчанию и активность отчетов в OSB помещают данные в файл журнала сервера домена или в базу данных, где мы настраиваем домен сервера. Если я хочу поместить все журналы в отдельную базу данных BigData. Мне понадобится любой из этих подходов:

  1. Выноска Java, используйте JMS или другую технологию для отправки данных на сервер больших данных.
  2. Вызов веб-службы, создайте отдельную веб-службу для обработки журналов.
  3. Создайте настраиваемый поставщик отчетов для замены используемого по умолчанию в отчетах OSB.
  4. Что-то другое

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


logging oracle profiling bigdata osb
person Tech Noob    schedule 26.10.2015    source источник

Ответы (2)


arrow_upward
1
arrow_downward

Разве структура ведения журнала в weblogic не основана на Log4j? Это означает, что вы можете использовать JMSAppender (вероятно, разумно обернуть его в приложение Async log4j, если сможете) и обрабатывать его, как хотите.

Или, если вы говорите о структуре отчетов OSB, есть несколько вариантов:

  1. Настройте поставщик отчетов JMS по умолчанию (который использует базовый базу данных SOAINFRA, которая, как мы надеемся, настроена лучше, чем экземпляр Derby по умолчанию), затем напишите MDB, которая извлекает отчеты из очереди и вставляет их в SAS BigData.
  2. Отключите поставщика JMS и используйте пользовательский поставщик, который может делать все, что угодно. Если вы хотите, вы все еще можете выполнить двухэтапный процесс, когда поставщик отчетов сам помещает отчеты в очередь JMS, чтобы он быстро возвращался, а другой MDB извлекает сообщения и сохраняет их в своем собственном темпе.

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

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

если у вас есть буфер, такой как очередь JMS, вы можете справляться с пиками, планируя заранее. Вы можете сказать: «На самом деле мне нужна очередь JMS из 10 000 сообщений, и если она по какой-либо причине переполняется, я хочу (переместить переполнение в отдельную очередь в этом другом поле) или (отфильтровать все несущественные сообщения). ) или (отбросить новые сообщения) или (действие по вашему выбору). Ах да, и если база данных журналов выйдет из строя, я попытаюсь 3 раза зафиксировать, а если нет, переместить ее в эту другую очередь». Или все, что вы хотите.

person Trent Bartlem    schedule 27.10.2015
comment
Можем ли мы использовать JMS и очереди для отправки данных журнала на сервер больших данных? В этом случае ведение журнала Log4j может нам не подойти. Таким образом, я могу использовать Java Callout для реализации JMS внутри кода Java, чтобы он выглядел синхронизированным. Или просто создайте собственный поставщик отчетов, который выполняет ту же работу (используйте JMS для отправки данных журнала на сервер больших данных) и замените поставщика отчетов по умолчанию. Будет ли это работать? Спасибо. - person Tech Noob; 27.10.2015
comment
Отредактировал мой основной вопрос, но вкратце да. - person Trent Bartlem; 28.10.2015
comment
Большое спасибо за ваш подробный ответ. - person Tech Noob; 28.10.2015

arrow_upward
0
arrow_downward

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

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

Ключевым моментом является избегание написания явного вызова службы в каждом конвейере/потоке, а описанные выше подходы используют стандартные регистраторы OSB/ODL*

* Ведение журнала диагностики Oracle

person Jang-Vijay Singh    schedule 16.01.2018