這份文件說明混合雲與多雲端部署項目的監控和記錄架構，並提供使用 Google Cloud實作這些架構的最佳做法。這份文件可協助您找出最適合環境的模式和產品。
每家企業都有獨特的應用程式工作負載組合，會對混合式雲端或多雲端設定的架構設有相關需求與限制。雖然您必須精心設計並打造出符合這些限制與需求的架構，您仍可仰賴一些常用的模式。
本文件涵蓋的模式可分為兩類：
- 在單一主控台架構中，所有監控和記錄作業都會集中處理，目的是提供單一存取和控制點。
- 在獨立應用程式和作業架構中，機密應用程式資料會與較不敏感的作業資料分開，目的是為了符合機密資料的法規遵循要求。
選擇架構模式
您可以參考下圖的決策樹，找出最適合您用途的架構。
本文將進一步探討各項架構的詳細資料，但就高層次而言，您可以選擇：
- 從 Monitoring 匯出至舊版解決方案。
- 直接匯出至舊版解決方案。
- 搭配使用 Monitoring 與 Prometheus 和 Fluentd 或 Fluent Bit。
- 搭配使用 Monitoring 與 observIQ BindPlane。
單一主控台架構
混合式系統的常見目標，是將多個應用程式和環境中各種來源的監控和記錄資訊，整合到單一顯示畫面。這類顯示畫面稱為「單一窗格」。
下圖說明這種模式：來自所有應用程式 (包括內部部署和雲端) 的監控和記錄資料，都會集中到雲端託管的單一存放區。
這個架構具有下列優點：
- 您可以在單一畫面中查看所有監控和記錄作業。
- 您可以在單一位置管理資料儲存空間和保留期限。
- 集中控管存取權及稽核。不過，您仍須確保傳輸至中央存放區的資料安全無虞。
透過單一主控台監控
Cloud Monitoring 是由 Google 代管，可監控與管理服務、容器、應用程式和基礎架構的解決方案。如要使用單一窗格，以及指標、記錄、追蹤記錄和事件的強大儲存解決方案，請使用 Google Cloud 可觀測性。此外，這套工具也提供完整的監控工具，例如資訊主頁、報告和快訊。
所有 Google Cloud 產品和服務都支援與 Monitoring 整合。此外，您也可以使用多種整合式工具，將 Cloud Monitoring 擴展至混合式和地端資源。
下列最佳做法適用於所有架構，這些架構使用 Monitoring 做為單一平台：
- 如要符合記錄保留的法規遵循需求，請為貴機構設定記錄接收器。
- 如要快速分析記錄事件，請設定將記錄匯出至 BigQuery，以進行安全性與存取分析。
- 如要分析記錄檔 bucket 中儲存的記錄，請透過記錄檔分析執行 SQL 查詢。
- 如果專案含有機密資料，建議啟用資料存取稽核記錄，追蹤資料存取者。
- 如要移除身分證字號、信用卡號碼和電子郵件地址等私密資訊，可以篩選記錄資料。您可以使用自訂 Fluent Bit 設定進行篩選，或擷取時排除記錄。您也可以單獨匯出未經過濾的記錄，以符合法規遵循要求。
使用 Monitoring 和 BindPlane by observIQ 進行混合式監控和記錄
透過 Google 合作夥伴 observIQ 的 BindPlane，您可以將內部部署 VM 和其他雲端供應商 (例如 Amazon Web Services (AWS)、Microsoft Azure、Alibaba Cloud 和 IBM Cloud) 的監控和記錄資料匯入 Google Cloud。下圖顯示 Monitoring 和 BindPlane 如何為混合雲提供單一窗格。
這個架構具有下列優點：
- 除了監控 VM 等資源，BindPlane 也內建超過 50 種熱門資料來源的深度整合功能。
- 使用 BindPlane 不會產生額外授權費用。 BindPlane 指標會匯入 Monitoring 做為自訂指標，這些指標會產生費用。 同樣地，BindPlane 記錄的費率與其他 Logging 記錄相同。
如要進一步瞭解如何導入這個模式，請參閱「使用 BindPlane 記錄及監控地端部署資源」。
使用 Prometheus 和 Monitoring 監控混合式 Google Kubernetes Engine
Google Cloud Managed Service for Prometheus 是由 Google Cloud全代管的熱門開放原始碼監控解決方案，可讓您使用 Cloud Monitoring 監控在多個 Kubernetes 叢集上執行的應用程式。在 Google Kubernetes Engine (GKE) 上執行 Kubernetes 工作負載時，這項架構非常實用，因為它可在Google Cloud 和地端資料中心的 Google Distributed Cloud 中提供統一介面。下圖顯示如何使用 Prometheus 和 Monitoring 收集器收集資料。
這個架構具有下列優點：
- 雲端和地端部署環境的 Kubernetes 指標一致。
- 您可以使用 Prometheus 監控世界各地的工作負載並接收快訊，無須大規模管理及操作 Prometheus。
- 使用 Prometheus 不會產生額外授權費用。Prometheus 指標會匯入 Monitoring。匯入的資料會產生費用，並依據擷取的樣本數計價。
這種架構有下列缺點：
- Prometheus 僅支援監控，因此必須另外設定記錄功能。下一節將討論使用 Fluentd 或 Fluent Bit 記錄的常見選項。
建議採取下列最佳做法：
- 根據預設，Prometheus 會收集所有公開指標，而每項指標都會成為可計費的指標。為避免非預期支出，建議實作監控成本控制。
使用 Fluentd 或 Fluent Bit 和 Cloud Logging 進行混合 GKE 記錄
透過 Fluentd 或 Fluent Bit 這款熱門的開放原始碼記錄代理程式和 Cloud Logging，您可以將多個 GKE 叢集上執行的應用程式記錄檔擷取至 Cloud Logging。如果您在內部部署資料中心執行 Kubernetes 工作負載，並將其分散到 GKE on Google Cloud 和 Google Distributed Cloud，這個架構就非常實用，因為它能為兩者提供統一的介面。下圖說明記錄的流動過程。
這個架構具有下列優點：
- 您可以在雲端和地端部署環境中，使用一致的 Kubernetes 記錄功能。
- 您可以自訂記錄功能，篩除機密資訊。
- 使用 Fluentd 或 Fluent Bit 不會產生額外授權費用。使用 Fluentd 或 Fluent Bit 匯入 Logging 的記錄會產生費用。
這種架構有下列缺點：
- Fluentd 和 Fluent Bit 僅支援記錄作業，因此必須另外設定監控功能。上一節討論了使用 Prometheus 進行監控的常見做法。
如要進一步瞭解如何實作這個模式，請參閱「自訂 Google Kubernetes Engine 記錄的 Fluent Bit」。
以單一主控台的形式提供合作夥伴服務
如果您已使用 Datadog 或 Splunk 等第三方監控或記錄服務，可能就不想改用 Logging。如果是，您可以從 Google Cloud 匯出資料至許多常見的監控和記錄服務。您可以選擇使用整合式監控和記錄服務，或選取最符合需求的個別監控和記錄服務。
從 Logging 匯出至合作夥伴服務
在這個模式中，您會授權合作夥伴的監控服務 (例如 Datadog) 連線至 Cloud Monitoring API。這項授權可讓服務擷取 Logging 提供的所有指標，因此 Datadog 可做為監控的單一窗格。
對於記錄資料，Logging 提供匯出功能 (記錄接收器) 至 Pub/Sub。這些匯出作業提供高效能且彈性的方法，讓合作夥伴記錄服務 (例如 Elastic 和 Splunk) 即時擷取大量記錄，因此這些合作夥伴服務可以提供單一記錄窗格。
下圖顯示記錄和監控的合併架構。
這個架構具有下列優點：
- 您可以繼續使用熟悉的現有工具。
- Google Cloud 支援團隊仍可存取記錄檔，以利排解問題。
這種架構有下列缺點：
- 合作夥伴解決方案通常會託管在外部，因此如果網路連線中斷，可能無法使用或收集資料。有時，您可以透過自行代管來減輕這項風險，但代價是必須自行維護解決方案的基礎架構。
- 支援團隊無法直接存取外部代管的資訊主頁。Google Cloud 如果無法取得這些資訊，問題的疑難排解和解決速度就會變慢。
- 商業合作夥伴解決方案可能需要支付更多授權費用。
以下是幾個詳細的整合範例：
- Datadog： 監控 Compute Engine 指標 和 收集 Cloud Logging 記錄
- Elastic： 將 Logging 記錄檔匯出至 Elastic Cloud
- Splunk： 從 Logging 進行匯出作業的情境
使用 Grafana 分析 Prometheus 和 Logging 的指標
Grafana 是熱門的開放原始碼監控工具，通常會與 Prometheus 搭配使用，用於收集指標。在這個架構中，您會使用 Prometheus 做為地端收集層，並使用 Grafana 做為Google Cloud 和地端資源的單一玻璃窗。下圖顯示範例架構，可分析 Google Cloud 和地端環境的指標。
這個架構具有下列優點：
- 適用於同時有 VM 和容器的混合環境。
- 如果貴機構已使用 Prometheus 和 Grafana，使用者可以繼續使用。
這種架構有下列缺點：
- Prometheus 僅支援監控，因此必須另外設定記錄功能，例如使用 Fluentd 或 Grafana 適用的 Cloud Logging 外掛程式。
- Prometheus 是開放原始碼軟體，可供擴充，但僅支援有限的企業軟體整合。
- Prometheus 和 Grafana 是第三方工具，而非 Google 官方產品。Google 不提供 Prometheus 或 Grafana 的支援服務。
詳情請參閱「使用 Grafana 的 Cloud Logging 外掛程式，更有效率地排解問題」。
使用 Fluentd 匯出記錄
先前的模式涵蓋使用 Fluentd 或 Fluent Bit 做為 Cloud Logging 的記錄檔收集器。您也可以將相同的基本架構用於支援 Fluentd 或 Fluent Bit 的其他記錄或資料分析系統，包括 BigQuery、Elastic 和 Splunk。下圖說明瞭這個模式。
這個架構具有下列優點：
- 適用於同時有 VM 和容器的混合環境。
- Fluentd 可以從許多資料來源讀取資料，包括系統記錄。
- Fluentd 提供許多熱門第三方記錄和資料分析系統的輸出外掛程式。
- Fluent Bit 也能從許多輸入讀取資料，包括系統記錄。
- Fluent Bit 提供許多熱門第三方記錄和資料分析系統的輸出。
這種架構有下列缺點：
- Fluentd 和 Fluent Bit 僅支援記錄，因此必須另外設定監控功能。上一節討論了使用 Prometheus 和 Grafana 進行監控的常見選項。
- Fluentd 和 Fluent Bit 是第三方工具，而非 Google 官方產品。Google 不提供相關支援。
- 匯出的記錄檔無法提供給 Google Cloud 支援團隊用於疑難排解。具體來說，如果沒有啟用記錄功能，Google 不會為 Google Distributed Cloud 叢集提供支援。
將應用程式和作業資料分開
單一主控台架構需要監控串流應用程式，並將記錄資料傳送至雲端。不過，您可能需要遵守法規或法規遵循要求，將客戶資料保留在內部部署環境，或對可儲存在公有雲中的資料設下嚴格限制。
在這些混合式環境中，一個實用的模式是將敏感應用程式資料與低風險作業資料分開，如下圖所示。
透過混合式雲端和多雲端架構，將應用程式和系統資料分開
如要監控地端叢集，可以使用 Prometheus 和 Grafana 等開放原始碼工具。如要收集及傳送遙測資料，可以使用 OpenTelemetry Collector 或 observIQ BindPlane 等解決方案。您可以使用這些工具設定要擷取及完全在本機查看的機密應用程式資料，例如在自行代管的監控和記錄解決方案中。您可以將較不敏感的系統資料匯出至 Google Cloud的監控和記錄服務。下圖說明這個架構。
這個架構具有下列優點：
- 機密應用程式資料完全保留在內部部署環境。
- 地端監控和記錄功能不需依賴雲端，即使網路連線中斷，仍可繼續使用。
- 所有 GKE 系統資料 (包括地端和Google Cloud) 都集中在 Monitoring 和 Logging 中，且支援團隊也能視需要存取 Google Cloud 。
後續步驟
- 如要進一步瞭解混合式雲端和多雲端的最佳做法，請參閱「混合式雲端和多雲端模式及做法」系列文章，包括架構模式和安全網路架構模式。
- 參加「Cloud Kubernetes Best Practice quest」，透過實作練習瞭解 GKE 的可觀測性等功能。
- 探索 Google Cloud 的參考架構、圖表和最佳做法。 歡迎瀏覽我們的雲端架構中心。