來源：https://blog.zhangbing.site/

在監控第三方API和Web服務時，監控的內容與監控的方式一樣重要。數據是有用的，但可操作的數據才是真正的價值所在。下面我們列出了在依賴第三方API集成和Web服務時，需要監控的最常見、最有價值的指標。準確的監控和警報可以為你的企業提供決策所需的數據，以決定使用哪些API，如何構建彈性應用程序以及將精力集中在何處。

當你開始監視API或Web服務時，以下是我們推薦的指標：

文章目錄

• • 延遲
  • 響應時間
  • 可用性
  • 消費量
  • 故障率
  • 狀態碼
  • 結束

延遲

延遲是指消息在“線上”花費的時間。這里，數字越短越好。延遲可能是由你的服務器和API服務器之間的連接引起的，它也可能是由你的服務器和API服務器之間發生的延遲造成的。這可能是網絡流量或資源過載的結果，在這種情況下節流請求可能會適應重載。

為了監控延遲，Web服務需要跟蹤發出和傳入請求的時間戳，并在給定時間內與過去和未來的請求進行比較。這仍然很棘手，因為來自服務器的響應也將受到響應時間的影響，如果可用，ping端點或調用健康檢查端點可能是接收準確延遲估計的最佳方式。

這種評估在對服務器進行地理定位時很有用，通過確定最低的延遲，你的企業可以決定選擇哪個供應商。如果確定延遲是導致響應延遲的真正原因，還可以選擇特定的區域提供商服務，或者如果資源的響應時間是問題所在，則可以選擇不同的提供商。在實際實踐中，等待時間和響應時間通常會合并為一個值。

響應時間

響應時間是指服務響應一個請求所需的時間。這可能更難用第三方API和Web服務來跟蹤，因為發送和接收數據的延遲是響應時間的一部分。你可以通過比較給定API上多個資源的響應時間來估計響應時間，由此，你可以估計API服務器和你的服務器之間的共享延遲，并確定真正的價值。

響應時間直接影響應用程序的性能，API響應的延遲將導致用戶交互變慢。你可以通過確保你所選擇的API提供商有響應時間保證，或者通過實施在檢測到尖峰時使用后備API或緩存資源的解決方案來避免這種情況。

可用性

API的可用性可以描述為停機時間或正常運行時間。兩者都基于相同的數據，但根據上下文可能會有不同的說法。

可用性可能是最容易跟蹤的指標。停機錯誤是可以識別的，有時API提供商會宣布預定的停機。但是，即使是最可靠的API也會遇到無法預料的停機時間。停機時間可以表示為單個事件，也可以表示為給定時期的總體平均值。雖然在評估API提供商時，停機配額和諸如“99.999%正常運行時間”之類的保證很有價值，但即使是最小的停機時間也可能對你的應用程序產生很大影響。

許多API依賴于外部提供商，如亞馬遜網絡服務（AWS）、微軟Azure和谷歌云服務。因此，現在個別網絡服務提供商的停機時間也依賴于你的應用不直接與之進行業務往來的第三方。即使 API 提供商的服務按預期運行，第三方也可能不會。因此，當出現較大的宕機時間時，你將希望有一個備用程序，它不依賴于與原始API相同的底層提供商。

雖然在衡量方式上與停機時間類似，但API的正常運行時間可以為業務決策提供洞察力。如果你知道某個API在關鍵工作時間內可以為客戶帶來更好的正常運行時間，則可以使用此指標在提供商之間進行切換。

一些利益相關者在選擇放棄哪個API提供商時可能會對停機時間做出反應，而其他利益相關者在考慮選擇哪個提供商時可能會更多地對正常運行時間做出反應。這些數值是有聯系的，但是，它們可以講述不同的數據故事。

消費量

在監控API的時候，很容易忘記使用情況，或者說消費情況。內部API可能不需要使用此指標，但是對第三方API使用的預測可以幫助制定業務決策，如果沒有適當的數據，使用Web服務時估計成本可能會很困難。消費量可以作為一個整體來評估，也可以以突發事件來評估。一些API供應商按月計費，但有些供應商可能對其定價層有費率限制，也會觀察較小時間窗口的使用情況。

通過跟蹤消費情況并設置高使用率警報，可以避免不必要的成本。此外，認識到什么時候沒有使用API也是有益的。缺乏消費是一個標志，表明一個API仍然是你的代碼庫的一部分，但可能對你的應用程序不重要，在這種情況下，你可以調整功能優先級并深入了解應用程序的使用情況。

最好將消費視為運行值，并可以通過時間窗口進行過濾，這使得儀表盤可以提供一個概覽，以及關于何時使用API的詳細情況。

故障率

請求失敗的原因有很多種。當對第三方API或Web服務的請求失敗時，可能是由于用戶錯誤、API停機、速率限制或各種網絡相關問題。雖然API故障有時可能是由你的應用程序引起的，但在跟蹤第三方API時，你希望主要關注你無法控制的失敗率。

跟蹤故障并確定故障率可以幫助：

• 向API供應商報告問題
• 在多個API提供商之間做出決定
• 做出與后備方案相關的明智決策
• 圍繞某些資源建立彈性

某些錯誤可能來自無效請求，這些可以告訴你應用程序在發出請求之前需要調整內部驗證。來自服務器相關問題的錯誤（如狀態碼在400和500范圍內）表明問題可能與API或web服務提供商有關。

狀態碼

跟蹤HTTP響應可以為你提供有關單個API的細粒度細節，但是跟蹤特定的狀態碼可以讓你更好地洞察問題的類型。例如，即使發生錯誤，某些API提供程序也會以 200 OK 狀態響應。這個錯誤的指標可能會讓你相信一切都按預期進行，但是用戶可能會遇到問題，并且你的內部日志記錄可能會講述一個不同的故事。

將 API 提供商的狀態碼指標與內部錯誤日志進行比較，可以進一步了解你的應用程序所依賴的第三方 Web 服務的真實錯誤率。

結束

記住這些指標，你的應用程序就可以更好地處理依賴于第三方集成時不可避免的問題。

測量所有這些指標聽起來像是一項艱巨的任務。幸運的是，某些開發人員工具（例如Bearer）可以幫助監控許多這些指標并應對自動出現的問題。

---

原文：https://dev.to/bearer
作者：Mark Michon

總結

以上是生活随笔為你收集整理的API监控：你应该衡量什么？的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。