Cloud Foundry 上的业务审计事件
Business audit events on Cloud Foundry
我有一些 spring-boot 微服务部署在 Cloud Foundry 上，我必须实现传播和存储（到存储库）它们发出的业务审计事件。
我可以通过多种方式做到这一点，例如：
- 将审计事件发布到
Source (Spring Cloud Stream / RabbitMQ) 并由 Sink 服务使用它，将事件写入存储库。
- 将审核事件发布为自定义应用程序日志，并通过
log-consuming service 过滤和将事件写入存储库来使用它。
- 使用
internal CF's mechanism 作为新自定义发布审计事件 log type or a custom audit event - 我认为这个选项不是一个好主意，但我可能是错的...
有没有推荐的approach/pattern在Cloud Foundry平台上实现这个问题？
编辑
所有方法都符合（在我看来）12-factor 规则，但每种方法都有其优点和缺点：
- (1) Spring 云流
+确保传递（事件不会丢失）+ 允许使用路由 (RabbitMQ) - 需要连接到消息代理（不像记录器那么简单）
- (2) 日志消费服务
+很简单- 日志可能会丢失- 审计业务信息传播得太广 - GDPR
- (3)新CF的日志类型
- 可能强制更改 CF
在我的申请中，我坚持 12 factor application 规则。
第十一条规则是：Treat logs as event streams
这是关于日志记录的重要部分：
A twelve-factor app never concerns itself with routing or storage of
its output stream. It should not attempt to write to or manage
logfiles. Instead, each running process writes its event stream,
unbuffered, to stdout. During local development, the developer will
view this stream in the foreground of their terminal to observe the
app’s behavior.
In staging or production deploys, each process’ stream will be
captured by the execution environment, collated together with all
other streams from the app, and routed to one or more final
destinations for viewing and long-term archival. These archival
destinations are not visible to or configurable by the app, and
instead are completely managed by the execution environment.
Open-source log routers (such as Logplex and Fluentd) are available
for this purpose.
因此，建议的方法是将日志写入标准输出。
我要用一个问题来回答你的问题。你的 "business audit logs" 到底是什么？如果你丢失了其中的一些，会有问题吗？
如果答案是是并且即使丢失一个日志也是不可接受的，那么我会证明它们不是真正的日志，而是业务记录（也许只是看起来像原木）。在这种情况下，将记录存储在数据库或其他可以保证存储的服务中。这是额外的工作，但您需要确保正确存储这些记录，这样额外的工作是值得的。
如果答案是否并且丢失部分甚至全部（最坏情况计划）这些日志是可以接受的，那么我建议只将它们写入 STDOUT。 Cloud Foundry 将为您处理这些日志的路由，因此非常简单。如果你想将它们发送到日志消费服务，你可以绑定一个 syslog drain，或者你可以实现一个 Loggregator Nozzle 并直接从 CF 读取日志。从应用程序的角度来看，这并不重要，您甚至可以稍后改变主意，而无需更新您的应用程序。
希望对您有所帮助！
我有一些 spring-boot 微服务部署在 Cloud Foundry 上，我必须实现传播和存储（到存储库）它们发出的业务审计事件。
我可以通过多种方式做到这一点，例如：
- 将审计事件发布到
Source(Spring Cloud Stream/ RabbitMQ) 并由Sink服务使用它，将事件写入存储库。 - 将审核事件发布为自定义应用程序日志，并通过
log-consuming service过滤和将事件写入存储库来使用它。 - 使用
internal CF's mechanism作为新自定义发布审计事件log typeor a customaudit event- 我认为这个选项不是一个好主意，但我可能是错的...
有没有推荐的approach/pattern在Cloud Foundry平台上实现这个问题？
编辑
所有方法都符合（在我看来）12-factor 规则，但每种方法都有其优点和缺点：
- (1) Spring 云流
+确保传递（事件不会丢失）+允许使用路由 (RabbitMQ)-需要连接到消息代理（不像记录器那么简单）
- (2) 日志消费服务
+很简单-日志可能会丢失-审计业务信息传播得太广 - GDPR
- (3)新CF的日志类型
-可能强制更改 CF
在我的申请中，我坚持 12 factor application 规则。
第十一条规则是：Treat logs as event streams
这是关于日志记录的重要部分：
A twelve-factor app never concerns itself with routing or storage of its output stream. It should not attempt to write to or manage logfiles. Instead, each running process writes its event stream, unbuffered, to stdout. During local development, the developer will view this stream in the foreground of their terminal to observe the app’s behavior.
In staging or production deploys, each process’ stream will be captured by the execution environment, collated together with all other streams from the app, and routed to one or more final destinations for viewing and long-term archival. These archival destinations are not visible to or configurable by the app, and instead are completely managed by the execution environment. Open-source log routers (such as Logplex and Fluentd) are available for this purpose.
因此，建议的方法是将日志写入标准输出。
我要用一个问题来回答你的问题。你的 "business audit logs" 到底是什么？如果你丢失了其中的一些，会有问题吗？
如果答案是是并且即使丢失一个日志也是不可接受的，那么我会证明它们不是真正的日志，而是业务记录（也许只是看起来像原木）。在这种情况下，将记录存储在数据库或其他可以保证存储的服务中。这是额外的工作，但您需要确保正确存储这些记录，这样额外的工作是值得的。
如果答案是否并且丢失部分甚至全部（最坏情况计划）这些日志是可以接受的，那么我建议只将它们写入 STDOUT。 Cloud Foundry 将为您处理这些日志的路由，因此非常简单。如果你想将它们发送到日志消费服务，你可以绑定一个 syslog drain，或者你可以实现一个 Loggregator Nozzle 并直接从 CF 读取日志。从应用程序的角度来看，这并不重要，您甚至可以稍后改变主意，而无需更新您的应用程序。
希望对您有所帮助！