我正在尝试将 Amazon Cloud Watch 设置为我正在开发的某些 C# 应用程序的远程日志记录目标。我不清楚的一件事是日志组和日志流之间的区别以及它们应该如何使用？
我有许多小应用程序，许多不同的用户将在许多计算机上运行这些应用程序。因此，我希望能够轻松识别每条日志消息的源应用程序和机器。
我的理解是日志流是“共享同一源的日志事件序列”，所以看起来我想为每台机器或每台机器的每个用户创建一个新的日志流。这听起来对吗？
这完全取决于您想要的聚合级别：
我不是这方面的专家，但这是我受过一定教育的意见和经验。
日志组和日志流有什么区别？
主要的功能差异在于，组“共享相同的保留、监控和访问控制设置”，而流则不然。因此，将流拆分为不同日志组的最明显情况是，如果您想要对它们进行不同的访问控制或保留，例如需要审核的应用程序与拥有应用程序就好。
应该如何使用它们？
但是，您也可以看到逻辑分组的差异，我相信这很大程度上取决于您。具体来说，我相信您可以将单个服务的日志拆分为多个流，例如如果您有大量日志，则显示错误、警告和信息，而当您只想查看错误时，不要关心信息。
我还在使用日志洞察，即 aws 中的日志搜索，我相信它们一次只能搜索 50 个日志组，所以我很可能会将我可能经常搜索的应用程序分组在一起，这样我就不会每次我要搜索每个日志组时都手动选择它们。我非常确定您应该能够为每个应用程序提供日志流，并将每个日志流分为错误和信息。不知道它有多么值得，因为无论如何你仍然可以过滤日志中的“错误”字符串，所以很可能只是做同一件事的不同方式。
我还认为，kubernetes 及其应用程序收集日志的默认方式是，它是整个集群的单个日志组，每个 pod 的每个容器都有自己的日志流。但我不确定这是否好，因为如果不同的 Pod 有不同的安全和审计要求，您就无法精细地进行访问控制和保留。但是，我确信可以为每个不同的 Pod 定义日志组，我只是从来不需要拆分它们。
对于 Lambda 和 ECS，有时我们有一个仅针对单个 lambda 的日志组，而其他的日志组如果它们紧密合作，则会被分组。 ECS 通常已经使用集群分成逻辑组，因此每个 ECS 集群都记录组。
我似乎想为每台机器或每台机器的每个用户创建一个新的日志流。这听起来对吗？
您当然应该能够做到这一点，尽管我个人会选择一个日志组，每个主题连接的应用程序都有流，并且通常与某些用户关联的日志将具有用户 ID 或一些跟踪 ID（如果您有）一些订单，我会根据这些订单过滤日志。但总的来说，我想说这更多的是个人喜好而不是其他任何东西。
TL； DR 如果访问控制和保留不重要，我认为这只是逻辑分组的个人品味。