我们在 AWS 的 ECS 平台上运行我们的服务，并将我们的日志发送到 AWS CloudWatch。
我们有两种类型的日志，任何容器都可以生产以下类型：
- 常见的应用程序日志（访问、错误、等等）；开发人员和管理员必须能够轻松查看这些日志
- 审计日志（人类可读的“谁在何时做了什么”日志）；必须限制对这些日志的访问
审计日志是法规强制要求的，除了更严格的访问控制要求外，它们的保留时间也比应用程序日志更长，因此将两者放在同一个日志流中并不是一个真正的选择。因此，我们使用两个日志流，其中一个位于具有严格访问策略的 CloudWatch 日志组中。
目前，我们将日志写入单独的磁盘文件，然后由日志代理将日志条目发送到 CloudWatch。但是，我们希望切换到“Docker 方式”的日志记录，即将所有日志写入 STDOUT 或 STDERR，让日志驱动程序处理其余部分。这听起来特别有吸引力，因为日志磁盘（几乎）是我们正在使用的唯一磁盘挂载，摆脱它们确实非常好。（除了日志磁盘外，我们的容器严格是只读的。）
问题是，我们无法找到一种合理的方法来保持日志流分离。显而易见的做法是以某种方式标记日志消息，然后稍后将它们分开，但仍然存在一个问题：
- 明智的做法是让日志驱动程序根据消息标签将消息分离到不同的日志流。Docker 的 awslogs 日志驱动程序不支持此功能。
- “强力”方法是写入单个 CloudWatch 日志流，然后使用自写过滤器重新处理该流，该过滤器写入另外两个日志流。由于 CloudWatch 计费基于 API 调用，因此这基本上会使成本翻倍，因此是不可能的。
- 我们也可以设置一个日志主机，并使用另一个 docker 日志驱动程序（例如 syslog）将所有日志发送到那里。然后我们可以拆分日志流，并将它们转发到 CloudWatch。这会给所有日志添加一个瓶颈和 SPOF，所以听起来也不太好。
希望我们忽略了一些明显的问题，在这种情况下，我们将非常感谢您的帮助。
如果没有，有没有什么解决方法（甚至是适当的解决方案）可以使这种事情发挥作用？
答案1
关于审计日志，您愿意分享一下您想要审计的内容吗？一般来说，出于这种目的，您可能需要使用 CloudTrail 或 GuardDuty。
答案2
我们仍在寻找更好的方法来做到这一点，但到目前为止，我们在我工作的公司要做的是将卷附加到容器并在那里写入，安装代理并将其视为普通日志文件。
我不知道这是否是一个可行的解决方案，因为我在阅读时发现了你的问题，但也许 fluentd 适合你的需求。它有一个 docker 驱动程序，你可以使用标记策略来路由日志。
答案3
AWS 至少有两种原生方式，
- 您可以创建订阅 CloudWatch 日志处理日志流以供审计
- 使用最近启动的功能火透镜将您的日志收集到您想要的任何目的地。