События бизнес-аудита на Cloud Foundry

Question

У меня есть некоторые подпружиненные микроуслуги, развернутые на Cloud Foundry , и мне нужно реализовать распространение и сохранение (в хранилище) событий бизнес-аудита, отправляемых ими.

Я могу сделать это несколькими способами, например ::1007

1. Публикация событий аудита в Source (Spring Cloud Stream / RabbitMQ) и их использование службой Sink, записывающей события в хранилище.
2. Публикация событий аудита в виде пользовательского журнала приложения и его использование путем log-consuming service фильтрации и записи событий в хранилище.
3. Публикация событий аудита с использованием internal CF's mechanism в качестве нового пользовательского log type или пользовательского audit event - я думаю, что этот вариант не очень хорошая идея, но я могу быть неправильно ...

Есть ли рекомендуемый подход / шаблон для решения этой проблемы на платформе Cloud Foundry?

---

EDIT

Все подходы соответствуют (на мой взгляд) правилам 12-фактора , но у каждого есть свои преимущества и недостатки:

• (1) Весенние облачные потоки
  • + обеспечивает доставку (события не будут потеряны)
  • + позволяет использовать маршрутизацию (RabbitMQ)
  • - требуется соединение с брокером сообщений (не так просто, как с регистратором)
• (2) служба обработки журналов
  • + легко
  • - журналы могут быть потеряны
  • - информация аудита слишком широко распространена - GDPR
• (3) новый тип журнала CF
  • -, вероятно, форсирует изменения в CF

Answer 1

Я собираюсь ответить на ваш вопрос вопросом. Каковы ваши "журналы аудита бизнеса"? Будет ли проблема, если вы потеряете некоторые из них?

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

Если ответ нет и допустимо потерять некоторые или даже все (план для худшего случая) этих журналов, то я бы предложил просто записать их в STDOUT. Cloud Foundry будет обрабатывать маршрутизацию этих журналов для вас, так что это очень просто. Вы можете связать приемник системного журнала, если хотите отправить их в службу, использующую журналы, или вы можете реализовать сопло Loggregator и читать журналы напрямую из CF. С точки зрения приложения это на самом деле не имеет значения, и вы можете даже передумать позже, и вам не нужно будет обновлять ваше приложение.

Надеюсь, это поможет!

Answer 2

В моем приложении я придерживаюсь 12-факторного приложения правил.

11-е правило: Обрабатывать журналы как потоки событий

Это важная часть ведения журнала:

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

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

Итак, предложенный способ - записывать логи на стандартный вывод.