，有趣實用的分散式架構頻道。

本文根據 SOFAChannel#6 直播分享整理，主題《輕量級監控分析系統 SOFALookout 原理講解和功能演示》。

 

回顧影片以及 PPT 檢視地址見文末。歡迎加入直播互動釘釘群：23195297，不錯過每場直播。

大家好，我是來自螞蟻金服響風，SOFALookout 的開源負責人。本期 SOFAChannel 我給大家帶來主題是《輕量級監控分析系統 SOFALookout 原理講解和功能演示》的分享。本期的講解內容如下將從以下四個部分展開：

• 監控預警基本概念介紹

• SOFALookout 的客戶端使用（包括系統設計簡介與實現）

• SOFALookout 的服務端使用（包括系統設計簡介與實現）

• SOFALookout 發展規劃

歡迎大家 Star 我，SOFALookout：

https://github.com/sofastack/sofa-lookout

1 監控預警基本概念介紹

1.1 什麼是 SOFALookout

現在我們開始第一部分，先介紹一些基本概念。6 月初，SOFALookout 服務端開源，具體內容可以檢視相關文章：螞蟻金服輕量級監控分析系統 SOFALookout 服務端開源，SOFALookout 客戶端在之前也已經開源。目前整個系統是真正地可以玩轉起來的，這裡先介紹一下 SOFALookout。

SOFALookout 是螞蟻金服開源的一款解決系統的度量和監控問題的輕量級中介軟體服務。開源版本只提供對 Metrics 的處理部分：涵蓋 Metrics 資料的產生，也就是 Metrics 的埋點、收集、加工、儲存與查詢等一系列服務。

1.2 Metrics 的前置知識

介紹一些 Metrics 的前置知識：

第一是時序資料，比較正式的解釋是“基於穩定頻率持續產生的一系列指標監測資料”。簡單說橫軸是時間，縱軸是數值的情況下，第一印象可以做成走勢圖的資料通常就是時序資料。比如 2009 年到 2018 年每年雙十一天貓的成交額，就構成了時序資料。

第二是標簽（Tag），它用於表明指標項監測針對的具體物件。還是以剛才的成交額為例子，其實我們要監測的指標是“成交額”，但是“成交額”並沒有標明要監測的物件，即誰的成交額，哪個省的成交額，也就是缺少“定語”。標簽的作用就相當於是“定語”。比如“天貓的 浙江省的 成交額”，在程式碼中通常會有鍵值對來描述，比如 type=”天貓”，province=”浙江”。

第三是時序資料庫，即專門為存查時序資料而設計的資料管理系統。主要有以下幾個特點：

• 寫多讀少

• 資料多維度，無 schema，需要多維度查詢或聚合

• 通常無刪除和更新操作， 或受限

以下是一些常見的開源時序資料庫：

• Graphite

• InfluxDB

• OpenTSDB

• Prometheus

由於篇幅關係，就不一一介紹了。

1.3 傳統 Metrics 和 Metrics 2.0 的對比

下麵再來看一下傳統 Metrics 和 Metrics 2.0 的對比。

1.3.1 傳統 Metrics

傳統 Metrics 是我對它的稱呼，簡單來說它只有 Name 和 Value，沒有顯式的 Tags 概念。比如 “temperature = 29″，溫度=29，當然這裡都省略了時間戳。這個運算式並沒有指出監測物件，傳統 Metrics 的做法是，將監測物件的資訊編碼到 Name 裡，因此可能就變成了 “temperature.hangzhou=29″。這裡是有一些隱式的 Tags 資訊的，只是被編碼到 Name 裡了。

這種做法會導致一個問題，來看一個例子：shanghai.host1.foo.exporter.bar 。 只看這個名字的話幾乎很難知道這個 Metrics 統計的是什麼。這是因為它並沒有把欄位對應的 Key 編碼到名字裡，所以在缺少一些背景關係的情況下，我們很難讀懂它的含義。

另外，欄位的順序也是很重要的，不能寫錯，這是因為編碼到 Name 裡的只有 Tag 的 Value，Key 不在裡面，於是又有了另外一種編碼方式：zone.shanghai.host.host1.app.foo.counters.exporter.bar 這種方式將 Tag 的 Key 也編碼在 Name 裡。但帶來的問題也很明顯：Name 越來越長。

我們再看下一個例子：login.success.h5，它想表達來自 H5 平臺登入成功的次數。假設我們還有其他平臺，比如安卓、IOS，我們想求所有平臺的總登入成功次數，那麼就需要做一個聚合操作。通常時序資料庫會提供型號來匹配所有值。

其實上面這些都是舊版本 Graphite 的例子, 不過它在 2017 年底的版本支援了 Tags 概念，所以已經不能拿新版來當反面教材了。

這是 Dropwizard 客戶端的一個簡單 Demo，它是一個很流行的 Metrics 埋點客戶端，但是隻能支援傳統 Metrics 的概念。

1. MetricRegistry registry = new MetricRegistry();

2. Counter h5Counter = registry.counter("login.success.h5");

3. h5Counter.inc();

    

1.3.2 Metrics 2.0

我們再來看 Metrics 2.0，其實 Metrics 2.0 也就只是多了 Tags 的概念，這裡同樣省略了 Timestamp。

這是 OpenTSDB 風格的資料描述。

1. { "metric": "login.counter",

2. "tags": {

3. "result": "success",

4. "platform": "h5"

5. },

6. "timestamp": 1560597254000,

7. "value": 100

8. }

    

這是 Prometheus 的描述方式。

1. temperature{city="hangzhou"}=29

    

這是對應的 lookout-client 的埋點程式碼。

1. Registry registry = …;

2. Id loginCounter = registry.createId("login.counter");

3. Id id = loginCounter.withTags

4. "result", "success",

5. "platform", "ios"

6. );

7. registry.counter(reqId).increment();

    

可以看到它們都顯式支援了 Metrics 2.0 的概念。

這裡我們花了點時間強調傳統 Metrics 與 Metrics 2.0版本的區別，主要是想強調合理使用 Name 和 Tags，避免將 Tags 都編碼在 Name 裡的傳統做法。現在基本上流行的開源時序資料庫都透過自己的方式支援了Metrics 2.0 的概念。

2 SOFALookout 的客戶端使用

介紹完前置知識之後，我們開始第二部分：SOFALookout 的客戶端使用。

lookout-client 是 JVM 平臺上的 Metrics 埋點客戶端。下圖是 lookout-client 的包結構：

API 包包含介面模型和空實現。API 包列出了一些重要的類，前 4 個是常見的 Metrics 資料模型。Registry 用於直接管理 Metrics，是 Metrics 的容器。Observer 負責觀察 Registry，比如定期將 Registry 的整個快照資料匯出到控制檯或者是儲存層，僅依賴 API 包就可以程式設計。此時用的是空實現，需要引入實現包，這樣才能真正匯出資料。最後，擴充套件包裡則包含收集常見指標的實現， 比如 CPU 記憶體資訊。

接下來我將演示 SOFALookout 客戶端的使用。我會使用開源的 lookout-client，介紹 SOFALookout 裡幾個基本概念和它們的使用，在整個過程中還會討論 Tags 的合理使用。

SOFALookout 客戶端的相關演示操作可以在文末獲取 Demo 地址以及演示影片檢視地址。

3 SOFALookout 的服務端使用

第三部分是 SOFALookout 的服務端使用。整個服務端有 2 個應用：Gateway（多協議的資料收集與處理設計與實實現）和 Server（PromQL 與多種儲存層的設計與實現）。各個客戶端將資料上報到 Gateway，Gateway 進行處理，然後落庫。Server 則負責對外提供查詢服務。

3.1 Gateway – 多協議的資料收集與處理設計與實現

我們來仔細看一下 Gateway 的設計與實現，下圖表明瞭資料的流動方向：

Gateway 負責收集資料，適配了多種協議。通常只要是支援 Metrics2.0 概念的協議都可以進行適配。這部分是由 Importer 負責的，目前主要是客戶端主動上報資料為主。如果是像普羅米修斯的拉樣式的話，則需要和服務發現系統或部署平臺打通，這個目前暫時沒有支援。

Gateway 還會負責資料的基本清洗，比如過濾掉一些已知的壞資料。這裡使用的是管道過濾器樣式, 所以我們可以很容易加入一個新的切麵邏輯.

經過各種過濾器之後, 資料到達了 exporter 配接器，它負責將資料寫入多種儲存。

3.2 Server – PromQL 與多種儲存層的設計與實現

下麵是 Server 的設計與實現，下圖表明瞭資料的流動方向：

Server 提供了與普羅米修斯一致的 HTTP API，它負責分析收到的 PromQL 陳述句，然後執行，在取資料的地方適配底層儲存。

由於 Server 是計算與儲存分離的架構，因此需要註意將一些聚合計算下推到儲存層，而不是將原始資料取到記憶體裡再進行計算，否則會很慢。

這裡我提一下為什麼我們選擇適配普羅米修斯的 API，而不是其他時序資料庫的 API：其中一個重要原因是它的查詢能力明顯比其他時序資料庫的查詢能力強大，也比較簡潔，特別是在跨多個 Metrics 查詢時。

舉一個例子，假設我們有一個 Metrics 記錄了成功數，有另一個 Metrics 記錄了總數，想求成功率。顯然就是兩個Metrics 除一下就行了，比如下方的程式碼，就是表達了這個意思：

1. sum(success{zone="..."}) by(service{zone="..."}) / sum(total{zone="..."}) by(service)

    

InfluxDB 的話，其實也可以做到，但前提是它需要將成功數和總數放在同一個 measurement 下，因此並不能對任意兩個指標做四則運算。

OpenTSDB 的聚合查詢能力則明顯比較弱了，但好在它能支援同時查多個查詢，實在無法處理的情況下可以取回來然後自己做計算。但是這個步驟前端的 grafana 並不能幫我們做掉。

當然 PromQL 的強大，這隻是其中一方面，並不代表它就全面優與其他的 QL。

3.3 SOFALookout 服務端演示

下麵，我來演示一下 SOFALookout 服務端的部署流程，以及演示整套系統從資料收集到展示的玩法。

為了演示流暢, 使用 Docker 來部署軟體，我已經事先將要用到映象拉到本地了。

預先拉取映象：

1. docker image pull grafana/grafana && \

2. docker image pull elasticsearch:5.6 && \

3. docker image pull docker.io/xzchaoo/lookout-allinone:1.6.0-SNAPSHOT

    

再啟動儲存層, 這裡用的是 ES：

1. docker run -d --name es -p 9200:9200 -p 9300:9300 -e "discovery.type=single-node" elasticsearch:5.6

    

執行 docker logs-f es 檢視 ES 啟動情況。

啟動 SOFALookout，因為演示機是 Mac， Docker 的 host 網路樣式無法正常工作，而 SOFALookout 預設連線到 localhost 的 ES，這會導致錯誤，因此需要改寫引數。

我們需要建立一個配置檔案, 比如 foo.properties，有如下內容：

1. gateway.metrics.exporter.es.host=es

2. metrics-server.spring.data.jest.uri=http://es:9200

    

然後啟動 SOFALookout 容器, 將該配置檔案掛到指定路徑, 並且使用 Docker 的 link 引數來取用 ES 容器的地址：

1. docker run -it \

2. --name allinone \

3. --link es:es \

4. -e TZ='Asia/Shanghai' \

5. -p 7200:7200 \

6. -p 9090:9090 \

7. -v $PWD/foo.properties:/home/admin/deploy/foo.properties \

8. -e JAVA_OPTS="-Duser.timezone=Asia/Shanghai -Dlookoutall.config-file=/home/admin/deploy/foo.properties" \

9. docker.io/xzchaoo/lookout-allinone:1.6.0-SNAPSHOT

    

最後啟動 grafana，同樣使用了 link 引數：

1. docker run --name grafana -d -p 3000:3000 --link allinone:allinone grafana/grafana

    

SOFALookout 啟動之後可以訪問其 9090 埠，我們開啟 http://localhost:9090，有一個簡單的控制檯, 我們搜尋一個 Metrics：jvm.classes.loaded{app="*"}，這是 lookout-client 擴充套件包自動採集的資料。執行之前寫的 lookut-client demo 程式，此時應該有幾個點的資料了，需要等一段時間資料點才會更多，這段時間內我們可以先到 grafana 上探索一下。

近期，對於 SOFALookout 開源版本主要是以完善適配為主，包括計算下推到 ES，和適配其他時序資料庫。之後，我們也會開源關於 Trace 資料的處理模組。

以上內容由 SOFAChannel#6 直播分享整理，如果大家有疑問可以在釘釘群（搜尋群號即可加入：23195297）或者 Github 上與我們討論交流，我們將進行解答。也歡迎大家一起參與共建呀~

SOFALookout：https://github.com/sofastack/sofa-lookout
分享