在Service Mesh中，不同的服務可能需要採集不同的可觀測性資料，因此需要支援針對網格代理與網關Pod分別定義採集配置規則，並統一標準化採集配置規則，以便更好地支援雲原生應用的可觀測性。可觀測性在雲原生應用中扮演著非常重要的角色，它可以協助我們即時監控服務的運行情況和效能指標，發現並解決服務故障和瓶頸，從而提高應用的可靠性和效能。阿里雲服務網格ASM提供了統一標準化方式，為您提供一種收斂後的可觀測資料產生與採集配置模式，以更好地支援雲原生應用的可觀測性。本文介紹可觀測的概念及相關功能。
可觀測介紹
隨著應用系統的複雜度越來越高，就越來越難保證所有的系統都一直處於穩健狀態，有可能某些部分會因問題而處於降級狀態。因此不僅需要將應用程式構建得更可靠且更具彈性，還需要通過可觀測性工具瞭解應用服務和基礎設施在運行時發生的情況。如果能夠瞭解實際發生的情況，就可以學會檢測故障並在觀察到某些意外情況時進行深入調試。這將有助於降低平均恢復，快速恢複對業務的影響。
可觀測性是一個包含各種層級的系統特徵，必須結合應用程式的指標採集、網路的指標採集、以及基礎設施（例如資料庫儲存等）來篩選儲存大量的資料，以便在發生不可預測的情況時拼湊出一個完整的視圖。Service Mesh在可觀測性方面可以有效提升應用程式層級的網路指標採集。從實際應用的角度來看，在系統中需要重視其穩定性，需要理解什麼時候系統運行良好或出現問題，從而可以更快地識別錯誤，並實施正確的自動化及手動控制來維護系統的可用性。
Service Mesh的資料平面代理位於服務之間的網路請求路徑中，通過捕獲代理的可觀測性資料可以在運行時瞭解應用程式網路和網格的運行情況。
在Service Mesh中實現可觀測性，涉及了日誌、監控指標、鏈路追蹤這些可觀測性資料的建置規則配置和採集配置，以及如何將這些可觀測資料擷取到雲託管服務或者自建服務中。同時，還需要考慮如何支援針對網格代理與網關Pod分別定義採集配置，以支援不同的情境訴求。ASM提供了統一標準化方式，為您提供一種收斂後的可觀測資料產生與採集配置模式，以更好地支援雲原生應用的可觀測性。
內建最佳實務
Telemetry CRD允許在多個命名空間內建立多個對象，但隨意定義可能造成衝突等，導致實際執行的結果與預期不符。基於實際操作得出的最佳實務如下：
在根命名空間istio-system中定義多個網格範圍的Telemetry資來源物件無效，即只能存在一個Telemetry資來源物件。ASM中已經內建了該最佳實務，在istio-system命名空間內只允許存在一個名稱為default的Telemetry資來源物件。
所有的命名空間下約束只存在一個Telemetry資來源物件允許工作負載的選取器selector為空白，且名稱為default。
可以通過使用工作負載選取器selector在所需命名空間中應用新的Telemetry資來源物件來實現特定工作負載的覆蓋。
如果存在具有相同的工作負載選取器selector的兩個Telemetry資來源物件，即這兩個Telemetry資來源物件選擇了相同的工作負載，則不確定這兩個Telemetry資來源物件中的哪一個會被執行。
當根命名空間istio-system下的全域Telemetry資來源物件中，未定位監控指標部分，預設對應不啟用產生指標。
日誌
在Service Mesh中，日誌的採集是實現可觀測性的重要手段之一。將所有服務的日誌彙總到一處，便於統一管理和檢索。為了實現這個目標，需要將每個服務的日誌列印到stdout或stderr，並使用日誌代理將它們收集到中心日誌系統中。ASM提供了日誌過濾和日誌格式化功能，可以根據需要對日誌進行過濾和格式化，以便更好地檢索和分析日誌。
日誌格式規則配置
在實際應用中，不同服務的日誌格式可能不同，因此需要設定建置規則來控制日誌的產生方式。部署在資料平面（即加入網格的Kubernetes叢集）的Envoy Proxy可以輸出所有訪問日誌。ASM支援自訂Envoy Proxy輸出的訪問日誌內容。
基於Telemetry CRD，ASM提供了如下圖所示的圖形化介面，簡化日誌資料格式的配置。具體操作，請參見自訂資料面訪問日誌。
對應產生的定義內容如下：
envoyFileAccessLog:
logFormat:
text: '{"bytes_received":"%BYTES_RECEIVED%","bytes_sent":"%BYTES_SENT%","downstream_local_address":"%DOWNSTREAM_LOCAL_ADDRESS%","downstream_remote_address":"%DOWNSTREAM_REMOTE_ADDRESS%","duration":"%DURATION%","istio_policy_status":"%DYNAMIC_METADATA(istio.mixer:status)%","method":"%REQ(:METHOD)%","path":"%REQ(X-ENVOY-ORIGINAL-PATH?:PATH)%","protocol":"%PROTOCOL%","request_id":"%REQ(X-REQUEST-ID)%","requested_server_name":"%REQUESTED_SERVER_NAME%","response_code":"%RESPONSE_CODE%","response_flags":"%RESPONSE_FLAGS%","route_name":"%ROUTE_NAME%","start_time":"%START_TIME%","trace_id":"%REQ(X-B3-TRACEID)%","upstream_cluster":"%UPSTREAM_CLUSTER%","upstream_host":"%UPSTREAM_HOST%","upstream_local_address":"%UPSTREAM_LOCAL_ADDRESS%","upstream_service_time":"%RESP(X-ENVOY-UPSTREAM-SERVICE-TIME)%","upstream_transport_failure_reason":"%UPSTREAM_TRANSPORT_FAILURE_REASON%","user_agent":"%REQ(USER-AGENT)%","x_forwarded_for":"%REQ(X-FORWARDED-FOR)%","authority_for":"%REQ(:AUTHORITY)%","upstream_response_time":"%RESP(X-ENVOY-UPSTREAM-SERVICE-TIME)%","xff":"%REQ(X-FORWARDED-FOR)%","app_service_name":"%UPSTREAM_CLUSTER%"}'
path: /dev/stdout對應的過濾條件內容如下：
accessLogging:
- disabled: false
filter:
expression: response.code >= 400
providers:
- name: envoy資料面日誌採集設定
將資料平面日誌採集到阿里雲Log ServiceSLS時，需要設定採集規則來控制日誌的採集方式和儲存有效期間。Container ServiceACK整合了Log Service功能，可對服務網格資料平面叢集的AccessLog進行採集。具體操作，請參見使用Log Service採集資料平面的AccessLog。
採集控制平面日誌及設定警示
ASM支援採集控制平面日誌和日誌警示，例如採集ASM控制平面向資料平面Sidecar推送配置的相關日誌。ASM控制面組件的主要功能之一是推送網格的規則配置到資料面的Sidecar代理或者網關中。如果您配置的網格規則內容存在一些衝突導致推送失敗，Sidecar代理或者網關將接收不到最新的配置內容。雖然Sidecar代理或網關在不重啟的情況下，可以使用已經接收到的配置繼續運行，但是一旦這些Pod重啟，很有可能導致Sidecar代理或網關啟動失敗。在很多實際情境中，經常出現使用者誤配置引發的網關或代理停用問題，因此啟用控制面的日誌警示，及時發現並解決問題十分必要。具體操作，請參見啟用控制平面日誌採集和日誌警示（舊版）或啟用控制平面日誌採集和日誌警示（新版）。
監控指標
監控指標是Service Mesh中的另一個重要可觀測性維度，用於描述請求的處理情況、服務之間的通訊狀況等。Istio採用Prometheus進行監控指標的採集和儲存，每個服務的代理（Envoy）會產生大量的監控指標。這些指標可以用於即時監控服務的運行情況和效能指標，還可以用於異常檢測和自動調整等情境。
指標資料建置規則配置
啟用服務網格資料平面監控指標可以使服務網格資料平面（網關和Sidecar代理）產生與其運行狀態相關的指標資料。您可以通過將指標採集到阿里雲ARMS Prometheus來直接查看監控報表（採集指標可能產生費用），或是自建Prometheus並從ASM資料平面抓取監控指標。
基於Telemetry CRD，ASM提供了如下圖所示的圖形化介面，簡化自訂指標配置。具體操作，請參見在ASM中自訂監控指標。
對應產生的定義內容如下：
監控指標註意事項
第一次開啟：阿里雲可觀測監控Prometheus版是收費服務，請您根據實際情況自行決定指標產生範圍，以免指標量過大，產生過高費用。例如，若需要針對網關進行監控，則需要開啟CLIENT側指標。對於已開啟過的指標，重新開啟之後的指標設定將保留使用上一次的設定規則。
ASM網格拓撲功能相關的指標設定：ASM網格拓撲功能依賴於Sidecar上報的監控指標，若您開啟了網格拓撲，關閉部分監控指標會對網格拓撲功能造成影響甚至不可用。
如果不啟用REQUEST_COUNT的SERVER側指標，將無法產生HTTP或gRPC服務的拓撲圖。
如果不啟用TCP_SENT_BYTES的SERVER側指標，將無法產生TCP服務的拓撲圖。
關閉REQUEST_SIZE和REQUEST_DURATION的SERVER側，REQUEST_SIZE的CLIENT側指標會導致部分拓撲圖節點的監控資訊無法展示。
指標採集配置
開啟Prometheus的統計資料收集功能，將採集到的監控指標發送到Prometheus中，以便進行儲存和分析。ASM整合了ARMS Prometheus功能，可以實現對服務網格的監控。具體操作，請參見整合可觀測監控Prometheus版實現網格監控。
Prometheus採集間隔會對指標收集開銷產生重大影響。間隔越長，抓取的資料點就越少，從而可以減少處理、儲存和計算開銷。當前的預設配置為15秒，對於生產情境來說可能過於頻繁。請根據實際需要在Prometheus側進行調整。如果使用的是ARMS Prometheus，請通過ARMS控制台進行相關配置。具體操作，請參見配置採集規則。
長條圖關聯的指標（包括istio_request_duration_milliseconds_bucket、istio_request_bytes_bucket、istio_response_bytes_bucket）通常比較密集，開銷較大。為了避免這些自訂指標持續產生費用，您可以廢棄這些自訂指標。如果使用的是ARMS Prometheus，請通過ARMS控制台進行配置。具體操作，請參見配置廢棄指標。
ASM整合自建Prometheus實現網格監控。具體操作，請參見整合自建Prometheus實現網格監控。
如下圖所示，您可以通過Grafana查看對應的儀錶盤。
合并Istio與應用的監控指標
已有Prometheus監控端點的應用服務，通過啟用合并Istio與應用的監控指標功能，可以藉助網格代理輸出原有業務指標。啟用合并Istio與應用的監控指標功能後，ASM會將應用程式指標合并到Istio指標中，相對應的prometheus.io註解會被加入到所有資料面Pod上，以啟用Prometheus的指標抓取能力。如果這些註解已經存在，就會被覆蓋。網格代理將應用指標和Istio指標進行合并，Prometheus可以從:15020/stats/prometheus端點拉取合并後的指標。具體操作，請參見合并Istio與應用的監控指標。
網格拓撲展示
網格拓撲是一個服務網格可觀測性工具，提供查看相關服務與配置的可視化介面。如下圖所示，ASM支援內建網格拓撲。具體操作，請參見開啟網格拓撲提高可觀測性。
服務等級目標SLO
服務等級指標SLI（Service Level Indicator）是衡量服務健康情況的指標。SLO是指服務等級的目標值或範圍值，由一個或多個服務等級指標SLI組成。
SLO提供了一種形式化的方式來描述、衡量和監控微服務應用程式的效能、品質和可靠性。SLO為應用開發和平台團隊、營運團隊提供了一個共用的品質基準，可作為衡量服務水平品質以及持續改進的參考。使用SLI組合定義的SLO能夠協助團隊以更精確的方式描述服務健康情況。
SLO樣本如下：
每分鐘平均QPS > 100,000/s
99%訪問延遲 < 500ms
99%每分鐘頻寬 > 200 MB/s
ASM提供了開箱即用的基於服務等級目標SLO（Service Level Objectives）的監控和警示能力，能夠監控應用服務之間調用的延遲和錯誤率特徵等。
ASM支援的SLI類型如下：
服務可用性：服務成功響應的時間比例，對應的SLI外掛程式類型為availability。HTTP響應碼為429或以5XX（以5開頭的狀態代碼）會被判斷為不可用。
延遲時間：服務返回請求的響應所需的時間（單位為毫秒），對應的SLI外掛程式類型為lantency。您可自訂延遲上限，高於上限的響應會被判斷為不合格。
ASM提供了定義SLO配置的UI介面如下。
使用ASM定義應用服務級SLO，可以自動產生Prometheus規則。將產生的規則匯入Prometheus中之後可以執行SLO。在Prometheus架構中，由AlertManager組件負責收集Prometheus Server產生的警示資訊，並根據您的配置發送給各個接收者。如下圖所示，當觸發警示時，您可以在Alertmanager頁面看到自訂警示資訊採集成功。關於SLO的更多資訊，請參見SLO管理。
分布式追蹤
分布式追蹤是Service Mesh中實現可觀測性的重要組成部分之一，是一種用於對應用程式進行概要分析和監視的方法，尤其是針對使用微服務架構構建的應用程式。在微服務架構中，服務之間的通訊通過網路進行，因此需要採用分布式追蹤技術來對服務之間的調用關係進行跟蹤和監控。在Istio中，可以使用Jaeger、Zipkin等分布式追蹤工具來實現這個功能。在分布式追蹤裡，存在Trace和Span兩個重要概念。
Span：分布式追蹤的基本組成單元，表示一個分布式系統中的單獨的工作單元，每一個Span可以包含其它Span的引用。多個Span在一起構成了Trace。
Trace：微服務中記錄的完整的請求執行過程，一個完整的Trace由一個或多個Span組成。
雖然Istio代理能夠自動發送Span資訊，但是應用程式仍然需要傳播適當的HTTP標題，以便在代理髮送Span時，可以將Span正確地關聯到單個跟蹤中。因此，應用程式需要收集以下標題並將其從傳入請求傳播到任何傳出請求：
x-request-id
x-b3-traceid
x-b3-spanid
x-b3-parentspanid
x-b3-sampled
x-b3-flags
x-ot-span-context
追蹤資料建置規則配置
基於Telemetry CRD，ASM提供了如下圖所示的圖形化介面，簡化定義分布式鏈路追蹤資料的建置規則配置。
對應產生的定義內容如下：
tracing:
- customTags:
mytag1:
literal:
value: fixedvalue
mytag2:
header:
defaultValue: value1
name: myheader1
mytag3:
environment:
defaultValue: value1
name: myenv1
providers:
- name: zipkin
randomSamplingPercentage: 90追蹤採集配置
若您需要將採集到的資料發送到雲託管服務或者自建服務中，可以使用以下方式：
在雲託管服務中，可以使用雲原生應用管理服務來實現資料的收集和分析。具體操作，請參見在ASM中實現分布式跟蹤。
在自建服務中，可以使用開源的資料收集和分析工具（例如Zipkin、Jaeger等）來實現資料的收集和分析。具體操作，請參見向自建系統匯出ASM鏈路追蹤資料。