云铸造业务审计事件

Question

我在Cloud上部署了一些spring引导微服务，并且我必须实现它们发出的业务审计事件的传播和存储(到存储库)。

我可以用几种方式做这件事，例如：

1. 将审计事件发布到Source (Spring Cloud Stream / RabbitMQ)，并由Sink服务将事件写入存储库。
2. 将审计事件发布为自定义应用程序日志，并通过log-consuming service筛选并将事件写入存储库来使用它。
3. 使用internal CF's mechanism作为新的自定义log type或自定义audit event发布审计事件--我认为这个选项不是一个好主意，但我可能错了……

是否有任何推荐的方法/模式来实现这一问题的云铸造平台？

编辑

所有的方法都符合(在我看来) 12因子规则，但每种方法都有其优点和缺点：

• (1) Spring
  • +确保交付(事件不会丢失)
  • +允许使用路由(RabbitMQ)
  • -需要连接到消息代理(不像记录器那么容易)

​

• (2)日志消费服务
  • +很容易
  • -日志可能会丢失
  • -审计biznes信息传播得太广- GDPR

​

• (3)新CF的日志类型
  • -可能强制在CF中进行更改

​

Answer 1

我要用一个问题回答你的问题。你的“业务审计日志”到底是什么？如果你失去了一些，会有什么问题吗？

如果答案是是，而且即使丢失一个日志也是不可接受的，那么我会说明它们不是真正的日志，而是业务记录(可能看起来就像日志)。在这种情况下，将记录存储在有存储的数据库或其他服务中是有保证的。这是额外的工作，但您需要确保这些记录被正确地存储，因此额外的工作是值得的。

如果答案是no，并且丢失一些甚至所有日志(最坏情况下的计划)是可以接受的，那么我建议将它们写到STDOUT。云Foundry将为您处理这些日志的路由，因此非常容易。如果要将syslog排水系统绑定到日志消费服务，或者可以实现Loggregator喷嘴并直接从CF读取日志，则可以绑定它们。从应用程序的角度来看，这并不重要，你甚至可以在以后改变主意，而不需要更新应用程序。

希望这能帮上忙！

Answer 2

在我的应用程序中，我坚持使用12因素应用规则。

第11条规则是：将日志视为事件流

这是日志记录的重要部分：

一个十二因素的应用程序从来不关心它的输出流的路由或存储。它不应试图写入或管理日志文件。相反，每个正在运行的进程都将其未缓冲的事件流写入stdout。在本地开发期间，开发人员将在终端的前台查看此流，以观察应用程序的行为。 在暂存或生产部署中，每个流程的流将被执行环境捕获，与应用程序中的所有其他流一起整理，并被路由到一个或多个最终目的地，以便查看和长期存档。这些归档目的地对应用程序不可见或可配置，而是完全由执行环境管理。开源日志路由器(如Logplex和Fluentd)可用于此目的.

因此，建议的方法是将日志写入stdout。