服务调用的监控

监控的对象，指标，维度

监控的对象

1. 客户端监控：功能的监控
2. 接口的监控：接口调用情况的监控
3. 资源监控：接口依赖资源的监控，例如：某个服务使用的是redis进行存储，对redis进行监控就属于资源监控
4. 基础监控：服务器本身健康状况的监控，cpu，mem，io等

监控指标

1. 请求量： 实时请求量（利用QPS进行统计）以及统计请求量（利用PV进行统计）
2. 响应时间：一段时间内的平均响应时间，统计时一般进行分段统计，例如0-50ms的 50-100ms的等，或者是按占比统计 P99 P90等
3. 错误率：一段时间内失败次数占总次数的总量

监控维度

1. 全局维度：从整体角度监控
2. 分机房维度
3. 单机维度：机器配置和新旧不同可能导致结果不同
4. 时间维度：不同时间抽样统计
5. 核心维度：核心业务和非核心业务隔离，分开监控

监控原理

先将所需的监控信息进行采集然后将数据信息按照服务进行聚合，计算出每个服务的请求量，响应时间，错误率等，最后将处理后的信息进行展示。

1. 数据采集：两种采集方式，1 在服务调用完成后，由服务主动上报 2 代理收集，服务调用后将信息存入日志，然后由代理上报服务的调用信息。在进行数据采集时，需要考虑采样率，采样率越高，越准，采样时需要考虑系统状态，在系统空闲时增加采样率
2. 数据传输

• 传输的方式 1 通过udp协议直接和服务器建立连接发送数据 2 利用消息中间件，将数据放到消息队列，然后在从消息队列中获取
• 传输的数据格式：1 二进制，常用的为PB对象，高压缩率，高性能 2 文本，常用json，可读性高

3. 数据处理，接口维度聚合，机器维度聚合（查看每个节点的调用情况），数据存储的话可以用Elasticsearch的nosql或者时序数据库OpenTSDB，用时间序列存储，可以安装时间快速聚合等
4. 数据展示：利用图表直观的展示（格子图有图表的效果，既能从颜色深浅进行对比，又可以在上面的字体标示看出每一个的详细信息）[图片上传失败...(image-f7ef61-1666165469617)]

服务追踪

1. 优化系统瓶颈，记录每条链路上的耗时，可以快速找到系统瓶颈
2. 优化链路调用，通过调用链的分析可以清晰的查看下游依赖的服务，优化整个调用流程，分布式时，服务A调用服务B时，是否就近调用的B服务，例如本地有B服务，却调用了远端的B服务
3. 生成网络拓扑
4. 透明传输数据

服务追踪的调用

原理：利用一个唯一的id，将一次请求的各个节点串联起来参考常用的服务追踪系统：zipkin，鹰眼、MTrace

1. 例如使用traceID标示一条具体的请求，把用户的一次请求串联起来
2. 例如使用spanId标示请求所处位置，例如请求1既要请求A又要请求B，那么A为0.1，B标为0.2，A又请求C，则c标记为0.1.1
3. 例如使用annotation标示自定义的埋点数据，用于标示一些感兴趣的数据

服务追踪实现

分为三个模块，数据采集、数据处理、数据展示

1. 数据采集层，在系统中埋点进行数据采集，然后上报给数据处理层，数据埋点流程：
   红色方框为A调用B，以此为例，讲解RPC的四个阶段

• CS clent send 客户端发起请求
• SR server recieve 服务器接收请求
• SS server send 服务器返回请求, 并上报服务器上下文数据traceId=123456，spanId=0.1，appKey=B，method=B.method，start=103， duration=35
• CR client recieve 客户端接收数据，并上传科幻短上下文数据traceId=123456，spanId=0.1，appKey=A，method=B.method，start=103， duration=35
  [图片上传失败...(image-8606f-1666165469617)]
  A调用B，E B调用C ，C在返回响应时上报第一条，然后B接收上报第二条，然后B返回给A上报第三条，然后A调用E，E返回时上报第四条，A接收到上报第五条

2. 数据处理

• 实时数据，一般采用Storm或者Spark Streaming对数据进行实时聚合，例如按照traceId进行聚合，存储一般使用OLTP数据仓库，例如Hbase（nosql）
• 离线数据，一般通过运行MapReduce或者Spark批处理计算，存储一般使用Hive（sql）

3. 数据展示层

• 链路图，可以看出总耗时等，以及一层一层的调用情况，可以用来做故障定位，类似浏览器性能测试中的图像
• 拓扑图，Pinpoint监控工具使用为拓扑图，一般用于全局的监控，例如某个服务qps变高了可以及时报警