SaaS應用的可觀測性設計

文 | 周江華

網易智慧企業資深業務架構師

引言

對於分佈式系統，因爲其遠超傳統軟件的系統複雜性，系統運維的難度大大增長，且會隨着分佈式節點的增長而指數級增加。

當系統出現故障時，要在數以千百計的應用節點中找出問題所在，對於開發人員來講，是一個巨大的挑戰。尤爲是不少節點的指標都異常時，何爲因，何爲果，每每難以辨別。

而另外一方面，對於 SaaS 應用來講，其面向企業的屬性，決定了對於服務可靠性的極高要求。一是出現故障時，咱們須要快速定位問題並排除故障，恢復服務。更重要的，則是可以時刻清楚瞭解系統的運行狀態，在系統有變壞趨勢發生前，及時發現，消滅故障於無形。

要作到這些，最基礎，又最重要的，即是系統具備極高的可觀測性。

什麼是可觀測性

當咱們開着一輛汽車行駛在路上時，儀表盤上的碼錶、轉速錶、油量計等儀表指示了汽車當前的基礎運行狀態。

當有黃色指示燈亮起時，表示車輛對應的某個零件有隱患，須要檢查，但還不至於影響車輛的基本運行和安全功能。而當有紅色指示燈亮起時，則是嚴重警告，最好當即把車送去檢查維修，不然車輛核心部件可能受損，或者存在嚴重安全隱患，容易引起事故。

汽車儀表盤及其鏈接的傳感器和信號傳輸系統，即是對於汽車系統可觀測性的最基礎，最直觀的例子。若是須要更深刻了解汽車各個部件的狀態，還能夠鏈接車輛的 OBD 接口，從中獲取到更多的車輛當前狀態以及歷史狀態數據。經過 OBD 接口，汽車系統的可觀測性也被大大加強。基於 OBD 數據，又衍生出了不少的手機管理軟件，能夠更簡單的觀察車輛狀態，還能記錄過往更多歷史數據，作駕駛習慣趨勢分析等，更大的擴展了汽車的可觀測性。

在 IT 領域，可觀測性的重要性有過之而無不及。CNCF（雲原生計算基金會）對於 Cloud Native 的定義中，就包含 observable 這一重要特徵。從汽車的例子，能夠簡單概括出可觀測性的定義，即可以將系統的內在狀態，經過採集，分析，處理後，經過合理的聚合，概括，展現指標數據，讓人能夠在最短期內瞭解到系統發生的一切。

具有可觀測性的系統，運維以及研發人員能夠直觀的觀察到系統的總體運行狀態是否健康，同時又能輕易的深刻到運行的各個細節角落。在正常運行時，觀測系統能對系統負載進行評估，對運維操做提供建議。在發生故障時，可協助快速定位和修復問題。在運維自動化和智能化的大趨勢中，系統的可觀測性是其中最基礎的一環。

構建完善的觀測系統

系統可觀測性的能力主要是由一個完善的監控系統提供。市面上有不少開源的分佈式監控系統，好比 Prometheus，Zabbix，nagios，CAT 等。其中，Prometheus 更已成爲事實上的接口標準。而各個大公司出於靈活，定製以及強大的運維開發能力，會有本身的監控系統。不管哪一種監控系統，其構成組件是基本同樣的，下面是 Prometheus 的架構圖：

（圖片引自 Prometheus 官網）

從圖中能夠看到，一個系統具有可觀測性，必須具有如下這些組件：

1. 服務狀態感知組件

在系統的各個節點，以全面的維度，採集服務狀態信息，提供原始數據。因爲採集的數據量巨大，該組件又直接部署在系統的運行節點上，須要使用各類方式來避免對系統正常運行形成影響。感知組件經過多種方式來採集狀態數據，而後按照標準接口輸出結構化的數據。經常使用的採集方式包括：

• 獨立監測工具，例如，監測系統運行狀態的 sar，top，dstat 等。
• 字節碼注入
• 結構化日誌
• 行爲事件埋點

2. 狀態數據蒐集和存儲

該組件是整個觀測體系的核心，將採集的數據上報，而後高效的存儲下來。對於不一樣的數據，不一樣的分析方式，應採用合適的存儲數據格式和存儲介質。最經常使用於存儲監控數據的是時序數據庫，例如 Prometheus，InfluxDB 等。對於數據採集方，提供各類度量類型，用於結構化的彙報數據，包括

• Gauges：計量器，用於內存，線程數等簡單計數場景。
• Counters：計數器，用於請求數，錯誤數等統計場景。
• Histograms：直方圖，用於平均響應時間，RT 95 值等須要計算均值，方差，分位數的場景。
• Meters：TPS計數器，用於速率統計，以及 1 分鐘，5 分鐘均值一類的統計。
• Timers：計時器，用於統計請求時延，例如請求時延，磁盤讀取時延等。

3. 可視化展現

觀測系統可否產生價值，可視化界面是最主要的一個決定因素，可視化系統必須支持靈活配置，靈活組合，又易於使用，信息展現足夠直觀。開源的可視化監控工具使用最普遍的是 Grafana。

4. 報警

報警功能是整個監控系統最核心的價值之一，在系統已經發生異常或者可能會發生異常時，報警系統能經過郵件，IM，短信，電話等多種渠道，及時通知到相關方，讓相關的運維和研發介入處理。

（IM通道報警示例）

報警配置主要有兩類，狀態事件報警和趨勢報警。

狀態事件是指已經發生的異常事件，例如：

• CPU 使用率超過 95%
• 磁盤空間佔用率超過 90%
• JVM 連續發生 fullgc
• 接口調用一段時間失敗超過 N 次，比率超過 x%
• Tomcat 線程數超過 120
• 業務打印出 ERROR 級別日誌

趨勢報警是指對指標變化趨勢進行分析，而後對異常變化進行報警處理，例如：

• 消息量比一週前降低 30%
• 某 URL 接口請求量比一分鐘前增長了 30%
• 內存使用量連續十分鐘增加超過 5%

覆蓋全面的觀測維度

資源監控

資源主要是指系統計算資源和網絡帶寬資源，常見的有 CPU，內存，磁盤 ID，網卡流量等。這類指標一般是以數值，百分比等方式進行統計，用於直觀的衡量系統負載狀況。做爲最基礎的監控項目，各類類型的開源監控系統和雲計算平臺都有提供。

（資源狀況監控示例）

對於各個類型的資源，下面是一些常常要關注的點，要在咱們的監控系統中清晰呈現出來。

1. CPU：對於計算型應用，CPU 是核心資源，負載高低直接指示了當前的系統的負載狀況。對於非計算型應用，CPU 一般處於低負載狀態，若是某個時間點 CPU 負載忽然飆高，一般指示應用有 bug 了，好比有死循環，或者是虛擬機在頻繁的 fullgc 致使負載下不來，或者是網絡流量飆高致使 CPU IO 處理以及上下文切換負擔加劇。
2. 進程存活狀況：檢查是否存在指定進程名的進程。
3. 內存：內存使用率，剩餘內存量。
4. 硬盤：包括硬盤空間，inode 數量，磁盤 IO 狀況等。
5. 網卡：進出網絡流量，進出網絡 PPS，丟包率等

性能監控

資源監控聚焦於操做系統層面，性能監控則聚焦於應用層面，也就是咱們常說的應用性能管理（APM）。

對於應用進程層面的監控，一般經過在虛擬機層，或者字節碼執行層經過隱式注入的方式，來獲取監控指標數據，常見的像 JVM，PHP 的 Zend Engine 等。以 Java 應用爲例，經過這種方式，咱們能夠獲取到的監控指標有：

• JVM 內存狀態
• JVM GC 狀況
• Java 方法調用統計
• Tomcat 線程狀態
• 自定義線程池工做狀態

而在接口層面，對於傳統的應用程序，仍舊能夠經過字節碼注入的方式來獲取。對於雲原生的應用，則能夠經過 sidecar 的方式來監控。經過監控，咱們能夠獲取到接口的 QPS，併發調用量，響應時間分佈，錯誤次數等各個指標。

（http 接口調用狀況監控示例）

能經過這種方式來監控的接口類型有：

• HTTP 接口調用/被調用狀況統計
• RPC 接口調用/被調用狀況統計
• SQL 執行狀況統計
• Redis 訪問狀況統計

單節點的接口性能只能體現一個節點的狀況，意義還不是那麼大。但當把整個平臺全部服務的接口調用狀況串起來以後，就能夠對系統全貌運行狀況有直觀的展現，這就是當下比較火熱的調用鏈路追蹤系統。當前主流的調用鏈路追蹤系統的理論基礎基本上都是 Google 的 Dapper，流行的開源組件有：Zipkin，Pinpoint，SkyWalking 等。經過調用鏈路追蹤，咱們能夠輕易作到：

• 各個服務節點性能分析
• 故障快速定位
• 請求調用鏈路分析
• 服務依賴分析與治理

（七魚全鏈路監控大盤）

業務監控

不論什麼時候，業務表現纔是最直接的關切點，最直接的監控也就是業務監控。常見的業務監控就是各類業務大盤，好比淘寶雙11 的交易數據大屏，這類大屏數據一般用於對外展現，或者給領導看，外觀都會設計的很酷炫，展現的數據類型上也會通過一些篩選。

而對於研發團隊，業務監控最重要的是指示業務的健康程度，所以展現的數據類型會全部不一樣，通常會更加細緻，維度也會更加全面。

首先，對業務總體狀態有監控。總體監控主要關注核心業務的健康度，保證核心業務有任何異常時，能夠即時提醒。

（七魚部分業務監控面板）

好比，對於七魚來講，其核心業務流程是訪客與客服的溝通，以及客服工做效率提高，所以總體業務監控指標會包括：

• 併發會話量
• 併發話務量
• AI 解答量
• AI 解決率
• 在線坐席數
• 消息收發速率
• 工單建立速率

然而，總體業務趨勢沒有明顯異常，但在某一個細分的維度下，可能業務已經徹底不可用了。所以在總體業務之下，監控還要繼續下鑽，從各個不一樣的維度進行監控。常見的細分維度有：

• 地域：地域主要關注的是網絡狀況，尤爲是對於視頻這種網絡敏感的業務。網絡地域差別最大的是 CDN 覆蓋質量，其次是各地域運營商對於網絡訪問的限制措施，再就是常常見諸報道的某個地方的光纖被挖斷的事件。
• 用戶：對於不一樣類型的用戶，可能會提供不一樣的功能，常見區分用戶的方式有 VIP，標籤等等。

租戶狀態跟蹤

對於 SaaS 業務，提供服務是以租戶爲粒度的。爲了提供個性化的服務，租戶有很大可自由定製的功能。同一個功能，在一個租戶是正常工做的，但在另外一租戶那裏，可能就已經徹底不可用了。所以，還須要分租戶維度對業務主體功能進行監控。對客戶的狀態跟蹤分爲兩部分，一部分是 SaaS 平臺功能，另外一部分是客戶的接口監控。

SaaS 平臺功能容易理解，是指由 SaaS 平臺給各個客戶提供的功能服務，對客戶，特別是大客戶以及新客戶的功能使用狀況進行持續跟蹤有很重要的意義。

首先，企業客戶對於服務的穩定性要求很高，一旦出現任何異常，即便是很是微小，但只要被客戶感知到，就極可能會影響客情關係，甚至引起投訴，影響後續的續費及增購。

其次，功能使用量的變化能夠反映客戶對於平臺的依賴程度，當客戶某個功能使用量忽然下降，或持續下降時，應關注客戶的業務是否是有收縮，或者是否是客戶一部分業務已經遷移到了競品，此時要及時瞭解緣由，維護好客情關係。若是某個功能忽然被客戶大量使用，則能夠開始爲客戶即將到來的增購作好準備了。

（重點企業消息接口監控面板）

另外一部分是客戶本身的接口。SaaS 平臺提供的功能中，不少都會涉及到客戶本身的業務數據，須要和客戶本身的系統作打通，所以 SaaS 一般會提供不少接口標準，由客戶實現，而後 SaaS 平臺在業務流程中去調用。這些外部接口不受平臺控制，提供的服務質量良莠不齊，出現異常的機率也很大。雖然這些接口故障不影響 SaaS 平臺的總體服務，但一來對具體的客戶則多是災難性的，二來出現故障後客戶的第一反應一般是 SaaS 平臺的故障，要求你儘快查清，這會浪費團隊至關多的時間。客戶也不必定有那麼完善的監控措施，因此，咱們必須把這些接口調用狀況按照租戶維度監控起來，在出現異常時及時通知到客戶，既是對客戶負責，也是減輕自身的工做壓力。

業務日誌

日誌是過後分析的主要手段。完善的日誌信息，能夠產生下面這些重要價值：

• 業務結果不符合預期時，能夠業務調用鏈路信息進行完整復原分析，找到問題的緣由。
• 對 ERROR 級別日誌以及特定關鍵字的日誌進行監控報警。
• 經過結構化的日誌，統計分析調用量，執行結果等信息，輔助運營數據統計。

爲了這些價值，使用日誌系統有一些最佳實踐能夠遵循。

首先，良好的日誌內容應該是記錄的信息很少很多剛恰好的。記錄信息太少的問題很明顯，可是太多也一樣會有問題，會致使真正有用的信息被稀釋，增長整個日誌系統的負擔，甚至影響到核心業務的性能。

其次，日誌信息應該是結構化的。一條完整的日誌信息應當包含完整的入參，出參，調用和被調用方信息，關鍵路徑執行結果，耗時等，nginx 的日誌就是一個典型例子。爲了方便日誌記錄，可在架構層面作日誌記錄，並提供方便的 SDK 進行接入。

再者，在分佈式架構下，一次完整的請求會通過不少的節點，在分析問題時，須要將這些節點上的調用日誌都串聯起來。這就須要一套完整的日誌採集和查詢工具，最經常使用的就是 ELK了。因爲日誌分佈在不一樣節點上，要把他們串聯起來，還須要對整個調用鏈路打標並記錄在日誌中。

高效的健康大盤

不一樣的監控維度，適合採用的監控方式和工具都不盡相同。平常使用以及進行問題排查時，若是還須要在不一樣的工具之間進行切換，效率無疑會大打折扣。經過統一的應用健康大盤，整合來源於各個系統的數據，在一個平臺進行展現和操做，能夠大幅提升觀測系統的易用性。

（簡潔的業務監控大盤示例）

做爲一個聚合展現平臺，健康大盤僅用於展現系統的實時健康狀態。各監測系統經過統一的接口彙報數據到平臺，數據內容包括：

• 服務信息：服務節點信息，服務名，節點標識，節點 IP 等。
• 業務域信息：服務所屬業務域，若有必要，可支持多級業務域。
• 數據維度：資源，性能，高可用，業務指標等監控維度。
• 維度優先級：不一樣優先級的展現權重不同，高優先級的異常會優先展現。
• 健康等級：指示服務的健康度，例如無異常時爲健康，有少許警告時爲亞健康，有大量報警時爲不健康，服務不可用時爲宕機。
• 詳情連接：用於詳情下鑽。

健康大盤支持如下功能：

• 監控維度聚合：同一節點的全部監控維度數據可聚合展現，按照優先級權重和健康等級，加權計算後展現。
• 應用狀態聚合：屬於統一服務的節點數據能夠聚合，屬於同一業務域的服務能夠聚合展現。
• 優先展現：可根據聚合後的健康度優先級實時排序展現，健康度低的優先展現。
• 數據下鑽分析：支持節點數據按照監控維度以及服務維度進行下鑽分析。

結語

在網易智慧企業，服務的量級已經上千，實例數已經到萬級。完善的觀測體系幫助咱們屏蔽了系統架構的複雜性，使得總體系統的運行狀態清晰可見，在故障預警以及問題排查方面發揮了巨大的做用。藉由觀測系統，咱們能夠清晰的看到系統流動的血液，跳動的脈搏，並守護系統的健康。

關於做者

周江華，網易智慧企業資深業務架構師。技術經歷豐富，前後主導過PC客戶端、移動端以及服務器的開發工做，是一名全棧工程師，目前主要專一於業務架構及技術管理的相關工做。