2022年10月24日22:43:30 熱門 1930

【轉載來源】https://cloud.tencent.com/developer/article/1638897

前言

談到 Service Mesh，人們總是想起微服務和服務治理，從 Dubbo 到 Spring Cloud (2016開始進入國內研發的視野，2017年繁榮)再到 Service Mesh (2018年開始被大家所熟悉)，正所謂長江後浪推前浪，作為後浪，Service Mesh 別無選擇，而 Spring Cloud 對 Service Mesh 滿懷羨慕，微服務架構的出現與繁榮，是互聯網時代架構形式的巨大突破。Service Mesh 具有一定的學習成本，實際上在國內的落地案例不多，大多是雲商與頭部企業，隨着性能與生態的完善以及各大社區推動容器化場景的落地，Service Mesh 也開始在大小公司生根發芽，彌補容器層與 Kubernetes 在服務治理方面的短缺之處。本次將以一個選型調研者的視角，來看看 Service Mesh 中的可觀測性主流實踐方案。

從Service Mesh談如何做好監控

可觀測性的哲學

可觀測性（ Observability ）不是一個新名詞，它在很久之前就已經誕生了，但是它在 IT 領域卻是一個新興事物。可觀察性在維基百科中原文是這樣定義的：「In control theory, observability is a measure of how well internal states of a system can be inferred from knowledge of its external outputs. 」。雲原生領域第一次出現這個詞，是在雲原生理念方興未艾的2017年，在雲原生的思潮之下，運用傳統的描述方式已經不足以概括這個時代的監控訴求，而 Observability 就顯得貼切許多。

回想一下傳統的監控方式，除去運維層面的主機監控、JVM 監控、消息隊列監控之外，有多少監控是事先就想好怎麼做的？很少！其實很多時候，我們做的事情就是在故障發生之後，對故障復盤的過程中，除了 bug 重現與修復，也會去定製加一些監控，以期望下次發生同樣的情況時有一個實時的告警。研發人員收到告警之後得以快速地處理問題，儘可能地減少損失。所以，傳統的監控模式大多都是在做亡羊補牢的事情，缺少一個主動性。

在雲原生時代的容器化體系當中就不一樣了，容器和服務的生命周期是緊密聯繫在一起的，加上容器完美的隔離特性，再加上 Kubernetes 的容器管理層，應用服務跑在容器當中就顯得更加地黑盒化，相較在傳統物理主機或者虛擬機當中，排查問題的時候顯得非常不便。所以在雲原生時代強調的是可觀測性，這樣的監控永遠都是兵馬未動而糧草先行的，需要提前想好我們要如何觀測容器內的服務以及服務之間的拓撲信息、各式指標的搜集等，這些監測能力相當重要。

關於可觀測性在雲原生領域是何時開始流行起來的，沒有一個很明確的時間。業界認為可觀測性最早是由 Cindy Sridharan 提出的，其實一位德國柏林的工程師 Peter Bourgon 早在2017年2月就已經有文章在討論可觀測性了，Peter 算是業界最早討論可觀測性的開發者，他寫的著名的博文《Metrics, Tracing, and Logging》被翻譯成了多種語言。真正可觀測性成為一種標準，是來自 Pivotal 公司的 Matt Stine 定義的雲原生標準，可觀測性位列其中，由此可觀測性就成為了雲原生時代一個標準主題。

Peter Bourgon 提出的可觀測性三大支柱圍繞 Metrics、Tracing 和 Logging 展開，這三個維度幾乎涵蓋了應用程序的各種表徵行為，開發人員通過收集並查看這三個維度的數據就可以做各種各樣的事情，時刻掌握應用程序的運行情況，關於三大支柱的理解如下：

Metrics：Metrics 是一種聚合態的數據形式，日常中經常會接觸到的 QPS、TP99、TP95 等等都屬於Metrics 的範疇，它和統計學的關係最為密切，往往需要使用統計學的原理來做一些設計；
Tracing：Tracing 這個概念幾乎是由 SOA 時代帶來的複雜性補償，服務化帶來的長調用鏈，僅僅依靠日誌是很難去定位問題的，因此它的表現形式比 Metrics 更複雜，好在業界湧現出來了多個協議以支撐 Tracing 維度的統一實現；
Logging：Logging 是由請求或者事件觸發，應用程序當中用以記錄狀態快照信息的一種形式，簡單說就是日誌，但這個日誌不僅僅是打印出來這麼簡單，它的統一收集、存儲以及解析都是一個有挑戰的事情，比如結構化(Structured)與非結構化(Unstructed)的日誌處理，往往需要一個高性能的解析器與緩衝器；

此外，Peter Bourgon 在博文中還提到了三大支柱結合態的一些理想輸出形式，以及對存儲的依賴，Metrics、Tracing、Logging 由於聚合程度的不同，對存儲依賴由低到高。更多細節，感興趣的同學可以查看文末的原文鏈接。

Peter Bourgon 關於可觀測性三大支柱的思考不止於此，他還在2018年的 GopherCon EU 的分享上面再次討論了 Metrics、Tracing 和 Logging 在工業生產當中的深層次意義，這次他探討了4個維度。

CapEx：表示指標初始收集成本，很明顯日誌的成本最低，埋點即可；其次是 Metrics，最難是 Tracing 數據，在有了協議支撐的情況下，依然要定義許多數據點，以完成鏈路追蹤必須的元數據定義收集；
OpEx：表示運維成本，一般指存儲成本，這個之前已經討論過；
Reaction：表示異常情況的響應靈敏度，顯然聚合之後的數據可以呈現出波動情況，因此 Metrics 是對異常情況最靈敏的；Logging 次之，也可以從 Logging 清洗之中發現異常量；而 Tracing 在響應靈敏度上面似乎沾不上邊，最多還是用在排障定位的場景；
Investigation：標準故障定位能力，這個維度是 Tracing 的強項，可以直觀看出鏈路當中的故障，精確定位；Logging 次之；Metrics 維度只能反饋波動，對定位故障幫助不大；

在 CNCF Landscape 當中，有一塊區域專門用作展示雲原生場景下的可觀測性解決方案，裏面又分為好幾個維度，圖中是截至2020年5月14日的最新版圖，未來還會有更多優秀的解決方案湧現出來。CNCF 目前畢業的10個項目庫當中，有3個是和可觀測性有關的，可見 CNCF 對可觀測性的重視程度。

談到這裡，很多同學也許對於可觀測性相關的協議比較感興趣。目前比較火的有好幾個，OpenTracing、OpenCensus、OpenTelemetry、OpenMetrics 等等，目前比較火的是前三個。OpenMetrics 這個項目已經不維護了。

OpenTracing 可以說是目前使用最廣的分佈式鏈路追蹤協議了，大名鼎鼎的 SkyWalking 就是基於它實現的，它定義了與廠商無關，與語言無關的鏈路追蹤協議 API，使得構建跨平台的鏈路追蹤成為一件比較輕鬆的事情，目前它在 CNCF 的孵化器當中茁壯成長。

OpenCensus 是谷歌提出的一個針對 Tracing 和 Metrics 場景的協議，背靠 Dapper 的加持與歷史背景，就連微軟也十分擁護，目前在商用領域十分流行。

其他的協議比如 W3C Trace Context，呼聲也很高，它甚至對數據在頭部進行了壓縮，與實現層無關。也許 CNCF 意識到各種協議又在層出不窮，以後各成氣候，群雄逐鹿，每一個中間件都要做許多兼容，這對整個技術生態本身不利，因此 OpenTelemetry 橫空出世。從字面意思就知道，CNCF 會將可觀測性的「遙測」進行到底，它融合了 OpenTracing 和 OpenCensus 的協議內容，旨在提高雲原生時代可觀測性指標的統一收集與處理，目前 OpenTelemetry 已經進入 beta 版本，其中令人欣喜的是，Java 版本的 SDK 已經有一個類似 SkyWalking 的基於 byte-buddy 框架的無侵入式探針。目前已經可以從47種 Java 庫當中自動探測獲取遙測數據，另外推出了可供使用的 Erlang、Go、Java、JavaScript、Python 的 API 和 SDK。此外，數據收集器 OpenTelemetry Collector 也可以使用了，可以用它接收 OpenTelemetry client 發射過來的數據，統一收集處理。目前 CNCF 對 Logging 相關的協議制定暫緩，但是有一個工作小組也在做這方面規範的事情。

Service Mesh 與可觀測性

要說 Service Mesh 與可觀測性的關係，那就是可觀測性是 Service Mesh 的功能子集。Service Mesh 是當今最為火爆的技術理念之一，它致力於為雲原生時代運行在容器當中的大規模服務提供統一的服務發現、邊緣路由、安全、流量控制、可觀測性等能力，它是對 Kubernetes 服務治理能力的補充強化。可以說，Service Mesh 是雲原生容器化時代的必然產物，它將對雲上服務架構產生深遠的影響。Service Mesh 的架構理念是將容器服務運行單元當成一個個網格，在每組運行單元中劫持流量，然後由一個統一的控制面板做統一處理，所有網格與控制面板維持一定的聯繫，這樣，控制面板就得以作為可觀測性解決方案與容器環境之間的橋樑。

市面上最為常見的 Service Mesh 技術有 Linkerd、Istio、Conduit 等，但是要在生產環境落地必須要經受住嚴苛的性能、合理的架構、社區活躍度的評估。

Linkerd 是由 Buoyant 開發維護，算是 Service Mesh 領域第一代的產品，Linkerd1.x 基於 Scala 編寫，可基於主機運行，大家都知道 Scala 運行環境依賴 JDK，因此對資源的消耗相對較大。隨後官方進行了整改，推出了新一代的數據平面組件 Conduit，基於 Rust 和 Go 編寫，與 Linkerd 雙劍合璧，成為 Linkerd2.x。總體來說，Linkerd2.x 性能有了較大的提升，也有可視化界面供操作，但是在國內就是不慍不火的，社區始終發展不起來。

轉頭看2017年出現的 Istio，也算是含着金湯匙出生的，由谷歌、IBM、Lyft 發起，雖然晚了 Linkerd 一年，但是一經推出，就受到廣泛的關注與追捧。Istio 基於 Golang 編寫，完美契合 Kubernetes 環境，數據平面整合 Envoy，在服務治理方面職責分明，國內落地案例相較 Linkerd 更加廣泛。

Istio 目前總體還算是一個年輕的開源中間件，大版本之間的組件架構有比較大的區別，比如 1.0 引入了Galley（如圖左），1.5 去掉了 Mixer，並且控制平面整合成單體，增加了 WASM 擴展機制（如圖右）。總體的架構形式沒有太大變化，數據面還是關注流量的劫持與轉發策略的執行，控制面依然做遙測收集、策略下發、安全的工作。目前國內業界對於 Istio 的使用上，雲商與頭部公司處於領先位置，比如螞蟻金服自研了自己基於 Golang 的數據平面 MOSN，兼容 Istio，做了許多優化工作，對 Istio 在國內落地做出了表率，更多的信息可以深入了解，看如何打造更適合國內互聯網的 Service Mesh 架構。

雖然在 1.5 版本當中 Mixer 已經基本被廢棄掉，進入維護階段直到 1.7 版本，默認情況下 Mixer 完全關閉，但是目前多數落地方案還是基於 1.0-1.4 這個版本區間，所以在沒有整體升級的情況下，以及 WASM 性能不明朗的似乎還，始終還是離不開 Mixer 的。前面說到 Service Mesh 是雲原生容器環境與可觀測性之間的橋樑，Mixer 的 Adapter 可以算得上是這個橋樑的鋼架主體了，並且具有良好的可擴展性。Mixer Adapter 除了為流量做 Check 之外，更重要的是在預檢階段和報告階段收集遙測數據，遙測數據通過 Adapter 暴露或發射數據到各種觀測端，觀測端基於數據繪製豐富的流量軌跡與事件快照。常用的用於可觀測性的 Adapter 有對各種商用方案的適配，比如 Datadog、New Relic 等，開源方案 Apache SKyWalking、Zipkin、Fluentd、Prometheus 等，相關內容會在下文展開。

數據平面比如 Envoy 會向 Mixer 上報日誌信息（Log）、鏈路數據（Trace），監控指標（Metric）等數據，Envoy 上報的原始數據都是一些屬性信息（Attributes），屬性信息是名稱和類型的元數據，用來描述入口和出口流量和流量產生時的環境信息，然後 Mixer 會依照 LogEntry、Metric 或者 TraceSpan 模板配置的格式對屬性進行格式化，最後再交給 Mixer Adapter 做進一步處理，當然對於數據量龐大的 Log 信息和 Trace 信息可以選擇直接上報處理端，Envoy 也原生支持一些特定組件。不同的 Adapter 需要不同的 Attributes，模板定義了 Attributes 到 Adapter 輸入數據映射的 schema，一個 Adapter 可以支持多個模板。Mixer 當中又可以抽象出三種配置模型：

Handler：表示一個配置好的 Adapter 實例；
Instance：定義 Attributes 信息的映射規則；
Rule：為 Handler 分配 Instance 以及觸發規則；

下圖是 Metric 模板與 LogEntry 模板，在映射關係之上還可以設定默認值，更多的設定可以查看官方文檔。

下圖是 TraceSpan 模板，熟悉 OpenTracing 的同學可能對映射內容比較熟悉，很多信息都是 OpenTracing 協議的標準值，比如 Span 的各種描述信息以及 http.method、http.status_code 等等，感興趣的同學也可以去看看 OpenTracing 的標準定義。另外在Service Mesh中對於鏈路追蹤普遍有一個問題，就是無論你在數據平面如何做流量劫持，如何透傳信息，以及如何生成或者繼承Span，入口流量和出口流量都有一個無法串聯的問題，這個問題要解決還是需要服務主容器來埋點透傳，將鏈路信息透傳到下一次請求當中去，這個問題是無法避免的，而OpenTelemetry的後續推行，可以解決這方面的標準化問題。

Istio 可觀測性實踐

在 Istio Mixer Adapter 當中我們可以獲知，Istio 支持 Apache SKyWalking、Zipkin、Jaeger 的鏈路追蹤，這三個中間件都支持 OpenTracing 協議，所以使用 TraceSpan 模板同時接入也沒有什麼問題。三者稍有不同的地方是：

Zipkin 算是老牌的鏈路追蹤中間件了，項目發起時間是2012年，新版的功能也比較好用；
Jaeger 是2016年發起的新興項目，使用 Go 編寫，但是由於雲原生的加持，致力於解決雲原生時代的鏈路追蹤問題，所以發展很快，它在 Istio 中集成極為簡易，也是 Istio 官方推薦的方案
SkyWalking 是2015年開始開源，目前正在蓬勃發展的一個項目，但是稍有不同的是，目前它與 Istio 的結合是通過進程外適配的方式，接入損耗稍微大一些，在最新的8.0版本（還未發佈）當中有相應的解決方案；

另外一個在雲原生鏈路追蹤領域收到廣泛使用的是中間件是 Jaeger，它是由 Uber 開源，被 CNCF 接納，目前已經是一個畢業項目。它原生支持 OpenTracing 協議，與市面上的其他中間件也具有互通性，支持多種後端存儲以及具備靈活的擴展性。在 Envoy 中原生支持 Jaeger，當請求到達 Envoy 的時候，Envoy 會選擇創建 Span 或繼承 Span，以保證鏈路的連貫性，它支持 Zipkin 的 B3 系列 Header 透傳，以及 Jaeger 與 LightStep 的 Header。下圖是 Jaeger 當中對鏈路的展示，可以通過 TraceId 準確定位某一次請求。

傳統的日誌解決方案，ELK 可以說是家喻戶曉的，從 Spring Cloud 盛行開始，它便是日誌解決方案的優良選擇。隨着技術的發展，近幾年又出現了 EFK 這種解決方案，存儲組件 ElasticSearch 和界面 Kibana 倒是沒有什麼特別大的變化，但是在嚴苛的線上環境與容器環境中，以及各種對資源敏感的場景下，對於日誌採集組件的要求也越來越高，目前比較流行的方案是使用 Fluentd 或者 Filebeat 替代 Logstash，下面是它們三者的一些介紹：

Logstash：Java 編寫，資源消耗大，現在一般不主張用作日誌採集；
Fluentd：主體由 C 編寫，插件由 Ruby 編寫，2019年4月從 CNCF 畢業，資源消耗非常小，通常佔用內存在30MB左右，可以將日誌發射到多個緩衝器，也就是多個接收端，目前在容器內比較常用的組件；
Filebeat：Go 編寫，但是線上出現過拉高底層資源 load average 的問題以及資源消耗較大，是 Fluentd 的10倍左右，在 Fluentd 出現之前，其被廣泛運用在虛擬機當中；

對於 Istio 中的日誌解決方案，儘管 Mixer 當中有提供 Fluentd Adapter，但是日誌的量級大家也知道，這種方式並不好，所以從 Envoy 去拿到原始的屬性日誌再進行加工發射到存儲端對應用是比較友好的，可以節省出很大一部分資源。

在日誌維度中，如果要定位問題，最好與請求綁定起來，而綁定請求與日誌，需要一個特定的標識，可以是 TransactionId 或者是 TraceId，所以鏈路追蹤與日誌融合是一個勢在必行的行業訴求，因此在選擇鏈路追蹤中間件的時候，一定要考慮到如何更好地獲取 TraceId 並與日誌結合起來。

那麼 Fluentd 就是最好的日誌收集和發射解決方案了嗎？

不是。Fluentd 的研發團隊又推出了更加輕量級的 Fluent Bit，它是使用純C編寫的，佔用資源更加少，從Fluentd 的 MB 級別直接降為 KB 級別，更加適合作為日誌收集器。而 Fluentd 插件種類非常繁多，目前共有接近上千種的插件了，所以它更適合作為日誌的聚合處理器，在日誌收集之後的加工與傳輸中使用。在實際應用中，使用 Fluent Bit 可能會遇到一些問題，使用比較早期的版本可能會有配置動態加載的問題，解決方法就是另起一個進程控制 Fluent Bit 的啟停，同時監聽配置的變化，有變化則 reload。

關於上圖中的 Loki，它的核心思想正如項目介紹，「Like Prometheus, but for logs」，類似於 prometheus 的聚合日誌解決方案，2018年12月開源，短短兩年，卻已有接近1萬個 Star 了！它由 Grafana 團隊開發，由此可以看出 Grafana 對於一統雲原生可觀察性的目的。

在雲原生時代，像以前那樣用昂貴的全文索引，如 ES，或者列式存儲，如 HBase，將大量的原始日誌直接存儲到昂貴的存儲介質之中的做法，似乎已經不太妥當。因為原始日誌99%是不會被查詢到的，所以日誌也是需要做一些歸併，歸併之後壓縮成 gzip，並且打上各式標籤，這樣可能會更加符合雲原生時代精細化運作的原則。

而 Loki 可以將大量的日誌存儲於廉價的對象存儲中，並且它為日誌打標歸併成日誌流的這種方式得以讓我們快速地檢索到對應的日誌條目。但是注意一點，想要使用 Loki 替代 EFK 是不明智的，它們針對的場景不一樣，對數據的完整性保證和檢索能力也有差別。

自從 Prometheus 出現以來，就牢牢佔據着監控指標的主要地位。Prometheus 應該是當前應用最廣的開源系統監控和報警平台了，隨着以 Kubernetes 為核心的容器技術的發展，Prometheus 強大的多維度數據模型、高效的數據採集能力、靈活的查詢語法，以及可擴展、方便集成的特點，尤其是和雲原生生態的結合，使其獲得了越來越廣泛的應用。

Prometheus 於2015年正式發佈，於2016年加入 CNCF，並於2018年成為第2個從 CNCF 畢業的項目（第一個是 Kubernetes，其影響力可見一斑）。目前 Envoy 支持 TCP 和 UDP statsd 協議，首先讓 Envoy 推送指標到 statsd，然後可以使用 Prometheus 從 statsd 拉取指標，以供 Grafana 可視化展示。另外我們也可以提供 Mixer Adapter，接收處理遙測數據供 Prometheus 採集。

在 Prometheus 的實際使用當中可能會存在一些問題，比如 pod 被殺掉需要另外啟一個，導致 Prometheus 數據丟失，這就需要一個 Prometheus 的數據可持久化的高可用方案。CNCF 的沙箱項目裏面有一個項目叫做 Thanos，它的核心思想相當於是在 Prometheus 之上做了一個類似數據庫 sharding 的方案，它有兩種架構模式：Sidecar 與 Receiver。目前官方的架構圖用的 Sidecar 方案，Receiver 是一個暫時還沒有完全發佈的組件，Sidecar 方案相對成熟一些，更加高效也更容易擴展。

Service Mesh 解決方案當中的 Linkerd 和 Conduit 都有可視化界面。Istio 相對來說比較黑盒，一直被詬病，不過 Istio 社區聯合 Kiali，共同推出了一個可視化方案，提供如下功能：

Topology：服務拓撲圖；
Health：可視化健康檢查；
Metrics：指標可視化；
Tracing：分佈式鏈路追蹤可視化；
Validations：配置校驗；
Wizards：路由配置；
Configuration：CRD 資源的可視化與編輯；

下面是 Kiali 的架構，可以比較清楚地看出，其本身是一個前後端分離的架構，並且可以從 Prometheus 或者集群特定 API 獲取指標數據，另外也囊括了 Jaeger 鏈路追蹤界面與 Grafana 展示界面，不過它們並非開箱即用，Kiali 依賴的三方組件需要單獨部署。

總結

在許多的中小型公司內部，其實 Service Mesh 還是處於一個預研階段，實際落地的時候需要考慮的因素繁多，如何才能獲得較好的的投入產出效能比，是每一個做選型的人員都必須要經歷的。其實不管落地情況，鑒於雲原生的可觀察性哲學來說，在落地的同時做好可觀察性，可以同步解決很多問題，避免耗費過多的資源在無意義的事情上面，綜合可觀察性的三大支柱以及 Service Mesh 中對可觀察性的支持來說，總結如下：

Metrics：合理運用 Prometheus，並且做好持久化與高可用工作是關鍵；
Tracing：選擇合適的鏈路追蹤中間件，關鍵在於集成契合度、整合 Logging、存儲、展示來考量；
Logging：什麼場景使用原始日誌，什麼場景使用摘要日誌，要明確；

觀測雲——快速實現系統可觀測

當前，雲計算市場對系統的可觀測性需求龐大，但真正具備可觀測性的統一實時監測產品卻寥寥無幾。作為國內首批一體化系統可觀測平台——觀測雲，能快速實現系統可觀測，統一滿足您雲、雲原生、應用及業務上的監測需求。

觀測雲是新一代一體化數據平台，與傳統方案完全不同。支持全場景監測，全面數據驅動，用數字化手段全力保障項目團隊方案，保障系統可靠性、穩定性。

觀測雲自問世以來，一直廣受業內高度關注和市場好評，活躍用戶數持續飛速增長。2022年4月，觀測雲首批通過中國信通院《可觀測性平台技術能力》「先進級」評估（最高級），晉級為國內可觀測性SaaS服務賽道內領軍品牌。4月28日，「2022觀測雲產品發佈會」上，觀測雲強調會加大投入到SRE理念在國內的傳播與實踐，及對新一代可觀測性技術的推廣普及。社區版的發佈，是觀測雲踐行承諾的重要舉措之一，繼觀測雲SaaS版之後，部署版也開放免費體驗。