做API 監(jiān)控有沒有什么方法

這篇文章給大家介紹做API 監(jiān)控有沒有什么方法，內(nèi)容非常詳細(xì)，感興趣的小伙伴們可以參考借鑒，希望對(duì)大家能有所幫助。

前言

針對(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ù)運(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ā)送速率，增加速率，訪問速率，調(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)也是有問題的，因?yàn)橛袝r(shí)候在系統(tǒng)故障的時(shí)候系統(tǒng)的訪問速率和請(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)的一些潛在問題。

指標(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)，那么問題就來(lái)了，我們?cè)诜治鱿到y(tǒng)問題的時(shí)候是所有的指標(biāo)都要看嗎?這個(gè)估計(jì)很難，那怎么做呢?

說(shuō)起這個(gè)問題讓我想到股市中的一種做法：指數(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è)的大部頭。他提到他提出這種模型就是為了讓大家可以快速的定位問題解決問題，而不用陷入細(xì)節(jié)而不知所措。

Gregg 說(shuō)通過(guò)問 3 個(gè)問題就應(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)的問題，其實(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)定位問題了，所以 RED  模型在針對(duì)復(fù)雜系統(tǒng)的健康評(píng)估的時(shí)候就比較有用了，可以看到使用的指標(biāo)并不是很多，也是像上面的靈魂三問一樣：你的系統(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ù)問題。它不像 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)注的問題點(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)。

一圖勝千言：

關(guān)于做API 監(jiān)控有沒有什么方法就分享到這里了，希望以上內(nèi)容可以對(duì)大家有一定的幫助，可以學(xué)到更多知識(shí)。如果覺得文章不錯(cuò)，可以把它分享出去讓更多的人看到。