WM_Skywalking应用实战暂时没用

Skywalking应用实战

能力目标：

能够理解服务监控三要素

能够理解常用的

APM系统优势差异

能够基于

IDEA集成Skywalking Agent

能基于生产环境使用Skywalking Agent

掌握Rocketbot

性能分析

链路追踪

仪表盘应用

Webhook

1 Skywalking概述

随着互联网架构的扩张，分布式系统变得日趋复杂，越来越多的组件开始走向分布式化，如微服务、消

息收发、分布式数据库、分布式缓存、分布式对象存储、跨域调用，这些组件共同构成了繁杂的分布式

网络。

我们思考下这些问题：

这些问题要想得到解决，一定是有数据支撑，绝不是靠开发人员或者运维人员的直觉。为了解决分布式

应用、微服务系统面临的这些挑战，APM系统营运而生。

1:一个请求经过了这些服务后其中出现了一个调用失败的问题，如何定位问题发生的地方？

2:如何计算每个节点访问流量？

3:流量波动的时候，增加哪些节点集群服务？

1.1 微服务系统监控三要素

Logging 就是记录系统行为的离散事件，例如，服务在处理某个请求时打印的错误日志，我们可以

将这些日志信息记录到 ElasticSearch 或是其他存储中，然后通过 Kibana 或是其他工具来分析这

些日志了解服务的行为和状态。大多数情况下，日志记录的数据很分散，并且相互独立，比如错误

日志、请求处理过程中关键步骤的日志等等。

Metrics 是系统在一段时间内某一方面的某个度量，可聚合的数据，且通常是固定类型的时序数

据，例如，电商系统在一分钟内的请求次数。我们常见的监控系统中记录的数据都属于这个范畴，

例如 Promethus、Open-Falcon 等，这些监控系统最终给运维人员展示的是一张张二维的折线

图。Metrics 是可以聚合的，例如，为电商系统中每个 HTTP 接口添加一个计数器，计算每个接口

的 QPS，之后我们就可以通过简单的加和计算得到系统的总负载情况。

Tracing 即我们常说的分布式链路追踪，记录单个请求的处理流程，其中包括服务调用和处理时长

等信息。在微服务架构系统中一个请求会经过很多服务处理，调用链路会非常长，要确定中间哪个

服务出现异常是非常麻烦的一件事。通过分布式链路追踪，运维人员就可以构建一个请求的视图，

这个视图上展示了一个请求从进入系统开始到返回响应的整个流程。这样，就可以从中了解到所有

服务的异常情况、网络调用，以及系统的性能瓶颈等。

1.2 什么是链路追踪

谷歌在 2010 年 4 月发表了一篇论文《Dapper, a Large-Scale Distributed Systems Tracing

Infrastructure》介绍了分布式追踪的概念，之后很多互联网公司都开始根据这篇论文打造自己的分布式

链路追踪系统。APM 系统的核心技术就是分布式链路追踪。

论文在线地址：https://storage.googleapis.com/pub-tools-public-publication-data/pdf/36356.pdf，

国内的翻译版：https://bigbully.github.io/Dapper-translation/

在此文中阐述了Google在生产环境下对于分布式链路追踪系统Drapper的设计思路与使用经验。随后各

大厂商基于这篇论文都开始自研自家的分布式链路追踪产品。如阿里的Eagle eye(鹰眼)、zipkin，京东

的“Hydra”、大众点评的“CAT”、新浪的“Watchman”、唯品会的“Microscope”、窝窝网的“Tracing”都是

基于这片文章的设计思路而实现的。所以要学习分布式链路追踪，对于Dapper论文的理解至关重要。

但是也带来了新的问题：各家的分布式追踪方案是互不兼容的，这才诞生了 OpenTracing。

OpenTracing 是一个 Library，定义了一套通用的数据上报接口，要求各个分布式追踪系统都来实现这

套接口。这样一来，应用程序只需要对接 OpenTracing，而无需关心后端采用的到底什么分布式追踪系

统，因此开发者可以无缝切换分布式追踪系统，也使得在通用代码库增加对分布式追踪的支持成为可

能。

OpenTracing 于 2016 年 10 月加入 CNCF（云原生计算基金会）基金会，是继 Kubernetes 和

Prometheus 之后，第三个加入CNCF 的开源项目。它是一个中立的（厂商无关、平台无关）分布式追

踪的 API 规范，提供统一接口，可方便开发者在自己的服务中集成一种或多种分布式追踪的实现。

OpenTracing API 目前支持的语言众多：

目前，主流的分布式追踪实现基本都已经支持 OpenTracing。

1.2.1 链路追踪

下面通过官方的一个示例简单介绍说明什么是 Tracing,把Tracing学完后，更有助于大家运用Skywalking

UI进行数据分析。

在一个分布式系统中，追踪一个事务或者调用流程，可以用下图方式描绘出来。这类流程图可以看清各

组件的组合关系，但它并不能看出一次调用触发了哪个组件调用、什么时间调用、是串行调用还是并行

调用。

一种更有效的展现方式就是下图这样，这是一个典型的 trace 视图，这种展现方式增加显示了执行时间

的上下文，相关服务间的层次关系，进程或者任务的串行或并行调用关系。这样的视图有助于发现系统

调用的关键路径。通过关注关键路径的执行过程，开发团队就可以专注于优化路径中的关键服务，最大

幅度的提升系统性能。例如下图中，我们可以看到请求串行的调用了授权服务、订单服务以及资源服

务，在资源服务中又并行的执行了三个子任务。我们还可以看到，在这整个请求的生命周期中，资源服

务耗时是最长的。

分布式追踪系统的原理：

分布式追踪系统大体分为三个部分，数据采集、数据持久化、数据展示。数据采集是指在代码中埋点，

设置请求中要上报的阶段，以及设置当前记录的阶段隶属于哪个上级阶段。数据持久化则是指将上报的

数据落盘存储，数据展示则是前端查询与之关联的请求阶段，并在界面上呈现。

上图是一个请求的流程例子，请求从客户端发出，到达负载均衡，再依次进行认证、计费，最后取到目

标资源。请求过程被采集之后，会以上图的形式呈现，横坐标是时间，圆角矩形是请求的执行的各个阶

段

1.2.2 OpenTracing

学好OpenTracing，更有助于我们运用Skywalking 。

1、数据模型：

这部分在 OpenTracing 的规范中写的非常清楚，下面只大概翻译一下其中的关键部分，细节可参考原始

文档《The OpenTracing Semantic Specification》。

Causal relationships between Spans in a single Trace

解释了Trace 和 Span的因果关系

[Span A] ←←←(the root span)

+------+------+

| |

[Span B] [Span C] ←←←(Span C is a `ChildOf` Span A)

| |

[Span D] +---+-------+

| |

[Span E] [Span F] >>> [Span G] >>> [Span H]

↑

(Span G `FollowsFrom` Span F)

Trace

一个 Trace 代表一个事务、请求或是流程在分布式系统中的执行过程。OpenTracing 中的一条 Trace调

用链，由多个 Span 组成，一个 Span 代表系统中具有开始时间和执行时长的逻辑单元，Span 一般会有

一个名称，一条 Trace 中 Span 是首尾连接的。

Span

Span 代表系统中具有开始时间和执行时长的逻辑单元，Span 之间通过嵌套或者顺序排列建立逻辑因果

关系。

如果按时间关系呈现的话如下所示：

每个 Span 中可以包含以下的信息：

操作名称：例如访问的具体 RPC 服务，访问的 URL 地址等；

起始时间；2021-1-25 22:00:00

结束时间；2021-1-30 22:00:00

Span Tag：一组键值对（k-v）构成的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 关系：表示跟随关系，意为在某个阶段之后发生了另一个阶段，用来描述顺序执行关系

Logs

每个 Span 可以进行多次 Logs 操作，每一次 Logs 操作，都需要带一个时间戳，以及一个可选的附加信

息。

相关术语：

3.1 agent

下载

Skywalking-agent

，它简称探针，用来收集和发送数据到归集器，我们先来学习下探针使用，探针对应

的jar包在Skywalking源码中，我们需要先下载源码。

Skywalking源码下载地址： https://archive.apache.org/dist/skywalking/ ，我们当前使用的版本是

8.3.0 ，选择下载对应版本。

agent目录结构如下：

目录结构说明：

skywalking-collector:链路数据归集器，数据可以落地ElasticSearch/H2

skywalking-ui:web可视化平台，用来展示落地的数据

skywalking-ag

ent:探针，用来收集和发送数据到归集器

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包】

我们在使用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，修改如下：

agent.config 是一个 KV 结构的配置文件，类似于 properties 文件，value 部分使用 "${}" 包裹，

其中使用冒号（":"）分为两部分，前半部分是可以覆盖该配置项的系统环境变量名称，后半部分为默

认值。例如这里的 agent.service_name 配置项，如果系统环境变量中指定了 SW_AGENT_NAME 值（注

意，全是大写），则优先使用环境变量中指定的值，如果环境变量未指定，则使用 hailtaxi-driver

这个默认值。

直接把配置修改好后放到项目的resource目录下(或者其他路径)是最不容易才出错的一种方式，同时我

们可以采用其他方式覆盖默认值：

1)JVM覆盖配置

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

2)探针配置覆盖

activations 当前skywalking正在使用的功能组件。

agent.config 文件是 SkyWalking Agent 的唯一配置文件。

plugins 目录存储了当前 Agent 生效的插件。

optional-plugins 目录存储了一些可选的插件（这些插件可能会影响整个系统的性能或是有版权问题），

如果需要使用这些插件，需将相应 jar 包移动到 plugins 目录下。

skywalking-ag

ent.jar 是 Agent 的核心 jar 包，由它负责读取 agent.config 配置文件，加载上

述插件 jar 包，运行时收集到的 Trace 和 Metrics 数据也是由它发送到 OAP 集群的。

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

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

# "skywalking."是 Skywalking环境变量的默认前缀

-Dskywalking.agent.service_name = hailtaxi-driver

将 Java Agent 配置为如下：

此时会使用该 Java Agent 配置值覆盖 agent.config 配置文件中 agent.service_name 默认值。

但是这些配置都有不同优先级，优先级如下：

3.2.2 IDEA

集成使用agent

1、修改agent中数据收集服务的地址： agent/config/agent.confg

当然也可以同构JVM参数配置

2、使用探针配置为2个项目分别配置agent：

1)hailtaxi-driver:

将上面配置赋值到IDEA中：

2)hailtaxi-order

# 默认格式是 -javaagent:agent.jar=[option1]=[value1],[option2]=[value2]

-javaagent:/path/skywalking-agent.jar=agent.service_name=hailtaxi-driver

探针配置 > JVM配

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

collector.backend_service=${SW_AGENT_COLLECTOR_BACKEND_SERVICES:192.168.200.129:

11800}

-javaagent:C:\developer\skywalking\apache-skywalking-apm-bin\agent\skywalking

agent.jar

-Dskywalking.agent.service_name=hailtaxi-driver

-javaagent:C:\developer\skywalking\apache-skywalking-apm-bin\agent\skywalking

agent.jar

-Dskywalking.agent.service_name=hailtaxi-order

将上面配置赋值到IDEA中：

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

如果你要追踪Gateway的话，你会发现：无法通过gateway发现路由的服务链路？

原因： Spring Cloud Gateway 是基于 WebFlux 实现，必须搭配上apm-spring-cloud-gateway-2.1.x

plugin 和 apm-spring-webflux-x.x-plugin 两个插件

方案：将agent/optional-plugins下的两个插件复制到 agent/plugins目录下3.3.3 生产环境使用agent

生产环境使用，因此我们需要将agent和每个项目的jar包上传到服务器上，上传 apache-skywalking

apm-bin 至 /usr/local/server/skywalking ，再将工程\hailtaxi-parent 中的项目打包，并分别上

传到服务器上

1)启动hailtaxi-driver

2)启动hailtaxi-order

3.3 Rocketbot

前面我们已经完成了SkyWalking环境搭建和项目应用agent使用，我们来看如何使用 SkyWalking 提供

的 UI 界面—— Skywalking Rocketbot。

OAP服务和Rocket（其实就是个web项目）均已启动

3.3.1 Rocketbot-仪表盘

具体细则可参考资料： Skywalking仪表盘使用

hailtaxi-order-1.0-SNAPSHOT.jar

hailtaxi-driver-1.0-SNAPSHOT.jar

java -jav

aagent:/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 &

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 &

Rocketbot从多个方面展示了服务信息，我们分别从多个方面进行讲解。

上图中的【仪表盘】、【拓扑图】、【追踪】、【性能剖析】、【日志】、【警告】属于功能菜单。

仪表盘属于数据统计功能，分别从服务热度、响应水平、服务个数、节点信息等展示统计数据。

Global Heatmap 面板：热力图，从全局展示了某段时间请求的热度。

Global Percent Response 面板：展示了全局请求响应时间的 P99、P95、P75 等分位数。

Global Brief 面板：展示了 SkyWalking 能感知到的 Service、Endpoint 的个数。

Global Top Troughput 面板：展示了吞吐量前几名的服务。

Global Top Slow Endpoint 面板：展示了耗时前几名的 Endpoint。

Service (Avg) ResponseTime 面板：展示了指定服务的（平均）耗时。

Service (Avg) Throughput 面板：展示了指定服务的（平均）吞吐量。

Service (Avg) SLA 面板：展示了指定服务的（平均）SLA（Service Level Agreement，服务等级

协议）。

Service Percent Response 面板：展示了指定服务响应时间的分位数。

Service Slow Endpoint 面板：展示了指定服务中耗时比较长的 Endpoint 信息。

Running ServiceInstance 面板：展示了指定服务下的实例信息。

除了 SkyWalking Rocketbot 默认提供的这些面板，我们还可以点击锁型按钮，自定义 Global 面板。在

ServiceInstance 面板中展示了很多 ServiceInstance 相关的监控信息，例如，JVM 内存使用情况、GC

次数、GC 耗时、CPU 使用率、ServiceInstance SLA 等等信息。

3.3.2 Rocketbot-拓扑图

【拓扑图】展示当前整个业务服务的拓扑图。点击拓扑图中的任意节点，可以看到服务相应的状态信

息，其中包括响应的平均耗时、SLA 等监控信息。点击拓扑图中任意一条边，还可以看到一条调用链路

的监控信息，其中会分别从客户端（上游调用方）和服务端（下游接收方）来观测这条调用链路的状

态，其中展示了该条链路的耗时、吞吐量、SLA 等信息。

3.3.3 追踪

【追踪】主要用来查询 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 告警

SkyWalking 告警功能是在6.x版本新增的，其核心由一组规则驱动，这些规则定义在 config/alarm

settings.yml 文件中。告警的定义分为两部分：

1. 告警规则：它们定义了应该如何触发度量警报，应该考虑什么条件。

2. Webhook（网络钩子）：定义当警告触发时，哪些服务终端需要被告知

3.3.5.1 警告规则详解

Skywalking每隔一段时间根据收集到的链路追踪的数据和配置的告警规则（如服务响应时间、服务响应

时间百分比）等，判断如果达到阈值则发送相应的告警信息。发送告警信息是通过调用webhook接口完

成，具体的webhook接口可以使用者自行定义，从而开发者可以在指定的webhook接口中编写各种告警

方式，比如邮件、短信等。告警的信息也可以在RocketBot中查看到。

我们可以进入到Skywalking容器中，再进入到config文件夹下就可以看到alarm-settings.yml，如下图：

SkyWalking 的发行版都会默认提供 config/alarm-settings.yml 文件，里面预先定义了一些常用的告

警规则。如下：

# Licensed to

(

)

# or more cont

ile

# distribu

# regardin

s file

# to you under the Apache License, Version 2.0 (the

# "Licens

;

# with th

# http://www.apache.org/licenses/LICENSE-2.0

# Unless required by applicable law or agreed to in writing, software

# distributed under the License is distributed on an "AS IS" BASIS,

# WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.

# See the License for the specific language governing permissions and

# limitations under the License.

# Sample alarm rules.

rules:

# Rule unique name, must be ended with `_rule`.

service_resp_time_rule:

metrics-name: service_resp_time

op: ">"

threshold: 1000

period: 10

silence-period: 5

message: Response time of service {name} is more than 1000ms in 3 minutes of

last 10 minutes.

service_sla_rule:

# Metrics value need to be long, double or int

metrics-name: service_sla

op: "<"

threshold: 8000

# The length of time to evaluate the metrics

period: 10

# How many times after the metrics match the condition, will trigger alarm

# How many times of checks, the alarm keeps silence after alarm triggered,

default as same as period.

silence-period: 3

message: Successful rate of service {name} is lower than 80% in 2 minutes of

last 10 minutes

service_resp_time_percentile_rule:

# Metrics value need to be long, double or int

metrics-name: service_percentile

op: ">"

threshold: 1000,1000,1000,1000,1000

period: 10

告警规则配置项的说明：

Rule name：规则名称，也是在告警信息中显示的唯一名称。必须以 _rule 结尾，前缀可自定义

Metrics name：度量名称，取值为 oal 脚本中的度量名，目前只支持 long 、 double 和 int 类

型。

Include names：该规则作用于哪些实体名称，比如服务名，终端名（可选，默认为全部）

Exclude names：该规则作不用于哪些实体名称，比如服务名，终端名（可选，默认为空）

Threshold：阈值

OP：操作符，目前支持 > 、 < 、 =

Period：多久告警规则需要被核实一下。这是一个时间窗口，与后端部署环境时间相匹配

Count：在一个Period窗口中，如果values超过Threshold值（按op），达到Count值，需要发送

警报

Silence period：在时间N中触发报警后，在TN -> TN + period这个阶段不告警。默认情况下，它

和Period一样，这意味着相同的告警（在同一个Metrics name拥有相同的Id）在同一个Period内

只会触发一次

message：告警消息

在配置文件中预先定义的告警规则总结如下：

1. 在过去10分钟内服务平均响应时间超过1秒达3次

2. 在过去10分钟内服务成功率低于80%达2次

silence-period: 5

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 >

1000, p95 > 1000, p99 > 1000

service_instance_resp_time_rule:

metrics-name: service_instance_resp_time

op: ">"

threshold: 1000

period: 10

silence-p

eriod: 5

messag

of service instance {name} is more than 1000ms in 2

minutes of

# Active

ics alarm will cost more memory than service and

service i

# 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:

# - http://127.0.0.1/notify/

# - http://127.0.0.1/go-wechat/

3. 在过去10分钟内服务90%响应时间低于1秒达3次

4. 在过去10分钟内服务的响应时间超过1秒达2次

5. 在过去10分钟内端点的响应时间超过1秒达2次

这些警告信息最终会在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.DefaultScopeDefine 里面声明。

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 ，代码如下：

2)接收警告方法创建

在 hailtaxi-driver 中创建 com.itheima.driver.controller.AlarmMessageController 用于接收

警告消息，代码如下：

一般情况下，这种接收告警的api会被放置在比较清闲的后台服务中！！！

3)修改Webhook地址

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

@Data

@ToString

@AllArgsC

@NoArgsCo

public class AlarmMessage {

private int scopeId;

private String name;

private String id0;

private String id1;

private String alarmMessage;

private long startTime;

String ruleName;

}

@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);

}

因为skywalking默认有一个告警规则：10分钟内服务成功率低于80%超过2次

所以为了能演示出告警效果，我们在 hailtaxi-driver 项目中的 driver/info 接口中添加一个一

句话

测试时将网关的条件断言给注释一下！！！

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

webhooks:

# - http://127.0.0.1/notify/

# - http://127.0.0.1/go-wechat/

- http://192.168.200.10:8001/driver/skywalking/webhook

/****

* 司

机信息

//@

GetMapping(value = "/info/{id}")

@RequestMapping(value = "/info/{id}")

public Driver info(@PathVariable(value = "id")String

id,HttpServletRequest request){

int i = 1/ 0; // 产生异常

Enumeration<String> headerNames = request.getHeaderNames();

while (headerNames.hasMoreElements()){

String name = headerNames.nextElement();

String value = request.getHeader(name);

System.out.println(name+":"+value);

System.out.println("--------------------------");

}

return driverService.findById(id);

}

posted @ 2023-05-13 23:47 十一vs十一阅读(98) 评论(0) 编辑收藏举报

刷新页面返回顶部

WM_Skywalking应用实战 暂时没用

公告

WM_Skywalking应用实战暂时没用