隨著應(yīng)用系統(tǒng)的復(fù)雜度越來越高，越來越難保證所有的系統(tǒng)都一直處于穩(wěn)健狀態(tài)，有可能某些部分會(huì)因問題而處于降級(jí)狀態(tài)。因此我們不僅必須將應(yīng)用程序構(gòu)建得更可靠和更具彈性，還必須通過可觀測性工具在運(yùn)行時(shí)能夠理解實(shí)際發(fā)生的事情。如果我們能夠了解應(yīng)用服務(wù)和基礎(chǔ)設(shè)施在運(yùn)行時(shí)發(fā)生了什么，我們就可以學(xué)會(huì)檢測故障并在觀察到某些意外情況時(shí)進(jìn)行深入調(diào)試。這將有助于降低平均恢復(fù)時(shí)間，快速恢復(fù)對(duì)業(yè)務(wù)的影響。

可觀測性是指通過查看系統(tǒng)的外部特征來理解和推理系統(tǒng)的內(nèi)部處于什么樣的狀態(tài)。它基于控制理論的研究，最初由 Rudolf E. Kálmán 在 1960 年的論文“關(guān)于控制系統(tǒng)的一般理論”中提出。從實(shí)際應(yīng)用的角度來看，我們在系統(tǒng)中需要重視其穩(wěn)定性，需要理解什么時(shí)候系統(tǒng)運(yùn)行良好或出現(xiàn)問題，從而可以更快地識(shí)別錯(cuò)誤，并實(shí)施正確的自動(dòng)化及手動(dòng)控制來維護(hù)系統(tǒng)的可用性。

阿里云服務(wù)網(wǎng)格 ASM 提供了統(tǒng)一標(biāo)準(zhǔn)化方式，為用戶提供一種收斂后的可觀測數(shù)據(jù)生成與采集配置模式，以更好地支持云原生應(yīng)用的可觀測性。

01?概述

可觀測介紹
可觀測性是一個(gè)包含各種級(jí)別的系統(tǒng)特征，必須結(jié)合應(yīng)用程序的指標(biāo)采集、網(wǎng)絡(luò)的的指標(biāo)采集、以及基礎(chǔ)設(shè)施如數(shù)據(jù)庫存儲(chǔ)等來篩選存儲(chǔ)大量的數(shù)據(jù)，以便在發(fā)生不可預(yù)測的情況時(shí)拼湊出一個(gè)完整的視圖。Service Mesh 在可觀測性方面可以有效提升應(yīng)用程序級(jí)別的網(wǎng)絡(luò)指標(biāo)采集。

Service Mesh 的數(shù)據(jù)平面代理位于服務(wù)之間的網(wǎng)絡(luò)請(qǐng)求路徑中，通過捕獲代理的可觀測性數(shù)據(jù)可以在運(yùn)行時(shí)了解應(yīng)用程序網(wǎng)絡(luò)和網(wǎng)格的運(yùn)行情況。

在 Service Mesh 中實(shí)現(xiàn)可觀測性，涉及了日志、監(jiān)控指標(biāo)以及鏈路追蹤這些可觀測性數(shù)據(jù)的生成規(guī)則配置和采集配置，以及如何將這些可觀測數(shù)據(jù)采集到云托管服務(wù)或者自建服務(wù)中。同時(shí)，還需要考慮如何支持針對(duì)網(wǎng)格代理與網(wǎng)關(guān) Pod 分別定義采集配置，以支持不同的場景訴求。阿里云服務(wù)網(wǎng)格 ASM 提供了統(tǒng)一標(biāo)準(zhǔn)化方式，為用戶提供一種收斂后的可觀測數(shù)據(jù)生成與采集配置模式，以更好地支持云原生應(yīng)用的可觀測性。

內(nèi)置最佳實(shí)踐
雖然 Telemetry CRD 允許在多個(gè)命名空間內(nèi)可以創(chuàng)建多個(gè)對(duì)象，但如果隨意定義造成沖突等，可能使得實(shí)際執(zhí)行的結(jié)果與預(yù)期不符合。我們在產(chǎn)品中總結(jié)并落實(shí)了如下幾個(gè)最佳實(shí)踐：

• 在根配置命名空間 istio-system 中定義多個(gè)網(wǎng)格范圍的 Telemetry 資源對(duì)象是無效的，也就是說只能在存在一個(gè) Telemetry 資源對(duì)象。阿里云服務(wù)網(wǎng)格 ASM 中已經(jīng)內(nèi)置了該最佳實(shí)踐，在 istio-system 命名空間內(nèi)只允許存在一個(gè)名稱為 default 的 Telemetry 資源對(duì)象。

• 所有的命名空間下約束為只存在一個(gè) Telemetry 資源對(duì)象允許工作負(fù)載的選擇器 selector 為空，且名稱為 default。

• 可以通過使用工作負(fù)載選擇器 selector 在所需命名空間中應(yīng)用新的 Telemetry 資源對(duì)象來實(shí)現(xiàn)特定于工作負(fù)載的覆蓋。

• 如果存在具有相同的工作負(fù)載選擇器 selector 的兩個(gè) Telemetry 資源對(duì)象，也就是說這兩個(gè) Telemetry 資源對(duì)象選擇了相同的工作負(fù)載，那么在這種情況下，產(chǎn)生行為是不確定的, 即不確定是這兩個(gè) Telemetry 資源對(duì)象中的哪一個(gè)會(huì)被執(zhí)行。

• 當(dāng)根配置命名空間 istio-system 下的全局 Telemetry 資源對(duì)象中，未定位監(jiān)控指標(biāo)部分，默認(rèn)對(duì)應(yīng)的是不啟用生成指標(biāo)。

• 為了避免這些指標(biāo)產(chǎn)生的存儲(chǔ)成本較大，在阿里云服務(wù)網(wǎng)格 ASM 中第一次開啟時(shí)的指標(biāo)設(shè)置中全局范圍內(nèi)只開啟 SERVER 側(cè)指標(biāo)，未開啟 CLIENT 側(cè)指標(biāo)。請(qǐng)根據(jù)需要，自行進(jìn)行開啟，例如需要針對(duì)網(wǎng)關(guān)進(jìn)行監(jiān)控，則需要進(jìn)行開啟 CLIENT 側(cè)指標(biāo)。需要注意的是，如果已經(jīng)開啟過，重新開啟之后的指標(biāo)設(shè)置將保留使用上一次的設(shè)置規(guī)則。

02?日志

在 Service Mesh 中，日志的采集是實(shí)現(xiàn)可觀測性的重要手段之一。通過將所有服務(wù)的日志聚合到一處，可以便于統(tǒng)一管理和檢索。為了實(shí)現(xiàn)這個(gè)目標(biāo)，需要將每個(gè)服務(wù)的日志打印到 stdout 或 stderr，并使用日志代理將它們收集到中心日志系統(tǒng)中。阿里云服務(wù)網(wǎng)格 ASM 提供了日志過濾和日志格式化功能，可以根據(jù)需要對(duì)日志進(jìn)行過濾和格式化，以便更好地進(jìn)行檢索和分析。

日志格式規(guī)則配置
在實(shí)際應(yīng)用中，需要考慮到不同服務(wù)的日志格式可能不同，因此需要設(shè)置生成規(guī)則來控制日志的生成方式。部署在數(shù)據(jù)平面（即加入網(wǎng)格的 Kubernetes 集群）的 Envoy Proxy 可以輸出所有訪問日志。ASM 支持自定義 Envoy Proxy 輸出的訪問日志內(nèi)容。

基于 Telemetry CRD，阿里云服務(wù)網(wǎng)格 ASM 提供了如下圖所示的圖形化界面，簡化用戶定義日志數(shù)據(jù)格式的配置。

對(duì)應(yīng)地，生成的定義內(nèi)容如下：

以及描述了過濾條件的配置內(nèi)容：

數(shù)據(jù)面日志采集設(shè)置

此外，需要設(shè)置采集規(guī)則來控制日志的采集方式和儲(chǔ)存有效期。

容器服務(wù) ACK 集成了日志服務(wù)功能，可對(duì)服務(wù)網(wǎng)格數(shù)據(jù)平面集群的 AccessLog 進(jìn)行采集。
采集控制平面日志及設(shè)置告警
ASM 支持采集控制平面日志和日志告警，例如采集 ASM 控制平面向數(shù)據(jù)平面 Sidecar 推送配置的相關(guān)日志。ASM 控制面組件的主要功能之一是推送網(wǎng)格的規(guī)則配置到數(shù)據(jù)面的 Sidecar 代理或者網(wǎng)關(guān)中。如果用戶配置的網(wǎng)格規(guī)則內(nèi)容存在一些沖突導(dǎo)致推送失敗，代理或者網(wǎng)關(guān)就接收不到最新的配置內(nèi)容。雖然代理或網(wǎng)關(guān)在不重啟的情況下，可以使用已經(jīng)接收到的配置繼續(xù)運(yùn)行，但是一旦這些 Pod 重啟，很有可能導(dǎo)致 Sidecar 代理或網(wǎng)關(guān)啟動(dòng)失敗。在很多實(shí)際場景中，經(jīng)常出現(xiàn)用戶誤配置引發(fā)的網(wǎng)關(guān)或代理不可用的問題，因此啟用控制面的日志告警，及時(shí)發(fā)現(xiàn)并解決問題十分必要。

03?監(jiān)控指標(biāo)

監(jiān)控指標(biāo)是 Service Mesh 中的另一個(gè)重要可觀測性維度，用于描述請(qǐng)求的處理情況、服務(wù)之間的通信狀況等等。Istio 采用 Prometheus 進(jìn)行監(jiān)控指標(biāo)的采集和存儲(chǔ)，每個(gè)服務(wù)的代理（Envoy）會(huì)生成大量的監(jiān)控指標(biāo)。這些指標(biāo)可以用于實(shí)時(shí)監(jiān)控服務(wù)的運(yùn)行情況和性能指標(biāo)，還可以用于異常檢測和自動(dòng)伸縮等場景。

指標(biāo)數(shù)據(jù)生成規(guī)則配置
啟用服務(wù)網(wǎng)格數(shù)據(jù)平面監(jiān)控指標(biāo)可以使服務(wù)網(wǎng)格數(shù)據(jù)平面（網(wǎng)關(guān)以及 Sidecar 代理）生成與其運(yùn)行狀態(tài)相關(guān)的指標(biāo)數(shù)據(jù)，您可以通過將指標(biāo)采集到阿里云 ARMS Prometheus 來直接查看監(jiān)控報(bào)表（采集指標(biāo)可能產(chǎn)生費(fèi)用），或是自建 Prometheus 并從 ASM 數(shù)據(jù)平面抓取監(jiān)控指標(biāo)。

基于 Telemetry CRD，阿里云服務(wù)網(wǎng)格 ASM 提供了如下圖所示的圖形化界面，簡化用戶自定義指標(biāo)配置。

對(duì)應(yīng)地，生成的定義內(nèi)容如下：

注意的是，第一次開啟時(shí)的指標(biāo)設(shè)置：

為了避免這些指標(biāo)產(chǎn)生費(fèi)用較大，第一次開啟時(shí)的指標(biāo)設(shè)置中全局范圍內(nèi)只開啟 SERVER 側(cè)指標(biāo)，未開啟 CLIENT 側(cè)指標(biāo)。請(qǐng)根據(jù)需要，自行進(jìn)行開啟，例如需要針對(duì)網(wǎng)關(guān)進(jìn)行監(jiān)控，則需要進(jìn)行開啟 CLIENT 側(cè)指標(biāo)。需要注意的是，如果已經(jīng)開啟過，重新開啟之后的指標(biāo)設(shè)置將保留使用上一次的設(shè)置規(guī)則。

ASM 網(wǎng)格拓?fù)涔δ芟嚓P(guān)的指標(biāo)設(shè)置：

ASM 網(wǎng)格拓?fù)涔δ芤蕾囉?Sidecar 上報(bào)的監(jiān)控指標(biāo)，若您開啟了網(wǎng)格拓?fù)?，關(guān)閉部分監(jiān)控指標(biāo)會(huì)對(duì)網(wǎng)格拓?fù)涔δ茉斐捎绊懮踔敛豢捎谩?/p>

• 如果不啟用 REQUEST_COUNT 的 SERVER 側(cè)指標(biāo)，將無法生成 HTTP/gRPC 服務(wù)的拓?fù)鋱D。

• 如果不啟用 TCP_SENT_BYTES 的 SERVER 側(cè)指標(biāo)，將無法生成 TCP 服務(wù)的拓?fù)鋱D。

• 關(guān)閉 REQUEST_SIZE 和 REQUEST_DURATION 的 SERVER 側(cè)，REQUEST_SIZE 的 CLIENT 側(cè)指標(biāo)會(huì)導(dǎo)致部分拓?fù)鋱D節(jié)點(diǎn)的監(jiān)控信息無法展示。

指標(biāo)采集配置
開啟 Prometheus 的統(tǒng)計(jì)數(shù)據(jù)收集功能，將采集到的監(jiān)控指標(biāo)發(fā)送到 Prometheus 中，以便進(jìn)行存儲(chǔ)和分析。服務(wù)網(wǎng)格 ASM 集成了 ARMS Prometheus 功能，可以實(shí)現(xiàn)對(duì)服務(wù)網(wǎng)格的監(jiān)控。

Prometheus 采集間隔會(huì)對(duì)指標(biāo)收集開銷產(chǎn)生重大影響，間隔越長，抓取的數(shù)據(jù)點(diǎn)就越少，從而減少處理、存儲(chǔ)和計(jì)算開銷。當(dāng)前的默認(rèn)配置為 15s，對(duì)于生產(chǎn)場景來說可能過于頻繁。請(qǐng)根據(jù)實(shí)際需要在 Prometheus 側(cè)進(jìn)行調(diào)整。

如果使用的是 ARMS Prometheus，請(qǐng)到 ARMS 控制臺(tái)中的設(shè)置頁中進(jìn)行配置，查看文檔說明。

直方圖關(guān)聯(lián)的指標(biāo)（包括 istio_request_duration_milliseconds_bucket、istio_request_bytes_bucket、istio_response_bytes_bucket）通常比較密集，開銷較大，為了避免這些自定義指標(biāo)繼續(xù)產(chǎn)生費(fèi)用，您可以廢棄這些自定義指標(biāo)。如果使用的是 ARMS Prometheus，請(qǐng)到 ARMS 控制臺(tái)中的指標(biāo)頁中進(jìn)行配置。

同時(shí)，也支持在 ASM 集成自建 Prometheus 實(shí)現(xiàn)網(wǎng)格監(jiān)控。

通過 Grafana 可以查看對(duì)應(yīng)的儀表盤，類似如下：

合并 Istio 與應(yīng)用的監(jiān)控指標(biāo)
已有 Prometheus 監(jiān)控端點(diǎn)的應(yīng)用服務(wù)，通過啟用合并 Istio 與應(yīng)用的監(jiān)控指標(biāo)功能，可以借助網(wǎng)格代理輸出原有業(yè)務(wù)指標(biāo)。啟用合并 Istio 與應(yīng)用的監(jiān)控指標(biāo)功能后，服務(wù)網(wǎng)格會(huì)將應(yīng)用程序指標(biāo)合并到 Istio 指標(biāo)中，相對(duì)應(yīng)的 prometheus.io 注解會(huì)被加入到所有數(shù)據(jù)面 Pod 上，以啟用 Prometheus 的指標(biāo)抓取能力。如果這些注解已經(jīng)存在，就會(huì)被覆蓋。網(wǎng)格代理將應(yīng)用指標(biāo)和 Istio 指標(biāo)進(jìn)行合并，Prometheus 可以從 :15020/stats/prometheus 端點(diǎn)拉取合并后的指標(biāo)。
網(wǎng)格拓?fù)湔故?/strong>
網(wǎng)格拓?fù)涫且粋€(gè)服務(wù)網(wǎng)格可觀測性工具，提供查看相關(guān)服務(wù)與配置的可視化界面。ASM 支持內(nèi)置網(wǎng)格拓?fù)?，類似如下?/p>

服務(wù)等級(jí)目標(biāo) SLO
服務(wù)等級(jí)指標(biāo) SLI（Service Level Indicator）是衡量服務(wù)健康狀況的指標(biāo)。SLO 是指服務(wù)等級(jí)的目標(biāo)值或范圍值，由一個(gè)或多個(gè)服務(wù)等級(jí)指標(biāo) SLI 組成。

SLO 提供了一種形式化的方式來描述、衡量和監(jiān)控微服務(wù)應(yīng)用程序的性能、質(zhì)量和可靠性。SLO 為應(yīng)用開發(fā)和平臺(tái)團(tuán)隊(duì)、運(yùn)維團(tuán)隊(duì)提供了一個(gè)共享的質(zhì)量基準(zhǔn)，可作為衡量服務(wù)水平質(zhì)量以及持續(xù)改進(jìn)的參考。使用 SLI 組合定義的 SLO 能夠幫助團(tuán)隊(duì)以更精確的方式描述服務(wù)健康狀況。

SLO 示例如下：

• 每分鐘平均 QPS > 100k/s

• 99% 訪問延遲 < 500ms

• 99% 每分鐘帶寬 > 200 MB/s

阿里云服務(wù)網(wǎng)格 ASM 提供了開箱即用的基于服務(wù)等級(jí)目標(biāo) SLO（Service Level Objectives）的監(jiān)控和告警能力，能夠監(jiān)控應(yīng)用服務(wù)之間調(diào)用的延遲和錯(cuò)誤率特征等。

ASM 支持的 SLI 類型如下：

• 服務(wù)可用性：服務(wù)成功響應(yīng)的時(shí)間比例，對(duì)應(yīng)的 SLI 插件類型為 availability。HTTP 響應(yīng)碼為 429 或以 5XX（以 5 開頭的狀態(tài)碼）會(huì)被判斷為不可用。

• 延遲時(shí)間：服務(wù)返回請(qǐng)求的響應(yīng)所需的時(shí)間（單位為毫秒），對(duì)應(yīng)的 SLI 插件類型為 lantency。您可自定義延遲上限，高于上限的響應(yīng)會(huì)被判斷為不合格。

阿里云服務(wù)網(wǎng)格 ASM 提供了定義 SLO 配置的 UI 界面，如下所示：

使用 ASM 定義應(yīng)用服務(wù)級(jí) SLO，可以自動(dòng)生成 Prometheus 規(guī)則。將生成的規(guī)則導(dǎo)入 Prometheus 中之后可以執(zhí)行 SLO。在 Prometheus 框架中，由 AlertManager 組件負(fù)責(zé)收集 Prometheus Server 產(chǎn)生的告警信息，并根據(jù)您的配置發(fā)送給各個(gè)接收者。當(dāng)觸發(fā)告警時(shí)，在 Alertmanager 頁面，如下圖所示，可以看到自定義告警信息采集成功。

04?分布式追蹤

分布式追蹤是 Service Mesh 中實(shí)現(xiàn)可觀測性的重要組成部分之一，是一種用于對(duì)應(yīng)用程序進(jìn)行概要分析和監(jiān)視的方法，尤其是針對(duì)使用微服務(wù)架構(gòu)構(gòu)建的應(yīng)用程序。在微服務(wù)架構(gòu)中，服務(wù)之間的通信是通過網(wǎng)絡(luò)進(jìn)行的，因此需要采用分布式追蹤技術(shù)來對(duì)服務(wù)之間的調(diào)用關(guān)系進(jìn)行跟蹤和監(jiān)控。在 Istio 中，可以使用 Jaeger、Zipkin 等分布式追蹤工具來實(shí)現(xiàn)這個(gè)功能。在分布式追蹤里，存在 Trace 和 Span 兩個(gè)重要概念：

• Span：分布式追蹤的基本組成單元，表示一個(gè)分布式系統(tǒng)中的單獨(dú)的工作單元，每一個(gè) Span 可以包含其它 Span 的引用。多個(gè) Span 在一起構(gòu)成了 Trace。

• Trace：微服務(wù)中記錄的完整的請(qǐng)求執(zhí)行過程，一個(gè)完整的 Trace 由一個(gè)或多個(gè) Span 組成。

雖然 Istio 代理能夠自動(dòng)發(fā)送 Span 信息，但是應(yīng)用程序仍然需要傳播適當(dāng)?shù)?HTTP 標(biāo)頭，以便在代理發(fā)送 Span 時(shí)，可以將 Span 正確地關(guān)聯(lián)到單個(gè)跟蹤中。為此，應(yīng)用程序需要收集以下標(biāo)頭并將其從傳入請(qǐng)求傳播到任何傳出請(qǐng)求：

• x-request-id

• x-b3-traceid

• x-b3-spanid

• x-b3-parentspanid

• x-b3-sampled

• x-b3-flags

• x-ot-span-context

追蹤數(shù)據(jù)生成規(guī)則配置
基于 Telemetry CRD，阿里云服務(wù)網(wǎng)格 ASM 提供了如下圖所示的圖形化界面，簡化用戶定義分布式鏈路追蹤數(shù)據(jù)的生成規(guī)則配置。

對(duì)應(yīng)地, 生成的定義內(nèi)容如下：

追蹤采集配置

需要將采集到的數(shù)據(jù)發(fā)送到云托管服務(wù)或者自建服務(wù)中。在云托管服務(wù)中，可以使用云原生應(yīng)用管理服務(wù)來實(shí)現(xiàn)數(shù)據(jù)的收集和分析。

在自建服務(wù)中，可以使用開源的數(shù)據(jù)收集和分析工具（如 Zipkin、Jaeger 等）來實(shí)現(xiàn)數(shù)據(jù)的收集和分析。

05?總結(jié)

在 Service Mesh 中，不同的服務(wù)可能需要采集不同的可觀測性數(shù)據(jù)，因此需要支持針對(duì)網(wǎng)格代理與網(wǎng)關(guān) Pod 分別定義采集配置規(guī)則，并統(tǒng)一標(biāo)準(zhǔn)化采集配置規(guī)則，以便更好地支持云原生應(yīng)用的可觀測性。

總的來說，可觀測性在云原生應(yīng)用中扮演著非常重要的角色，它可以幫助我們實(shí)時(shí)監(jiān)控服務(wù)的運(yùn)行情況和性能指標(biāo)，發(fā)現(xiàn)并解決服務(wù)故障和瓶頸，從而提高應(yīng)用的可靠性和性能。因此，借助于 Service Mesh 的無侵入式可觀測性的實(shí)現(xiàn)，基于標(biāo)準(zhǔn)的統(tǒng)一化的可觀測數(shù)據(jù)生成與采集配置，一定可以更好地支持云原生應(yīng)用的發(fā)展。

標(biāo)簽：服務(wù)網(wǎng)格可觀測性阿里云