本文档讨论了混合云和多云端部署的监控和日志记录架构，并介绍了使用 Google Cloud 实现此类架构的最佳做法。通过本文档，您可以确定哪些模式和产品最适合您的环境。
每家企业都有独特的应用工作负载组合，对混合或多云端设置的架构提出了要求和限制条件。虽然您必须设计和定制架构来满足这些限制条件和要求，但您可以依靠一些常见模式。
本文档介绍的模式分为两类：
- 在单一管理平台架构中，所有监控和日志记录都集中在一个位置，旨在提供单一访问和控制点。
- 在单独的应用和操作架构中，敏感应用数据与不太敏感的操作数据彼此分隔，其目的是满足敏感数据的合规性要求。
选择架构模式
您可以使用下图中的决策树来确定适用于您的使用场景的最佳架构。
本文档详细介绍了每种架构，但概括来讲，您有以下几种选择：
- 从 Monitoring 导出到旧解决方案。
- 直接导出到旧解决方案。
- 将 Monitoring 与 Prometheus 和 Fluentd 或 Fluent Bit 搭配使用。
- 将 Monitoring 与 observIQ BindPlane 搭配使用。
单一管理平台架构
混合系统的一个常见目标是将来自多个应用和环境的各种来源的监控和日志记录信息集成到单个显示中。这种显示类型称为单一管理平台。
下图说明了这种模式，在该模式下，来自本地和云端所有应用的监控和日志记录数据都集中到云端托管的单个代码库中。
此架构具有以下优势：
- 所有监控和日志记录都在一个统一的视图中。
- 您可以在同一个位置管理数据存储和保留。
- 可以实现集中式访问控制和审核。但是，您仍需要确保传送到中央代码库的传输中数据的安全性。
将 Monitoring 作为单一管理平台
Cloud Monitoring 是一个可监控和管理服务、容器、应用及基础架构的解决方案，由 Google 管理。如需获得针对指标、日志、跟踪记录和事件的单一管理平台和强大的存储解决方案，请使用 Google Cloud Observability。该套件还提供了一整套实现可监测性的工具，例如信息中心、报告和提醒。
所有 Google Cloud 产品和服务均支持与 Monitoring 集成。此外，您还可以使用多个集成工具将 Monitoring 扩展到混合和本地资源。
以下最佳做法适用于将 Monitoring 用作单一管理平台的所有架构：
- 为满足日志保留的合规性要求，请为您的组织设置日志接收器。
- 如需快速分析日志事件，请设置将日志导出到 BigQuery 以实现安全性和访问分析。
- 如需分析存储在日志存储桶中的日志，请通过日志分析运行 SQL 查询。
- 对于包含敏感数据的项目，请考虑启用数据访问审核日志，这样您可以跟踪访问了这些数据的人员。
- 如需移除敏感信息（如社会保障号、信用卡号和电子邮件地址），您可以过滤日志数据。您可以使用自定义 Fluentd 配置、自定义 Fluent Bit 配置或通过日志排除项注入数据来进行过滤。您还可以单独导出未过滤的日志以满足合规性要求。
- 为优化费用，请分析 Monitoring 和 Logging 使用情况并实施费用控制。Monitoring 和 Logging 是代管式服务，日志和指标按用量计费。
使用 Monitoring 和 observIQ 提供的 BindPlane 进行混合监控和日志记录
借助 Google 的合作伙伴 observIQ 的 BindPlane，您可以将监控和日志记录数据从本地虚拟机和 Amazon Web Services (AWS)、Microsoft Azure、Alibaba Cloud 和 IBM Cloud 等其他云服务提供商导入到 Google Cloud 中。下图展示了 Monitoring 和 BindPlane 如何为混合云提供单一管理平台。
此架构具有以下优势：
- 除了监控虚拟机等资源之外，BindPlane 还具有针对超过 50 个热门数据源的内置深度集成。
- 使用 BindPlane 不会产生额外的许可费用。 BindPlane 指标会作为自定义指标导入到 Monitoring 中，这些指标是收费指标。BindPlane 日志与其他 Logging 日志的费率相同。
如需详细了解如何实现此模式，请参阅使用 BindPlane 对本地资源进行日志记录和监控。
使用 Prometheus 和 Monitoring 进行 Google Kubernetes Engine 混合监控
借助 Google Cloud Managed Service for Prometheus（一种由 Google Cloud 完全管理的常用开源监控解决方案），您可以使用 Monitoring 监控在多个 Kubernetes 集群上运行的应用。当运行分布在 Google Cloud 上的 Google Kubernetes Engine (GKE) 和本地数据中心内的 GKE on VMware 中的 Kubernetes 工作负载时，此架构非常有用，因为它在这两者之间提供了一个统一的接口。下图展示了如何使用 Prometheus 和 Monitoring 收集器收集数据。
此架构具有以下优势：
- 跨云端和本地环境使用一致的 Kubernetes 指标。
- 您可以使用 Prometheus 全局监控工作负载并发出提醒，而无需大规模手动管理和操作 Prometheus。
- 使用 Prometheus 无需支付额外的许可费用。Prometheus 指标会导入到 Monitoring 中。导入操作需要收费，按注入的样本数计费。
此架构具有以下缺点：
- Prometheus 仅支持监控，因此必须单独配置日志记录。以下部分介绍了使用 Fluentd 或 Fluent Bit 进行日志记录的常见方式。
我们推荐以下最佳做法：
- 默认情况下，Prometheus 会收集所有公开的指标，每个指标都会成为收费指标。为避免产生意外费用，请考虑实施 Monitoring 费用控制。
使用 Fluentd 或 Fluent Bit 和 Cloud Logging 进行 GKE 混合日志记录
借助 Fluentd 或 Fluent Bit（一种常用的开源日志记录代理）和 Cloud Logging，您可以将在多个 GKE 集群上运行的应用中的日志注入到 Cloud Logging。当运行分布在 Google Cloud 上的 GKE 和本地数据中心内的 GKE on VMware 中的 Kubernetes 工作负载时，此架构非常有用，因为它在这两者之间提供了一个统一的接口。下图展示了日志流。
此架构具有以下优势：
- 实现跨云端和本地环境的 Kubernetes 日志记录一致性。
- 您可以自定义 Logging 以过滤掉敏感信息。
- 使用 Fluentd 或 Fluent Bit 不会产生额外的许可费用。使用 Fluentd 或 Fluent Bit 导入到 Logging 中的日志需要收费。
此架构具有以下缺点：
- Fluentd 和 Fluent Bit 仅支持日志记录，因此必须单独配置监控。上一部分讨论了使用 Prometheus 进行监控的常见方式。
如需详细了解如何实现此模式，请参阅使用 Fluentd 为 Google Kubernetes Engine 自定义 Logging 日志或使用 Fluent Bit 为 Google Kubernetes Engine 自定义 Logging 日志。
将合作伙伴服务作为单一管理平台
如果您已在使用第三方监控或日志记录服务（如 Datadog 或 Splunk），您可能不希望迁移到 Logging。如果是这样，您可以将 Google Cloud 中的数据导出到许多常见的监控和日志记录服务。您可以选择使用集成的监控和日志记录服务，也可以选择最符合您需求的单独的监控和日志记录服务。
从 Logging 导出到合作伙伴服务
在此模式中，您需要向合作伙伴的监控服务（例如 Datadog）授权，以连接到 Cloud Monitoring API。此授权会允许该服务提取 Logging 可用的所有指标，使 Datadog 可以充当监控的单一管理平台。
对于日志记录数据，Logging 提供到 Pub/Sub 的导出（日志接收器）。这些导出为 Elastic 和 Splunk 等合作伙伴日志记录服务提供了一种性能良好且灵活的方法，用于从 Logging 中实时提取大量日志，使这些合作伙伴服务可以充当日志的单一管理平台。
下图展示了日志记录和监控的组合架构。
此架构具有以下优势：
- 您可以继续使用熟悉的现有工具。
- Google Cloud 支持团队仍然有权访问 Logging 日志进行问题排查。
此架构具有以下缺点：
- 合作伙伴解决方案通常由外部托管，这意味着如果网络连接中断，它们可能无法使用或收集数据。虽然有时您可以通过自托管来降低这种风险，但需要自行维护解决方案的基础架构。
- Google Cloud 支持团队无法直接访问外部托管的信息中心。这种可访问性的缺失可能会导致问题排查和缓解速度减慢。
- 商业合作伙伴解决方案可能会产生更多的许可费用。
以下是一些详细的集成示例：
- Datadog：监控 Compute Engine 指标和收集 Logging 日志
- Elastic：将 Logging 日志导出到 Elastic Cloud
- Splunk：导出 Logging 的场景
使用 Grafana 分析来自 Prometheus 和 Logging 的指标
Grafana 是一种常用的开源监控工具，通常与 Prometheus 配合使用以收集指标。在此架构中，您需要使用 Prometheus 作为本地收集层，使用 Grafana 作为 Google Cloud 和本地资源的单一管理平台。下图展示了一个示例架构，用于分析来自 Google Cloud 和本地的指标。
此架构具有以下优势：
- 它适用于同时拥有虚拟机和容器的混合环境。
- 如果您的组织已在使用 Prometheus 和 Grafana，那您的用户可以继续使用它们。
此架构具有以下缺点：
- Prometheus 仅支持监控，因此必须单独配置日志记录，例如使用 Fluentd 或适用于 Grafana 的 Cloud Logging 插件。
- Prometheus 是一种可扩展的开源工具，但支持的企业软件集成范围有限。
- Prometheus 和 Grafana 是第三方工具，不是 Google 官方产品。Google 不会为 Prometheus 或 Grafana 提供支持。
如需了解详情，请参阅使用适用于 Grafana 的 Cloud Logging 插件更好地进行问题排查。
使用 Fluentd 导出日志
前面的模式涵盖了使用 Fluentd 或 Fluent Bit 作为 Logging 的日志收集器。这一基本架构也可用于支持 Fluentd 或 Fluent Bit 的其他日志记录或数据分析系统，包括 BigQuery、Elastic 和 Splunk。下图演示了此模式。
此架构具有以下优势：
- 它适用于同时拥有虚拟机和容器的混合环境。
- Fluentd 可以从多个数据源（包括系统日志）读取数据。
- Fluentd 为许多常用的第三方日志记录和数据分析系统提供了输出插件。
- Fluent Bit 也可以从多个输入（包括系统日志）中读取数据。
- Fluent Bit 为许多常用的第三方日志记录和数据分析系统提供了输出。
此架构具有以下缺点：
- Fluentd 和 Fluent Bit 仅支持日志，因此必须单独配置监控。上一部分介绍了使用 Prometheus 和 Grafana 进行监控的常见方式。
- Fluentd 和 Fluent Bit 是第三方工具，并非 Google 官方产品。Google 不会为它们提供支持。
- Google Cloud 支持团队无法访问导出的日志以进行问题排查。需要特别指出的是，Google 不会为未启用 Logging 的 GKE on VMware 集群提供支持。
将应用数据和操作数据分开
单一管理平台架构要求将应用监控和日志记录数据流式传输到云端。然而，您可能需要遵守那些要求将客户数据保存在本地或对可以存储在公有云中的数据有严格限制的法规或合规性要求。
对于这些混合环境，一个有用模式是将敏感应用数据与低风险操作数据分开，如下图所示。
使用 GKE Enterprise 分隔应用数据和系统数据
GKE Enterprise on VMware 是 GKE Enterprise 套件的一部分，包括用于监控本地集群的 Grafana。此外，您还可以选择安装 Elastic Stack 或 Splunk 等合作伙伴解决方案以进行日志记录。通过使用这些解决方案，您可以完全在本地提取和查看敏感应用数据，同时仍将系统数据导出至 Google Cloud 上的 Logging。下图说明了此架构。
此架构具有以下优势：
- 敏感应用数据完全保留在本地。
- 本地监控和日志记录没有云依赖项，即使网络连接中断也仍然可用。
- 所有 GKE 系统数据（包括本地和 Google Cloud）都集中在 Logging 中，Google Cloud 支持团队可根据需要访问这些数据。
如需查看使用 Elastic Stack 作为合作伙伴解决方案的实现示例，请参阅使用 Elastic Stack 监控 GKE Enterprise。
后续步骤
- 如需详细了解混合和多云最佳实践，请参阅混合和多云模式及实践系列文章，包括架构模式和安全网络架构模式。
- 注册 Cloud Kubernetes 最佳做法任务，获取关于 GKE 上可监测性及其他方面的实践练习。
- 探索有关 Google Cloud 的参考架构、图表和最佳做法。查看我们的 Cloud Architecture Center。