已啟用 Azure Arc 的 Kubernetes 服務可觀察性
可檢視性 是一種應用程式特性，是指系統內部狀態或狀態如何從其外部輸出中瞭解。 我們會藉由觀察 CPU 時間、記憶體、磁碟空間、延遲、錯誤和其他計量來測量電腦系統。 系統更容易觀察，我們更容易瞭解它正在做什麼。
系統的可觀察性對其營運成本有顯著的影響。 可觀察的系統會為其操作員產生有意義的可操作數據，讓他們能夠取得有利的結果，且停機時間較少。 詳細資訊不一定會轉譯成更容易觀察的系統。 事實上，有時候系統所產生的資訊量可能會使得從應用程式所產生的雜訊中識別有價值的健康訊號會更加困難。
服務可觀察性很重要，因為它可協助您根據動態架構了解分散式和雲端系統中的效能和問題。
實作達成服務可檢視性的解決方案可協助您：
- 請確定終端使用者可以使用您的應用程式，並符合您的商務期望。
- 瞭解整個系統，以及如何使用單一玻璃窗格一起運作。
- 為您的系統建立基準，並瞭解不同情況如何影響系統的效能。
- 從非預期的案例和行為產生動作專案。
已啟用 Azure Arc 的 Kubernetes 提供兩個整合式擴充功能選項，可協助您達成服務可檢視性：開放式服務網格和自我裝載 API 管理 閘道。 這些選項會在下列設計考慮小節中詳細討論。
架構
下圖說明服務可檢視性與數據量影響的三大要素。
下圖顯示在已啟用Arc的 Kubernetes 叢集中執行的各種Open Service Mesh 元件。 它也會顯示服務網格中啟用的範例應用程式，其會自動設定 Envoy 側車容器。
設計考量
可觀察性的三個要素是計量、記錄和追蹤。 將它們納入您的可觀察性策略，以協助讓您的系統可觀察。
- 計量是數值，可描述系統在特定時間點的某些層面，而且一律會定期收集它們。
下列螢幕快照顯示服務的 HTTP 要求計量範例視覺效果。 此範例中的計量會顯示為指定時段內每分鐘 HTTP 要求率。
記錄 可以儲存具有其本身結構的各種數據類型。 記錄包含交易的詳細數據，可讓您取得指定事件更完整的故事。 應用程式記錄通常包含時間戳、記錄層級，以及瞭解事件內容所需的任何資訊。 記錄會收集並運送至記錄服務以進行記憶體和分析。
分散式追蹤 是一種診斷技術，可協助使用者將應用程式內的失敗和效能問題當地語系化，特別是分散於多部計算機或進程的任何專案。 這項技術會透過應用程式追蹤要求、將不同應用程式元件完成的工作相互關聯，以及將應用程式可能針對並行要求執行的其他工作分開。
下列螢幕快照顯示使用ApplicationInsights的端對端交易視覺效果。 此視覺效果可讓您輕鬆瞭解回應時間、回應時間，以及交易鏈結中要求之間發生的任何例外狀況。
計量、記錄和分散式追蹤的三個要素相互關聯。 計量會儲存為時間序列資料庫中的數值。 它們也比記錄小得多，這可讓記錄更容易評估和用於近乎即時的警示。 記錄會擷取並傳達比計量更多的資訊，讓它們更深入的偵錯很有用。 追蹤是要求範圍，而且有助於在存取分散式系統的各種元件時查看要求。
下表顯示三個要素的集合影響。
| 集合特性 | 計量 | 記錄 | 分散式追蹤 |
|---|---|---|---|
| 每個交易的帳戶 | Yes | Yes | 否 （取樣） |
| 免疫到基數問題 | No | .是 | Yes |
| 成本 | 低 | 高 | 低 |
有許多不同的方式可以達到服務可觀察性。 您可以使用服務網格在平台層執行此作業，其中您的應用程式不會察覺且未變更。 您也可以使用連結庫檢測應用程式，此連結庫通常是使用Application 效能監視器 ing （APM） 工具，例如 Application Insights。 API 閘道可為南北流量提供可檢視性，但 Pod 通訊缺乏可檢視性，且可大規模設定。
下列各節說明如何使用服務網格和可供 Azure Arc 使用的自我裝載 API 閘道，以達到服務可檢視性。
服務網格
服務網狀架構提供流量管理、復原、原則強制執行、傳輸安全性、身分識別安全性，以及工作負載可檢視性等功能。 您的應用程式與這些作業功能分離;服務網格會將它們移出應用層，並向下移至基礎結構層。 這是透過高效能 Proxy 來完成，以調解您服務的所有輸入和輸出流量。
- 已啟用 Azure Arc 的 Kubernetes 支援 開放服務 Mesh （OSM），這是雲端原生運算基礎 （NCF） 專案，該專案會部署為 延伸模組。 Open Service Mesh 是輕量型、可延伸的雲端原生服務網格，可讓用戶針對高度動態微服務環境統一管理、保護及取得現成的可觀察性功能。
- 其他需要廠商支援的熱門服務網格包括 Istio、Consul 連線 和 Linkerd。
- 根據實作服務網格時所使用的功能，應用程式操作員可能會承擔額外的責任，為每個服務定義組態（例如存取規則和上線服務）。 此外，叢集操作員必須管理和注意服務網格控制器。 由於服務網格使用 側車模式的方式，在偵錯輸出和輸入時，需要從服務網格控制平面和側車存取記錄。
服務網格可觀察性
可檢視性是服務網格所提供的許多功能中的重要功能。 選擇符合您最低可觀察性需求的 Service Mesh，因此您可以減少服務網格隨附的複雜度和元件數量，而且需要設定。 評估服務網格提供的下列常見功能和可觀察性使用案例：
- 計量產生，包括四個黃金訊號：延遲、流量、錯誤和飽和度。
- RED 方法（Rates-call/sec、Errors、Duration-call 延遲），這是四個黃金訊號的子集，可用來測量服務。 您的服務網格應該提供標準化的方式來收集 RED 計量、追蹤等。
- 可觀察性增加，從擴大涵蓋範圍到屬於服務網格一部分的所有服務。
- 透過自動檢測所有服務來增加可觀察性採用的功能。
- 與服務可觀察性要素的強式整合。 您的服務網格應該能夠擷取計量，並收集顯示在監視解決方案中的記錄。 請確定服務網狀架構的遙測集合支援您的業務需求，並與現有的監視解決方案整合良好。
下圖顯示數據收集和轉送的 Service Mesh Proxy 功能範例。
API 管理自我裝載閘道
透過 Azure API 管理 與 Kubernetes 上的 Azure Arc 之間的整合，您可以將 API 管理 閘道元件部署為已啟用 Azure Arc 的 Kubernetes 叢集中的延伸模組。 這可讓容器化版本的 API 管理 閘道在您的叢集中執行。 所有自我裝載閘道都是從與其同盟的 API 管理 服務進行管理，為您提供所有內部和外部 API 的可見度和統一的管理體驗。
設定自我裝載網關以接受連入流量以導向您的服務需要建立原則。 隨著您的服務規模成長，其管理可能會變得更複雜。
如需詳細資訊，請參閱 自我裝載網關概觀
API 管理 自我裝載閘道可檢視性
自我裝載閘道會發出計量、stdout 記錄和 stderr 記錄。 其發出的計量可由叢集中的 ConfigMap 設定。 如需使用 API 管理 進行進階監視的資訊，請參閱進階監視。
自我裝載閘道可檢視性會說明進入叢集的外部流量（南北），但不會為叢集（東西方）內的Pod對Pod流量提供任何可觀察性。
雲端計量和記錄： 計量預設會發出至 Azure 監視器。 Log Analytics 可讓您使用適用於容器的 Azure 監視器來收集及檢視自我裝載閘道容器記錄。 如需詳細資訊，請參閱設定 Azure API 管理 自我裝載網關的本機計量和記錄。
本機計量和記錄： 來自自我裝載閘道的計量和記錄可以與您的本機監視工具整合，或由 Config Map 發出。 您可以設定計量以發佈至計量伺服器。 閘道記錄預設會發出至 stdout 和 stderr。 如需詳細資訊，請參閱設定 Azure API 管理 自我裝載網關的本機計量和記錄。
技術比較表
下表顯示實作選項之間的差異，以協助您選擇取得服務可檢視性的方法。
| 功能 | 服務網格 | 應用程式效能監視 | 自我裝載 API 閘道 |
|---|---|---|---|
| 支援東西向流量 | Yes | .是 | No |
| 計量功能 | Yes | .是 | Yes |
| 記錄功能 | Yes | Yes | 自定義實作 |
| 分散式追蹤功能 | Yes | .是 | Yes |
| 實作層 | 網路 | 申請 | 網路 |
| 支援的通訊協定 | HTTP（S）、TCP、gRPC | N/A | HTTP（S），websocket |
| 設定責任 | 叢集運算子 | 應用程式開發人員 | 應用程式操作員和叢集運算符 |
| 可觀察性的設定複雜度 | 低 | 高 | 中 |
設計建議
實作 Open Service Mesh，以取得服務健康情況和效能的可觀察性。 Open Service Mesh 會使用將側車 Proxy 插入為與工作負載相同的 Pod 中的個別容器，以取得遙測數據。 這些 Proxy 會攔截您工作負載的所有輸入和輸出 HTTP 流量，並將數據報告至 Open Service Mesh。 使用此系統，服務開發人員不需要檢測其程式代碼來收集遙測數據。
使用已啟用 Azure Arc 的 Kubernetes 叢集擴充功能來啟用 Open Service Mesh，讓 Microsoft 能夠為您管理控制平面。 如需詳細資訊，請參閱部署已啟用 Azure Arc 的 Open Service Mesh（預覽版）。
若要將應用程式和服務的可用性和效能最大化，請啟用 Azure 監視器 Container Insights。 它提供全方位的解決方案，可從您的雲端和內部部署環境收集、分析及處理遙測數據。 已啟用 Azure Arc 的 Open Service Mesh 與 Azure 監視器緊密整合，讓您順暢地檢視和回應 OSM 計量和應用程式容器記錄所提供的重要 KPI。 您可以遵循 下列步驟來啟用 OSM 計量。 針對分散式追蹤，我們建議 Jaeger，其可與OSM控制平面整合。
Open Service Mesh 也提供 Prometheus 和 Grafana 計量記錄 的可觀察性整合 、使用 Jaeger 進行追蹤，以及使用 Fluent Bit 記錄轉送。 如果您未使用 Azure 監視解決方案，這些整合會提供替代選項。 您可以使用這些整合，視需要擴充至其他內部監視工具。
您至少應該定義下列三個 RED 計量，並針對所有服務加以測量：
- 要求速率： 服務每秒接收的要求數目。
- 錯誤： 失敗的要求數目或每秒失敗要求的速率。
- 持續時間： 服務處理要求所需的時間量。
Open Service Mesh 在 Azure 監視器中提供數個預先設定的服務活頁簿，因此您不需要手動設定儀錶板和圖表。 此詳細的遙測可讓您觀察服務行為，並讓您針對應用程式進行疑難解答、維護和優化。 在 Azure 監視器中使用 OSM 監視活頁簿可讓您：
- 取得網格中所有服務的概觀，並取得監視四個黃金訊號中的三個關鍵服務等級計量：延遲、要求和錯誤。
- 針對服務等級目標定義、檢閱和設定 警示 ，以摘要說明您服務的用戶可見效能。
- 檢視個別服務的計量圖表，讓您可以使用篩選和分解、依響應碼、通訊協定、目的地 Pod、流量來源等來深入分析它們。
使用 Jaeger UI 中的視覺效果來：
- 觀察拓撲圖表視覺效果，其中顯示哪些微服務彼此通訊、要求移至何處，以及其花費的時間長度。
- 檢查特定要求和回應，以瞭解其如何及何時進行監視和疑難解答分散式系統。
服務可觀察性只是雲端監視策略的一個專業領域。 如需管理專業領域的詳細資訊，請檢閱 管理專業領域關鍵設計區域。
下一步
如需混合式和多雲端雲端旅程的詳細資訊，請參閱下列文章：
- 檢閱 已啟用 Azure Arc 的 Kubernetes 的必要條件 。
- 檢閱 已啟用 Azure Arc 之 Kubernetes 的已驗證 Kubernetes 散發 套件。
- 瞭解如何 管理混合式和多重雲端環境。
- 若要深入瞭解已啟用 Azure Arc 的 Open Service Mesh，請參閱：
- 瞭解如何 在 Azure Kubernetes Service 上使用 Open Service Mesh 設定監視和可檢視性 （AKS）
- 瞭解 已啟用 Azure Arc 的 Kubernetes 管理和監視。
- 瞭解 服務網格。
- 使用 Azure Arc Jumpstart 的 Open Service Mesh 擴充功能體驗已啟用 Azure Arc 的 Kubernetes。
- 透過 Azure Arc 學習路徑深入瞭解 Azure Arc。
- 請參閱 常見問題 - 已啟用 Azure Arc 以尋找最常見問題的解答。