1、監控結構Instana 監控整體上分為三層結構，Application、Service、endpoint。Application：是Service的邏輯集合，根據實際的情況對S

1、監控結構

Instana 監控整體上分為三層結構，Application、Service、endpoint。

• Application：是Service的邏輯集合，根據實際的情況對Service進行歸類。
• Service：Service是基礎組件的集合，可以是主機、容器、進程的集合。 以Java為例， 其可以是若干個Java進程的集合，合并方式通過進程中jar的名稱。這個類似java應用的概念。 以redis為例，其可以是redis的進程，合并方式為 hostname + port 。
• endpoint：endpoint是指服務提供的API，對于類似Java 應用的 API 很容易理解，其可以restful http api 也可以 rpc 的api。對于緩存類型的其是操作類型，比如redis 為 put get 等等。

Instana 在Service這一層統一了應用層和基礎組件層。這點和 appdynamics、 dynatrace 有差異。后者 緩存和數據庫都是屬于基礎組件層，在這一層有統一的監控。

2、拓撲結構

2.1、Trace

單次請求鏈路信息

整體請求路徑分析如下：

• payment 接受 http 請求
• payment 訪問 user 服務
• user 服務 查詢 users 數據庫
• payment 發送消息到 dispatch
• dispatch 接受消息進行處理
• payment 訪問 cart（購物車）
• car 訪問 redis 清空購物車內容

2.1、Endpoint 拓撲

endpoint 拓撲是業務接口拓撲

業務接口拓撲和trace單次鏈路是一致的，主要有以下三個路徑：

• payment -> user -> users(db)
• payment -> payment(robot-shop)(消息中間件) -> dispatch 服務
• payment -> cart -> redis:6397

2.2、服務拓撲

服務拓撲是指經過某個服務的所有的請求產生的拓撲，此服務可能處于這個拓撲的任意位置。

服務拓撲數據有些混亂？多個 payment 不知道具體意思！ mq 消息和service 分開有個單獨的節點是比較清晰的。

2.3、Application 拓撲

一個Application下所有的Service 的關系

消息中間件沒有體現出來

3、Stack

3.1、Application

一個 Service 屬于那幾個 Application ，一個Service提供那些服務接口

注意 這里一個Service可以屬于多個 Application和其它廠商也存在區別，

3.2、Kubernetes

• Service 運行在那個集群上
• Service 運行在那幾個Node上
• Service 在那幾個 Namespace 下運行
• Service 在那幾個 Deployment 下運行
• Service 由那個 K8s Service 提供服務
• Service 在那個POD 下運行

3.3、Infrastructure

• 運行在那幾個可用區內
• 運行在那幾個 Custom Zones
• 運行在那幾個主機上
• 運行在那幾個容器上
• 運行在那幾個進程上
• 運行在那幾個JVM中 對于JVM而言，一個進行只能運行一個VM，但是進程和VM監控內容是不一樣的。