iT邦幫忙

1
鐵人賽 神助攻 Nutanix

Kubernetes監控:地圖和追蹤的服務依賴性

https://ithelp.ithome.com.tw/upload/images/20201009/20129565TR13WUl3ms.jpg

可靠的分佈式系統必須擁有觀察和理解組件之間依賴性的能力,若不了解服務依賴關係造成的盲目性代價高昂:

  • 令消費者失望的原因:「服務看起來不錯; 其他一些依賴性導致錯誤。」
  • 長時間停機:「哪個服務導致停機?」
  • 錯誤的部署:「不知道此代碼更改會影響該服務!」
  • 無效的計劃:「哪些服務對最終用戶交易最為重要?」
    新興產品希望解決跨服務的可觀察性挑戰。這些可觀察性產品會生成時即時地圖和追蹤,以捕獲服務之間的依賴關係結構。此外,也能獲得監視服務運行狀況的黃金訊號-延遲、附載量和錯誤率。在本文中,我們將討論Netsil Maps和OpenTracing,以提供對依賴關係結構和服務交互運行狀況的完整性。

Netsil地圖

Netsil應用程序運營中心 (AOC) 提供了自動Kubernetes服務及其相互作用的程式。可以在Kubernetes群集的多個抽象級別上創建Netsil。例如:下圖顯示了(a)主機、(b)命名空間和(c)窗格級別的反應。

https://ithelp.ithome.com.tw/upload/images/20201006/20129565sqc8bUpRnV.png

除了依賴關係結構外,Netsil反應還顯示了服務交互的延遲和附載量,只需點擊兩個服務之間的鏈接,即可取得任服務交互作用。例如:下圖示範了 sock-shop / frontend 和 sock-shop / catalogue pod之間的http 交互概況 。透過相關URI、請求方法、返回狀態代碼等,有洞察力的訊息對延遲、附載量和錯誤率進行了分組。

https://ithelp.ithome.com.tw/upload/images/20201006/20129565eVuodqifBQ.png

Netsil AOC透過對數據進行深入分析生成服務交互圖。Netsil反應不需要更改任何代碼或容器即可了解服務交互的運行狀況。AOC能夠分析和理解大多數通用服務協議,包括 gRPC、HTTP2、HTTP、PostgreSQL、MySQL、DNS、Cassandra、Redis 等(點此處觀看完整列表)。

DevOps團隊輕鬆地將Netsil收集器部署為DaemonSet,並利用地圖和指標。每次部署都會對其他依賴服務產生大程度的負面影響,Netsil反應不僅可以顯示依賴性,還可以提醒延遲出現、附載量下降或錯誤率增加的負面影響等等。這樣一來,可以防止不良部署影響生產,並避免代價高昂的停機時間。

Netsil反應出現在服務交互的各個部分,一種限制是缺少因果關係訊息。時間戳點和呼叫簽名(即URI、MySQL查詢等)提供了啟發式推斷因果關係。由於通信具有高度重複性,因此在單個事務級別不需要因果關係,但如果細粒度的單個事務級別追蹤對於程式需求非常,那麼OpenTracing是一個不錯但卻麻煩的選擇。

開放追蹤

Netsil使用「黑盒」方法生成地圖,而OpenTracing使用「白盒」方法。對於 OpenTracing (或通常分佈式跟蹤),應用程序代碼:

  • 創建跨部門功能
    
  • 創建所需的上下文並將其發送到後續的鏈接範圍使用
    
  • 建立跨部門之間的因果關係。
    

例如:下圖中,假設A、B、C表示與各個範圍關係的服務。服務A創建 SpanA 作為請求處理的一部分。只有服務A知道自己滿足進行中的請求並同時呼叫服務B和C,服務A將需要創建上下文並將其發送給服務B、C,服務B和C可以將它們各自的跨部門鏈設定為SpanA的子集。

https://ithelp.ithome.com.tw/upload/images/20201006/20129565zsuOurAtAD.png

只有應用程序具有可靠、明確的因果關係,因此出於實際使用,為了使跟蹤正常運用,必須向應用程序添加追蹤碼。如果已經編寫了大量的代碼就會非常費力,尤其是為了插入追蹤碼而難以更改的代碼。還有許多第三方軟體,例如緩存、數據庫、付款處理、庫存管理等等,可能無法為其插入跟追蹤代碼。開創性的Google Dapper論文啟發了許多分佈式追蹤工作。

追蹤程序的另一個重要挑戰是基礎協議和上下資料串接所需的存取「空間」。儘管HTTP等協議提供對自定義功能的支持,但仍有許多協議沒有存取空間。諸如gRPC,Thrift等的現代通信渠道都為OpenTracing提供技術支持,但是在沒有這些渠道的情況下,底層運營商協議的約束成為跨服務串接資訊流動的挑戰。

結論

觀察和監視服務依賴性對微服務應用程序(通常對於任何分佈式應用程序)的可靠性和性能至關重要。使用Netsil能夠輕鬆的取得地圖,並且可以了解通信和業務流程的結構。Netsil反應和指標能幫助DevOps團隊進行部署管理、事件響應、原因分析和儲存規劃。
如果需要事務級別的切割,則應考慮更嚴緊的檢測方法追蹤所有服務。進行追蹤時,開發團隊必須適當地處理追蹤資料,確保底層的通信協議可以承載追蹤的資訊流動,並確保彈性分析可用於查詢大量追蹤以獲取有意義的見解。雖然追蹤工作可能需要幾個月的時間才能得到成果,但是Netsil能在幾分鐘之內為kubernetes集群提供可觀察性。


尚未有邦友留言

立即登入留言