定義與使用多雲環境的監控與管理工具
本文是關於監控我們的多雲環境。 我們如何追踪雲端資源的健康狀況？ 我們將使用不同 CSP(Cloud Service Provider — AWS、Azure、GCP) 的原生監控工具，但我們還將探索一些提供單一控制儀表板的工具 ，我們可以在其中統一查看整個多雲環境。
在本文中，我們將首先定義監控和管理流程，然後再了解 AWS、Azure 和 GCP 的不同工具。 我們還將了解可以使用哪些工具來管理我們的雲端環境，並將更深入地裡解我們應該在 OSI 模型的七層中監控什麼，以及如何考慮監控資料以使其與業務面相關。 最後，我們將簡要介紹兩個提供單一控制儀表板的平台：ServerNow 和 BMC Helix。
本文中我們會探討以下的議題：
- 定義監控與管理流程
- 探討主要CSP的原生監控與管理工具
- 理解如何合併與解釋監控資料
- 理解單一控制儀表板的概念
定義監控與管理流程
本書的這一部分都是關於 BaseOps 的，我們將研究主要 CSP 和超大規模 (AWS、Azure 和 GCP) 提供的 CAF(Cloud Adoption Framework)。 這些框架有很多共同的基本原則。 我們可以在框架中識別出五個領域：
- Governance(治理)
- Cost Management(成本管理)
- Security(安全性)
- Automation(自動化)
- Monitoring(監控)
在這面一系列的文章中中，我們介紹了治理、服務設計、政策、在不同雲端中實現著區域、韌性和效能。最後，我們了解瞭如何自動化環境的部署和管理。我們現在要討論關於 BaseOps 的最後一件事，那就是監控。
監控在 IT 系統的專業管理中至關重要。監控我們環境中的所有內容是沒有意義的，但許多公司仍然這樣做：他們只是開啟監控，然後等到告警出現。但是在大型企業的多雲環境中的，大量的告警會使我們需要注意最重要的告警和關鍵事件變得困難(太多狼來了)。就像我們已經討論過的所有事情一樣，我們需要一個計劃。該計劃需要來自業務需求：他們設置了一個stage。這些要求定義了我們必須如何在雲端中管理我們的系統以及我們應該監控什麼。
分層思考是有幫助的，就像我們在定義多雲環境下的自動化工具與流程文章中討論自動化時所做的那樣。如果我們談論的是end to end監控，那麼這就是從終端使用者的角度進行監控：這種類型的監控檢查所有層次。 業務層次就是頂層，終端使用者在此啟動和進行業務處理流程。 這可以是任何處理流程，但通常它是frontend system的交易(transaction)，例如網頁。 該交易必須由嵌入在應用程式中的函數處理。 這是第二層：應用程式和應用程式與資料庫和其他系統的介面，用來通訊交易內容。
應用程式、資料庫與介面使用的是基礎設施層(VM/network/storage/container platform)。但是PaaS也參與了這一層。 基礎設施由不同的組件組成，這是我們在定義多雲環境下的自動化工具與流程中學到的。 最後一層是組件或資源層。 下圖顯示了階層的概念模型。
對於每一層次，我們可以有單獨的監控工具。 但是，我們希望有終端使用者的視角。 資源可能已啟動並運行並運作良好，但如果應用層出現問題，終端使用者將面臨系統故障 — — 即使對資源的監控告訴我們一切正常。 這是 IT 界的一個常見笑話：全是亮綠燈，但都不會動。 因此，我們需要事件監控或前面提到的end-to-end監控：可以在不同層次之間關聯並為我們提供full-stack view的監控系統。
我們要在stack中監控的主要議題如下:
雲端服務是不是還活著
有時這被稱為hearbeat monitoring，基本上就是這樣。 我們想知道我們託管環境的雲端平台是否仍然存在並且良好。 例如，系統和服務是否仍在正常運行？ 主要的CSP都有這一類的儀表板，可以為我們提供有關其平台狀態。 以下是三大CSP提供的服務監控：
https://health.aws.amazon.com/health/status
現在，如果我們通過儀表板檢查例如 Azure 的健康狀態，我們會發現某些region的服務沒有回報。 原因很簡單：Azure 並非在每個region都提供所有服務。 以下截圖顯示，Azure 的中東和非洲資料中心不提供 CloudSimple 和大型in-memory ERP 系統 的SAP HANA 的大型instance：
AWS則描述了一些特定的資料中心有運作哪些服務：
上圖顯示了 AWS 歐洲區域的 Amazon Managed Streaming for Apache Kafka服務範例，運行在法蘭克福、愛爾蘭、倫敦和巴黎的資料中心。
雲端服務的效能
效能與健康度有關，更多的是與系統的回應能力有關。 系統的回應能力決定了它的效能水準。 系統慢在哪裡？ 為了能夠回答這個問題，我們必須定義什麼是可接受的效能。 回到業務需求是什麼。 假設預期是，如果有人在網站上買了一個商品，交易必須在幾秒鐘內完成。 但是，交易請求對在一個龐大系統內的複雜計算可能需要一些時間。 而處理的準確性也很重要，但實際處理時間會有很大差異。 這兩個指標 — — “處理結果的品質和處理時間” — — 對於定義雲端效能很重要，並決定了我們應該如何監控這些指標。
治理
作為實現 CAF(Cloud Adoption Framework) 的一部分，我們為 RBAC(Role-Based access control) 設計了一個模型。 RBAC 定義了誰被授權在特定條件下執行某些操作：誰被允許做什麼、何時以及如何做。 它與安全性密切相關，但治理的作用遠不止於此。 它還監控雲端環境中 API 的使用情況，並檢查觸發了哪些processes來存取系統。 例如，如果管理員（或呼叫系統帳號的系統 API）建立了一個新帳號，則在該帳號被確認之前，監控將遵循授權的路徑。
安全
安全監控或多或少是不言自明的 這是關於檢查我們環境中的漏洞並在發現漏洞時獲得告警。 安全監控就是預防(prevention)和防禦(defense)：防止病毒入侵、惡意訪問。 或試圖淹沒系統以使它們最終崩潰的流量模式，例如在 DDoS 攻擊中。 如果某人或某物設法通過我們設置的防線，則應立即觸發緩解措施以控制損害，例如自動進行流量清洗。
雲端使用量(分析)
我們想知道在資源、虛擬機、網路、存儲和服務方面我們在雲端中使用了什麼。例如，我們可以監控我們在虛擬機中使用的 CPU 的使用率。如果我們長時間測量使用率，我們可以分析這些資料，看看我們是否需要調整機器的大小。如果 CPU 未得到充分利用，我們可能需要縮減規模並節省成本。或者，如果我們從效能監控中發現系統回應緩慢，我們應該分析 CPU 是否被過度使用。在這種情況下，我們應該考慮scaling out or up我們的系統。這些分析還將報告我們在近期和更遠的將來所需容量方面的預期趨勢。
既然我們已經定義了我們可以在雲端環境中甚至監控的內容，那麼是時候看一下 CSP 必須提供的工具了。問題是，我們如何整合來自監控系統的所有 廖並為我們提供單一的控制儀表板？
探討主要CSP的原生監控與管理工具
在本節中，我們將首先研究 AWS、Azure 和 GCP 提供的原生監控。 之後，我們將簡要介紹一些市場上流行的、跨雲端的end-to-end監控系統。
在深入研究這些工具之前，我們應該對監控的工作原理有一個High-level的理解。 通常，這些工具與收集資源運行狀況和效能資料會共用同一個agents。 這通常是將原始資料轉譯成更易於理解的格式，以便對其進行分析。 從那裡，它被可視化，例如，在儀表板中的圖形呈現，可以在控制台中查看。
監控也會有告警觸發：系統可能會出現故障或其他問題。 在這種情況下，監控服務將發出告警回應的警報。 該回應可以是在系統耗盡資源（例如處理器能力或記憶體容量）時啟動擴展過程，也可以是啟動故障轉移機制的自動化過程。
下圖顯示了基本監控功能的High-level overview：
以上這些是監控的基本原理。 在接下來的部分中，我們將討論 AWS、Azure 和 GCP 中的監控服務。
Azure Monitor and Lighthouse
Azure Monitor 可從 Azur入口網站找到。 Azure Monitor的關鍵組件是指標(metric)和日誌(logs)，這是 Azure Monitor中存儲的兩種資料類型。這是 Azure Monitor是收集我們在 Azure 中使用的資源和服務檢索的所有資料的地方。指標包含有關資源狀態的即時資料，日誌是可用於追踪事件的資料集合。為了分析日誌，我們可以使用 Log Analytics來更深入地了解資源和服務的效能。 Log Analytics是 Azure 中的一個單獨模組，用於分析監控的指標。
Azure Monitor 收集了大量資料，可以立即從 Azure 入口網站的儀表板中查看這些資料。 Azure Monitor可以監控已部署在 Azure 內和 Azure 外的資源，包括其他雲端平台和地端機房。
其次，還有可以擴大Azure Monitor監控範圍的附加服務。兩個重要的服務是 Application insight和 Azure Monitor for container。 Application insight是 Azure 中的一項單獨服務，用於監控 Azure 中託管的應用程式，但它也可用於地端機房的應用程式。它記錄應用程式的操作並回報應用程式代碼和連接服務中的問題。
我們正在從更傳統的虛擬機環境轉移到容器，當然 Azure Monitor已經為此做好了準備。 此服務收集有關 Kubernetes 資源（例如 nodes、controllers 和 container本身）的處理器和記憶體使用情況的指標。 Azure Monitor將容器用於 AKS。 但是，請注意，它僅監視用於容器的基礎設施。 它不監視容器的內部； 為此，我們將需要不同的工具。
在 Azure 中的雲端環境管理方面，有一個值得討論的產品。 2019 年，微軟推出了 Azure Lighthouse。 許多企業面臨的挑戰是，他們在公有雲中並沒有個單一個租戶。 通常，企業將擁有多個租戶和訂閱，就像他們擁有多個部門、業務群一樣。 他們隨後面臨的問題是監控和管理所有這些不同的租戶和訂閱。 為此，Lighthouse 是解決方案。
Lighthouse 提供跨多個租戶和訂閱的集中管理和監控。 它基本上是企業在 Azure 中運行的所有環境的單一管理平台。
AWS CloudWatch and Control Tower
AWS CloudWatch的關鍵組件可與 Azure Monitor相比。 AWS CloudWatch 使用指標和統計數據，儘管其核心是指標存儲庫。 來自資源的資料以指標(metric)形式收集並轉換為控制台上顯示的圖形。 CloudWatch 可以從 AWS 提供的幾乎所有類型的資源中收集了大量指標。 顯然，AWS 中有運算、存儲和網路方面的指標，還有 AWS 中 Kinesis 和 IoT 環境中的資料和stream等服務，以及 SageMaker 中的數據分析。
CloudWatch 與 AWS 中的許多其他服務整合，其中 SNS(Simple Notification Service) 和 EC2 的自動擴展是最重要的。 SNS 基本上是 AWS 中的pub/sub messaging 機制。 它可以觸發自動擴展過程以增加資源的容量。
與 Azure 一樣，AWS 將在我們在平台上建立第一個帳號後立即開始收集指標。 很多 AWS 服務會自動呼叫 CloudWatch API 來開始監控。 這適用於 EC2 中的運算、EBS 的存儲和 RDS 中的DB instance。 但是，我們仍然需要根據我們希望如何呈現指標、以什麼頻率以及我們認為有價值的告警類型來配置監控。 在 AWS CloudWatch 中，我們可以為特定Item建立告警。
另外在 AWS 中有一個end-to-end監控的解決方案：CloudWatch Synthetics。 在 Synthetic 中，我們建立金絲雀。 這些腳本模擬終端使用者在 AWS 中執行的過程。
在管理方面，AWS 提供 Control Tower。 它是企業在 AWS 中註冊的所有帳號的集中管理控制台，可確保所有這些帳號都與企業必須遵守的框架保持一致並符合要求。 我們在設計，實現與管理多雲的著陸區中討論的著陸區是 Control Tower的一部分。 它包含所有組織單位、用戶、帳戶和所有受企業內合規性和安全法規約束並在 AWS 環境中強制執行的資源。
為了追踪 AWS 中的所有這些ietm，這個平台提供了一種圍欄。 我們可以設置預防性和檢測性圍欄。 這些規則可確保組織內的各單位、帳號、用戶和資源始終與為環境設置的政策保持一致。 這些規則可以有不同的標籤：強制性的、推薦性的的和可選的． Control Tower有一個儀表板，以便負責系統整體管理的團隊有一個單一的控制儀表板，涵蓋在AWS所有已部署的環境。
GCP 的Cloud Monitor與Operations Suite
GCP 中的 Cloud Monitor非常簡單。 我們不需要安裝或配置任何東西：只要我們開始在 GCP 中使用系統或服務，Cloud Monitor就會開始收集指標。 這是通過 Cloud Run完成的，這是 GCP 完全託管的服務。
GCP 中的 Cloud Monitor還有一項服務可以提供，那就是 GKE 上的 Cloud Run。 GCP 提供單獨的服務來監控我們託管容器的 Kubetnetes cluster。 該服務實際上被命名為 Cloud Monitorfor Anthos，因為它針對的是 GCP的 Anthos stack。
Anthos — — 在 VMware vSphere 或 Hyper-V insatnce上運行的 GCP 服務套件 — — 有助於將VM上的舊應用程序轉換為容器(不過有其限制)，以便它們可以在 Kubernetes 上運行。 Anthos 是一個混合多雲環境，因為我們也可以從其他雲端（例如 AWS）管理 Anthos 上的容器。
我們不需要配置監控，但我們可以加上自定義的指標。 該服務使用開源監控 OpenCensus。 在這裡，我們可以加上我們想要從 GCP 中監控資源中檢索的特定指標資料。 如果我們想為容器監控這樣做，我們必須對 Knative metric 做同樣的事情。 Knative 是一個基於 Kubernetes 的平台，用於部署和管理現代serverless工作負載。
所以GCP的Cloud Monitor是一個完全整合的服務，我們不需要配置。 但是，如果我們添加帶有正常運作時間檢查和告警的指標，我們可以從中獲得更多效益。
GCP的整體監控服務稱為Operation suite，以前稱為 StackDriver。 Operation suite還包含 Cloud Logging、Error Reporting以及 Cloud Debugger和 Cloud Trace等自動化服務。
VMware Tanzu
越來越多企業將他們的服務轉向容器，而這是我們在管理方面尚未深入討論的問題。我們如何管理跨雲端和多雲容器？這裡應該提到的一個產品是 Vmware 的 Tanzu，尤其是 Tanzu Mission Control。
我們已經看到，所有主要的 CSP 都有自己的 Container Orchestration。它們都使用 Kubernetes 來啟動和控制cluster nodes來託管容器，但它們都有自己的風格：Azure 有 AKS，AWS 有 KES，GCP 有GKE ，以及在 Vmware 平台上，我們可以使用 PKS(Pivotal Kubernetes Service)。但容器的主要優勢在於它們不依賴於底層的OS，它們可以真正獨立於雲端。但是我們如何控制 跨雲端的Kubernetes 環境呢？
Vmware 使用 Tanzu 監控和操作所有上述CSP上的不同 Kubernetes 環境，更具體地說，是 2019 年推出的 Tanzu Mission Control。我們可以將 Kubernetes 環境掛載到任何雲端中 (WS、Azure 或 GCP 等等)。 在Tanzu，從那裡我們可以集中管理身份、集中訪問cluster、集中政策管理，以便我們所有的cluster都以相同的方式運行，以及一個監控我們所有cluster的監控系統。
其他end-to-end 監控工具
我們已經介紹了 end-to-end監控。 end-to-end監控的意思是從最終用戶的角度來看系統。 要理解這一點，我們必須了解 OSI 模型。 該模型包含七層。 下圖呈現此模型：
現在讓我們更詳細地解釋這些層面中發生的事情，以便更好地理解每一層代表什麼。 請注意：這些是技術層，而不是我們在本文第一節中討論的層。 在那裡，我們在high-level的層面上討論了三個層次：業務、應用程式和技術。 這與我們在企業的雲端架構管理中探討的 TOGAF 相對應； OSI 模型實際上是關於技術堆疊的：
- L1 : 這是實體層，或稱硬體層．這一層全都是有關硬體裝置的
- L2 :這層是data link，將資料轉換為可以通過網路傳輸的格式
- L3 :這一層是網路層，這是定義網路路由的地方
- L4 :這是transport layer．這涉及如何根據指定的網路協議實際發送或傳輸資料
- L5 :這是session layer.
- L6 :到目前為止，我們一直在談論原始資料(raw data)。 我們需要把它變成一種易於理解的格式。 例如，可以將圖片的原始資料轉換為 JPEG 格式，以便我們查看圖片本身而不僅僅是資料。 這就是在這一層發生的事情。
- L7 : 這是application layer. 這是終端用戶與底層系統交互的層面。 L7 通常被稱為human interface layer。
End-toend監控有什麼作用？ 它會有一個從 L7 一直到 L1的agent ，在它看過的所有層面中取得metric。 通常，監控機制會通過堆疊從 L7 發出一個transaction，並衡量這個transaction的效能。 如果transaction失敗，監控機制可以確定失敗的位置和原因。 如果我們比監控機制更進一步，那麼我們可以想像監控機制將觸發流程以減輕故障的衝擊：這就是自動化的用武之地。最終，我們擁有能夠預測和預防故障的系統，因為它們實際上 從他們從監控agent那裡收到的資訊。 這一個是 AIOps，我們將在後面的文章中討論 AIOps。
當我們關注end-to-end監控時，有多種產品可供選擇。這需要另一本書才能講完，但範例產品包括 Lakeside、Splunk、Datadog 和 CheckMK。所有這些套件都有針對雲端環境的產品，都是從終端用戶的角度來看的。例如，Lakeside 為此提供了 SysTrack Cloud Edition； CheckMk 是一種流行的用於基礎設施和應用程式的開源監控。
Splunk 和 Datadog 有點不同，它們比較偏 AIOps 。 Splunk Cloud 聲稱是真正實現智慧運營的監控環境。 Splunk Cloud 是跨雲端的，也跨業務案例。使用案例是反欺詐的，我們必須結合來自不同來源的資料來檢測欺詐。監控工具 Splunk 將收集雲環境中可能有詐欺操作的資料。 Splunk 使用的搜索引擎 Search Processing Language具有強大的功能。我們可以要求監控系統將來自不同系統的資料關聯起來，以深入了解整串的應用程式交付鏈及其效能。
理解如何合併與解釋監控資料
企業唯一需要關心的是 IT 的事件如何影響企業的運營。為了能夠辨別這一點，我們需要整合和解釋監測資料。
最大的問題是：監控資料何時會與業務相關？向業務負責人通知 VM 中 CPU 的效能是沒有意義的，但是當系統容量不足並阻礙處理業務交易的速度時，通知他確實有意義。在這種情況下，業務可能會因為交易處理速度太慢而蒙受損失，或者更糟的是由於超時失敗而交易失敗。
資料何時與業務相關？簡單來說，資料應該支持業務決策。部署額外的虛擬機或橫向擴展環境不是業務決策。這些是技術決定。業務決策是像將在特定時刻推出新產品。在這種情況下，我們應該知道我們的環境是否為此做好了準備。從監控資料中，我們應該分析我們的系統在現有產品組合中的表現。系統是否有足夠的容量來吸納額外的流量？這樣的問題和它們驅動著我們的架構：如果我們從監控資料中發現系統從技術角度來看還沒有準備好或者預計無法吸納額外的負載，那麼我們可能不得不重新架構系統。
監控的主要陷阱之一是許多公司將其視為被動的。在這種情況下，監控只是一種在系統出現故障時開始發出告警的工具。但到那時，我們已經知道得太晚了。業務可能已經受到大規模影響。
因為終端使用者開始看到他們的請求以較慢的方式處理，我們的監控系統應該提醒系統組件達到某些容量閾值(thresholds)或遇到故障的介面。我們可以通過收集大量資料來做到這一點，以便我們了解系統在正常條件下的回應方式，即基線(baseline)。任何與這些條件的偏差都會導致告警。這些告警可以是主動的，因此我們可以在某些事情真正中斷之前進行調整。
總結一下：企業業務只對 L7 發生的事情感興趣，這是使用者和系統之間實際交互的層次。終端使用者存取系統的速度有多快，交易處理的速度有多快，新產品的推出速度有多快？為了回答這些問題，我們必須從我們的系統中收集大量資料，以便我們知道關鍵閾值是什麼，以便我們能夠預測對業務的需求。
監控資料必須易於業務決策者理解；例如，假設我們當前的系統每天可以額外容納 5,000 名訪客訪問公司的交易網站。這種聲明的理由應該來自監測資料。
監控對於在開發和維運或 DevOps 中做出正確決策非常重要。但在財務報告方面，監控顯然也非常重要。這是 FinOps 的一部分。
理解單一控制儀表板的概念
在本文中，我們多次提到單一控制儀表板視圖。我們可以從中監控和管理來自多個平台的環境。想像一下，我們在 AWS、Azure、與 GCP 中有雲端環境。我們甚至可能在地端機房有系統。如果我們希望我們的系統管理員管理這些環境，他們很有可能需要登錄到每個平台。對於 Azure，他們需要登入 Azure 入口網站，對於 AWS，他們也需要登入 AWS 入口網站，但那不是很有效。
解決方案是擁有一個單一的控制台，這個單一控制台獨立於我們的雲端環境，甚至更好地從這個單一控制台管理所有雲端環境。想像它就像一把瑞士刀：一種我們可以用於不同目的的工具。刀、螺絲刀、剪刀 — — 但它仍然只是一種工具。
聽起來很炫炮，但實際情況是，這些工具的開發極其複雜，並且要與各種雲端平台上不斷發布的所有新功能保持同步。提供單一平台的這一工具必須與所有雲端平台整合。實現這一點的 API 必須不斷地重新評估。這就是為什麼市場上只有少數工具可以真正做到這一點的原因。市場上的這類解決方案的領導者像是ServiceNow 和 BMC Helix。當然，也有其他產品，如ManageEgine。
ServiceNow和 MBC Helix 都提供了一個平台來執行 IT 服務管理、多雲操作、多雲環境中安全性和合規性的多雲成本管理，並在一個套件中監控所有內容。它們與主要雲平台的原生工具整合。例如，他們的 API 連接到 Azure Monitor、CloudWatch 和 GCP 的 Cloud Monitoring，以從雲端平台取得資料並將這些資料整合到整成到 ServiceNow 的管理平台中。
這些套件具有大量模組組合，企業可以使用這些模組從一個控制台運行許多服務。但是有一個陷阱：這些平台將處理所有基本服務，但總會有一些服務無法從這個整合控制台查看和管理，例如，serverless功能。這些多雲平台永遠不會為每個雲端平台控制每一個功能，這絕對不是一個缺點。這只是我們必須考慮的事情。
總結
在本文中，我們通過在不同層次上定義監控過程以及決定我們應該在我們的環境中監控什麼來理解如何建立良好的監控。 我們已經了解到，最好有end-to-end的監控，以終端用戶體驗這些系統行為的方式來看待系統。
我們看到了 OSI 模型，並且對監控如何從各個層次取得資料有了更深入的了解。 我們已經了解到，我們需要整合和解釋受監控的資料，以使其對企業是有價值，使其能夠用於制定業務決策。 我們現在也應該對單一控制儀表板視圖的概念有所了解。
我們現在能夠決定如何監控系統。 我們還要區分監控系統和監控方法。 最後，我們了解了 CSP 提供的各種原生工具以及我們如何使用它們。
