Instana 监控结构
发布时间：
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监控内容是不一样的。
