[[338018]]

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

前言

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

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

框架是說(shuō)大方向，明確各個(gè)部分的關(guān)系，讓大家能在這個(gè)框架之下達(dá)成共識(shí);

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

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

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

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

API 管理的基本框架

在 API 的管理上我是認(rèn)為有幾個(gè)方面的：

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

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

API 監(jiān)控級(jí)別

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

• 基礎(chǔ)設(shè)施監(jiān)控
• 服務(wù)級(jí)別監(jiān)控
• 業(yè)務(wù)級(jí)別監(jiān)控

基礎(chǔ)設(shè)施監(jiān)控

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

服務(wù)級(jí)別的監(jiān)控

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

業(yè)務(wù)級(jí)別監(jiān)控

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

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

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

速率

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

請(qǐng)求延時(shí)

這個(gè)指標(biāo)很多時(shí)候和上面的速率這個(gè)指標(biāo)是有關(guān)系的，一般來(lái)說(shuō)這個(gè)這個(gè)數(shù)值越小，說(shuō)明你的服務(wù)性能越好。這個(gè)指標(biāo)一般可以在 API 網(wǎng)關(guān)上進(jìn)行采集或者是在客戶端采集。

錯(cuò)誤率

對(duì)系統(tǒng)錯(cuò)誤的監(jiān)控對(duì)一個(gè)系統(tǒng)來(lái)至關(guān)重要，還有對(duì)不同錯(cuò)誤碼的統(tǒng)計(jì)計(jì)數(shù)，有了對(duì)這些個(gè)指標(biāo)的監(jiān)控，系統(tǒng)的可用性監(jiān)控就有了。

如果單純的只看前面兩個(gè)指標(biāo)也是有問(wèn)題的，因?yàn)橛袝r(shí)候在系統(tǒng)故障的時(shí)候系統(tǒng)的訪問(wèn)速率和請(qǐng)求延時(shí)會(huì)表現(xiàn)的很好，但是實(shí)際上是有很多錯(cuò)誤請(qǐng)求和錯(cuò)誤返回，比如系統(tǒng)的快速錯(cuò)誤返回，大量錯(cuò)誤的請(qǐng)求等。

配額突發(fā)過(guò)載

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

指標(biāo)平均值

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

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

上面都是鋪墊了，這部分其實(shí)才是我今天主要想分享的的內(nèi)容，我感覺這部分內(nèi)容才是比較有意思的。我上面列舉了那么多指標(biāo)類型，每個(gè)類型在實(shí)際實(shí)施的時(shí)候又會(huì)派生出很多指標(biāo)，那么問(wèn)題就來(lái)了，我們?cè)诜治鱿到y(tǒng)問(wèn)題的時(shí)候是所有的指標(biāo)都要看嗎?這個(gè)估計(jì)很難，那怎么做呢?

說(shuō)起這個(gè)問(wèn)題讓我想到股市中的一種做法：指數(shù)。提到這里大家如果了解所謂的指數(shù)，應(yīng)該就知道我要說(shuō)什么了，股票指數(shù)他可以通過(guò)對(duì)股市中的一些圈定的股票指標(biāo)用特別的算法，計(jì)算出來(lái)一個(gè)值來(lái)表示股市的好壞。比如美國(guó)有納斯達(dá)克綜合指數(shù)，中國(guó)有上證指數(shù)和深成指數(shù)。

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

USE 模型

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

Gregg 說(shuō)通過(guò)問(wèn) 3 個(gè)問(wèn)題就應(yīng)該可以對(duì)你的系統(tǒng)可以有非常好的理解了：利用率如何?飽和度如何?錯(cuò)誤或者錯(cuò)誤率如何?

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

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

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

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

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

或許你說(shuō)這個(gè)和 API 監(jiān)控有什么關(guān)系?Gregg 最早提出的目標(biāo)確實(shí)是針對(duì)系統(tǒng)的指標(biāo)分析，但是實(shí)際上這套方法模型應(yīng)用在系統(tǒng)線程分析，網(wǎng)絡(luò)請(qǐng)求分析也是可以的。但是從根本來(lái)說(shuō)它還是主要針對(duì)基礎(chǔ)設(shè)施的監(jiān)控模型。

RED 模型

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

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

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

LETS 模型

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

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

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

總結(jié)

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

對(duì)于 API 的監(jiān)控模型來(lái)說(shuō)，這里也要說(shuō)明一下，不同的監(jiān)控模型關(guān)注的問(wèn)題點(diǎn)不同，或者說(shuō)關(guān)注的監(jiān)控層次不同。而且在實(shí)際的團(tuán)隊(duì)中這塊的工作一般是會(huì)分為幾個(gè)組織來(lái)共同完成的。不同的團(tuán)隊(duì)關(guān)注點(diǎn)會(huì)不一樣，所以可以針對(duì)具體的關(guān)注點(diǎn)可以選擇不同的模型。

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

一圖勝千言：