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

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

Netsil地圖

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

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

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的子集。

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

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

結論

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