[[338018]]

本文轉(zhuǎn)載自微信公眾號「黑光技術(shù)」，作者 helight  。轉(zhuǎn)載本文請聯(lián)系黑光技術(shù)公眾號。

前言

針對 API 的管理，非常重要的一點就是做 API 監(jiān)控。前段時間看了 Nginx 社區(qū)發(fā)布的一本關于 API 流量管理的書，感覺書中的內(nèi)容還不錯，結(jié)合我在實際應用中的經(jīng)驗，今天就來梳理一下 API 的監(jiān)控的一些方法。

看了原文書感覺國外這些技術(shù)人在做事之前還是很有條理的，另外最近在也在讀一本社區(qū)管理的書，其中他們就把社區(qū)研究的層次分為了 3 層：框架(Frameworks)，理論(Theories)，模型(Models)。下面簡單解釋一下，感覺這個方法論非常實用，我感覺在很多地方都可以使用。

框架是說大方向，明確各個部分的關系，讓大家能在這個框架之下達成共識;

理論是比框架更明確的一個概念，它是在框架之下對每個模塊或者子模塊的進一步細化，或者是處理具體事情的技術(shù)或者原理性的解釋以及指導;

模型是更為具體的，解決特定事件的解釋和指導。研究人員使用模型來測試基于理論的各種假設，模型可以使用多種工具開發(fā)，包括數(shù)學、統(tǒng)計技術(shù)等。

這是一個做事情的框架體系，大家在思考和處理事情的應該也是有這樣一個模式的。

所以今天我在梳理 API 監(jiān)控方面的內(nèi)容的時候也想按照這樣一個基本思路來。

API 管理的基本框架

在 API 的管理上我是認為有幾個方面的：

• API 的基本開發(fā)管理(API設計，接口元信息，調(diào)用管理，測試，限流，路由管理等等)
• API 的基本監(jiān)控(流量，耗時，錯誤碼，可用性監(jiān)控等等)
• API 的安全管控(STL，鑒權(quán)，證書等等)
• API 的高級特性(可擴展性，緩存，伸縮，性能分析，流量放大分析等等)

從 API 的基本開發(fā)管理和到高級的功能分層進行管理，從基本可用到安全可控。API 的基本設計也是一個非常復雜的事情，要做好一個 API 的設計也不是那么容易的，這部分我后面也打算寫一個系列來介紹一下。今天的重點是是 API 的基本監(jiān)控。

API 監(jiān)控級別

API 監(jiān)控同樣也是符合上面的理論，也是有一個理論框架的。對于 API 的監(jiān)控首先是分級別的，這是為了監(jiān)控的實施，很多事情分層之后就會很清晰，無論在理解上和該怎么實施上都會很清晰。那看看對于 API 監(jiān)控是怎么分級的。

• 基礎設施監(jiān)控
• 服務級別監(jiān)控
• 業(yè)務級別監(jiān)控

基礎設施監(jiān)控

這里我們主要關注的是硬件cpu，磁盤，內(nèi)存等的可靠性，還有比如操作系統(tǒng)，隊列服務等組件的可靠性。上篇文章也介紹過如何快速分析定位系統(tǒng)中的這些問題。這些是服務運行穩(wěn)定的基礎，所以對這些設施的監(jiān)控是一個通用的做法，這個不是只有在 API 監(jiān)控中才有的，但是如果要做完整的 API 監(jiān)控，最后一部分當然是不可缺少的。

服務級別的監(jiān)控

在服務級別的監(jiān)控中，主要關注的是服務組件是不是健康可靠的，比如監(jiān)控數(shù)據(jù)的讀寫，文件創(chuàng)建，服務的基本存活，服務調(diào)用延遲，服務的性能等等。

業(yè)務級別監(jiān)控

最后是業(yè)務級別的監(jiān)控，不同的應用場景和業(yè)務，對于監(jiān)控的內(nèi)容也是不一樣的。比如你要監(jiān)控購買的量，監(jiān)控登陸用戶，消息發(fā)送的條數(shù)，收到的禮物數(shù)，走過的路線等等，不同的業(yè)務場景需要監(jiān)控的指標是不一樣的，這部分非常特性。

API 監(jiān)控常見的監(jiān)控指標

雖然上面說的第三個級別的監(jiān)控是有很多特性，但是對于監(jiān)控的內(nèi)容來說他們還是有一些共性的。所以這里給大家列一些常用的監(jiān)控指標類型。

速率

速率是一個常用的監(jiān)控指標，數(shù)據(jù)的發(fā)送速率，增加速率，訪問速率，調(diào)用速率等等，這個指標旨在監(jiān)控你的系統(tǒng)的服務能力。一般來說這個指標越大，服務能力越強。

請求延時

這個指標很多時候和上面的速率這個指標是有關系的，一般來說這個這個數(shù)值越小，說明你的服務性能越好。這個指標一般可以在 API 網(wǎng)關上進行采集或者是在客戶端采集。

錯誤率

對系統(tǒng)錯誤的監(jiān)控對一個系統(tǒng)來至關重要，還有對不同錯誤碼的統(tǒng)計計數(shù)，有了對這些個指標的監(jiān)控，系統(tǒng)的可用性監(jiān)控就有了。

如果單純的只看前面兩個指標也是有問題的，因為有時候在系統(tǒng)故障的時候系統(tǒng)的訪問速率和請求延時會表現(xiàn)的很好，但是實際上是有很多錯誤請求和錯誤返回，比如系統(tǒng)的快速錯誤返回，大量錯誤的請求等。

配額突發(fā)過載

這種也是要監(jiān)控的一個點，很多時候有瞬時過載的情況，這也是暴露了系統(tǒng)的一些潛在問題。

指標平均值

對于系統(tǒng)的穩(wěn)定性、服務能力以及服務特點的監(jiān)控這個是有必要的，很多時候不但要看當前狀態(tài)值，還要進一步看服務指標最近 5 分鐘、 10 分鐘、15 分鐘等的平均值。

API 監(jiān)控常見的監(jiān)控模型

上面都是鋪墊了，這部分其實才是我今天主要想分享的的內(nèi)容，我感覺這部分內(nèi)容才是比較有意思的。我上面列舉了那么多指標類型，每個類型在實際實施的時候又會派生出很多指標，那么問題就來了，我們在分析系統(tǒng)問題的時候是所有的指標都要看嗎?這個估計很難，那怎么做呢?

說起這個問題讓我想到股市中的一種做法：指數(shù)。提到這里大家如果了解所謂的指數(shù)，應該就知道我要說什么了，股票指數(shù)他可以通過對股市中的一些圈定的股票指標用特別的算法，計算出來一個值來表示股市的好壞。比如美國有納斯達克綜合指數(shù)，中國有上證指數(shù)和深成指數(shù)。

所以我這里介紹的這個所謂的監(jiān)控模型也是類似的想法，但是這個模型是目前其它公司或者組織已經(jīng)梳理好的，不是我的原創(chuàng)哈。

USE 模型

這里介紹第一種模型：USE (Utilization, Saturation, and Errors)，這個模型最早是由 Brendan Gregg 大神提出來的，目前在 Netflix 公司，大名鼎鼎的《BPF Performance Tools》這本書的作者，1300 多頁的大部頭。他提到他提出這種模型就是為了讓大家可以快速的定位問題解決問題，而不用陷入細節(jié)而不知所措。

Gregg 說通過問 3 個問題就應該可以對你的系統(tǒng)可以有非常好的理解了：利用率如何?飽和度如何?錯誤或者錯誤率如何?

Utilization 利用率是指對系統(tǒng)諸如 CPU，磁盤，I/O 等的利用情況如何，是否空閑。

Saturation 飽和度是系統(tǒng)等待處理的業(yè)務或者請求程度，表示是否超過了目前系統(tǒng)的最大承受能力。

Errors 錯誤或者錯誤率這個也比較好理解，就是系統(tǒng)在處理這些業(yè)務或者請求的時候出現(xiàn)的錯誤事件。

關于這個模型更為詳細的解釋可以去他的個人網(wǎng)站了解：http://www.brendangregg.com/usemethod.html。

實際上也是這樣的，我在前面一篇翻譯的文章中介紹如何定位 Linux 系統(tǒng)的問題，其實大部分的方法思路都是這樣的。

或許你說這個和 API 監(jiān)控有什么關系?Gregg 最早提出的目標確實是針對系統(tǒng)的指標分析，但是實際上這套方法模型應用在系統(tǒng)線程分析，網(wǎng)絡請求分析也是可以的。但是從根本來說它還是主要針對基礎設施的監(jiān)控模型。

RED 模型

RED (Requests, Errors, and Duration)，這個模型是由 Tom Wilkie 在 2015 的時候提出來的，它是對 USE 模型的一種升級，USE 模型在單機模型中會比較好用，但是在目前的分布式環(huán)境，微服務環(huán)境下，其實很難快速的來定位問題了，所以 RED 模型在針對復雜系統(tǒng)的健康評估的時候就比較有用了，可以看到使用的指標并不是很多，也是像上面的靈魂三問一樣：你的系統(tǒng)請求量多大?錯誤或者錯誤率有多少?耗時多大?

這里對這三個指標就不多解釋了，實際上大家在平時對 API 接口的考察估計也差不多會用到這些指標，但是我估計很多人從來沒有想過通過指標來構(gòu)建一種模型，從而反映系統(tǒng)的的整體穩(wěn)定性和可靠性。而且尤其對于微服務來說這個模型還是非常不錯的。

可以看出來這就是對應上面的服務級別監(jiān)控。RED 模型是正對系統(tǒng)的整體可用性進行的一種評估方式。通過對系統(tǒng)請求的完整監(jiān)控(從請求開始到返回的整個過程)，并且從中抽取 3 個關鍵指標，來評估系統(tǒng)的可用性。RED 模型一般是在 API 網(wǎng)關這一層來使用，在這一層就可以對服務進行監(jiān)控了。

LETS 模型

LETS (Latency, Errors, Traffic, and Saturation)，整個模型是 Google 在 2003 年提出的，其實這個模型是 Google 提出他們的 SRE 的時候提出來的一個模型，這 4 個指標在 SRE 這本書中被稱之為 “The Four Golden Signals”。書中說如果你只能關注 4 個指標，那就關注這 4 個：延遲，錯誤，流量和飽和度。

“If you can only measure four metrics, focus on these four: Latency, Errors, Traffic, and Saturation.”

這個模型用最小關注指標集，提供了對系統(tǒng)可用性的評估。通過這 4 個指標的關注你就會發(fā)現(xiàn)系統(tǒng)中的大多數(shù)問題。它不像 USE 一樣比較底層，它是一個針對服務可用性的監(jiān)控分析模型。

總結(jié)

做事情還是得有一定的方法論來指導的，今天這里總結(jié)的這篇文章目的就在于對 API 的監(jiān)控方面進行梳理，梳理出了 API 監(jiān)控的基本層次，常用指標和常見的監(jiān)控模型。

對于 API 的監(jiān)控模型來說，這里也要說明一下，不同的監(jiān)控模型關注的問題點不同，或者說關注的監(jiān)控層次不同。而且在實際的團隊中這塊的工作一般是會分為幾個組織來共同完成的。不同的團隊關注點會不一樣，所以可以針對具體的關注點可以選擇不同的模型。

另外要說的是，對于 API 的監(jiān)控，雖然上面提到的層次、指標和模型都是前人總結(jié)的。但是時代在發(fā)展，技術(shù)在進步，大家在實際場景中使用的時候應該一方面選擇合適可用的，另一方面應該也可以想一想，可選的模型是否適應現(xiàn)在的場景，如果不適應又沒有更好的選擇的時候是不是自己可以抽象開發(fā)出一個針對自己場景的模型。讓定制的模型可以準確的反映自己系統(tǒng)的狀態(tài)。

一圖勝千言：