集中的多项目日志监控
在云环境中，根据我们的需要创建和销毁资源是很常见的。出于安全或保密的原因，强烈分离资源也很常见；或者只是为了在发生事故时限制爆炸半径。
在谷歌云上，创建几个项目，每个客户一个，每个项目部署相同的应用程序，这是一个常见的模式，特别是当你有项目依赖的资源，如App Engine或Firestore/Datastore。
你最终会在几个单租户项目中部署一个多租户服务。
这是为设计服务的，但在 第二天你需要监控你的应用程序，在不同的项目中调度。
在我看来，为了跟踪错误，我习惯于 定义几个 基于日志的衡量标准来过滤我的错误案例中的相关日志。然后，我在这些指标上添加一个 云监控警报 在这些指标上添加了一个，以便将错误通知给各个团队（使用电子邮件、PubSub...）。
多个项目的日志
当你有多个项目时，问题是你有 几个 云日志 实例，每个项目一个，很难在同一时间、同一地点监控所有的项目。
此外，当你设置基于日志的指标时，你只能在当前的项目中进行过滤，你不能在文件夹或组织层面上设置过滤器。
因为不同项目中部署的代码是一样的，所以在每个项目中都要重复设置基于日志的指标和警报是没有意义的。在一个地方这样做更有效，也更一致!
文件夹和组织层面的汇
值得庆幸的是，可以用水槽在文件夹和组织层面过滤日志。这里的诀窍是在文件夹和组织层面上 包括子节点的能力。
一个文件夹和一个组织的子节点是文件夹和项目。因此，如果你在你的汇中包括子节点，你也会添加所有的文件夹和项目 (递归)。
该功能被命名为"聚合水槽”.你可以从所有的子节点获得过滤后的日志，并将其汇入BigQuery、PubSub、云存储和Log Bucket。
遗憾的是，这只是一个日志转发，你不能在一个聚合汇上定义一个基于日志的度量。你需要添加其他东西
云日志桶
该解决方案来自于云日志服务本身。你现在可以定义 日志桶.这是一个用户定义的日志存储，你可以在那里路由日志，并在用户定义的保留期（以天为单位）保留它们。
这个功能很有意思，可以将日志保留到一个合法的时期，例如3年。在我们的案例中，保留期并不十分重要，我们只想把日志放在一个地方。
请记住，你的日志保存的时间越长，你使用的存储空间就越多，你为此付出的代价也越大。
汇入云记录日志桶
聚合汇和日志桶的组合是关键。下面是如何使他们在行动中。
- 首先，创建 你需要的资源组织 ，例如，创建一个文件夹，里面有2个项目。
- 然后，在这2个项目中创建一个类似的日志条目，例如，运行一个BigQuery查询，失败了
SELECT * FROM 'bigquery-public-data.austin_311.311_service_requests' where unique_key=3
要查看日志中的错误，请进入云日志，并使用这个过滤器。
resource.type="bigquery_resource"
获取这个日志过滤器，以便以后使用。
- 选择一个日志专用 项目。它可以是2个项目中的一个，或在另一个项目中。然后，创建一个日志水槽
gcloud logging buckets create --location=global \
- 然后在你的文件夹上创建一个聚合水槽 （这也适用于 --组织参数，在组织层面上创建）。
gcloud logging sinks create --folder=<FOLDER_ID> \
- 最后，再次运行你错误的BigQuery查询。
现在，检查云记录日志桶中的新日志条目。要做到这一点
- 转到云端日志页面，点击细化范围
- 选择按存储范围选项，并只选择你的特定日志桶
什么都没有发生，没有日志条目，也没有错误，这让人不安......
实际上，这是一个安全问题：在文件夹级别创建的聚合汇没有写到日志桶的权限
为了解决这个问题，我们需要获得 聚合水槽的writerIdentity
gcloud logging sinks describe --folder=<FOLDER_ID>\
并最终授予writerIdentity服务账户作为日志专用项目的日志桶写入者 。
gcloud projects add-iam-policy-binding <PROJECT_ID> \
再次尝试你的BigQuery查询，嘣！!
你有你的日志在你的日志桶里。
集中你的日志并使用它们
现在，你可以把你所有应用程序的租户的所有相关日志 放在一个地方，你可以对它们做你想做的事情
- 长期/合法地保存它们
- 授权一个团队只访问这个_日志专用_ 项目，以访问日志，但不访问租户项目（和数据）。
- 在一个单一的、汇总的地方创建基于日志的指标。
你呢，你的用例是什么，把所有的日志放在同一个地方？
多个项目的日志监测在一个地方最初发表在Google Cloud - Communityon Medium，人们通过强调和回应这个故事来继续对话。
