觀察之道：帶你走進可觀察性

今年，「可觀察性」（Observability）被引入到了 IT 領域。可觀察性是一套理念系統。其重點是團隊要融入可觀察性的理念，特別是要求研發寫出的應用是可觀察的。將可觀察性包含在你的需求之中，它是與擴展性，可用性同等重要的非業務性需求。

一個故事

距離倫敦 150 英里的地方有一座農莊，笨笨的農夫養著一大群動物。農場中的動物們雖然打打鬧鬧，但是每當農夫出現，這群聰明的動物馬上就會乖起來。「為什麼呢？爸爸」我女兒每次聽到這裡都會問這個問題，「因為如果農夫能看見他們幹壞事，就會不給他們東西吃」。

而在倫敦，農夫的兒子經營著一家十幾個人的小電商網站。雖然他比他老爸聰明多了，但軟體公司的秩序比農場要混亂百倍。客戶的訂單經常無法正常流轉，而所有人花了兩周時間也不知道問題出在哪裡。

「這個就更奇怪了，他可比他老爸聰明多了？」女兒貌似陷入了更深的疑惑，「如果他看不出來誰在幹壞事，再聰明的人也沒有辦法！」

當然第二個故事是我編的，我女兒根本不知道什麼是電商。但聰明的讀者，你們會理解這個故事的。

觀察

農夫的兒子不會想到，目前一個新的理念悄然來臨，或許可以解決他現實的問題。

今年，「可觀察性」（Observability）被引入到了 IT 領域，其首先表現為 CNCF-Landscape 出現了 Observability 分組。

從該分組的內容看包含了監控，日誌，Tracing 等領域的項目。同時 o11y 大會等該領域的專業會議也已經排上了日程表。

彷彿一夜之間這個概念已經沸沸揚揚，但一個尷尬的現象卻擺在眼前，目前沒有一個人能清楚的解釋這個概念，並定義它的邊界。對於一個全新的概念，人們傾向於從之前的認知來定義它。而在可觀察性之前，我們常常使用「監控」這個概念。可觀察性與監控有什麼不同？簡單說來，後者是前者的一個子集。監控關注系統的失敗因素，從而定義出系統的失敗模型。它的核心是運維，是監控設施。他們站在局外人的角度，去審視系統的運行情況。而可觀察性除了關註失敗之外，其核心是研發，是應用，是對系統的一種自我審視。是站在創造者的角度去探究系統應如何恰當的展現自身的狀態。一個由外向內，一個由內向外。所以可觀察性並不是新生物，而是一種觀念創新。

一個可觀察的系統應包含三個關鍵詞，應用，主動，關聯。應用表明我們關注的不是機器，不是網路這些間接證據，而是關注應用本身的狀態。我們關注應用真實的吞吐，延遲，而不是從網關上去推測這些指標。而主動是觀測的一個核心，它相對於被動更能暴露出問題的實質，後者只能回答 What，而前者可以回答 Why。現如今，微服務大行其道，工程師僅僅關注「點」的問題已經不夠了。點線面，甚至與點線面體的結合才能應對當今的挑戰。

觀察之源

一個新物種，肯定有它的起源。從原點出發，我們可以知道它為什麼是如今的模樣。

可觀察性進入人們的視野是來自於 Apple 的工程師 Cindy Sridharan 的博文「監控與觀察」（Monitoring and Oberservability）。其中重點闡述了監控與觀察的關係，觀察的特點等重要的理念。隨後 Zipkin 的 PL Adrain Cole 也從 Zipkin 的角度談了可觀察性的實踐方法。

但我認為，Google 著名的 SRE 體系在以上大佬之前已經奠定了可觀察性的理論基礎。該體系中在監控領域 (是的，當時還沒有可觀察性這個概念)，特彆強調白盒監控的重要性，而將當時技術圈常用的黑盒監控放在了相對次要的位置。而白盒監控正是應和了可觀察性中「主動」的概念。

正因為 SRE 在整個雲原生運動中的突出地位，越來越多的團隊意識到，應該從系統建設之初去主動的規劃監控指標。特別在一些強調自己雲原生特性的項目，如 linkerd，traefik 等， 會主動設計可觀測系統內部狀況的入口。這些入口包括但不限於，Promethues 的 endpoint，Zipkin 協議的支持等。

觀察之法

相信大家對可觀察性已經了初步的認識，現在我來進一步解釋如何在你的團隊中應用它。

可觀察性是一套理念系統。

其重點是團隊要融入可觀察性的理念，特別是要求研發寫出的應用是可觀察的。將可觀察性包含在你的需求之中，它是與擴展性，可用性同等重要的非業務性需求。

這讓我想起了 TDD 和極限編程流行的年代，重要的不是單元測試本身，而是對研發流程的治理。而將可觀察性納入到需求也是對產品的挑戰，因為這項需求並不是業務需求，產品經理會非常輕視它。而我認為架構師和資深工程師應該肩負起將可觀察性融入團隊則責任，因為只有他們才會清醒的認識到它對系統的重要意義。

打造可觀察性系統可以通過以下三個手段：

1.Logging，展現的是應用運行而產生的事件，可以詳細解釋系統的運行狀態，但是存儲和查詢需要消耗大量的資源。所以往往使用過濾器減少數據量。

2.Metrics，是一種聚合數值，存儲空間很小，可以觀察系統的狀態和趨勢，但對於問題定位缺乏細節展示。這個時候使用等高線指標等多維數據結構來增強對於細節的表現力。

3.Tracing，面向的是請求，可以輕鬆分析出請求中異常點，但與 logging 有相同的問題就是資源消耗較大。通常也需要通過採樣的方式減少數據量。三種形式的組合使用將會產生豐富的觀察數據。

其次可視化也是可觀察性中比較強調的一點，這是由人類大腦傾向於形象思維所決定的。一行一行的系統指標數據根本不會比一張系統拓撲圖更直觀。直觀的圖形將幫助人們跟容易理解系統，發現問題。同時圖形的大量引入也會減少人的疲勞感，增強趣味性。想像一下使用系統如同在玩一款即時戰略遊戲，那該是多每秒的一種體驗。而大屏幕最近變得越來越流行，這也是對可視化有了更高的要求。對於相關觀察數據來說，Tracing 和服務關係的可視化是觀察系統的設計重點與難點。

最後是報警，報警在監控的體系是用於提示系統異常。而在觀察的體系下，更多了一層過濾繁雜信息的作用。設想一下在一個超過 1000 個節點的環境中存在大量的觀察指標，究竟人們需要關注什麼？而通過對報警規則的設置，從而提示出需要注意的一些特殊的事件，而這些事件往往成為影響系統穩定的關鍵因素。

接下來是具體工具的介紹，Zipkin，Jaeger 等關注與 Tracing 領域。fluentd，elk 等等是 logging 領域的典型代表。而 promethues，grafana，influxdb 則是 Metrics 領域的前去。而我所在的 Apache Skywalking 則是融合了 Tracing 和 Metrics，目標是最大限度的實踐可觀察性的理念。

觀察之道

「道」的理念是強調事物的本源，如果我們僅僅被「可觀察性」帶來的外部工具這個表象所吸引，而沒有認識到其內在的驅動動力，就很容易在實踐「可觀察性」時犯錯誤。

首先可觀察性帶來了團隊文化的轉變，讓我以 DevOps 做一個類比。DevOps 中一個重要的概念是強調研發與運維的無縫配合，從而形成一個整體。而可觀察性的語境下，研發是主體，他首先需要主動考慮如何將應用的那些關鍵指標以什麼形式暴露出去。而之前大部分研發只有在應用出現故障的時候，才會考慮在什麼位置加個日誌看看。這是巨大的進步，將研發與運維的關係從 Tom 和 Jerry 轉換為了海爾兄弟。你看，這是一幅多麼美妙的情景啊！

其次，可觀察性有利於系統的生長，工程師之間流傳這樣一句名言：系統不是設計出來的，而是長出來的。而掌握了觀察之法，人們會了解到系統目前的實際情況，系統不再是一張靜態的架構圖，而是一個鮮活的生命體。從現在的位置出發，大家會有無限的靈感來打造系統的生長方向。甚至基於大數據與人工智慧可以模擬採用哪種方向會帶來更好的結果。這種交互設計方式將給整個 IT 產業帶來革命性的變化。

最後，觀察會帶來外部的關注。有這樣一個故事，有一家互聯網公司使用 Skywalking 的一大目的就是利用其應用拓撲圖的功能，向投資人解釋該公司的技術實力。這非常震撼，可觀察性降低了人們理解系統的門檻，從而獲得更多的關注，而關注本身就是一種稀缺資源。同時如果各方都能對系統有一些理解，那麼產品與研發，運營與研發的關係我覺得可以更加和諧。

故事的結局

回到最開始的故事，農夫的兒子需要一雙觀察之眼好好的審視系統的情況。希望他也能如他父親一樣，可以容易的管理他自己的 Cat 和 Cattle 們。

作者簡介：

高洪濤 Bitmain，資深工程師

原華為技術專家，目前為 Apache SkyWalking (incubating) PMC。開源達人，曾參與 Sharding-JDBC，Elastic-Job 等知名開源項目。對區塊鏈，分散式資料庫，容器調度，微服務，ServicMesh 等技術有深入的了解。

活動推薦

喜歡這篇文章嗎？立刻分享出去讓更多人知道吧！