自動探索及監視
概念
"在我們的規模上，人類無法持續監視我們所有系統的狀態"。 - Netflix
這適用於傳統 APM 工具，主要由效能調整專家用來手動分析及關聯資訊，以識別正式作業中的瓶頸和錯誤。 有了更高的規模和動力，這項任務就像在大海撈針一樣。 有太多要產生關聯的移動組件和度量值。
如果將機器智慧方法套用至系統管理，則核心模型和資料集必須無懈可擊。 微服務應用程式是由建置區塊的 100s 至 1000s 所組成，且不斷演進。 因此，必須瞭解所有區塊及其相依關係，它們需要 探索的進階方法。
元件
應用程式監視需要涵蓋的建置區塊如下:
實體元件
- 資料中心/可用性區域 -區域可以位於不同大陸及地區。 它們可能失敗或具有不同的效能性質。
- 主機/機器 -實體、虛擬或「即服務」。 每一部主機都有 CPU、記憶體和 IO 之類的資源，這可能是瓶頸。 每一個主機都在一個區域中執行。
- 儲存器 -在主機上執行，且可以由排程器 (例如 Kubernetes 或 Apache Mesos) 管理。
- 處理程序 -在儲存器中執行 (通常每個儲存器一個) 或在主機上執行，可以是執行時期環境 (例如 Java 或 PHP) ，也可以是中介軟體 (例如 Tomcat、 Oracle或 Elasticsearch)。
- 叢集 -許多服務可以作為群組或叢集，因此它們會顯示為外部世界的一個分散式處理程序。 叢集內的實例數可以變更，且可能會影響叢集效能。
邏輯元件
- 服務 -邏輯工作單元，可在先前提及的實體建置區塊之上執行許多實例及不同版本。
- 端點 -將特定指令公開給系統其餘部分的服務公用 API。
- 應用程式視景 (也稱為「應用程式」) -由一般環境定義 (使用標籤宣告) 所定義的一組服務和端點的視景。
- 追蹤 -追蹤是服務之間的同步及非同步通訊順序。 服務彼此交談，並針對使用者要求提供結果。 轉換資料流程中的資料可能涉及許多服務。
- 呼叫 -說明兩個服務之間的要求。 追蹤由一或多個呼叫組成。
商業元件
- 商業服務 -「商業服務」可以是提供獨特商業價值及服務之服務與應用程式的組合。
- 商業程序 -形成程序的技術追蹤資料組合。 例如，它可能是電子商務中的「購買」追蹤，接著是 ERP 中的訂單追蹤，接著是 FedEx遞送給客戶的物流追蹤。
不同版本中的數千個服務實例在多個大陸上不同區域的數百個主機上執行，以提供應用程式給其使用者，這並不罕見。 這會建立元件之間的相依關係網路，這些元件必須完美地一起運作，以確保應用程式的服務品質，以及提供商業價值。 當單一元件超過臨界值時，傳統監視工具會發出警示。 不過，其中一個或多個元件的失敗並不表示應用程式的品質肯定會受到影響。 因此，現代監視工具必須瞭解整個元件網路及其相依關係，以監視、分析及預測服務品質。
識別及編目變更
如所述，服務及其相依關係的數目比 SOA 型應用程式中的 10-100x 高，這會對監視工具造成挑戰。 而且情況越來越糟糕-持續交付方法、自動化工具和儲存器平台以指數方式增加應用程式的變更率，讓人類無法跟上變更或持續將監視工具配置到新部署的區塊中 (例如，由編排工具啟動的新儲存器)。 因此，需要現代監視解決方案，才能在分析及瞭解每一個區塊之前對它們進行自動且立即的探索。
然後，變更需要鏈結至前一個 Snapshot ，以便保留持續性，並且可以隨時重新建構模式來調查發生事件。
隨時可以在任何建置區塊中進行變更。 如需每一個元件中的變更範例，請參閱此圖形:
Instana 如何探索每一個拼圖片段
Instana Dynamic APM 解決方案的一個關鍵要素是我們的代理程式架構，特別是使用感應器。 感應器是小型代理程式-專為連接及監視一個事物而設計的小型程式。 它們由我們的 單一代理程式 自動管理 (每個主機一個代理程式) ，它會部署為主機上的獨立式處理程序，或透過儲存器排程器部署為儲存器。
代理程式首先會自動偵測實體元件，例如 AWS中的區域、主機或 Kubernetes上執行的 Docker 儲存器、 HAProxy、 Nginx、JVM、 Spring Boot、 Postgres、 Cassandra 或 Elasticsearch，以及這些處理程序的叢集，例如 Cassandra 叢集。 對於它偵測到的每一個元件，代理程式會收集其配置資料，並開始監視它是否有變更。 它也會 每秒開始傳送每一個元件的重要度量值。 代理程式會自動偵測並使用服務 (例如 JMX 或 Dropwizard) 所提供的度量。
作為下一步，代理程式會開始將追蹤功能注入服務程式碼中。 例如，它會截取 Elasticsearch的 HTTP 呼叫、資料庫呼叫及查詢。 它會擷取每一個呼叫的環境定義，例如堆疊追蹤或有效負載。
在伺服器上完成將此資料結合為追蹤資料、探索相依關係和服務，以及偵測變更和問題的情報。 因此，代理程式是輕量型，且可以注入數千個主機。
自動、立即及連續探索是新一代監視解決方案的需求。 Instana 已根據此需求進行基本設計。
Instana 如何收集資料
Instana 使用具有多個感應器的 單一代理程式 ，目前我們支援超過 100 個感應器。 這些 感應器不是延伸，它們完全由代理程式更新、載入及卸載。 有一個選用指令行介面，可讓您存取代理程式狀態、個別感應器及代理程式日誌。
感應器設計用於自動探索及監視特定技術，並將其資料傳遞至代理程式。 代理程式會管理與 Instana Service Quality Engine 的所有通訊。 在探索之後，感應器會收集詳細資料及度量資料，以提供元件狀態的精確表示法。 特定感應器會收集其各自技術的特定資料類型，視技術而定。 感應器會收集下列項目:
- 配置 -編目現行設定和狀態，以便追蹤任何變更。
- 事件 -起始探索、所有狀態變更 (線上及離線)、根據實體上的失敗性能規則來觸發問題或突發事件的內建事件，以及根據任何給定實體的個別度量值臨界值來觸發問題或突發事件的自訂事件。
- 追蹤 -根據程式設計語言平台來擷取追蹤。
- 度量 -指出效能之技術的限定屬性。
此外，探索在感應器內是遞迴的。 例如， Java Machine 感應器會繼續堆疊並探索在其上執行的架構 (例如 Tomcat 或 SpringBoot) ，然後協助代理程式載入適當的其他感應器。
在伺服器上完成將此資料結合為追蹤資料、探索相依關係和服務，以及偵測變更和問題的情報。 因此，代理程式是輕量型，可以注入數千個主機中。
Instana 後端使用串流技術，能夠處理每秒從代理程式串流的數百萬個事件。 此串流引擎有效即時，只需 3 秒即可處理狀況並向使用者顯示。