多雲監控平台怎麼選：資源、權限與帳單怎樣連起來

多雲監控平台選型，我會先看一次調查需要跨過多少邊界，再看產品支援多少朵雲。AWS 的資源告警、Azure 上的應用程式鏈路和 Google Cloud 的日誌都能開啟，工程師仍可能要手動找帳號、換時間範圍，再確認幾個不同名稱是否指向同一個服務。平台真正能省下的，是這些每天重複發生的工作。

既有雲端監控運作穩定，各業務也相對獨立，保留原生工具通常很合理。跨雲呼叫已經進入日常排障，或多個團隊正在重複維護採集、權限和告警，再考慮統一後端或查詢入口會更有價值。觀測雲適合希望把相關訊號和調查流程放到同一產品體系、減少後端維運工作的團隊；工作空間與站點邊界，也要放進架構一起設計。

觀測雲編輯部 · 2026 年 10 月 28 日。本文根據官方文件討論多雲監控工具的機制與維運責任，觀測雲也是文中方案之一；未執行相同負載壓測或客戶成本測試。

先讓同一資源和服務有穩定的身分

一台主機在雲端帳單裡屬於某個帳號和區域，在容器平台裡承載幾個服務，在鏈路裡又可能只留下應用程式名稱。直接把三個來源放進同一張圖，並不會自動建立它們之間的關係。

比較可靠的起點，是保留雲端供應商的原生資源識別碼，再補齊團隊約定的服務、環境和負責人。下面是正規化約定的例子，不是某個平台會自動填好的欄位：

OpenTelemetry 的資源語義約定定義了供應商、帳號、區域和原生資源 ID 等屬性。採集到這些屬性之後，仍需對應到後端使用的欄位。業務日誌裡的 service、OTel 的 service.name 與雲端資源標籤，可以指向同一服務，但不能靠字串看起來相近就合併。

時間與採樣也同樣重要。兩邊的時間範圍不同，或失敗請求的 Span 沒有保留下來，關聯結果就會缺一段。統一介面的價值，應體現在這些欄位和記錄對齊後，工程師能少做多少次重複篩選。

雲端原生監控可以繼續用，查詢範圍要分清

AWS、Azure 和 Google Cloud 都有跨資源或跨專案能力。把它們概括為「各管一朵雲、無法關聯」，會過早排除既有投入。

CloudWatch 的跨帳號可觀測性在同一區域內連接監控帳號與來源帳號，可以分享設定的指標、日誌和鏈路等資料。跨區域日誌集中化則是另一條路徑：按照規則複製新到達的日誌，規則建立之前的歷史日誌不會自動回填。跨帳號查詢與跨區複製，會形成不同的資料流和費用。CloudWatch 日誌集中化

Azure Monitor 也能接收執行在 AWS、GCP 和其他位置的工作負載遙測。虛擬機器的客體資料可使用 Azure Arc 與 Azure Monitor Agent，應用程式可使用對應的 Application Insights 接入方式；稽核日誌等情境還涉及相應連接器和產品。選擇這條路線，仍要安裝、授權並維護相應採集路徑，不能由「支援多雲」推導所有資料已經可查。Azure 多雲監控

Google Cloud Monitoring 的 metrics scope 決定一個專案能繪圖和監控哪些專案的時序資料。日誌查詢範圍由 Cloud Logging 的 log scope 等設定管理，不能把指標範圍當成日誌權限或日誌已集中儲存的證明。指標範圍 · 日誌範圍

因此，原生工具是否足夠，取決於業務調查是否能在這些邊界內完成。區域業務各自獨立、團隊熟悉既有主控台時，繼續使用通常能保留雲端服務的脈絡。經常跨雲追查同一次呼叫，才更需要減少入口、欄位和權限之間的串接工作。

統一介面之後，資料和查詢放在哪裡

控制平面負責設定、身分與操作入口，資料平面負責接收、儲存和執行查詢。兩者可以分開安排。多個區域使用同一產品，不等於所有資料都集中在一處；一個頁面顯示幾個區域，也不等於能對它們做一次明細關聯查詢。

聯邦或聯合查詢適合部分需求，卻沒有讓後兩項工作消失。來源區域無法連線時，結果是報錯、逾時，還是回傳明確標示的部分資料，會直接影響值班人員的判斷。圖表裡的空白不能被悄悄解讀為沒有錯誤。

觀測雲的跨工作空間授權允許接收方查詢授權範圍內的資料。跨站點授權需要產生、匯入授權套件；一次聯合查詢面向同一目標站點內的工作空間。需要多個站點的彙總時，應按站點分別請求，再由用戶端合併。這個用戶端在哪裡執行、彙整哪些欄位，也屬於資料流設計的一部分。DQL 查詢 API

其他產品也有自己的邊界。Datadog 的站點彼此獨立，官方說明站點之間不能分享資料；Grafana Cloud 可以連接支援的外部資料來源，但網路連線、資料來源憑證與查詢能力仍隨具體後端而定。把幾張圖放到同一儀表板，不會自動將它們變成一套可跨站點關聯的記錄。Datadog Sites · Grafana 外部資料來源

儲存位置、備份、匯出、遠端存取和查詢結果，都需要進入組織的資料處理安排。區域站點有助於選擇存放地點，具體要求仍取決於實際資料、存取方式和契約，不能僅憑一個地區名稱得出合規結論。

關聯排障能減少什麼工作

假設一個服務從 AWS 呼叫 Azure 上的下游。服務名稱可以協助找到負責人，trace ID 才能繼續區分這一條請求；對應主機的資源識別資訊，又將調查帶到當時的 CPU、容器和網路狀態。這些關聯各有依據，不能全部交給一個「多雲標籤」。

觀測雲的鏈路詳情可以按 trace_id 關聯日誌，並結合相應資訊查看主機、容器和 Pod 等資料。相關訊號必須已接入，服務屬性、索引對應、時間和權限也要匹配。日誌保留得更久，並不能找回已經過期的鏈路。鏈路詳情與關聯分析

對希望減少平台維護的團隊，這類託管入口的收益很具體：採集與業務規則設定好以後，日誌、鏈路和資源調查不必先依賴另一個後端建設專案。團隊仍要維護服務命名、上下文傳播和告警責任；託管服務接手的是後端維運，以及既有分析功能的交付。

既有平台團隊也可以繼續自建。Prometheus federation 採集選定的時序資料，Thanos Query 讀取支援的 StoreAPI 資料來源；它們處理的是指標，日誌和鏈路仍要安排相應後端。高可用副本的重複序列、區域逾時和部分回應，也需要按實際查詢設定處理。Prometheus federation · Thanos Query

如果這套服務已經穩定，遷移收益應與真正能減少的元件和維護時間比較。把同一套採集換個目的位址，卻繼續保留全部舊系統，短期內反而會多出雙寫和歷史查詢的成本。

雲端帳單與觀測平台帳單要分別解釋

多雲監控的成本有兩層：業務資源本身花了多少錢，以及為了觀測這些資源又付了多少錢。兩份帳單可以用帳號、資源和費用期間聯繫起來，但更新時間和計量單位並不相同。

例如觀測雲的 AWS Billing 整合要求設定相應 Cost Explorer 權限，並在採集器的 extra_tags 中設定 account_name 與 account_id；資源層級資料還需要在 AWS 開啟對應設定。這項整合採集 T-1（前一天）帳單資料，適合回看費用變化與資源使用，不應當成目前執行中資源的即時價格資訊。

標籤對應也要有人維護。資源重建、帳號遷移或成本中心變更之後，舊帳單中的歸屬未必會跟著改。用現有標籤替歷史成本重新分組時，應保留原計費期間和原始識別碼，才能解釋分攤口徑為什麼改變。

觀測平台則按實際訊號和服務計量。主機、活躍指標序列、攝入位元組、索引事件、保留期間、查詢、RUM 工作階段和額外運算不能互換。「200 台主機、每天 200 GB 日誌」只提供部分輸入，還不足以推導完整 SaaS 月費。

總投入
= 各區域平台費用之和
+ 客戶端採集、儲存與網路費用
+ 共用查詢和身分整合的維護投入
+ 遷移期間雙寫與歷史資料存取費用

平台已經包含的服務無須重複加價，仍由客戶執行的部分則不能遺漏。一般月份與尖峰月份分開計算，按相同調查範圍和保留結果比較。工程時間與現金支出分列，才看得清託管費用是否換回足夠的維護投入。

從最費力的調查路徑開始收斂

我會保留運作良好的雲端原生監控，先收斂經常跨雲的服務識別、告警入口和證據連結。這樣可以較早減少重複篩選，也不會為了統一品牌而搬走所有歷史資料。

若大部分工作仍發生在各自區域與雲內，原生工具加上少量有明確負責人的整合通常就夠了。跨雲調查已成為日常，而團隊沒有餘力維護查詢、儲存和關聯後端時，觀測雲這類託管平台更值得投入。它的價值應表現在調查路徑更短、需要自行交付的後端更少。

需要自行掌握底層資源、已有能力長期維護整套服務的團隊，可以繼續發展自建架構。無論採用哪條路線，先保留共通的資源身分和資料意義；遷移某個服務或訊號時，再一起移動對應權限、查詢和告警。一個容易理解、能持續維護的多雲架構，比一個看起來包辦所有雲的大盤更有用。