運用動態圖形

「動態圖形」是應用程式的模型，可瞭解元件 (例如主機、OS、JVM、 Cassandra 節點、 MySQL等) 的所有實體及邏輯相依關係。 圖形也包括邏輯元件，例如追蹤資料、應用程式、服務、叢集及表格空間。 代理程式及感應器會自動探索元件及其相依關係，這表示圖形會即時保持最新。

圖形中的每個節點也會持續更新狀態資訊，例如度量、配置資料，以及根據語意知識和機器學習方法所計算的性能值。 此知識也會分析圖形中的相依關係，以尋找邏輯分組 (例如服務及應用程式) ，以瞭解對該層次的影響，並衍生問題的重要性。 整個圖形是持續性的，表示 Instana 應用程式可以在時間上來回移動，以利用圖形的整個知識庫來處理許多作業使用案例。

根據「動態圖形」，我們會計算變更和問題對應用程式或服務的影響，如果影響很嚴重，我們會將一組相關聯的問題和變更結合成 發生事件。 發生事件顯示問題和變更在一段時間內如何演變，讓 Instana 能夠直接指向發生事件的主要原因。 然後會自動探索任何變更，並計算其對周圍節點的影響。 變更可以是性能退化 (我們稱為「問題」)、配置變更、部署或程序、儲存器或伺服器的外觀/消失。

若要讓此具體化，讓我們看看如何建立模型，並瞭解使用 Elasticsearch 叢集來使用 Web 介面搜尋產品的簡式應用程式。 事實上，這可能只是一個 µ Service ，但它顯示我們如何瞭解 Instana 中的叢集和相依關係。

動態應用程式

讓我們開發 Elasticsearch 叢集的動態圖形模型，以瞭解它如何運作，以及為何它在分散式及流動環境中很有用。

我們從單一 Elasticsearch 節點開始，技術上是 Java 應用程式，因此圖形看起來如下:

ES 節點圖形

節點會顯示主機上自動探索到的元件及其關係。 對於 Elasticsearch 節點，我們會探索 JVM、處理程序、 Docker 儲存器 (如果節點在儲存器內執行) ，以及它執行所在的主機。 如果它在 Amazon AWS之類的雲端環境中執行，我們也會探索其可用性區域，並將該區域新增至圖形。

每一個節點都具有內容 (例如 JVM_Version=1.7.21) 及即時的所有相關度量，例如主機的 I/O 及網路統計資料、JVM 的記憶體回收統計資料，以及 ES 節點編製索引的文件數。

節點之間的邊緣說明它們的關係。 在此情況下，這些是「執行於」關係。 例如， ES 節點 "執行於" JVM。

若為 Elasticsearch 叢集，我們會有多個節點正在建置叢集。

ES 叢集圖形

在此情況下，我們在圖形中新增的叢集節點，代表整個叢集的狀態及性能。 它在包含叢集的所有四個 Elasticsearch 節點上具有相依關係。

Elasticsearch 的邏輯單元是索引-應用程式使用索引來存取 Elasticsearch中的文件。 它實際上是在分送給叢集中 ES 節點的 Shard 中進行結構化。

我們將索引新增至圖形，以瞭解應用程式所使用之索引的統計資料及性能。

ES 索引圖形

此外，我們假設我們使用簡式 Spring Boot 應用程式來存取 Elasticsearch 索引。

現在，圖形包含 Spring Boot 應用程式。

Spring Boot 圖形

當 Instana Java 感應器記錄分散式追蹤時， Instana 會知道 Spring Boot 應用程式是否會存取 Elasticsearch 索引。 我們將這些追蹤與圖形中的邏輯元件產生關聯，並追蹤不同追蹤資料的統計資料及性能。

使用此圖形，我們可以瞭解不同的 Elasticsearch 問題，並顯示如何分析對整體服務性能的影響。

假設我們有兩個不同的問題:

  1. 一個主機上的 I/O 問題導致索引/Shard 資料上的讀寫速度變慢。
  2. 一個 Elasticsearch 節點中的執行緒儲存區已超載，因此要求會排入佇列，因為在執行緒釋放之前無法處理它們。

圖形發生事件

發生事件說明

在此情況下，主機 (1) 開始有 I/O 問題。 我們的健康情報會將宿主的健康顯示為黃色，然後向我們的問題追蹤器發出問題。 幾分鐘後， ES (Elasticsearch) 節點 (2) 將受到此影響，我們的性能情報會看到此節點上的傳輸量降低到我們將此節點標示為黃色的層次-再次發動問題。 然後，我們的引擎會將這兩個問題產生關聯，並將它們新增至一個事件，而在此情況下，不會將它們標示為有問題，因為叢集性能仍然良好，因此不會影響服務品質。

然後在另一個 ES 節點 (3) 上，會填滿用於處理查詢的執行緒儲存區，並將要求放入儲存區。 由於效能受到此影響，我們的引擎會將節點的狀態標示為紅色。 這會影響 ES 叢集 (4) ，這會變成黃色，因為傳輸量正在減少。 產生的兩個問題會聚集至起始發生事件。

因為叢集會影響索引 (5) 的效能，所以我們將索引標示為黃色，並將問題新增至發生事件。 現在，產品搜尋交易的效能受到影響，我們的效能性能分析會將交易標示為黃色 (6) ，這也會影響應用程式 (7) 的性能。

由於應用程式和交易都受到影響，我們的事件實際上會以黃色狀態激發，表示產品搜尋效能降低且使用者受到影響。 會強調顯示兩個主要原因的路徑-I/O 問題及執行緒儲存區問題。 如擷取畫面所示， Instana 將顯示事件的發展，使用者可以在發生問題時探查元件-包括該時間點的確切歷程環境及度量值。

這會顯示 Instana 的獨特功能:

  • 使用圖形來結合實體、程序及追蹤資訊，以瞭解其相依關係。
  • 瞭解單一元件性能的智慧，以及叢集、應用程式及追蹤資料的性能。
  • 智慧型影響分析，以瞭解問題是否嚴重。
  • 顯示問題的主要原因，並提供可採取行動的資訊和環境定義。
  • 保留圖形的歷程、其內容、度量、變更和問題，並提供「時間」特性，以清楚檢視所有元件的狀態和相依關係來分析任何給定的問題。

在現代環境中尋找根本原因只會在未來幾年變得更有挑戰性。 上述簡式範例顯示，在不瞭解環境定義、相依關係及影響的情況下，尋找主要原因並不是一項平凡的作業。 現在想想以 µ Services 為基礎的「液體」系統，它會隨時新增及移除服務，並經常推出新的版本-Instana 會即時追蹤狀態及性能，並瞭解這些變更或問題的任何影響。 這全都是在沒有任何手動配置的情況下即時完成。

使用情形

即會自動建立並更新「動態圖形」。 部分元件 (例如服務) 的定義可以透過 服務配置進一步指定。

可以使用我們強大的 動態焦點 功能來完成圖形遍訪和範圍設定。