端點

端點會定義服務的 API ,並提供服務公開哪些作業的精細視圖。 每次呼叫服務都會在單一端點上發生。 每個端點都有單一自動探索的類型: BATCHSHELLDATABASEHTTPMESSAGINGRPC。 就像服務一樣,可以透過應用程式視景的鏡頭來檢視端點。

端點可以靜態宣告,也可以根據呼叫標籤 (相對於通常使用基礎架構標籤 (例如 SpringBoot 名稱) 來決定的服務)。 例如, {call.http.method} {call.http.path} 組合是 HTTP 服務的一般端點。

定義服務個別端點的另一個好處是,主要使用「整體」,服務可以包括許多不同的架構及技術 :HTTP/REST API、資料庫存取、訊息匯流排整合等。 透過為每個 API 類型至少建立端點,並可能進一步細分 (例如通訊協定詳細資料) ,會針對每個 API 類型擷取度量值及統計資料。

Instana 會根據預設規則自動對映端點。 如需相關資訊,請參閱 端點對映

預先定義的規則

Instana 會根據一組預先定義的規則自動對映端點。 下列規則會以降冪來考量。 當規則相符時,會建立個別端點。

規則 標籤
自訂端點規則 使用者定義的標籤 (請參閱 自訂端點對映)
透過 HTTP 標頭的使用者定義端點名稱 {call.http.header.x-instana-endpoint}
sdk 跨距資料中的使用者定義端點名稱 {call.tag.endpoint}
OpenTelemetry 定義的作業名稱 {otel.operation}
Jaeger 定義的作業名稱 {call.tag.jaeger.operation}
Zipkin 定義的作業名稱 {call.tag.zipkin.operation}
SOAP 動作 HTTP 標頭 {call.http.header.soapaction}
具有 WSDL 名稱空間的 RPC {call.rpc.method-1}
RPC {call.rpc.method}
GraphQL {call.graphql.operationType?} {call.graphql.operationName?}
批次石英類型而非十六進位型樣 {call.batch.jobType}
批次石英類型取代截止時間 {call.batch.jobType}
具有字首的批次十六進位 {call.batch.job-1}
批次石英數值字尾 {call.batch.job-1}
批次 {call.batch.job}
稜鏡模型 {call.database.statement-1}
稜鏡模型撤回 普里斯馬
JDBC 剖析陳述式 {call.database.statement-1}
JDBC 儲存程序陳述式結果 {call.database.statement-1}
Neo4j 剖析陳述式 {call.database.statement-1}
Cassandra 已剖析陳述式 {call.database.statement-1}
Cosmos non-sql 指令 {call.database.schema-1}
ElasticSearch 多重索引 {call.database.schema-1}
ElasticSearch 單一索引 {call.database.schema}
ElasticSearch 動作 {call.database.commandType}
ElasticSearch 細項 API 端點 細項 API 端點
從查詢剖析的 MongoDB 集合 {call.database.schema-1}.{call.database.statement-2}
無法從查詢剖析 MongoDB 集合 {call.database.schema-1}
已從名稱空間剖析 MongoDB 集合 {call.database.schema}
DynamoDB 表格 {call.database.schema}
Redis 指令 {call.database.statement}
AWS S3 儲存區 {call.database.schema}
AWS S3 作業 細項 API 端點
GCS 儲存區 {call.database.schema}
GCS 作業 細項 API 端點
Memcache/ Memcached / EhCache 作業 {call.database.commandType}
Couchbase 儲存區 {call.database.schema}
資料網格快取 {call.database.schema}
Couchbase 已剖析陳述式 {call.database.statement-1}
Aerospike 聲明 {call.database.statement}
IMS 結束程式 {call.database.statement}
IMS DB ,不含陳述式 {call.database.statement}
IMS DB ,不含陳述式 IMS DB
暫時傳訊佇列 暫時佇列
使用位址的 IBM MQ 跨距 {call.messaging.address-1}
使用位址的 IBM ACE 跨距 {call.messaging.address-1}
AzureQueue 的傳訊預設交換 {call.messaging.exchangeType}
使用位址的 Apache RocketMQ 跨距 {call.messaging.address-1}
一般傳訊 {call.messaging.address}
RabbitMQ 的傳訊預設交換 預設交換
暫時傳訊佇列 暫時佇列
z/OS Connect API {call.zcee.apiName}
含路徑範本的 HTTP {call.http.method?} /{call.http.pathTemplate-1}
具有路徑 ID 的 HTTP {call.http.routeId}
API 版本之後的第一個 HTTP 路徑區段 (如果有的話) {call.http.method?} {call.http.path-1}
具有根路徑的 HTTP 方法 {call.http.method} /
HTTP 根路徑 {call.http.method?} /
事件一般 {call.event.source}
取得不含引數的 Shell 二進位名稱,以及不含引數的 Script 名稱 {call.shell.command-1} {call.shell.command-2}
取得不含引數的 Shell 二進位名稱 {call.shell.command}
作為具有名稱和版本的服務 {faas.functionname}:{faas.functionversion}
函數作為僅具有名稱的服務 {faas.functionname}
功能即 ID 為的服務 {cloud.id}
SDK.name {call.sdk.name}

端點對映

端點會根據端點類型自動對映。

例如, Instana 會根據路徑範本 (如果可存取的話) 自動將 HTTP 端點分組。

/hospital/1948/patient/291148
/hospital/728/patient/924892
/hospital/47/patient/25978
/hospital/108429/patient/1847

在上述範例中,由相同應用程式碼提供且因此具有共用效能設定檔的前述端點將分組在一起並報告如下:

/hospital/{hid}/patient/{pid}

這會自動完成,且已知架構不需要任何使用者步驟。

當路徑範本無法使用時,端點會對映至第一個路徑區段,或者可以 根據需要配置

以下是無法使用路徑範本時的一些範例:

  • 受監視服務中未使用任何路徑範本。
  • 追蹤程式不支援路徑範本。
  • 在某些邊緣情況下 (例如鑑別失敗) ,追蹤程式無法存取路徑範本資訊。
  • 不監視目的地服務,且來自用戶端的結束跨距不知道路徑範本。

如果您要撰寫自己的追蹤程式碼,請參閱 自訂追蹤最佳作法 ,以瞭解如何達到相同的結果。

自訂端點對映

對於每一個服務, Instana 容許有一項配置,可控制如何擷取服務端點。 若要存取配置,請導覽至服務儀表板,移至端點標籤,然後按一下「配置端點」。

應用程式相依關係對映概觀

請注意,自訂端點配置僅適用於 HTTP 型服務。

自訂端點規則

Instana 隨附三個預設 HTTP 規則,這些規則一律是擷取鏈的一部分:

  • 偵測到的架構: 擷取偵測到的架構中指定的端點 (如果可存取的話)。
  • /*: 根據第一個路徑參數擷取端點。
  • 未指定: 將不符合之前規則的呼叫指派給 此端點

若要指定其他配置,您可以定義多個自訂規則。 如果要這麼做,請從任何 HTTP 服務存取自訂端點配置對話框,然後按一下「新增自訂 HTTP 規則」。 即將來臨的對話框可讓您定義特定路徑 (實際規則) 和多個測試案例,以檢查所定義的路徑是否如預期般運作。 對於路徑,您可以使用靜態區段 (例如 /api/myShopEndpoint)、路徑參數 (例如 /{productId}) ,或比對任何區段與 /*

在對話框的規則測試器組件中,您可以定義多個測試案例來驗證規則。 例如,假設有查詢 /api/*/{version},則下列測試案例 /api/anyName/123 將符合,而 /otherApi/anyName/123 將不符合。

應用程式相依關係對映概觀

循序評估

會從上到下套用規則,並將呼叫指派給第一個相符規則。 變更順序,只會重新排序規則,但只會拖放。 Instana 預設規則可以停用,但不能重新排序。

應用程式相依關係對映概觀

虛構端點

僅接收虛構資料流量的端點 (例如對性能檢查端點的呼叫) 可能會扭曲應用程式及服務的 KPI。 Instana 會自動偵測這些端點,並將它們標示為 虛構 ,以防止它們影響應用程式及服務 KPI。

如何在 Instana 中使用虛構端點

在「無界限分析」中,在虛構端點下存檔的每個呼叫都會標示為虛構,且不會針對「應用程式視景」、「服務」及「端點」視圖的 KPI 進行計數。

綜合端點

雖然他們的呼叫不針對應用程式視景及服務的 KPI ,但個別虛構端點具有自己的儀表板,例如其非虛構對等項目。

綜合端點

預設虛構端點

依預設,虛構端點由下列 URL 型樣識別:

可以停用上面列出的內建規則,並且可以指定自訂規則以將其他端點標示為虛構,請參閱 虛構端點的自訂規則 文件。 內建和自訂端點規則的配置是透過「服務」清單頂端的 配置服務 按鈕來存取。

虛構端點的自訂規則

附註: 自訂規則會在所有服務之間廣域套用。

為了輔助配置,會顯示受影響的端點和服務。

虛構端點配置

虛構呼叫

除了可以將整個端點標示為 Synthetic 之外,也可以將個別呼叫標示為 Synthetic。 當虛構檢查使用「正式作業」API 時,這特別有用,這通常是一個 絕佳 構想。

虛構呼叫規則

如果符合下列一或多個條件,則會在 Instana 中將呼叫標示為虛構:

Unbounded Analytics 中的虛構呼叫

依預設,綜合呼叫會隱藏在「無界限分析」中,因為只有在它們 非常錯誤時才會對效能分析感興趣。 若要讓「無界限分析」查詢也具有虛構呼叫,您必須透過 隱藏呼叫-> 虛構呼叫 參數接受。

在無界限分析中選擇虛構呼叫

未指定的端點

當資訊不足,無法自動將呼叫對映至端點時 (例如: 手動檢測端點,而不提供足夠資料) ,這些呼叫會對映至特殊「未指定」端點。

其他端點

在給定服務上偵測到太多端點時,會將呼叫分組在特殊「其他」端點下。 此防護措施旨在將端點集保持在合理大小。

通常會在其中一個 Instana 預先定義規則自訂規則 將呼叫分組到大量端點時發生,這些端點各會收到一次呼叫。

例如,其中一個 Instana 預先定義規則 是將 HTTP 呼叫對映至端點,其名稱來自 URL 中找到的第一個路徑區段。 如果這些區段是從動態值 (例如 "GET /blue-item"、"GET /red-item" ...) 建置, 套用此規則會導致大量端點,這沒有用。

處理 HTTP 端點時,可以透過變更 端點擷取規則的配置來改善狀況。

內部觸發程式端點

Instana 自動擷取的追蹤資料通常是從對服務的送入呼叫開始。 不過,當使用 Instana SDK 時,可以使用來自服務的送出呼叫來啟動追蹤。 在該情況下, Instana 會建立該服務的 Synthetic 母項呼叫 (對映至「內部觸發程式」端點) ,以提高可讀性。

內部觸發程式端點