基礎架構相關性

此頁面說明如何將 應用程式監視 與 基礎架構監視 的世界整合在一起。 雖然部分使用者可能主要依賴應用程式監視，但有時可以更充分地瞭解邏輯層如何對映至實體層，並在對應用程式層次偵測到的問題進行疑難排解時需要這樣做，但其主要原因是在基礎架構層。

Instana 容許在使用者介面中應用程式與基礎架構監視之間進行雙向導覽:

基礎架構相關性也在下列方面扮演重要角色:

同樣地， 應用程式監視 和 網站監視 會整合在一起，如更多詳細資料中所說明 這裡。

在其最簡單的形式中，服務由單一處理程序 (例如， Spring boot 應用程式) 執行。 不過，通常由多個處理程序執行，以支援各種使用案例:

  • 增加傳輸量和備援，處理程序越多越好
  • 依不同的租戶或配置劃分工作
  • 執行該服務的不同版本，通常在不同的環境中

這表示您通常可以從服務導覽至一或多個基礎處理程序及相關實體，例如主機、容器、 Kubernetes Pod 等。

其中一個進入點是「基礎架構」標籤內的 堆疊，它會告訴您基礎架構哪些部分負責執行服務，包括其性能及重要度量值 (例如 CPU 或記憶體用量)。

從服務堆疊

另一個進入點是服務儀表板的「基礎架構」標籤，它提供不同於「堆疊」的明細，此外還提供追蹤度量值，例如呼叫計數、錯誤率及從主機層次到處理程序層次的平均延遲。

基礎架構標籤

上述兩個小組件都提供 Kubernetes 及 Pivotal Cloud Foundry 作為一等公民，可讓您直接存取相關實體，例如 Kubernetes 服務或 PCF 應用程式。

在 Kubernetes中執行之服務的堆疊範例:

Kubernetes 的堆疊

在 Kubernetes中執行之服務的「基礎架構」標籤範例:

Kubernetes 的基礎架構標籤

一般而言，追蹤資料會鏈結至基礎架構實體。 更具體地說，呼叫可以鏈結至最多 2 個處理程序: 起始呼叫的來源及該呼叫的目的地處理。 例如， NodeJS 程序對 PHP 程序發出 HTTP 呼叫。

在 追蹤視圖中，您可以選取任何呼叫來開啟 通話詳細資料。 從來源及目的地區段中，您都可以知道所涉及的基礎架構部分。

在此範例中，來源是 PHP 程序，目的地是 Spring 開機應用程式 (Java 程序):

呼叫明細

有時無法與基礎架構產生關聯，這通常表示基礎程序不受 Instana 監視。

追蹤的 root 呼叫一律如此，因為外部未受監視的用戶端會發出起始要求。 在這裡，會從 Instana 未監視的項目呼叫 shipping 服務:

呼叫詳細資料根呼叫

另一個情況是當送出呼叫以外部協力廠商服務為目標時。 在這裡， payment 服務稱為外部 www.paypal.com 外部服務。

通話詳細資料外部服務

查看 基礎架構 或平台 (Kubernetes、 Pivotal Cloud Foundry及 vSphere) 實體時，您可以使用 堆疊 來取得它正在執行的服務清單，以及它所屬的應用程式及度量值 (例如呼叫和錯誤計數)。

來自基礎架構的堆疊

上游/下游 可讓您存取分別呼叫及由現行基礎架構實體呼叫的服務及應用程式。

來自基礎架構的上游/下游

如何運作

在任何事情之前，請務必瞭解 應用 和 基礎架構 監視採用兩個不同的資料管線:

這兩個世界無縫合併，因為我們稱之為基礎架構鏈結的機制，其中呼叫會鏈結至受監視的基礎架構實體。 當找到兩端的一般 ID 時，即會進行鏈結。

已檢測服務

追蹤程式會檢測您的處理程序，以擷取送入及送出呼叫。 然後會將這些呼叫報告給 Instana 後端，我們會嘗試將這些呼叫的來源和目的地鏈結至一些已知的基礎架構實體。 當檢測來源處理程序 (或目的地處理程序) 時，它必然表示來源處理程序 (或目的地處理程序) 也受到 Instana 感應器監視，它知道它的一切。 因為追蹤程式和感應器都位於同一位置，所以它們都知道主機和處理程序，這使得基礎架構鏈結成為可能。

例如， Python 程序由 Python 追蹤器檢測，它會擷取所有送入及送出呼叫。 同時在執行此處理程序的主機上啟動了數個感應器: 主機、處理程序及 Python 感應器。 追蹤程式和感應器會分別將資料傳送至 Instana 後端，但它們都包含程序的相同 ID。 因此，可以將送入呼叫的目的地及送出呼叫的來源鏈結至 Python 程序。

資料庫、傳訊系統及雲端服務

Instana 追蹤程式不會檢測資料庫、傳訊系統或雲端服務。 不過，會檢測呼叫這些未追蹤系統的程序，因此送出的要求會適當地對映至呼叫。 例如， Java 追蹤程式會記錄從 Java 處理程序到 MySQL 資料庫的送出要求，並將這些要求分析為呼叫，並以 Java 處理程序作為來源，以 MySQL 資料庫作為目的地。 這些呼叫在 Instana 中可見，其目的地通常會鏈結至接收呼叫的基礎架構實體。 怎麼可能?

一方面， Instana 會透過其中一個 Instana 感應器來監視資料庫或傳訊系統，因此知道程序、其埠及主機。 另一方面， Instana 會分析送出的要求，其中可能包含足夠的資訊來猜測目的地程序，通常是所攜帶的主機名稱或 IP 及埠，例如連線字串。

例如， MySQL 實例的送出要求可能包含連線字串 jdbc:mysql://10.128.0.6:3306。

MySQL 連線字串

基礎架構監視偵測到對應的 MySQL 處理程序公開埠 3306 ，並在公開 IP 10.128.0.6的主機上執行。

MySQL 實例

由於 IP 和埠相符，呼叫和 MySQL 實例會鏈結在一起:

鏈結至 MySQL 實例的呼叫

Instana 也支援包含 Kubernetes 服務名稱 (例如 jdbc:mysql://mysql-svc) 的連線字串。 它會在幕後嘗試完整限定服務名稱，以在所有名稱空間及叢集之間唯一識別服務。 結果是其目的地鏈結至 Kubernetes 服務的呼叫，而不是最終處理程序。

對於雲端服務，沒有處理程序，但構想相同: 尋找受監視雲端服務共用的一般 ID ，以及該服務的送出要求。 例如， AWS ARN 之類的資源 ID。

當連線字串中給定的主機或 IP 不符合基礎架構監視端已知的任何主機或 IP 時，有時無法將呼叫鏈結至基礎架構。 當呼叫遠端資料庫 (或傳訊服務或雲端服務) 的程序使用下列主機名稱時，通常會出現間接層次:

  • /etc/hosts 系統檔案中的項目
  • DNS CNAME 項目
  • Proxy 或負載平衡器的指標
  • Service Discovery 服務 (例如 Consul 或 Zookeeper) 提供的別名

外部服務

外部服務依定義不受 Instana 監視，因此在基礎架構監視端甚至看不到。 因為我們對這些服務一無所知，所以對這些服務的呼叫根本無法與任何已知的基礎架構實體連結。

在基礎架構標籤中，您可以將這些呼叫識別為「未受監視」:

基礎架構標籤

應用程式和服務對映中的基礎架構相關性

基礎架構相關性在 應用 和 服務 對映中的角色為何?

當 Instana 後端分析追蹤資料和呼叫時，它會先將它們鏈結至已知基礎架構實體，並使用基礎架構標籤 (例如 host.name、 springboot.name 或 docker.label) 來強化它們。 然後會使用這些標籤，利用 預先定義的規則 或 使用者定義的規則，將這些呼叫自動對映至服務。 例如，鏈結至 Springboot 處理程序的呼叫將對映至從 springboot 應用程式名稱取得其名稱的服務。 或者您可以定義 Docker 標籤 service-name ，它可用來 建立自訂服務對映規則 ，以命名在 Docker中執行的大部分服務。

自訂服務對映

應用程式對映 也是如此，其中您可以使用這些基礎架構標籤來定義應用程式，例如使用 kubernetes.namespace 標籤:

應用程式配置

無法進行基礎架構鏈結時，服務對映無法依賴基礎架構標籤，而是依賴使用呼叫標籤 (例如 call.http.host 或 call.database.schema) 定義的所謂撤回規則。

基礎架構相關性及突發事件

事件 會利用 動態圖形來分組相關事件。 將呼叫 (以及應用程式和服務) 鏈結至基礎架構實體的能力，可透過連接兩個世界的其他連線來強化動態圖形，因此將導致更完整的發生事件及更快速的主要原因分析。