[[412676]]

可觀測性（ Observability ）主要是指了解程序內部運行情況的能力。我們不希望應用發布上線后，對應用的內部一無所知。對于我們來說，整個應用就是一個黑盒子。即便應用出現錯誤或者發生崩潰，我們也可以得到崩潰前的所有相關數據，這也是飛機黑匣子（ Flight Recorder ）設計的出發點，如 圖1 所示。

圖1 飛行記錄儀之日志、度量和追蹤

目前，關于可觀測性的架構設計主要涉及三個部分：日志（logging）、度量（Metrics）和追蹤（Tracing）。下面就從這三個方面詳細闡述可觀測性架構的設計。

通常，我們不用考慮日志處理的問題，畢竟日志處理技術經過長時間的發展，目前已經非常成熟，幾乎所有的編程語言都有對應的日志框架。目前，云廠商基本上都會提供日志服務，對接非常簡單，或者自行安裝成熟的日志處理系統，如 ElasticStack 等。

度量

Aliware

度量不僅包括 CPU 負載、內存使用量等技術指標的度量，還包括非常多的業務度量（ Business Metrics ），如每分鐘的交易額、每分鐘會員登錄數等。對于這些業務度量參數，我們在做架構設計的時候，需要以參考指標的方式全部羅列出來，以便于觀測上線后的數據，并做出相應的業務決策。

這里可能會有讀者產生疑問，我們已經使用日志記錄了相關的數據，數據庫中也保存了最終的數據，為什么還要增加對數據的記錄？為了解答這個問題，我們首先看一下如下區別。

第一，日志記錄的是發生在某個時間點的事情，其中包含非常多的細節，可以說是事無巨細的。

第二，數據庫記錄的是當前數據的最新快照，我們通常不會關注中間的過程，如電商網站的商品價格可能經過多次調整，但數據庫通常只會記錄商品的最新價格。

第三，度量統計的是一個窗口期的聚合數據，可以是平均值，也可以是累計值。如果是 CPU 負載，就統計一段時間的平均值；如果是 1 分鐘內交易的訂單數，就需要統計累計值。還有一類比較特殊，就是那些沒有時間區間的情況，如計數器等，在應用啟動后的整個運行期間，它的值會不停地累加，在應用重啟后它會被重新計算。

雖然日志可以計算出一些數據，如訂單數、訂單金額等，但這里需要考慮數據分析的成本和實時性，以更好地實現計算資源、存儲節約和快速查詢等。而度量統計的是窗口期的數據，所以不需要再次計算，從而節約了計算資源；同時也不需要保存窗口期中每一條具體的數據，因此可以節約存儲資源；從用戶角度來說，由于數據經過了窗口期的預處理，因此查詢響應的速度也會更快。

總體來說，度量部分處理的是可觀測性數據中的垂直場景。當我們更關注某一窗口期的聚合數據，同時關注點主要聚焦于數據的趨勢和對比時，度量剛好能夠滿足這類需求。

典型的度量指標主要由以下 5 個部分組成：

1）名稱：因為度量指標的名稱要表達其代表的意思，所以最好采用命名空間級聯的方式，可以使用類似域名的“ . ”分隔，或者使用 Prometheus 中采用的“ _”分隔。

2）時間點：采集度量的時間點，通常由度量框架自動設置。

3）數字值：度量值只能為數字值，不能為字符串等其他值。

4）類型：典型的類型分別為計數器、直方圖、平均比率、計時器、計量表等。

5）標簽：主要包括一些元信息，如來源服務器標識、應用名稱、分組信息、運行環境等。標簽是為了方便后續的度量查詢和再聚合處理。

當以上信息保存到 Prometheus 等度量系統后，我們可以根據上述結構進行查詢。PromQL 是 Prometheus 提供的度量查詢語言。

最后為大家介紹基于度量系統的一些預警規則。預警規則非常豐富，下面列舉幾條以方便大家參考：

1）閾值預警：當某一度量指標的值低于或高于某一預設值時，就會觸發警報。例如，CPU 的負載、業務上的度量值跌至零，這些都會觸發預警。

2）同期數據對比：在某些場景下，通過絕對值判斷是不能發現系統問題的，比如，一個電商網站每天不同時段的交易額是有差別的，所以比對每周同一天同一時段的數據來判斷問題會更加精確。

3）趨勢預警：主要是針對計數器類型設置的預警，如果度量數值出現激增或驟降，或者游離在正常的曲線趨勢之外，就需要引起我們的注意。

回到實際的應用開發，大多數云廠商也提供了度量集成化服務，如阿里云的Prometheus 服務。在程序中，我們基本上只需要直接對接即可，諸如度量指標的采集、存儲、監控、告警、圖表展現等數據監控服務。

追蹤

Aliware

微服務架構后基本上是分布式的架構設計。一個簡單的 HTTP 請求可能涉及 5 個以上應用，一旦出現問題，就會很難快速定位。例如，用戶反饋會員登錄非常慢，基本要花費 5 秒以上的時間，這種情況該如何定位問題所在？定位問題涉及登錄的 Web應用、賬號驗證服務、會員信息服務、登錄的安全監控系統，還涉及 Redis、數據庫等。如果沒有一個高效的追蹤系統，排查定位問題的復雜度可想而知。

首先，讓我們看一下追蹤系統的基本元素。

1.  traceId

traceId 用來標識一個追蹤鏈，如一個 64 位或 128 位長度的字符串。不同追蹤鏈的 traceId 不同。但在某一個追蹤鏈中，traceId 始終保持不變。traceId 通常在請求的入口處生成。如對于 HTTP 請求，traceId 基本上在網關層生成，也可以延后到具體的 Web 應用中生成。在產品環境中，并不是所有的請求都要啟動追蹤。我們只會采樣部分請求，如只會追蹤 2% 的請求，這樣做主要是考慮到追蹤對整個系統會造成額外的開銷。當然，在測試環境中，為便于排查問題，建議所有請求都開啟追蹤。

2.  spanId

spanId 用于在一個追蹤鏈中記錄一個跨時間段的操作。例如，我們訪問數據庫或者進行 RPC 調用的過程，就對應于一個 spanId。在一個區間（span）中，ID 的作用是便于識別。ID 通常是一個 64 位的 long 型數值，名稱的作用是便于用戶了解是什么操作，起始時間和結束時間的作用是便于了解操作時長。另外，區間還可以包含其他元信息。總的來說，一個追蹤鏈是由多個區間組成的。區間提供具體的操作信息。區間的生成會涉及應用中的代碼，我們稱之為區間的埋點。

3.  parentId

在追蹤鏈中，我們可能需要對一些區間進行分組，如將某一應用內部的多個區間歸在一起，這樣就可以了解該應用在整個調用鏈中消耗的時間。其解決方案是為區間添加parentId，將不同類別的區間歸在一起。通常，我們在進入一個應用時會進行 parentId 的設置。例如，進入會員登錄應用時會設置一個 parentId，在進入賬號驗證服務時會設置一個 parentId ，這樣我們就能根據不同的應用對區間進行歸類。在同一個應用內部，我們還可以基于應用的 parentId 設置子 parentId。如果想要歸類數據庫相關的操作，則將操作全部列在數據庫的 parentId 下。

追蹤鏈可以將整個請求在不同應用和系統中的操作信息串聯起來。我們只要輸入traceId ，就可以在追蹤系統中了解整個調用鏈的詳細信息。那么，在不同的應用和系統中，路徑和區間信息又是如何采集的呢？Zipkin 是一款知名的路徑跟蹤產品，其中 Brave SDK 可以實現路徑和區間信息的采集。Brave SDK 負責創建路徑和區間，同時將這些信息異步上報給 Zipkin，完成追蹤鏈的數據采集工作。由于路徑和區間信息的采集是通過遠程調用實現的，因此這個采集過程一定要是異步實現的，只有這樣，才能確保不會影響到正常的業務操作。最典型的采集方法就是對接 gRPC、Kafka 和 RSocket 等異步協議或系統，以確保數據的采集全部是異步的。

事件流訂閱

Aliware

日志記錄、度量和路徑追蹤是實現可觀測性架構模式的三大保證。但是在一些場景中，還存在其他非常精巧的設計，如 Java 飛行記錄器（Java Flight Recorder，JFR）。與前三者不太一樣的是，這是一種基于事件流（Event  Stream）的推送設計。我們可以在應用中定義各種 JFR 事件，并在業務流程中觸發這些事件。與日志記錄不太一樣的是，JFR 事件可能并不需要像 CPU 負荷那樣被持久化記錄下來并保存到日志文件中，而是在用戶對這些事件感興趣時才通過訂閱來開啟這些事件的采集，我們暫且稱之為事件流訂閱。與日志分析相比，這種方式更靈活，隨時開啟、隨時分析、隨時退出，而且完全是實時的。

基于 JFR 開啟實時事件流訂閱的好處是，我們不需要關心額外的開銷對系統性能的影響，因為 JFR 的設計對系統額外開銷的影響已經降到了非常低，只有不到 1%，比日志對系統的影響還要小。這就意味著在生產環境中，我們可以隨時快速開啟事件流監控。

在 Java14 中，JFR 有了進一步的提升和改進，包括性能優化、自定義事件 API 和流式訂閱等，這些都使得 JFR 的使用變得更加容易。在最新的 JDK15 中，JFR 的事件類型數量高達157個，如 CPU 負載（jdk.CPULoad）、Thread 啟動（jdk.ThreadStart）、文件讀取（jdk. FileRead）、Socket 讀取（jdk.SocketRead）等。這些都有事件記錄，對監控的幫助也非常大。但 JFR 只針對 Java 平臺，如果某個項目是基于 Java 的，那么 JFR 就可以很好地提升系統的可觀測性。最新的 JUnit5.7 版本也已經默認支持 JFR 的特性。