[[412676]]

可觀測性（ Observability ）主要是指了解程序內(nèi)部運(yùn)行情況的能力。我們不希望應(yīng)用發(fā)布上線后，對應(yīng)用的內(nèi)部一無所知。對于我們來說，整個(gè)應(yīng)用就是一個(gè)黑盒子。即便應(yīng)用出現(xiàn)錯(cuò)誤或者發(fā)生崩潰，我們也可以得到崩潰前的所有相關(guān)數(shù)據(jù)，這也是飛機(jī)黑匣子（ Flight Recorder ）設(shè)計(jì)的出發(fā)點(diǎn)，如 圖1 所示。

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

目前，關(guān)于可觀測性的架構(gòu)設(shè)計(jì)主要涉及三個(gè)部分：日志（logging）、度量（Metrics）和追蹤（Tracing）。下面就從這三個(gè)方面詳細(xì)闡述可觀測性架構(gòu)的設(shè)計(jì)。

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

度量

Aliware

度量不僅包括 CPU 負(fù)載、內(nèi)存使用量等技術(shù)指標(biāo)的度量，還包括非常多的業(yè)務(wù)度量（ Business Metrics ），如每分鐘的交易額、每分鐘會(huì)員登錄數(shù)等。對于這些業(yè)務(wù)度量參數(shù)，我們在做架構(gòu)設(shè)計(jì)的時(shí)候，需要以參考指標(biāo)的方式全部羅列出來，以便于觀測上線后的數(shù)據(jù)，并做出相應(yīng)的業(yè)務(wù)決策。

這里可能會(huì)有讀者產(chǎn)生疑問，我們已經(jīng)使用日志記錄了相關(guān)的數(shù)據(jù)，數(shù)據(jù)庫中也保存了最終的數(shù)據(jù)，為什么還要增加對數(shù)據(jù)的記錄？為了解答這個(gè)問題，我們首先看一下如下區(qū)別。

第一，日志記錄的是發(fā)生在某個(gè)時(shí)間點(diǎn)的事情，其中包含非常多的細(xì)節(jié)，可以說是事無巨細(xì)的。

第二，數(shù)據(jù)庫記錄的是當(dāng)前數(shù)據(jù)的最新快照，我們通常不會(huì)關(guān)注中間的過程，如電商網(wǎng)站的商品價(jià)格可能經(jīng)過多次調(diào)整，但數(shù)據(jù)庫通常只會(huì)記錄商品的最新價(jià)格。

第三，度量統(tǒng)計(jì)的是一個(gè)窗口期的聚合數(shù)據(jù)，可以是平均值，也可以是累計(jì)值。如果是 CPU 負(fù)載，就統(tǒng)計(jì)一段時(shí)間的平均值；如果是 1 分鐘內(nèi)交易的訂單數(shù)，就需要統(tǒng)計(jì)累計(jì)值。還有一類比較特殊，就是那些沒有時(shí)間區(qū)間的情況，如計(jì)數(shù)器等，在應(yīng)用啟動(dòng)后的整個(gè)運(yùn)行期間，它的值會(huì)不停地累加，在應(yīng)用重啟后它會(huì)被重新計(jì)算。

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

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

典型的度量指標(biāo)主要由以下 5 個(gè)部分組成：

1）名稱：因?yàn)槎攘恐笜?biāo)的名稱要表達(dá)其代表的意思，所以最好采用命名空間級聯(lián)的方式，可以使用類似域名的“ . ”分隔，或者使用 Prometheus 中采用的“ _”分隔。

2）時(shí)間點(diǎn)：采集度量的時(shí)間點(diǎn)，通常由度量框架自動(dòng)設(shè)置。

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

4）類型：典型的類型分別為計(jì)數(shù)器、直方圖、平均比率、計(jì)時(shí)器、計(jì)量表等。

5）標(biāo)簽：主要包括一些元信息，如來源服務(wù)器標(biāo)識、應(yīng)用名稱、分組信息、運(yùn)行環(huán)境等。標(biāo)簽是為了方便后續(xù)的度量查詢和再聚合處理。

當(dāng)以上信息保存到 Prometheus 等度量系統(tǒng)后，我們可以根據(jù)上述結(jié)構(gòu)進(jìn)行查詢。PromQL 是 Prometheus 提供的度量查詢語言。

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

1）閾值預(yù)警：當(dāng)某一度量指標(biāo)的值低于或高于某一預(yù)設(shè)值時(shí)，就會(huì)觸發(fā)警報(bào)。例如，CPU 的負(fù)載、業(yè)務(wù)上的度量值跌至零，這些都會(huì)觸發(fā)預(yù)警。

2）同期數(shù)據(jù)對比：在某些場景下，通過絕對值判斷是不能發(fā)現(xiàn)系統(tǒng)問題的，比如，一個(gè)電商網(wǎng)站每天不同時(shí)段的交易額是有差別的，所以比對每周同一天同一時(shí)段的數(shù)據(jù)來判斷問題會(huì)更加精確。

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

回到實(shí)際的應(yīng)用開發(fā)，大多數(shù)云廠商也提供了度量集成化服務(wù)，如阿里云的Prometheus 服務(wù)。在程序中，我們基本上只需要直接對接即可，諸如度量指標(biāo)的采集、存儲(chǔ)、監(jiān)控、告警、圖表展現(xiàn)等數(shù)據(jù)監(jiān)控服務(wù)。

追蹤

Aliware

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

首先，讓我們看一下追蹤系統(tǒng)的基本元素。

1.  traceId

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

2.  spanId

spanId 用于在一個(gè)追蹤鏈中記錄一個(gè)跨時(shí)間段的操作。例如，我們訪問數(shù)據(jù)庫或者進(jìn)行 RPC 調(diào)用的過程，就對應(yīng)于一個(gè) spanId。在一個(gè)區(qū)間（span）中，ID 的作用是便于識別。ID 通常是一個(gè) 64 位的 long 型數(shù)值，名稱的作用是便于用戶了解是什么操作，起始時(shí)間和結(jié)束時(shí)間的作用是便于了解操作時(shí)長。另外，區(qū)間還可以包含其他元信息。總的來說，一個(gè)追蹤鏈?zhǔn)怯啥鄠€(gè)區(qū)間組成的。區(qū)間提供具體的操作信息。區(qū)間的生成會(huì)涉及應(yīng)用中的代碼，我們稱之為區(qū)間的埋點(diǎn)。

3.  parentId

在追蹤鏈中，我們可能需要對一些區(qū)間進(jìn)行分組，如將某一應(yīng)用內(nèi)部的多個(gè)區(qū)間歸在一起，這樣就可以了解該應(yīng)用在整個(gè)調(diào)用鏈中消耗的時(shí)間。其解決方案是為區(qū)間添加parentId，將不同類別的區(qū)間歸在一起。通常，我們在進(jìn)入一個(gè)應(yīng)用時(shí)會(huì)進(jìn)行 parentId 的設(shè)置。例如，進(jìn)入會(huì)員登錄應(yīng)用時(shí)會(huì)設(shè)置一個(gè) parentId，在進(jìn)入賬號驗(yàn)證服務(wù)時(shí)會(huì)設(shè)置一個(gè) parentId ，這樣我們就能根據(jù)不同的應(yīng)用對區(qū)間進(jìn)行歸類。在同一個(gè)應(yīng)用內(nèi)部，我們還可以基于應(yīng)用的 parentId 設(shè)置子 parentId。如果想要?dú)w類數(shù)據(jù)庫相關(guān)的操作，則將操作全部列在數(shù)據(jù)庫的 parentId 下。

追蹤鏈可以將整個(gè)請求在不同應(yīng)用和系統(tǒng)中的操作信息串聯(lián)起來。我們只要輸入traceId ，就可以在追蹤系統(tǒng)中了解整個(gè)調(diào)用鏈的詳細(xì)信息。那么，在不同的應(yīng)用和系統(tǒng)中，路徑和區(qū)間信息又是如何采集的呢？Zipkin 是一款知名的路徑跟蹤產(chǎn)品，其中 Brave SDK 可以實(shí)現(xiàn)路徑和區(qū)間信息的采集。Brave SDK 負(fù)責(zé)創(chuàng)建路徑和區(qū)間，同時(shí)將這些信息異步上報(bào)給 Zipkin，完成追蹤鏈的數(shù)據(jù)采集工作。由于路徑和區(qū)間信息的采集是通過遠(yuǎn)程調(diào)用實(shí)現(xiàn)的，因此這個(gè)采集過程一定要是異步實(shí)現(xiàn)的，只有這樣，才能確保不會(huì)影響到正常的業(yè)務(wù)操作。最典型的采集方法就是對接 gRPC、Kafka 和 RSocket 等異步協(xié)議或系統(tǒng)，以確保數(shù)據(jù)的采集全部是異步的。

事件流訂閱

Aliware

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

基于 JFR 開啟實(shí)時(shí)事件流訂閱的好處是，我們不需要關(guān)心額外的開銷對系統(tǒng)性能的影響，因?yàn)?JFR 的設(shè)計(jì)對系統(tǒng)額外開銷的影響已經(jīng)降到了非常低，只有不到 1%，比日志對系統(tǒng)的影響還要小。這就意味著在生產(chǎn)環(huán)境中，我們可以隨時(shí)快速開啟事件流監(jiān)控。

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