AI視頻剪輯工具：解鎖創(chuàng)作的無限可能
向值班工程師詢問關(guān)鍵服務(wù)，他們通常會提到由于警報優(yōu)先級設(shè)置不當(dāng)而帶來的額外開銷。例如，假設(shè)一個分布式應(yīng)用程序擁有 20 個 API。即使為這些 API 設(shè)置了跨延遲、錯誤和流量的基本警報監(jiān)視器，最終也需要監(jiān)控和維護 60 個警報定義，這是一項龐大的任務(wù)。為了在避免監(jiān)控盲點和防止警報疲勞之間取得平衡，運營團隊必須對所有事件有清晰的了解，并優(yōu)先為支持關(guān)鍵流量的事件配置警報。
在定義新的警報條件時，應(yīng)注重質(zhì)量而非數(shù)量，每個新條件都應(yīng)具備緊急性、可操作性，并且能夠主動或立即對用戶可見。每個警報條件還應(yīng)包含需要用戶積極參與的智能機制，而不僅僅依賴于自動化響應(yīng)。Apigee 的 API 監(jiān)控功能允許根據(jù)指標(biāo)或日志創(chuàng)建警報條件，同時提供可操作的信息（例如狀態(tài)代碼、速率等）和詳細(xì)的診斷手冊。
在當(dāng)今的多層系統(tǒng)中，一個團隊遇到的癥狀（“出了什么問題？”）可能是另一個下游系統(tǒng)的原因（“為什么會這樣？”）。即使某些事件不適合作為可操作的警報，故障仍需向下游系統(tǒng)廣播信息，以減輕上游依賴性的影響。在這種情況下，投資于自動化警報、將多個事件分組到通知渠道以及事件跟蹤是必要的。例如，Apigee 允許將警報通知集成和分組到 Slack、PagerDuty、Webhooks 等渠道。
現(xiàn)代生產(chǎn)系統(tǒng)不斷演進，當(dāng)前罕見的警報可能會變得頻繁且可自動化。類似于工單積壓管理，定期審查警報策略以識別新情況，并使用新的閾值、優(yōu)先級和關(guān)聯(lián)性來優(yōu)化現(xiàn)有警報是必要的。Advanced API Ops 等控制工具利用人工智能（AI）和機器學(xué)習(xí)（ML）技術(shù)，檢測與隨機波動不同的異常流量，幫助定義更加準(zhǔn)確的警報條件。
根據(jù)谷歌的《站點可靠性工程》一書，通過構(gòu)建儀表板來實現(xiàn)有效診斷的案例表明，這些儀表板能夠回答有關(guān)每項服務(wù)的基本問題，通常包括四種黃金信號中的某種形式——延遲、流量、錯誤和飽和度。然而，僅捕捉不同粒度級別的這些黃金指標(biāo)可能會迅速堆積。與所有軟件系統(tǒng)一樣，監(jiān)控可能成為一個無盡的復(fù)雜深淵，難以更改且維護成本高昂。在同一本書中，創(chuàng)建功能良好的獨立系統(tǒng)的最有效方法是收集和聚合基本指標(biāo)，并與警報和儀表板配合使用。
對于運行大型 API 程序并由專門團隊進行監(jiān)控的組織，可以利用 API 管理解決方案中的現(xiàn)成監(jiān)控儀表板（例如 Apigee 的 API 監(jiān)控）來收集有關(guān) API 的實時見解，包括 API 性能、可用性、延遲和錯誤。在其他情況下，可以使用云監(jiān)控等解決方案，這些解決方案提供整個應(yīng)用程序堆棧的可見性，并通過豐富的查詢語言對各個指標(biāo)、事件和元數(shù)據(jù)進行可視化，便于快速分析。利用單一系統(tǒng)對應(yīng)用程序堆棧進行監(jiān)控不僅提供了上下文中的可觀察性，還減少了在不同系統(tǒng)之間導(dǎo)航所需的時間。Apigee 客戶可以默認(rèn)使用 Cloud Monitoring，也可以通過 Cloud Monitoring API 與其他系統(tǒng)集成。
即使在收集和匯總指標(biāo)之后，擁有有影響力的數(shù)據(jù)可視化以快速了解問題并在診斷過程中識別相關(guān)性也至關(guān)重要。在數(shù)據(jù)可視化中，關(guān)注過多的儀表板會導(dǎo)致學(xué)習(xí)曲線陡峭，并增加每次診斷的平均時間。例如，Apigee API Monitoring 提供以下標(biāo)準(zhǔn)可視化，以平衡簡單性和效率：
這些可視化工具使運營團隊能夠迅速識別和隔離問題區(qū)域，提高診斷效率，確保 API 的穩(wěn)定運行和高性能。
現(xiàn)代應(yīng)用程序開發(fā)加速了云、容器、API、微服務(wù)架構(gòu)、DevOps、SRE 等技術(shù)和實踐的采用。雖然這提升了發(fā)布速度，但也增加了應(yīng)用程序堆棧的復(fù)雜性和故障點。例如，客戶請求的緩慢響應(yīng)可能涉及多個團隊管理和監(jiān)控的微服務(wù)，這些團隊可能未能單獨觀察到任何性能問題。缺乏請求的端到端上下文視圖，幾乎無法隔離高延遲點。
在這種情況下，分布式跟蹤成為 DevOps、運營和 SRE 獲取服務(wù)運行狀況、缺陷根本原因或分布式系統(tǒng)性能瓶頸等問題答案的最佳方式。組織應(yīng)投資使用 OpenCensus 和 Zipkin 等開源標(biāo)準(zhǔn)來檢測分布式應(yīng)用程序。利用 Cloud Trace 等工具，這些工具具有廣泛的平臺、語言和環(huán)境支持，能夠輕松從任何來源（開放儀器或?qū)Ｓ写恚┇@取數(shù)據(jù)。
盡管分布式跟蹤有助于縮小問題范圍至特定服務(wù)，但在某些情況下，可能需要進一步的上下文來查明根本原因。例如，即使已將性能問題的根源隔離到 API 代理，識別正在執(zhí)行的多個策略中的正確瓶頸仍然繁瑣。Apigee 的調(diào)試工具能夠放大 API 代理流程，深入探查每個步驟的詳細(xì)信息，包括策略執(zhí)行、性能問題和路由等內(nèi)部細(xì)節(jié)。
一旦請求跨越多個微服務(wù)，分布式跟蹤和調(diào)試工具便成為監(jiān)控策略的關(guān)鍵要素。當(dāng)分布式系統(tǒng)中的每個服務(wù)都生成跟蹤數(shù)據(jù)時，數(shù)據(jù)量迅速增長，導(dǎo)致經(jīng)典的“大海撈針”問題。在這種情況下，正確提出問題并在基于頭部的采樣（隨機選擇分析的跟蹤）與基于尾部的采樣（觀察所有跟蹤信息并對異常延遲或錯誤的跟蹤進行采樣）之間進行選擇，變得至關(guān)重要，具體取決于應(yīng)用程序的復(fù)雜性。
分布式跟蹤不僅提供了全面的請求路徑視圖，還能夠幫助識別跨服務(wù)的性能瓶頸和錯誤源。通過整合分布式跟蹤，運營團隊能夠更快速地定位和解決問題，確保應(yīng)用程序的高可用性和卓越性能。
Apigee 的 API 監(jiān)控功能（基于系統(tǒng)內(nèi)部公開的指標(biāo)）與現(xiàn)有的監(jiān)控基礎(chǔ)架構(gòu)配合使用，能夠縮短平均診斷時間并提升應(yīng)用程序的彈性。具體而言，運營團隊可以利用以下功能：
使用 Apigee 的 API 監(jiān)控，可以通過全面的控制保持高應(yīng)用程序彈性，從而縮短診斷和解決問題的平均時間。
原文鏈接：3 best practices to reduce application downtime with Google Cloud’s API monitoring tools
