• Skywalking UI使用攻略

    文章目录

    一、前言

    基于skywalking 8.9.0版本，为大家提供UI使用攻略，帮助大家快速理解各项指标及其含义。

    二、指标术语解释

    Apdex：应用性能指数，Apdex(Application Performance Index)是一个国际通用标准，Apdex 是用户对应用性能满意度的量化值，供了一个统一的测量和报告用户体验的方法，把最终用户的体验和应用性能作为一个完整的指标进行统一度量，其中最高为1最低为0；
ResponseTime：响应时间，即在选定时间内，服务所有请求的平均响应时间(ms)；
Throughput：吞吐量，即在选定时间内，每分钟服务响应的请求量；
SLA：服务等级协议(Service Level Agreement)，SW中指每分钟内请求响应成功的占比；
PPM：Packets Per Minute，特指TCP服务，每分钟收发包数；
CPM：Calls Per Minute，即每分钟请求数；
APM：Application Performance Monitor，应用程序性能监控工具；
OAP：Observability Analysis Platform，可观测性分析平台；
OAL：Observability Analysis Language，是一门用来分析流式数据的语言，主要聚焦于度量 Service 、 Service Instance 和 Endpoint 的指标。OAL 基于 altlr 与 javassist 将 oal 脚本转化为动态生成的类文件；
Service：表示对请求提供相同行为的一组工作负载；
Instance：一组工作负载中的每一个工作负载称为一个实例。一个服务实例可以理解为操作系统上的一个真实进程；
Endpoint：端点，即对于特定服务所接收的请求路径，如HTTP请求的URI路径、gRPC服务的类名+方法签名；

    • 1
    • 2
    • 3
    • 4
    • 5
    • 6
    • 7
    • 8
    • 9
    • 10
    • 11
    • 12

    三、指标盘界面通识

    在这里插入图片描述

    仪表盘：提供全局(Global)、当前服务(Service)、当前实例(Instance)、当前端点(Endpoint )几个维度的运行状态和监控指标；
拓扑图：以拓扑图的方式展现服务之间的依赖关系，并且可以以此为入口查看告警、调用链、服务状态等信息；
追踪：以接口列表的方式展现，追踪接口内部调用过程，可以通过 traceid 查询，进行分布式集群的日志查看及问题排查；
性能剖析：对某个服务的某个具体端点进行采样分析，并且可查看到详细的堆栈信息；
日志：提供查看日志功能，包括了 browser 与 service 日志集合。这个功能需要在业务项目中接入Skywalking的日志系统才会在这显示日志信息，成功接入日志后，我们就可以根据 追踪ID 进行跨服务整体流程日志的追踪；
告警：展示触发了告警的告警列表，包括实例、请求超时等信息；
事件：展示服务实例的启动和服务端点的调用等事件信息；
调试：此功能模块目前还没使用过，后续再做补充；
时间区：用来设定统计指标的时间域，所有的指标数据展示都依赖于这个时间范围；
刷新：点击自动按钮，可以开启自动刷新模式。

    • 1
    • 2
    • 3
    • 4
    • 5
    • 6
    • 7
    • 8
    • 9
    • 10

    另外，在Skywalking UI上G3服务都是以前缀“G3_”开头，如：
    在这里插入图片描述

    四、各指标模块介绍

    4.1【仪表盘】模块

    仪表盘模块下的 APM和Database两大维度，各项指标的英文含义已对照着官方为大家翻译成了中文，方便大家理解。但是，切指标图的时候把中文翻译版和英文原版都贴出来了，大家可以对照着参考。

    4.1.1 APM监控

    4.1.1.1 APM - Global

    1）各指标英文名称：
    在这里插入图片描述
    2）各指标对应的中文含义：
    在这里插入图片描述

    4.1.1.2 APM - Service

    1）各指标英文名称：
    在这里插入图片描述
    2）各指标对应的中文含义：
    在这里插入图片描述

    4.1.1.3 APM - Instance

    1）各指标英文名称：
    在这里插入图片描述
    2）各指标对应的中文含义：
    在这里插入图片描述

    4.1.1.4 APM - EndPoint

    1）各指标英文名称：
    在这里插入图片描述
    2）各指标对应的中文含义：
    在这里插入图片描述

    4.1.2 DataBase监控

    1）各指标英文名称：
    在这里插入图片描述
    2）各指标对应的中文含义：
    在这里插入图片描述

    4.1.3 SelfObservability监控

    该指标为SkywalkingOAP服务自我监控指标，包括对CPU的占比、内存占用大小、垃圾回收次数和耗时、每分钟链路收集量和每分钟数据聚合量等等，此项指标的监控大家无需关心，了解下即可。
    在这里插入图片描述

    4.2【拓扑图】模块

    在这里插入图片描述
    拓扑图展示服务之间的调用依赖关系，当服务可用率低的时候服务会显示为红色。除此之外，拓扑图还能查看服务运行信息进行度量，包括开发框架类型、服务平均响应时间、吞吐量、百分比响应、Apdex分值、SLA值等。

    4.2.1 拓扑图的功能区

    在这里插入图片描述

    1. All Groups：选择服务组。提供服务组的任意子拓扑功能，但是分组的信息是保存在浏览器内的；
2. All Services：选择服务。支持显示直接关系，包括上游和下游；建议大家选择具体的服务查看，加载全部的话会很慢且有点卡顿。
3. Create Group：创建新的服务组。
4. 服务引用拓扑图：展示服务之间的调用关系，以及服务器的健康状态。点击任何小方格会显示该服务的菜单，可以查看服务详情，该图形还可以对所选择的服务进行度量、跟踪和告警查询。
5. 服务指标的关系虚线：提供服务RPC交互的度量以及这两个服务的实例。点击小圆点，会显示调用信息、调用次数、延迟时间。

    • 1
    • 2
    • 3
    • 4
    • 5

    Tips

    • 鼠标单机，可以随意拉动拓扑图位置；
    • 鼠标选中小方格，也可以随意拉动；
    • 双击或拖动鼠标滚轮（MAC通过双指）可放大、缩小拓扑区域；

    4.2.2 实例信息面板

    在这里插入图片描述

    A. 服务调用追踪

    在这里插入图片描述
    在这里插入图片描述

    • 当前服务：可选择具体服务
    • 当前端点：可选择具体端点
    • 当前深度：可以选择展示的调用深度

    Tips： 滑动指向连接线，点击后可以出现以下指标：

    1. 平均响应时间
    2. 平均吞吐量
    3. 平均SLA
    4. 相应百分比

    说明：其实部分功能都是可以在其他地方看见的，只是这里多了一个全局调用链深度展示的功能。

    B. 通向告警面板

    C. 通向追踪面板

    D. 通向服务实例性能监控面板

    E. 通向EndPoint性能监控面板

    4.3【追踪】模块

    我们可以使用trace功能进行链路追踪，查看每个接口的调用链，链路中每个步骤的耗时、状态，并且可以看到请求都走了那些服务中间件。如果调用失败会展示错误信息；如果是数据库会展示查询语句；如果是Redis还会展示操作指令等。另外可以根据追踪ID和标记关键词进行条件筛选。
    在这里插入图片描述
    在这里插入图片描述

    1. 这一部分筛选条件：选择服务、实例、状态（error、success）、端点。
2. 追踪ID: 可以根据 traceId 获取整个监控平台下相同 traceId的分布式集群的日志查看。
3. 时间范围: 选择日志时间范围。
4. 红色点大家应该都看见了，就是整个链路中报错的位置。点击后可以弹出相对应的异常信息。

    • 1
    • 2
    • 3
    • 4

    4.3.1 链路追踪详细说明

    在这里插入图片描述

    上图标1的区域，Trace列表中每一行都是一个分布式链路追踪树；
上图标2的区域，可以选择trace链路追踪列表的排序方式。按访问时间或链路持续时间（链路总耗时）倒序排列；
上图标3的区域，表示请求链路跨越的服务都是有哪些。每个服务都是链路的一个TraceSegment；
上图标4的区域，表示当前TraceSegment的所有Span元素。每一行都是一个span，鼠标悬浮每个span上面会显示当前span操作的自身耗时和它下面子span的所有总耗时；点击每个span行，在左侧会弹出详细的跨度信息。
上图标5的区域，列出了选择查看链路追踪信息的几种方式。

    • 1
    • 2
    • 3
    • 4
    • 5

    4.3.2 链路追踪相关术语

    这里给大家简单介绍一下链路追踪中涉及到的几个Skywalking术语，感兴趣的可以了解下。

    4.3.2.1 Trace

    上图左侧列表，每一行都是一个trace，即链路追踪树。可以根据据图服务的具体端点筛选，然后按照开始时间或持续时间排列。

    4.3.2.2 TraceSegment

    TraceSegment是和线程绑定的，代表一个JVM进程的一个线程内的所有操作。分布式链路追踪基本上都要跨多个进程或者线程执行，实际上它的追踪树（Trace）就是由一个或多个TraceSegment组成。

    4.3.2.3 Span

    组成TraceSegment的基本元素，有三种类型，分别为EntrySpan、LocalSpan、ExitSpan。

    1. EntrySpan表示服务提供者点（即服务调用方调用目标服务时，线程即将进入目标服务的入口点），例如Tomcat服务器入口、Apsaras调用入口、RabbitMQ消息队列等都是EntrySpan。EntrySpan是TraceSegment的起点（即第一个Span），即使在一个复杂的应用程序中可能有多个入口点，但是EntrySpan只表示第一个，这也是为什么称为"入口"Span的原因。可以把entryspan简单理解为进程|线程开始准备进入目标服务的操作；
2. ExitSpan表示一个服务消费者点（即服务调用方调用目标服务时，线程即将离开调用方所在服务的出口点），例如FeignClient、HttpClient、通过JDBC访问DB、读取Redis等都属于ExitSpan。它是一条链路追踪树的一个出口点。在单个rpc调用中，由于调用可能会跨多个服务，所以可能包含多个出口点，但是exitspan只会展示第一个。可以把exitspan简单理解为离开当前进程|线程的操作；
3. LocalSpan表示一种普通的Java方法，如本地方法。它与远程服务无关。它既不是MQ的生产者/消费者，也不是服务(如HTTP服务)provider/consumer。

    • 1
    • 2
    • 3

    4.3.3 链路追踪中自身耗时和总耗时分析

    参见：Skywalking链路追踪自身耗时和总耗时算法分析

    4.4 【性能剖析】模块

    【追踪】功能展示出的跨度是服务调用粒度的，如果要看应用实时的堆栈信息，可以选择性能剖析功能。Skywalking 在性能剖析方面非常强大，提供到基于堆栈的分析结果，能够让开发人员看到调用过程中各个步骤所消耗的时间，以便有针对性的进行优化。如果发现某个端点耗时很长，又不知道具体耗时点在哪里，可以借助此模块进行堆栈分析。

    性能剖析主要的工作就是通过新建任务、对不同的端点进行采样，然后提供一个更加详细的分析报告。它比链路追踪多了线程栈信息、慢方法提示等内容。

    1. Task List：任务列表
    2. 新建任务：创建一个性能剖析的任务。
    3. Sampled Traces：性能采样列表，最多展示的条数为创建任务时设置的最大采样数。

    接下来我们就介绍下怎么进行性能剖析。

    Step1、新建任务

    在性能剖析模块 -> 新建任务 -> 选择服务、填写端点、监控时间等，如下图：在这里插入图片描述
    在这里插入图片描述
    创建好任务后，Skywalking将开始采集应用端点的实时堆栈信息。并且采样结束后，用户点击分析即可查看具体的堆栈信息。

    Step2、执行分析：

    选定的服务和端点作为分析对象，多次访问dhgate-review-service_prod-jxq-r服务的 “POST:/com.dhgate.review.api.ReviewOpenService/loadReviewsBySupplieridNew” 接口，然后选择这个任务将会出现监控到的数据，如下图：
    在这里插入图片描述

    注意：
    1、每个服务，相同时间只能添加一个任务，且添加的任务不能更改也不能删除，只能等待过期后自动删除。
    2、需要连续执行多次请求，因为存在采样设置。如果执行次数少，可能不会出现采样数据，也就无法进行分析了。

    Step3、性能剖析

    在这里插入图片描述
    上图可以看出，“POST:/com.dhgate.review.api.ReviewOpenService/loadReviewsBySupplieridNew” 接口耗费了474ms，通过分析详细堆栈信息，我们可以看到耗时最多的操作就是com.dhgate.review.impl.ReviewOpenServiceImpl 类的loadReviewsBySupplieridNew()方法，耗费了264ms，如下图所示：
    在这里插入图片描述
    所以性能剖析对于我们解决慢接口慢响应到底哪里耗时，是非常有帮助的。

    4.5 【日志】模块

    日志界面提供了查看客户端和服务端日志的功能，默认是没有数据的，需要在项目中接入sw的日志系统才会在这显示出日志信息。成功接入日志后，我们就可以根据追踪ID进行跨服务整体流程日志的追踪。

    4.5.1 服务如何对接skywalking日志集成系统？

    官方参考文档：
    1）log4j2日志框架接入：
    https://github.com/apache/skywalking-java/blob/20fb8c81b3da76ba6628d34c12d23d3d45c973ef/docs/en/setup/service-agent/java-agent/Application-toolkit-log4j-2.x.md
    2）logback日志框架接入：
    https://github.com/apache/skywalking-java/blob/20fb8c81b3da76ba6628d34c12d23d3d45c973ef/docs/en/setup/service-agent/java-agent/Application-toolkit-logback-1.x.md
    3）log4j日志框架接入：
    https://github.com/apache/skywalking-java/blob/20fb8c81b3da76ba6628d34c12d23d3d45c973ef/docs/en/setup/service-agent/java-agent/Application-toolkit-log4j-1.x.md

    以G4工程使用的logback日志框架为例，配置步骤如下：

    4.5.1.1 添加依赖

    <dependency>
    <groupId>org.apache.skywalkinggroupId>
    <artifactId>apm-toolkit-logback-1.xartifactId>
    <version>8.9.0version>
dependency>

    • 1
    • 2
    • 3
    • 4
    • 5

    4.5.1.2 修改日志配置文件

    在 logback-spring.xml 配置文件中：
    1）日志输出中加上打印Skywalking的traceId格式：

    <appender name="STDOUT-SW" class="ch.qos.logback.core.ConsoleAppender">
    <encoder class="ch.qos.logback.core.encoder.LayoutWrappingEncoder">
        <layout class="org.apache.skywalking.apm.toolkit.log.logback.v1.x.mdc.TraceIdMDCPatternLogbackLayout">
            
            <Pattern>%d{yyyy-MM-dd HH:mm:ss.SSS} [%X{tid}] [%thread] %-5level %logger{36} -%msg%nPattern>
        layout>
    encoder>
appender>

    • 1
    • 2
    • 3
    • 4
    • 5
    • 6
    • 7
    • 8

    2）添加服务日志传输到Skywalking OAP系统的appender：

    
<appender name="GRPC-SW" class="org.apache.skywalking.apm.toolkit.log.logback.v1.x.log.GRPCLogClientAppender">
    <encoder class="ch.qos.logback.core.encoder.LayoutWrappingEncoder">
        <layout class="org.apache.skywalking.apm.toolkit.log.logback.v1.x.mdc.TraceIdMDCPatternLogbackLayout">
            <Pattern>%d{yyyy-MM-dd HH:mm:ss.SSS} [%X{tid}] [%thread] %-5level %logger{36} -%msg%nPattern>
        layout>
    encoder>
appender>

    • 1
    • 2
    • 3
    • 4
    • 5
    • 6
    • 7
    • 8

    3）把需要上报到skywalking系统的日志appender，添加到多环境日志输出配置里

    <springProfile name="qa">
    <root level="${level}">
        
        <appender-ref ref="STDOUT"/>
        
        <appender-ref ref="STDOUT-SW"/>
        <appender-ref ref="GRPC-SW"/>
    root>
springProfile>

    • 1
    • 2
    • 3
    • 4
    • 5
    • 6
    • 7
    • 8
    • 9

    只需要在日志配置文件中添加以上这些配置，即可实现服务日志接入到Skywalking系统！

    当然，也支持日志异步上报到sw系统，主要配置如下：

    <configuration scan="true" scanPeriod=" 5 seconds">
    <appender name="STDOUT" class="ch.qos.logback.core.ConsoleAppender">
        <encoder class="ch.qos.logback.core.encoder.LayoutWrappingEncoder">
            <layout class="org.apache.skywalking.apm.toolkit.log.logback.v1.x.mdc.TraceIdMDCPatternLogbackLayout">
                <Pattern>%d{yyyy-MM-dd HH:mm:ss.SSS} [%X{tid}] [%thread] %-5level %logger{36} -%msg%nPattern>
            layout>
        encoder>
    appender>

    <appender name="ASYNC" class="ch.qos.logback.classic.AsyncAppender">
        <discardingThreshold>0discardingThreshold>
        <queueSize>1024queueSize>
        <neverBlock>trueneverBlock>
        <appender-ref ref="STDOUT"/>
    appender>

    <root level="INFO">
        <appender-ref ref="ASYNC"/>
    root>
configuration>

    • 1
    • 2
    • 3
    • 4
    • 5
    • 6
    • 7
    • 8
    • 9
    • 10
    • 11
    • 12
    • 13
    • 14
    • 15
    • 16
    • 17
    • 18
    • 19
    • 20

    4.5.1.3 日志集成到OAP系统后查看

    如下图，我们的服务日志成功集成到Skywalking OAP系统的话，启动服务可以在日志输出中看到“[TID:N/A]”的标识，其含义：当使用’ -javaagent '来激活SkyWalking探针时，如果探针成功激活，日志返回将输出traceId。如果探针未被注入或tracer不活跃，日志将会输出：TID: N/A
    在这里插入图片描述
    在这里插入图片描述
    输出的日志中可以看到已经打印出了traceId。

    skywalking中的日志模块输出的日志如下图：
    在这里插入图片描述
    在这里插入图片描述
    可以看到日志已经传输到了skywalking中…

    注意：如果agent和oap服务不在同一台服务器上，在/agent/config/agent.config配置文件末尾需要添加如下配置：

    plugin.toolkit.log.grpc.reporter.server_host=OAP服务地址
    plugin.toolkit.log.grpc.reporter.server_port=11800
    plugin.toolkit.log.grpc.reporter.max_message_size=10485760
    plugin.toolkit.log.grpc.reporter.upstream_timeout=30

    4.5.1.4 各日志框架下配置完整样例

    1、log4j.properties

    log4j.rootLogger=info,CustomAppender
log4j.appender.CustomAppender=org.apache.skywalking.apm.toolkit.log.log4j.v1.x.log.GRPCLogClientAppender
log4j.appender.CustomAppender.layout=org.apache.log4j.PatternLayout
log4j.appender.CustomAppender.layout.ConversionPattern=[%t] %-5p %c %x - %m%n

log4j.logger.fileLogger=info,FileAppender
log4j.appender.FileAppender=org.apache.log4j.FileAppender
log4j.appender.FileAppender.ImmediateFlush=true
log4j.appender.FileAppender.Append=true
log4j.appender.FileAppender.File=/tmp/skywalking-logs/log4j1/e2e-service-provider.log
log4j.appender.FileAppender.layout=org.apache.skywalking.apm.toolkit.log.log4j.v1.x.TraceIdPatternLayout
log4j.appender.FileAppender.layout.ConversionPattern=[%T{SW_CTX}] [%p] %d{yyyy-MM-dd HH:mm:ss.SSS} [%t] %c:%L - %m%n

    • 1
    • 2
    • 3
    • 4
    • 5
    • 6
    • 7
    • 8
    • 9
    • 10
    • 11
    • 12

    2、log4j2.xml

    
<Configuration status="WARN">
    <Appenders>
        <Console name="Console" target="SYSTEM_OUT">
            <PatternLayout pattern="%d{HH:mm:ss.SSS} [%t] %-5level %logger{36} - %msg%n"/>
        Console>
        <GRPCLogClientAppender name="grpc-log">
            <PatternLayout pattern="%d{HH:mm:ss.SSS} [%t] %-5level %logger{36} - %msg%n"/>
        GRPCLogClientAppender>
        <RandomAccessFile name="fileAppender" fileName="/tmp/skywalking-logs/log4j2/e2e-service-provider.log" immediateFlush="true" append="true">
            <PatternLayout>
                <Pattern>[%sw_ctx] [%p] %d{yyyy-MM-dd HH:mm:ss.SSS} [%t] %c:%L - %m%nPattern>
            PatternLayout>
        RandomAccessFile>
    Appenders>

    <Loggers>
        <Root level="info">
            <AppenderRef ref="Console"/>
            <AppenderRef ref="grpc-log"/>
        Root>
        <Logger name="fileLogger" level="info" additivity="false">
            <AppenderRef ref="fileAppender"/>
        Logger>
    Loggers>
Configuration>

    • 1
    • 2
    • 3
    • 4
    • 5
    • 6
    • 7
    • 8
    • 9
    • 10
    • 11
    • 12
    • 13
    • 14
    • 15
    • 16
    • 17
    • 18
    • 19
    • 20
    • 21
    • 22
    • 23
    • 24
    • 25
    • 26

    3、logback.xml

    
<configuration scan="true" scanPeriod=" 5 seconds">

    <appender name="stdout" class="ch.qos.logback.core.ConsoleAppender">
        <encoder class="ch.qos.logback.core.encoder.LayoutWrappingEncoder">
            <layout class="org.apache.skywalking.apm.toolkit.log.logback.v1.x.mdc.TraceIdMDCPatternLogbackLayout">
                
                <Pattern>%d{yyyy-MM-dd HH:mm:ss.SSS} [%X{tid}] [%thread] %-5level %logger{36} -%msg%nPattern>
            layout>
        encoder>
    appender>

    <appender name="grpc-log" class="org.apache.skywalking.apm.toolkit.log.logback.v1.x.log.GRPCLogClientAppender">
        <encoder class="ch.qos.logback.core.encoder.LayoutWrappingEncoder">
            <layout class="org.apache.skywalking.apm.toolkit.log.logback.v1.x.mdc.TraceIdMDCPatternLogbackLayout">
                <Pattern>%d{yyyy-MM-dd HH:mm:ss.SSS} [%X{tid}] [%thread] %-5level %logger{36} -%msg%nPattern>
            layout>
        encoder>
    appender>

    <appender name="fileAppender" class="ch.qos.logback.core.FileAppender">
        <file>/tmp/skywalking-logs/logback/e2e-service-provider.logfile>
        <encoder class="ch.qos.logback.core.encoder.LayoutWrappingEncoder">
            <layout class="org.apache.skywalking.apm.toolkit.log.logback.v1.x.TraceIdPatternLogbackLayout">
                <Pattern>[%sw_ctx] [%level] %d{yyyy-MM-dd HH:mm:ss.SSS} [%thread] %logger:%line - %msg%nPattern>
            layout>
        encoder>
    appender>

    <root level="INFO">
        <appender-ref ref="grpc-log"/>
        <appender-ref ref="stdout"/>
    root>
    <logger name="fileLogger" level="INFO">
        <appender-ref ref="fileAppender"/>
    logger>
configuration>

    • 1
    • 2
    • 3
    • 4
    • 5
    • 6
    • 7
    • 8
    • 9
    • 10
    • 11
    • 12
    • 13
    • 14
    • 15
    • 16
    • 17
    • 18
    • 19
    • 20
    • 21
    • 22
    • 23
    • 24
    • 25
    • 26
    • 27
    • 28
    • 29
    • 30
    • 31
    • 32
    • 33
    • 34
    • 35
    • 36
    • 37

    4.6 【告警】模块

    对于服务的异常信息，比如接口有较长延迟，skywalking也做出了告警功能，如下图：在这里插入图片描述

    界面提供查看告警记录功能：

    • 过滤范围，可以按照一下几个维度进行过滤
      – 服务
      – 服务实例
      – 端点
      – 服务关系
      – 服务实例关系
      – 服务端点关系
    • 关键字
    • 标签

    4.6.1 默认告警规则

    Skywalking中有一些默认的告警规则，如下：

    • 最近3分钟内服务的平均响应时间超过1秒
    • 最近2分钟服务成功率低于80%
    • 最近3分钟90%服务响应时间超过1秒
    • 最近2分钟内服务实例的平均响应时间超过1秒

    当然除了以上四种，随着Skywalking不断迭代也会新增其他规则，这些规则的配置在config/alarm-settings.yml配置文件中，如下：

    # 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
    count: 3
    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
    count: 2
    # 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
    count: 3
    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
    count: 2
    silence-period: 5
    message: Response time of service instance {name} is more than 1000ms in 2 minutes of last 10 minutes
  database_access_resp_time_rule:
    metrics-name: database_access_resp_time
    threshold: 1000
    op: ">"
    period: 10
    count: 2
    message: Response time of database access {name} is more than 1000ms in 2 minutes of last 10 minutes
  endpoint_relation_resp_time_rule:
    metrics-name: endpoint_relation_resp_time
    threshold: 1000
    op: ">"
    period: 10
    count: 2
    message: 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:
#  - http://127.0.0.1/notify/
#  - http://127.0.0.1/go-wechat/

    • 1
    • 2
    • 3
    • 4
    • 5
    • 6
    • 7
    • 8
    • 9
    • 10
    • 11
    • 12
    • 13
    • 14
    • 15
    • 16
    • 17
    • 18
    • 19
    • 20
    • 21
    • 22
    • 23
    • 24
    • 25
    • 26
    • 27
    • 28
    • 29
    • 30
    • 31
    • 32
    • 33
    • 34
    • 35
    • 36
    • 37
    • 38
    • 39
    • 40
    • 41
    • 42
    • 43
    • 44
    • 45
    • 46
    • 47
    • 48
    • 49
    • 50
    • 51
    • 52
    • 53
    • 54
    • 55
    • 56
    • 57
    • 58
    • 59
    • 60
    • 61
    • 62
    • 63
    • 64
    • 65
    • 66
    • 67
    • 68
    • 69

    4.6.2 告警规则属性及其含义

    每个规则都由相同的属性组成，这些属性的含义如下图：
    在这里插入图片描述
    如果想要调整默认的规则，比如监控返回的信息，监控的参数等等，只需要改动上述配置文件中的参数即可。当然除了以上默认的几种规则，Skywalking还适配了一些钩子（webhooks），其实就是相当于一个回调函数，一旦触发了上述或自定义规则告警，Skywalking则会调用配置的webhook钩子函数，这样我们就可以定制一些处理方法，比如发送邮件、微信、飞书等通知运维或开发人员处理。

    钩子函数的开发有如下三点要求：

    • POST请求；
    • application/json 格式接收数据；
    • 入参格式必须按照 {@link AlarmMessage} 中指定的属性规则定义；

    org.apache.skywalking.oap.server.core.alarm.AlarmMessage类的属性，如下图：在这里插入图片描述

    4.6.3 自定义告警功能

    如何在业务工程中开发自定义监控告警呢？

    4.6.3.1 创建controller
    package com.dhgate.controller;

import com.alibaba.fastjson.JSON;
import lombok.AllArgsConstructor;
import lombok.Builder;
import lombok.Data;
import lombok.EqualsAndHashCode;
import lombok.Getter;
import lombok.NoArgsConstructor;
import lombok.Setter;
import lombok.experimental.Accessors;
import lombok.extern.slf4j.Slf4j;
import org.springframework.util.CollectionUtils;
import org.springframework.web.bind.annotation.PostMapping;
import org.springframework.web.bind.annotation.RequestBody;
import org.springframework.web.bind.annotation.RequestMapping;
import org.springframework.web.bind.annotation.RestController;

import java.util.ArrayList;
import java.util.Collections;
import java.util.List;
import java.util.stream.Collectors;

@Slf4j
@RestController
@RequestMapping("sw/alarm")
public class AlarmMessageController {

    // 保存从oap接收到的所有告警信息
    private List<AlarmMessage> alarmMessages = new ArrayList<AlarmMessage>();

    /**
     * Skywalking告警回调方法：一旦触发告警，则会调用这个接口
     *
     * @param list 指定的参数，必须按照 {@link AlarmMessage} 属性规则定义
     */
    @PostMapping("/doAlarm")
    public void receiveAlarmMessage(@RequestBody List<AlarmMessage> list) {
        // 告警信息放入alarmMessages集合
        log.info("自定义告警发送信息：" + JSON.toJSON(list));
        alarmMessages.addAll(list);

        // TODO 实现发邮件、微信、飞书通知的业务需求
        // ......
    }

    /**
     * 读取告警信息
     *
     * @return
     */
    @PostMapping("/read")
    public Alarms readMessages() {
        return Alarms.builder().messages(alarmMessages).build();
    }

    /**
     * Alarm message represents the details of each alarm.
     */
    @Setter
    @Getter
    @NoArgsConstructor
    public static class AlarmMessage {
        private int scopeId;
        private String scope;
        private String name;
        private String id0;
        private String id1;
        private String ruleName;
        private String alarmMessage;
        private long startTime;
        private List<KeyValue> tags;
    }

    @Getter
    @Setter
    @EqualsAndHashCode
    @NoArgsConstructor
    @AllArgsConstructor
    @Data
    @Accessors(chain = true)
    public static class KeyValue {
        private String key;
        private String value;

        @Override
        public String toString() {
            return key + "=" + value;
        }

        public static class Util {
            public static List<String> toStringList(List<KeyValue> list) {
                if (CollectionUtils.isEmpty(list)) {
                    return Collections.emptyList();
                }
                return list.stream().map(KeyValue::toString).collect(Collectors.toList());
            }
        }
    }

    /**
     * Alarm wrapper
     */
    @Data
    @Builder
    @NoArgsConstructor
    @AllArgsConstructor
    public static class Alarms {
        private List<AlarmMessage> messages;
    }

}

    • 1
    • 2
    • 3
    • 4
    • 5
    • 6
    • 7
    • 8
    • 9
    • 10
    • 11
    • 12
    • 13
    • 14
    • 15
    • 16
    • 17
    • 18
    • 19
    • 20
    • 21
    • 22
    • 23
    • 24
    • 25
    • 26
    • 27
    • 28
    • 29
    • 30
    • 31
    • 32
    • 33
    • 34
    • 35
    • 36
    • 37
    • 38
    • 39
    • 40
    • 41
    • 42
    • 43
    • 44
    • 45
    • 46
    • 47
    • 48
    • 49
    • 50
    • 51
    • 52
    • 53
    • 54
    • 55
    • 56
    • 57
    • 58
    • 59
    • 60
    • 61
    • 62
    • 63
    • 64
    • 65
    • 66
    • 67
    • 68
    • 69
    • 70
    • 71
    • 72
    • 73
    • 74
    • 75
    • 76
    • 77
    • 78
    • 79
    • 80
    • 81
    • 82
    • 83
    • 84
    • 85
    • 86
    • 87
    • 88
    • 89
    • 90
    • 91
    • 92
    • 93
    • 94
    • 95
    • 96
    • 97
    • 98
    • 99
    • 100
    • 101
    • 102
    • 103
    • 104
    • 105
    • 106
    • 107
    • 108
    • 109
    • 110
    • 111
    • 112
    4.6.3.2 修改alarm-settings.yml配置

    接口定制完成后，在apache-skywalking-apm-8.9.1/dist-material/alarm-settings.yml配置文件中添加上这个钩子的回调：

    webhooks:
  # 本地测试，生产环境需要配置正确的ip:port
  - http://127.0.0.1:7997/sw/alarm/doAlarm/

    • 1
    • 2
    • 3

    这里需要大家注意的是：自定义告警的钩子函数功能，如果有需求，需要联系架构组统一定制，不建议自己开发。

    4.7 【事件】模块

    该模块会展示一些如服务启动、告警信息等事件。也包括实例、端点请求超时等信息。
    在这里插入图片描述
    在这里插入图片描述

    五、自定义链路追踪

    Skywalking的调用链路中，记录的一般都是服务中对外暴露的接口URL，比如带有注解@RequestMapping、@PostMapping、@GetMapping的方法。那如果我们希望追踪链路中能记录到服务中Service层的业务方法，以便于我们更加方便地排查问题。那么该怎么实现呢？

    step1、引入依赖

    
<dependency>
    <groupId>org.apache.skywalkinggroupId>
    <artifactId>apm-toolkit-traceartifactId>
    <version>8.9.0version>
dependency>

    • 1
    • 2
    • 3
    • 4
    • 5
    • 6

    step2、@Trace注解

    如果一个业务方法，想要在UI界面的追踪链路上显示出来，只需要在业务方法上加上@Trace注解即可。

    step3、@Tag或@Tags注解

    我们还可以为自定义追踪链路添加其他额外的信息，比如记录参数和返回值信息。
    实现方式：在方法上增加 @Tag 或 @Tags 注解。其中@Tags注解是@Tag的包装，以允许对单个方法span设置多个标记:

    import com.dhgate.disputeg3test.dao.TdRefundBeforeDao;
import com.dhgate.disputeg3test.po.TdRfxRefundBefore;
import com.dhgate.framework.service.service.impl.AbstractGenericServiceImpl;
import org.apache.skywalking.apm.toolkit.trace.Tag;
import org.apache.skywalking.apm.toolkit.trace.Tags;
import org.apache.skywalking.apm.toolkit.trace.Trace;
import org.springframework.beans.factory.annotation.Autowired;
import org.springframework.stereotype.Service;

@Service
public class RefundBeforeBean extends AbstractGenericServiceImpl {
    @Autowired
    TdRefundBeforeDao tdRefundBeforeDao;

    // 加入@Trace注解，就把当前的业务方法也加入到追踪链路中
    @Trace
    // 为当前业务方法设置返回值标签，key="方法返回值标签名"，value="returnedObj"
    // @Tag(key = "queryRefundBefore", value = "returnedObj")
    @Tags({
            @Tag(key = "返回值", value = "returnedObj"),// 指定返回值
            @Tag(key = "参数值", value = "arg[0]") // 指定参数
    })
    public TdRfxRefundBefore queryRefundBefore(String rfxid) {
        return tdRefundBeforeDao.getTdRfxRefundBefore(rfxid);
    }
}

    • 1
    • 2
    • 3
    • 4
    • 5
    • 6
    • 7
    • 8
    • 9
    • 10
    • 11
    • 12
    • 13
    • 14
    • 15
    • 16
    • 17
    • 18
    • 19
    • 20
    • 21
    • 22
    • 23
    • 24
    • 25
    • 26

    注意：
    1）使用@Tag或@Tags注解实现方法返回值的时候，返回值一定要实现toString()方法；
    2）使用@Tag或@Tags注解的时候，前提一定要有@Trace注解，单独使用没有作用。

    最后

    PDF文档下载：Skywalking UI使用攻略

  • 相关阅读:
    全网最牛自动化测试框架系列之pytest(4)-测试用例执行顺序
    有没有什么赚钱的副业？分享，适合学生赚钱的30个副业！
    网络安全（黑客）自学
    爬虫到底难在哪里？
    360杀毒卸载办法
    Grunt、Gulp 与 webpack：谁更胜一筹？
    django configparser.NoSectionError: No section: ‘Samples
    【目标检测】yolov7改进系列：添加CBAM注意力机制
    Python3语法入门题题解 & AcWing Django框架课
    【Koltin Flow（三）】Flow操作符之中间操作符（三）
  • 原文地址：https://blog.csdn.net/want_you_gogo/article/details/126097905