Skywalking应用

Skywalking应用
- 1 Skywalking概述
- - 1.1 微服务系统监控三要素
  - 1.2 什么是链路追踪
  - - 1.2.1 链路追踪
    - 1.2.2 OpenTracing
  - 1.3 常见APM系统
  - 1.4 Skywalking介绍
- 2 Skywalking安装
- - 2.1 elasticsearch安装
  - 2.2 Skywalking安装
- 3 Skywalking应用
- - 3.1 agent下载
  - 3.2 agent应用
  - - 3.2.1 应用名配置
    - 3.2.2 IDEA集成使用agent
    - 3.3.3 生产环境使用agent
  - 3.3 Rocketbot
  - - 3.3.1 Rocketbot-仪表盘
    - - 1.1 APM
      - 1.1.1 Global全局维度
        
        1.1.2 Service服务维度
        
        1.1.3 Instance实例维度
        
        1.1.4 Endpoint端点（API）维度
      - 1.2 DataSource展示栏
      - 1.3 编辑仪表盘
    - 3.3.2 Rocketbot-拓扑图
    - 3.3.3 追踪
    - 3.3.4 性能分析
    - 3.3.5 告警
    - - 3.3.5.1 警告规则详解
      - 3.3.5.2 Webhook规则

Skywalking应用

1 Skywalking概述

随着互联网架构的扩张，分布式系统变得日趋复杂，越来越多的组件开始走向分布式化，如微服务、消息收发、分布式数据库、分布式缓存、分布式对象存储、跨域调用，这些组件共同构成了繁杂的分布式网络。
我们思考下这些问题：

1:一个请求经过了这些服务后其中出现了一个调用失败的问题，如何定位问题发生的地方？
2:如何计算每个节点访问流量？
3:流量波动的时候，增加哪些节点集群服务？

这些问题要想得到解决，一定是有数据支撑，绝不是靠开发人员或者运维人员的直觉。为了解决分布式
应用、微服务系统面临的这些挑战，APM系统营运而生。

1.1 微服务系统监控三要素

Logging 就是记录系统行为的离散事件，例如，服务在处理某个请求时打印的错误日志，我们可以将这些日志信息记录到 ElasticSearch 或是其他存储中，然后通过 Kibana 或是其他工具来分析这些日志了解服务的行为和状态。大多数情况下，日志记录的数据很分散，并且相互独立，比如错误日志、请求处理过程中关键步骤的日志等等。

Metrics 是系统在一段时间内某一方面的某个度量，例如，电商系统在一分钟内的请求次数。我们常见的监控系统中记录的数据都属于这个范畴，例如 Promethus、Open-Falcon 等，这些监控系统最终给运维人员展示的是一张张二维的折线图。Metrics 是可以聚合的，例如，为电商系统中每个 HTTP 接口添加一个计数器，计算每个接口的 QPS，之后我们就可以通过简单的加和计算得到系统的总负载情况。

Tracing 即我们常说的分布式链路追踪。在微服务架构系统中一个请求会经过很多服务处理，调用链路会非常长，要确定中间哪个服务出现异常是非常麻烦的一件事。通过分布式链路追踪，运维人员就可以构建一个请求的视图，这个视图上展示了一个请求从进入系统开始到返回响应的整个流程。这样，就可以从中了解到所有服务的异常情况、网络调用，以及系统的性能瓶颈等。

1.2 什么是链路追踪

谷歌在 2010 年 4 月发表了一篇论文《Dapper, a Large-Scale Distributed Systems TracingInfrastructure》介绍了分布式追踪的概念，之后很多互联网公司都开始根据这篇论文打造自己的分布式链路追踪系统。前面提到的 APM 系统的核心技术就是分布式链路追踪。
OpenTracing提供了一个标准的、与供应商无关的框架，这意味着如果开发者想要尝试一种不同的分布式追踪系统，开发者只需要简单地修改Tracer配置即可，而不需要替换整个分布式追踪系统。
OpenTracing API目前支持的语言众多：

1.2.1 链路追踪

下面通过官方的一个示例简单介绍说明什么是 Tracing,把Tracing学完后，更有助于大家运用Skywalking UI进行数据分析。
在一个分布式系统中，追踪一个事务或者调用流程，可以用下图方式描绘出来。这类流程图可以看清各组件的组合关系，但它并不能看出一次调用触发了哪个组件调用、什么时间调用、是串行调用还是并行调用。

一种更有效的展现方式就是下图这样，这是一个典型的 trace 视图，这种展现方式增加显示了执行时间的上下文，相关服务间的层次关系，进程或者任务的串行或并行调用关系。这样的视图有助于发现系统调用的关键路径。通过关注关键路径的执行过程，开发团队就可以专注于优化路径中的关键服务，最大幅度的提升系统性能。例如下图中，我们可以看到请求串行的调用了授权服务、订单服务以及资源服务，在资源服务中又并行的执行了三个子任务。我们还可以看到，在这整个请求的生命周期中，资源服务耗时是最长的。

1.2.2 OpenTracing

学好OpenTracing，更有助于我们运用Skywalking UI进行数据分析。
Trace
一个 Trace 代表一个事务、请求或是流程在分布式系统中的执行过程。OpenTracing 中的一条 Trace 被认为是一个由多个 Span 组成的有向无环图（ DAG 图），一个 Span 代表系统中具有开始时间和执行时长的逻辑单元，Span 一般会有一个名称，一条 Trace 中 Span 是首尾连接的。
Span
Span 代表系统中具有开始时间和执行时长的逻辑单元，Span 之间通过嵌套或者顺序排列建立逻辑因果关系。
每个 Span 中可以包含以下的信息：
操作名称：例如访问的具体 RPC 服务，访问的 URL 地址等；
起始时间；2021-1-25 22:00:00
结束时间；2021-1-30 22:00:00
Span Tag：一组键值对构成的Span标签集合，其中键必须为字符串类型，值可以是字符串、bool值或者数字；
Span Log：一组 Span 的日志集合；
SpanContext：Trace 的全局上下文信息；
References：Span 之间的引用关系，下面详细说明 Span 之间的引用关系；
在一个 Trace 中，一个 Span 可以和一个或者多个 Span 间存在因果关系。目前，OpenTracing 定义了ChildOf 和 FollowsFrom 两种 Span 之间的引用关系。这两种引用类型代表了子节点和父节点间的直接
因果关系。
ChildOf 关系：一个 Span 可能是一个父级 Span 的孩子，即为 ChildOf 关系。下面这些情况会构成 ChildOf 关系：
一个 HTTP 请求之中，被调用的服务端产生的 Span，与发起调用的客户端产生的 Span，就构成了 ChildOf 关系；
一个 SQL Insert 操作的 Span，和 ORM 的 save 方法的 Span 构成 ChildOf 关系。
很明显，上述 ChildOf 关系中的父级 Span 都要等待子 Span 的返回，子 Span 的执行时间影响了其所在父级 Span 的执行时间，父级 Span 依赖子 Span 的执行结果。除了串行的任务之外，我们的逻辑中还有很多并行的任务，它们对应的 Span 也是并行的，这种情况下一个父级 Span 可以合并所有子 Span的执行结果并等待所有并行子 Span 结束。
FollowsFrom 关系：在分布式系统中，一些上游系统（父节点）不以任何方式依赖下游系统（子节点）的执行结果，例如，上游系统通过消息队列向下游系统发送消息。这种情况下，下游系统对应的子Span 和上游系统对应的父级 Span 之间是 FollowsFrom 关系。
Logs
每个 Span 可以进行多次 Logs 操作，每一次 Logs 操作，都需要带一个时间戳，以及一个可选的附加信息。
Tags
每个 Span 可以有多个键值对形式的 Tags，Tags 是没有时间戳的，只是为 Span 添加一些简单解释和补充信息。
SpanContext 和 Baggage
SpanContext 表示进程边界，在跨进调用时需要将一些全局信息，例如，TraceId、当前 SpanId 等信息封装到 Baggage 中传递到另一个进程（下游系统）中。
Baggage 是存储在 SpanContext 中的一个键值对集合。它会在一条 Trace 中全局传输，该 Trace 中的所有 Span 都可以获取到其中的信息。
需要注意的是，由于 Baggage 需要跨进程全局传输，就会涉及相关数据的序列化和反序列化操作，如果在 Baggage 中存放过多的数据，就会导致序列化和反序列化操作耗时变长，使整个系统的 RPC 的延迟增加、吞吐量下降。
虽然 Baggage 与 Span Tags 一样，都是键值对集合，但两者最大区别在于 Span Tags 中的信息不会跨进程传输，而 Baggage 需要全局传输。因此，OpenTracing 要求实现提供 Inject 和 Extract 两种操作，SpanContext 可以通过 Inject 操作向 Baggage 中添加键值对数据，通过 Extract 从 Baggage 中获取键值对数据。
核心接口语义
OpenTracing 希望各个实现平台能够根据上述的核心概念来建模实现，不仅如此，OpenTracing 还提供了核心接口的描述，帮助开发人员更好的实现 OpenTracing 规范。
Span 接口
Span接口必须实现以下的功能：
获取关联的 SpanContext：通过 Span 获取关联的 SpanContext 对象。
关闭（Finish）Span：完成已经开始的 Span。
添加 Span Tag：为 Span 添加 Tag 键值对。
添加 Log：为 Span 增加一个 Log 事件。
添加 Baggage Item：向 Baggage 中添加一组键值对。
获取 Baggage Item：根据 Key 获取 Baggage 中的元素。
SpanContext 接口
SpanContext 接口必须实现以下功能，用户可以通过 Span 实例或者 Tracer 的 Extract 能力获取
SpanContext 接口实例。
Tracer 接口
Tracer 接口必须实现以下功能：
创建 Span：创建新的 Span。
注入 SpanContext：主要是将跨进程调用携带的 Baggage 数据记录到当前 SpanContext 中。
提取 SpanContext ，主要是将当前 SpanContext 中的全局信息提取出来，封装成 Baggage 用于
后续的跨进程调用。

1.3 常见APM系统

我们前面提到了APM系统，APM 系统（Application Performance Management，即应用性能管理）是对企业的应用系统进行实时监控，实现对应用性能管理和故障定位的系统化解决方案，在运维中常用。

CAT（开源）：由国内美团点评开源的，基于 Java 语言开发，目前提供 Java、C/C++、Node.js、Python、Go 等语言的客户端，监控数据会全量统计。国内很多公司在用，例如美团点评、携程、拼多多等。CAT 需要开发人员手动在应用程序中埋点，对代码侵入性比较强。
Zipkin（开源）：由 Twitter 公司开发并开源，Java 语言实现。侵入性相对于 CAT 要低一点，需要对web.xml 等相关配置文件进行修改，但依然对系统有一定的侵入性。Zipkin 可以轻松与Spring Cloud 进行集成，也是 Spring Cloud 推荐的 APM 系统。
Pinpoint（开源）：韩国团队开源的 APM 产品，运用了字节码增强技术，只需要在启动时添加启动参数即可实现 APM 功能，对代码无侵入。目前支持 Java 和 PHP 语言，底层采用 HBase 来存储数据，探针收集的数据粒度非常细，但性能损耗较大，因其出现的时间较长，完成度也很高，文档也较为丰富，应用的公司较多。
SkyWalking（开源）：国人开源的产品，2019 年 4 月 17 日 SkyWalking 从 Apache 基金会的孵化器毕业成为顶级项目。目前 SkyWalking 支持 Java、.Net、Node.js 等探针，数据存储支持MySQL、ElasticSearch等。
还有很多不开源的 APM 系统，例如，淘宝鹰眼、Google Dapper 等等。
我们将学习Skywalking，Skywalking有很多优秀特性。SkyWalking 对业务代码无侵入，性能表现优秀，SkyWalking 增长势头强劲，社区活跃，中文文档齐全，支持多语言探针， SkyWalking 支持Dubbo、gRPC、SOFARPC 等很多框架。

1.4 Skywalking介绍

Skywalking是一个可观测性分析平台和应用性能管理系统，它也是基于OpenTracing规范、开源的AMP系统。Skywalking提供分布式跟踪、服务网格遥测分析、度量聚合和可视化一体化解决方案。支持Java.Net Core, PHP, NodeJS, Golang, LUA, c++代理。支持Istio +特使服务网格
我们在学习Skywalking之前，可以先访问官方提供的控制台演示
演示地址：http://demo.skywalking.apache.org/ 账号：skywalking 密码：skywalking

SkyWalking 核心功能：

服务、服务实例、端点指标分析。
服务拓扑图分析
服务、服务实例和端点（Endpoint）SLA 分析
慢查询检测
告警
SkyWalking 特点：
多语言自动探针，支持 Java、.NET Code 等多种语言。
为多种开源项目提供了插件，为 Tomcat、 HttpClient、Spring、RabbitMQ、MySQL 等常见基础设施和组件提供了自动探针。
微内核 + 插件的架构，存储、集群管理、使用插件集合都可以进行自由选择。
支持告警。
优秀的可视化效果。

Skywalking架构图：

SkyWalking 分为三个核心部分：
Agent（探针）：Agent 运行在各个服务实例中，负责采集服务实例的 Trace 、Metrics 等数据，然后通过 gRPC 方式上报给 SkyWalking 后端。
OAP：SkyWalking 的后端服务，其主要责任有两个。
一个是负责接收 Agent 上报上来的 Trace、Metrics 等数据，交给 Analysis Core （涉及SkyWalking OAP 中的多个模块）进行流式分析，最终将分析得到的结果写入持久化存储中。SkyWalking 可以使用 ElasticSearch、H2、MySQL 等作为其持久化存储，一般线上使用ElasticSearch 集群作为其后端存储。
另一个是负责响应 SkyWalking UI 界面发送来的查询请求，将前面持久化的数据查询出来，组成正确的响应结果返回给 UI 界面进行展示。
UI 界面：SkyWalking 前后端进行分离，该 UI 界面负责将用户的查询操作封装为 GraphQL 请求
提交给 OAP 后端触发后续的查询操作，待拿到查询结果之后会在前端负责展示。

2 Skywalking安装

Skywalking数据存储方式有2种，分别为H2(内存)和elasticsearch，如果数据量比较大，建议使用后者，工作中也建议使用后者。
Skywalking自身提供了UI管理控制台，我们安装的组件：

1:elasticsearch,建议使用elasticsearch7.x
2:elasticsearch-hq,elasticsearch的管理工具，更方便管理elasticsearch
3:Skywalking
4:Skywalking-UI

2.1 elasticsearch安装

1)系统资源配置修改
elasticsearch占用系统资源比较大，我们需要修改下系统资源配置，这样才能很好的运行
elasticsearch，修改虚拟机配置， vi /etc/security/limits.conf ，追加内容:

* soft nofile 65536
* hard nofile 65536

修改 vi /etc/sysctl.conf ，追加内容 :

vm.max_map_count=655360

让配置立即生效：

/sbin/sysctl -p

2)安装elasticsearch
建议安装elasticsearch7.x，我们这里选择7.6.2,并且采用容器的安装方式，安装如下：

docker run --name elasticsearch -p 9200:9200 -p 9300:9300 -e "discovery.type=single-node" -e ES_JAVA_OPTS="-Xms84m -Xmx512m" -d elasticsearch:7.6.2

3)elasticsearch跨域配置
elasticsearch默认是没有开启跨域，我们需要配置跨域，并配置集群节点名字：

#进入容器
docker exec -it elasticsearch /bin/bash

修改容器中 /usr/share/elasticsearch/config/elasticsearch.yml 文件，添加配置如下：

cluster.name: "elasticsearch"
http.cors.enabled: true
http.cors.allow-origin: "*"
network.host: 0.0.0.0
discovery.zen.minimum_master_nodes: 1

参数说明：

cluster.name:集群服务名字
http.cors.enabled:开启跨域
http.cors.allow-origin: 允许跨域域名，*代表所有域名
network.host: 外部访问的IP
discovery.zen.minimum_master_nodes: 最小主节点个数

安装完成后，重启容器 docker restart elasticsearch ，再访问 http://192.168.211.145:9200/
效果如下：

安装 ElasticSearch管理界面elasticsearch-hq

docker run -d --name elastic-hq -p 5000:5000 --restart always elastichq/elasticsearch-hq

安装完成后，访问控制台地址 http://192.168.211.145:5000/#!/clusters/elasticsearch

2.2 Skywalking安装

Skywalking的安装我们也采用Docker安装方式，同时我们需要为Skywalking指定存储服务：

docker pull apache/skywalking-oap-server:8.3.0-es7

#安装Skywalking
docker run --name oap --restart always -d \
--restart=always \
-e TZ=Asia/Shanghai \
-p 12800:12800 \
-p 11800:11800 \
--link es7:es7 \
-e SW_STORAGE=elasticsearch7 \
-e SW_STORAGE_ES_CLUSTER_NODES=es7:9200 \
apache/skywalking-oap-server:8.3.0-es7

参数说明：

--link elasticsearch:elasticsearch:存储服务使用elasticsearch
-e SW_STORAGE=elasticsearch7：存储服务elasticsearch的版本
-e SW_STORAGE_ES_CLUSTER_NODES=elasticsearch:9200:存储服务elasticsearch的链接地址

接下来安装Skywalking-UI，需要指定Skywalking服务名字：

docker pull docker pull apache/skywalking-ui:8.3.0

docker run -d --name skywalking-ui \
--restart=always \
-e TZ=Asia/Shanghai \
-p 8080:8080 \
--link oap:oap \
-e SW_OAP_ADDRESS=oap:12800 \
apache/skywalking-ui:8.3.0

安装完成后，我们接下来访问Skywalking控制台：http://192.168.211.145:8080

3 Skywalking应用

3.1 agent下载

Skywalking-agent，它简称探针，用来收集和发送数据到归集器，我们先来学习下探针使用，探针对应
的jar包在Skywalking源码中，我们需要先下载源码。
Skywalking源码下载地址： https://archive.apache.org/dist/skywalking/ ,我们当前使用的版本是8.3.0 ，选择下载对应版本。

agent目录结构如下：

├── activations │ ├── apm-toolkit-kafka-activation-8.3.0.jar │ ├── ... │ └── apm-toolkit-trace-activation-8.3.0.jar ├── config # Agent 配置文件 │ └── agent.config ├── logs # 日志文件 ├── optional-plugins # 可选插件 │ ├── apm-customize-enhance-plugin-8.3.0.jar │ ├── apm-gson-2.x-plugin-8.3.0.jar目录结构说明：│ └── ... ... ├── bootstrap-plugins # jdk插件 │ ├── apm-jdk-http-plugin-8.3.0.jar │ └── apm-jdk-threading-plugin-8.3.0.jar ├── plugins # 当前生效插件 │ ├── apm-activemq-5.x-plugin-8.3.0.jar │ ├── apm-armeria-0.84.x-plugin-8.3.0.jar │ ├── apm-armeria-0.85.x-plugin-8.3.0.jar │ └── ... ... ├── optional-reporter-plugins │ └── kafka-reporter-plugin-8.3.0.jar └── skywalking-agent.jar【应用的jar包】

目录结构说明：

activations 当前skywalking正在使用的功能组件。
agent.config 文件是 SkyWalking Agent 的唯一配置文件。
plugins 目录存储了当前 Agent 生效的插件。
optional-plugins 目录存储了一些可选的插件（这些插件可能会影响整个系统的性或是有版权问 题），如果需要使用这些插件，需将相应 jar 包移动到 plugins 目下。
skywalking-agent.jar 是 Agent 的核心 jar 包，由它负责读取 agent.config配置文件，加载 上述插件 jar 包，运行时收集到 的 Trace 和 Metrics 数据也是由它发送到 OAP 集群的。

我们在使用Skywalking的时候，整个过程中都会用到 skywalking-agent.jar ，而无论是RPC还是
HTTP开发的项目，用法都一样，因此我们讲解当前主流的SpringBoot项目对agent的使用即可。

3.2 agent应用

项目使用agent，如果是开发环境，可以使用IDEA集成，如果是生产环境，需要将项目打包上传到服务器。为了使用agent，我们同时需要将下载的 apache-skywalking-apm-bin 文件包上传到服务器上去。不过无论是开发环境还是生产环境使用agent，对项目都是无侵入式的。

3.2.1 应用名配置

我们需要用到 agent ，此时需要将 agent/config/agent.config 配置文件拷贝到每个需要集成Skywalking工程的resource目录下，我们将 agent.config 拷贝到工程\hailtaxi-parent 的每个子工程目录下，并修改其中的agent.service_name，修改如下：

hailtaxi-gateway: agent.service_name=${SW_AGENT_NAME:hailtaxi-gateway}
hailtaxi-driver: agent.service_name=${SW_AGENT_NAME:hailtaxi-driver}
hailtaxi-order: agent.service_name=${SW_AGENT_NAME:hailtaxi-order}

agent.config 是一个 KV 结构的配置文件，类似于 properties 文件，value 部分使用 “${}” 包裹，其中使用冒号（“:”）分为两部分，前半部分是可以覆盖该配置项的系统环境变量名称，后半部分为默认值。例如这里的 agent.service_name 配置项，如果系统环境变量中指定了SW_AGENT_NAME 值（注意，全是大写），则优先使用环境变量中指定的值，如果环境变量未指定，则使用 hailtaxi-driver 这个默认值。直接把配置修改好后放到项目的resource目录下(或者其他路径)是最不容易才出错的一种方式，同时我们可以采用其他方式覆盖默认值：

1)JVM覆盖配置
例如这里的 agent.service_name 配置项，如果在 JVM 启动之前，明确中指定了下面的 JVM 配置：

# "skywalking."是 Skywalking环境变量的默认前缀
-Dskywalking.agent.service_name = hailtaxi-driver

2)探针配置覆盖
将 Java Agent 配置为如下：

# 默认格式是 -javaagent:agent.jar=[option1]=[value1],[option2]=[value2]
-javaagent:/path/skywalking-agent.jar=agent.service_name=hailtaxi-driver

此时会使用该 Java Agent 配置值覆盖 agent.config 配置文件中 agent.service_name 默认值。但是这些配置都有不同优先级，优先级如下

探针配置 > JVM配置 > 系统环境变量配置 > agent.config文件默认值

3.2.2 IDEA集成使用agent

开发环境IDEA中使用探针配置即可集成使用agent，我们把 apache-skywalking-apm-bin 放到本地D:/dev/install/ 目录下，此时我们使用探针配置为3个项目分别配置agent：

1)hailtaxi-driver:

-javaagent:D:/dev/install/apache-skywalking-apm-bin/agent/skywalking-agent.jar -Dskywalking_config=D:/project/skywalking/hailtaxi-parent/hailtaxi-driver/src/main/resources/agent.config -Dskywalking.collector.backend_service=192.168.211.145:11800

将上面配置赋值到IDEA中：

2)hailtaxi-order

-javaagent:D:/dev/install/apache-skywalking-apm-bin/agent/skywalking-agent.jar -Dskywalking_config=D:/project/skywalking/hailtaxi-parent/hailtaxi-order/src/main/resources/agent.config -Dskywalking.collector.backend_service=192.168.211.145:11800

3)hailtaxi-gateway

-javaagent:D:/dev/install/apache-skywalking-apm-bin/agent/skywalking-agent.jar -Dskywalking_config=D:/project/skywalking/hailtaxi-parent/hailtaxi-gateway/src/main/resources/agent.config -Dskywalking.collector.backend_service=192.168.211.145:11800

将上面配置赋值到IDEA中：

此时启动IDEA，并访问 http://192.168.211.145:8080/ 效果如下：

3.3.3 生产环境使用agent

生产环境使用，因此我们需要将agent和每个项目的jar包上传到服务器上，上传 apache-skywalking- apm-bin 至 /usr/local/server/skywalking ，再将工程\hailtaxi-parent 中的项目打包，并分别上传到服务器上，如下三个工程：

1)启动hailtaxi-gateway

java -javaagent:/usr/local/server/skywalking/apache-skywalking-apm-bin/agent/skywalking-agent.jar -Dskywalking.agent.service_name=hailtaxi-gateway -jar hailtaxi-gateway-1.0-SNAPSHOT.jar &

2)启动hailtaxi-driver

java -javaagent:/usr/local/server/skywalking/apache-skywalking-apm- bin/agent/skywalking-agent.jar -Dskywalking.agent.service_name=hailtaxi-driver -jar hailtaxi-driver-1.0-SNAPSHOT.jar &

3)启动hailtaxi-order

java -javaagent:/usr/local/server/skywalking/apache-skywalking-apm-bin/agent/skywalking-agent.jar -Dskywalking.agent.service_name=hailtaxi-order -jar hailtaxi-order-1.0-SNAPSHOT.jar &

nohup java -javaagent:/data/app/tzsb-zhgl/controller/apache-skywalking-apm-bin/agent/skywalking-agent.jar -Dskywalking.agent.service_name=is-controller -Dskywalking.collector.backend_service=10.145.241.11:11800 -Dloader.path=lib -jar is-controller-0527.jar --spring.profiles.active=prod > /dev/null 2>&1 &

3.3 Rocketbot

前面我们已经完成了SkyWalking环境搭建和项目应用agent使用，我们来看如何使用 SkyWalking 提供的 UI 界面—— Skywalking Rocketbot。
OAP服务和Rocket（其实就是个web项目）波特均已启动

3.3.1 Rocketbot-仪表盘

作用：查看被监控服务的运行状态
1)监控面板

1.1 APM

APM：应用性能管理，通过各种探针采集数据，收集关键指标，同时搭配数据呈现以实现对应用程序性能管理和故障管理的系统化解决方案。

1.1.1 Global全局维度

板块描述：

Services load:服务每分钟请求数
Slow Services:慢响应服务，单位ms
Un-Health services(Apdex):Apdex性能指标，1为满分。
Show Endpoints:慢响应端点，单面ms
Global Response Latency:百分比响应延时，不同百分比的延时时间，单位ms
Global Heatmap:服务响应时间热力分布图，根据时间段内不同响应时间的数量显示颜色深度
底部栏:展示数据的时间区间，点击可以调整

1.1.2 Service服务维度

属性描述：

Service Apdex（数字）:当前服务的评分
Service Apdex（折线图）:不同时间的Apdex评分
Service Avg Response Times:平均响应延时，单位ms
Global Response Time Percentile:百分比响应延时
Successful Rate（数字）:请求成功率
Successful Rate（折线图）:不同时间的请求成功率
Servce Load（数字）:每分钟请求数
Servce Load（折线图）:不同时间的每分钟请求数
Servce Instances Load:每个服务实例的每分钟请求数
Show Service Instance:每个服务实例的最大延时
Service Instance Successful Rate:每个服务实例的请求成功率

1.1.3 Instance实例维度

属性描述：

Service Instance Load:当前实例的每分钟请求数
Service Instance Successful Rate:当前实例的请求成功率
Service Instance Latency:当前实例的响应延时
JVM CPU:jvm占用CPU的百分比
JVM Memory:JVM内存占用大小，单位m
JVM GC Time:JVM垃圾回收时间，包含YGC和OGC
JVM GC Count:JVM垃圾回收次数，包含YGC和OGC
JVM Thread Count (Java Service):JVM创建线程数量
CLR xx:类似JVM虚拟机(可以直接理解成虚拟机)

1.1.4 Endpoint端点（API）维度

属性描述:

Endpoint Load in Current Service:每个端点的每分钟请求数
Slow Endpoints in Current Service:每个端点的最慢请求时间，单位ms
Successful Rate in Current Service:每个端点的请求成功率
Endpoint Load:当前端点每个时间段的请求数据
Endpoint Avg Response Time:当前端点每个时间段的请求行响应时间
Endpoint Response Time Percentile:当前端点每个时间段的响应时间占比
Endpoint Successful Rate:当前端点每个时间段的请求成功率

1.2 DataSource展示栏

属性描述:

当前数据库：选择查看数据库指标
Database Avg Response Time:当前数据库事件平均响应时间，单位ms
Database Access Successful Rate:当前数据库访问成功率
Database Traffic:CPM，当前数据库每分钟请求数
Database Access Latency Percentile:数据库不同比例的响应时间，单位ms
Slow Statements:前N个慢查询，单位ms
All Database Loads:所有数据库中CPM排名
Un-Health Databases:所有数据库健康排名，请求成功率排名

注意：

Istio:适配容器/k8s，采集容器信息并呈现。
https://istio.io/latest/zh/docs/reference/config/policy-and- telemetry/adapters/apache-skywalking/ SelfObservability:自监控，监控Skywalking自身信息。 Web Browser:SkyWalking 8.2.0 拓展了核心功能，并将其监控边界拓展到浏览器端。使用者不仅可以 像以前一样监控浏览器发送给后端服务的与请求，还能看到前端的渲染速度、错误日志等信息。

1.3 编辑仪表盘

指标:

read the single value in the duration:读取持续时间内的单个值
read all values in the duration:读取持续时间内的所有值
get sorted top N values:排序前N个值

选择器(确定指定服务)：

Common selectors:通用选择器
Self selectors:自定义选择器

数据计算:

Plus +(加)
Minus -(减)
Multiplication *(乘)
Division ÷(除法)
Convert Unix Timestamp(时间转换)

3.3.2 Rocketbot-拓扑图

【拓扑图】展示当前整个业务服务的拓扑图。点击拓扑图中的任意节点，可以看到服务相应的状态信息，其中包括响应的平均耗时、SLA 等监控信息。点击拓扑图中任意一条边，还可以看到一条调用链路的监控信息，其中会分别从客户端（上游调用方）和服务端（下游接收方）来观测这条调用链路的状态，其中展示了该条链路的耗时、吞吐量、SLA 等信息。

3.3.3 追踪

属性描述:

左侧:api接口列表，红色-异常请求，蓝色-正常请求
右侧:api追踪列表，api请求连接各端点的先后顺序和时间

【追踪】主要用来查询 Trace 信息，如下图所示。在①处可以选择Trace 的查询条件，其中可以指定Trace 涉及到的 Service、ServiceInstance、Endpoint 以及Trace 的状态继续模糊查询，还可以指定TraceId 和时间范围进行精确查询。在②处可以直接根据请求连接查找调用链路信息。在③处展示了Trace 的简略信息。在④处可以选择不同的方式展示追踪信息。

在这里，我们不仅能看到调用链路信息，还能看到MySQL操作监控,如下图：

错误异常信息也能追踪,如下图：

3.3.4 性能分析

在传统的监控系统中，我们如果想要得知系统中的业务是否正常，会采用进程监控、日志收集分析等方式来对系统进行监控。当机器或者服务出现问题时，则会触发告警及时通知负责人。通过这种方式，我们可以得知具体哪些服务出现了问题。但是这时我们并不能得知具体的错误原因出在了哪里，开发人员或者运维人员需要到日志系统里面查看错误日志，甚至需要到真实的业务服务器上查看执行情况来解决问题。
如此一来，仅仅是发现问题的阶段，可能就会耗费相当长的时间；另外，发现问题但是并不能追溯到问题产生具体原因的情况，也常有发生。这样反反复复极其耗费时间和精力，为此我们便有了基于分布式
追踪的APM系统。
通过将业务系统接入分布式追踪中，我们就像是给程序增加了一个放大镜功能，可以清晰看到真实业务请求的整体链路，包括请求时间、请求路径，甚至是操作数据库的语句都可以看得一清二楚。通过这种方式，我们结合告警便可以快速追踪到真实用户请求的完整链路信息，并且这些数据信息完全是持久化的，可以随时进行查询，复盘错误的原因。

然而随着我们对服务监控理解的加深，我们发现事情并没有那么简单。在分布式链路追踪中我们有这样的两个流派：代码埋点和字节码增强。无论使用哪种方式，底层逻辑一定都逃不过面向切面这个基础逻辑。因为只有这样才可以做到大面积的使用。这也就决定了它只能做到框架级别和RPC粒度的监控。这时我们可能依旧会遇到程序执行缓慢或者响应时间不稳定等情况，但无法具体查询到原因。这时候，大家很自然的会考虑到增加埋点粒度，比如对所有的Spring Bean方法、甚至主要的业务层方法都加上埋点。但是这种思路会遇到不小的挑战：
第一，增加埋点时系统开销大，埋点覆盖不够全面。通过这种方式我们确实可以做到具体业务场景具体分析。但随着业务不断迭代上线，弊端也很明显：大量的埋点无疑会加大系统资源的开销，造成CPU、内存使用率增加，更有可能拖慢整个链路的执行效率。虽然每个埋点消耗的性能很小，在微秒级别，但是因为数量的增加，甚至因为业务代码重用造成重复埋点或者循环使用，此时的性能开销已经无法忽略。
第二，动态埋点作为一项埋点技术，和手动埋点的性能消耗上十分类似，只是减少的代码修改量，但是因为通用技术的特别，上一个挑战中提到的循环埋点和重复使用的场景甚至更为严重。比如选择所有方法或者特定包下的所有方法埋点，很可能造成系统性能彻底崩溃。
第三，即使我们通过合理设计和埋点，解决了上述问题，但是JDK函数是广泛使用的，我们很难限制对JDK API的使用场景。对JDK过多方法、特别是非RPC方法的监控会造成系统的巨大延迟风险。而且有一些基础类型和底层工具类，是很难通过字节码进行增强的。当我们的SDK使用不当或者出现bug时，我们无法具体得知真实的错误原因。
Skywalking中可以使用性能剖析分析特定断点的性能，我们需要先创建一个监控任务：

新建任务后，在右侧可以查看任务性能分析报表，还可以点击分析线程栈信息，如下图：新建性能剖析属性描述:

服务:需要分析的服务
端点:链路监控中端点的名称，可以再链路追踪中查看端点名称
监控时间:采集数据的开始时间
监控持续时间:监控采集多长时间
起始监控时间:多少秒后进行采集
监控间隔:多少秒采集一次
最大采集数:最大采集多少样本

3.3.5 告警

3.3.5.1 警告规则详解

Skywalking每隔一段时间根据收集到的链路追踪的数据和配置的告警规则（如服务响应时间、服务响应时间百分比）等，判断如果达到阈值则发送相应的告警信息。发送告警信息是通过调用webhook接口完成，具体webhook接口可以使用者自行定义，从而开发者可以在指定的webhook接口中编写各种告警方式，比如邮件、短信等。告警的信息也可以在RocketBot中查看到。
我们可以进入到Skywalking容器中，再进入到config文件夹下就可以看到alarm-settings.yml，如下图：

警告规则配置有很多关键词,了解这些关键词后更容易理解警告配置，告警规则组成关键字段如下：
告警规则组成关键字段如下

1:Rule name：具有唯一性，展示在告警信息里面，必须以_rule结尾。
2:Metrics name：oal脚本里面的指标名称，支持long, double, int 类型。
3:Include names：规则里包含的实体名称，例如：服务名字，端点名字。
4:Excluse names：规则里排除的实体名称，例如：服务名字，端点名字。
5:Threshold：目标值（阈值）。对于多值指标（如：百分位），这个阈值是一个数组，格式如： value1,value2,value3,value4,value5。与指标格式一一对应。当不想其中某些指标触发告警时，阈 值设置为横杠(-)
6:OP：操作，目前支持 >，>=，<，<=，=。
7:Period：周期。一个时间窗口，表示告警规则应当被检测多长时间。
8:Count：在期限窗口时间段内，如果统计次数达到阈值，将触发告警。
9:Silence Period：静默时间，表示在多长时间内只会触发一次告警。默认值和Period相同，即在一个 周期内，只会触发一次告警。

alarm-settings.yml配置如下：

#告警规则配置，展示最近10分钟内的告警数据
rules:# Rule unique name, must be ended with `_rule`.# 规则名称不能重复，且必须以`_rule`结尾#========================================service_resp_time Start======================================================service_resp_time_rule:#指定的规则名称（与规则名不同，这里是对应的告警中的规则map），oal目录下文件中指定的变量名字#平均响应时间metrics-name: service_resp_time# 比较操作符，可以设定>,<,=op: ">"# 阈值threshold: 1000# 多久检查一次当前的指标数据是否符合告警规则period: 10# 达到多少次告警后，发送告警消息count: 3# 在多久之内，忽略相同的告警消息silence-period: 5# 告警消息内容   {name}服务在过去10分钟中有3(变化值)分钟响应时间大于1000ms。message: Response time of service {name} is more than 1000ms in 3 minutes of last 10 minutes.#========================================service_resp_time End======================================================service_sla_rule:#度量单位为Long/int/dubbo# Metrics value need to be long, double or int# 成功率规则定义metrics-name: service_sla# 成功率低于指定值op: "<"# 阈值threshold: 8000# 多久检查一次当前的指标数据是否符合告警规则period: 10#达到多少次告警后，发送告警消息count: 2# 在多久之内，忽略相同的告警消息silence-period: 3#告警消息内容   {name}服务在过去10分钟的2(变化值)分钟内成功率低于80%message: Successful rate of service {name} is lower than 80% in 2 minutes of last 10 minutesservice_resp_time_percentile_rule:# Metrics value need to be long, double or int#响应时间百分比metrics-name: service_percentileop: ">"threshold: 1000,1000,1000,1000,1000period: 10count: 3silence-period: 5#告警消息内容   {name}服务告警在过去10分钟的3分钟内的百分比响应时间，#一下至少有一个条件成立#50%以上请求响应时间超过1000毫秒#75%以上请求响应时间超过1000毫秒#90%以上请求响应时间超过100毫秒message: Percentile response time of service {name} alarm in 3 minutes of last 10 minutes, due to more than one condition of p50 > 1000, p75 > 1000, p90 > 100service_instance_resp_time_rule:# 服务实例的平均响应时间超过1秒metrics-name: service_instance_resp_timeop: ">"threshold: 1000period: 10count: 2silence-period: 5#告警消息内容  {name}服务实例最近10分钟内2分钟平均响应时间大于1000msmessage: Response time of service instance {name} is more than 1000ms in 2 minutes of last 10 minutesdatabase_access_resp_time_rule:#数据库访问响应时间metrics-name: database_access_resp_timethreshold: 1000op: ">"period: 10count: 2#告警消息内容  {name}数据库访问的响应时间在最近10分钟的2分钟内大于1000msmessage: Response time of database access {name} is more than 1000ms in 2 minutes of last 10 minutesendpoint_relation_resp_time_rule:#端点平均响应时间(某个请求路径响应时间)metrics-name: endpoint_relation_resp_timethreshold: 1000op: ">"period: 10count: 2# {name}端点在最近10分钟的2分钟内响应时间大于1000msmessage: Response time of endpoint relation {name} is more than 1000ms in 2 minutes of last 10 minutes
#  Active endpoint related metrics alarm will cost more memory than service and service instance metrics alarm.
#  Because the number of endpoint is much more than service and instance.
#
#  endpoint_avg_rule:
#    metrics-name: endpoint_avg
#    op: ">"
#    threshold: 1000
#    period: 10
#    count: 2
#    silence-period: 5
#    message: Response time of endpoint {name} is more than 1000ms in 2 minutes of last 10 minutes
# webhooks每3分钟推送一次
webhooks:
#  - http://127.0.0.1/notify/
#  - http://127.0.0.1/go-wechat/

以上文件定义了默认的5种规则：

1:最近3分钟内服务平均响应时间超过1秒。
2:最近2分钟的服务成功率低于80％。
3:最近3分钟的服务响应时间百分比超过1s。
4:最近2分钟内服务实例的平均响应时间超过1秒。
5:最近2分钟内端点平均响应时间超过1秒。

这些警告信息最终会在Skywalking-UI上展示，效果如下：

3.3.5.2 Webhook规则

Webhook配置其实是警告消息接收回调处理，我们可以在程序中写一个方法接收警告信息，Skywalking会以 application/json 格式通过http请求发送，消息格式声明为：
List<org.apache.skywalking.oap.server.core.alarm.AlarmMessage 。

字段如下：
scopeId, scope: 所有的scope实体在
org.apache.skywalking.oap.server.core.source.DefaultScopeDefifine 里面声明。
name. 目标scope实体名称。
id0: scope实体ID，匹配名称。
id1: 不使用。
ruleName: 配置在 alarm-settings.yml 里面的规则名称.
alarmMessage: 告警信息.
startTime：触发告警的时间示例：

[ { "scopeId": 2, "scope": "SERVICE_INSTANCE", "name": "c00158f28efc45cd813e21b6b8848a3a@192.168.1.104 of hailtaxi-driver", "id0": "aGFpbHpdmVy.1_YzAwMAMTkyLjE2OC4xLjEwNA\u003d\u003d", "id1": "", "ruleName": "service_instance_resp_time_rule", "alarmMessage": "Response time of service instance c00158f28efc45cd813e21b6b8848a3a@192.168.1.104 of hailtaxi-driver is more than 1000ms in 2 minutes of last 10 minutes", "startTime": 1611612258056 }]

3.3.5.3 自定义Webhook消息接收
我们按照如下步骤，可以在自己程序中接收警告信息：
1)定义消息接收对象
在 hailtaxi-api 中创建 com.itheima.skywalking.model.AlarmMessage ，代码如下：

@Data @ToString @AllArgsConstructor @NoArgsConstructor public class AlarmMessage { private int scopeId; private String name; private String id0; private String id1; private String alarmMessage; private long startTime; String ruleName; }

2)接收警告方法创建
在 hailtaxi-driver 中创建 com.itheima.driver.controller.AlarmMessageController 用于接收警告消息，代码如下：

@RestController @RequestMapping(value = "/skywalking") public class AlarmMessageController { /*** \* 接收警告信息 \* @param alarmMessageList */ @PostMapping("/webhook") public void webhook(@RequestBody List<AlarmMessage> alarmMessageList) { for (AlarmMessage alarmMessage : alarmMessageList) { System.out.println("webhook:"+alarmMessage);       } } }

3)修改Webhook地址
修改 alarm-settings.yml 中的webhook地址：

webhooks: - http://192.168.211.1:18081/skywalking/webhook/ - # - http://127.0.0.1/go-wechat/

此时我们程序中就能接收警告信息了。