Spring Cloud Alibaba全家桶——微服務鍊路追蹤SkyWalking

本文為大家帶來微服務鍊路追蹤SkyWalking 相關知識，具體内容包括SkyWalking簡介，SkyWalking環境搭建部署，SkyWalking接入微服務，SkyWalking持久化跟蹤資料，自定義SkyWalking鍊路追蹤，SkyWalking內建日志架構，SkyWalking告警功能，SkyWalking高可用，SkyWalking UI介紹等進行詳盡介紹~

一、SkyWalking簡介

1️⃣鍊路追蹤介紹

對于一個大型的幾十個、幾百個微服務構成的微服務架構系統，通常會遇到下面一些問題，比如：

（1）如何串聯整個調用鍊路，快速定位問題？

（2）如何縷清各個微服務之間的依賴關系？

（3）如何進行各個微服務接口的性能分折？

（4）如何跟蹤整個業務流程的調用處理順序？

2️⃣SkyWalking是什麼

SkyWalking是一個國産開源架構，2015年由吳晟開源， 2017年加入Apache孵化器。skywalking是分布式系統的應用程式性能監視工具，專為微服務、雲原生架構和基于容器（Docker、K8s、Mesos）架構而設計。它是一款優秀的APM（Application Performance Management）工具，包括了分布式追蹤、性能名額分析、應用和服務依賴分析等。

————————————————

3️⃣鍊路追蹤架構對比

（1）Zipkin是Twitter開源的調用鍊分析工具，目前基于springcloud sleuth得到了廣泛的使用，特點是輕量，使用部署簡單。

（2）Pinpoint是南韓人開源的基于位元組碼注入的調用鍊分析，以及應用監控分析工具。特點是支援多種插件，UI功能強大，接入端無

代碼侵入。

（3）SkyWalking是本土開源的基于位元組碼注入的調用鍊分析，以及應用監控分析工具。特點是支援多種插件，UI功能較強，接入端

無代碼侵入。目前已加入Apache孵化器。

（4）CAT是大衆點評開源的基于編碼和配置的調用鍊分析，應用監控分析，日志采集，監控報警等一系列的監控平台工具。

模拟了三種并發使用者：500，750，1000。使用jmeter測試，每個線程發送30個請求，設定思考時間為10ms。使用的采樣率為1，即100%，這邊與生産可能有差别。pinpoint預設的采樣率為20，即50%，通過設定agent的配置檔案改為100%。zipkin預設也是1。組合起來，一共有12種。下面看下彙總表：

從上表可以看出，在三種鍊路監控元件中，skywalking的探針對吞吐量的影響最小，zipkin的吞吐量居中。pinpoint的探針對吞吐量的影響較為明顯，在500并發使用者時，測試服務的吞吐量從1385降低到774，影響很大。然後再看下CPU和memory的影響，在内部伺服器進行的壓測，對CPU和memory的影響都差不多在10%之内。

4️⃣SkyWalking功能特性

（1）多種監控手段，可以通過語言探針和service mesh獲得監控的資料；

（2）支援多種語言自動探針，包括 Java，.NET Core 和 Node.JS；

（3）輕量高效，無需大資料平台和大量的伺服器資源；

（4）子產品化，UI、存儲、叢集管理都有多種機制可選；

（5）支援告警；

（6）優秀的可視化解決方案。

二、SkyWalking環境搭建部署

skywalking agent和業務系統綁定在一起，負責收集各種監控資料；
skywalking oapservice是負責處理監控資料的，比如接受skywalking agent的監控資料，并存儲在資料庫中；
接受skywalking webapp的前端請求，從資料庫查詢資料，并傳回資料給前端。skywalking oapservice通常以叢集的形式存在；
skywalking webapp，前端界面，用于展示資料；
用于存儲監控資料的資料庫，比如mysql、elasticsearch等。

1️⃣下載下傳 SkyWalking

目錄結構：

2️⃣搭建SkyWalking OAP 服務

啟動腳本bin/startup.sh

日志資訊存儲在logs目錄

啟動成功後會啟動兩個服務，一個是skywalking-oap-server，一個是skywalking-web-ui ： 8868

skywalking-oap-server服務啟動後會暴露11800 和 12800 兩個端口，分别為收集監控資料的端口11800和接受前端請求的端口12800，修改端口可以修改config/applicaiton.yml

skywalking-web-ui服務會占用 8080 端口，修改端口可以修改webapp/webapp.yml

server.port：SkyWalking UI服務端口，預設是8080；collector.ribbon.listOfServers：SkyWalking OAP服務位址數組，SkyWalking UI界面的資料是通過請求SkyWalking OAP服務來獲得；

通路：http://192.168.3.100:8080/

頁面的右下角可以中英文切換，可以切換選擇要展示的時間區間的跟蹤資料。

3️⃣SkyWalking中三個概念

服務(Service) ：表示對請求提供相同行為的一系列或一組工作負載，在使用Agent時，可以定義服務的名字；

服務執行個體(Service Instance) ：上述的一組工作負載中的每一個工作負載稱為一個執行個體，一個服務執行個體實際就是作業系統上的一個真實程序；

端點(Endpoint) ：對于特定服務所接收的請求路徑, 如HTTP的URI路徑和gRPC服務的類名 + 方法簽名。

三、SkyWalking接入微服務

1️⃣linux環境——通過jar包方式接入

準備一個springboot程式，打成可執行jar包，寫一個shell腳本，在啟動項目的Shell腳本上，通過 -javaagent 參數進行配置SkyWalking Agent來跟蹤微服務。

startup.sh腳本啟動

#!/bin/sh
# SkyWalking Agent配置
export SW_AGENT_NAME=springboot‐skywalking‐demo #Agent名字,一般使用`spring.application.name`
export SW_AGENT_COLLECTOR_BACKEND_SERVICES=127.0.0.1:11800 #配置 Collector 位址。
export SW_AGENT_SPAN_LIMIT=2000 #配置鍊路的最大Span數量，預設為 300。
export JAVA_AGENT=‐javaagent:/usr/local/soft/apache‐skywalking‐apm‐bin‐es7/agent/skywalking‐agent.jar
java $JAVA_AGENT ‐jar springboot‐skywalking‐demo‐0.0.1‐SNAPSHOT.jar #jar啟動

啟動日志：

以上啟動等同于：

java ‐javaagent:/usr/local/soft/apache‐skywalking‐apm‐bin‐es7/agent/skywalking‐agent.jar
‐DSW_AGENT_COLLECTOR_BACKEND_SERVICES=127.0.0.1:11800
‐DSW_AGENT_NAME=springboot‐skywalking‐demo ‐jar springboot‐skywalking‐demo‐0.0.1‐SNAPSHOT.jar

參數名對應agent/config/agent.config配置檔案中的屬性。

屬性對應的源碼：org.apache.skywalking.apm.agent.core.conf.Config.java。

# The service name in UI
agent.service_name=${SW_AGENT_NAME:Your_ApplicationName}
# Backend service addresses.
collector.backend_service=${SW_AGENT_COLLECTOR_BACKEND_SERVICES:127.0.0.1:11800}

我們也可以使用skywalking.+配置檔案中的配置名作為系統配置項來進行覆寫。 javaagent參數配置方式優先級更高。

測試：通路你的微服務

2️⃣Windows環境——在IDEA中使用SkyWalking

在運作的程式配置jvm參數，如下圖所示：

# skywalking‐agent.jar的本地磁盤的路徑
‐javaagent:D:\apache\apache‐skywalking‐apm‐es7‐8.4.0\apache‐skywalking‐apm‐bin‐es7\agent\skywalking‐agent.jar
# 在skywalking上顯示的服務名
‐DSW_AGENT_NAME=springboot‐skywalking‐demo
# skywalking的collector服務的IP及端口
‐DSW_AGENT_COLLECTOR_BACKEND_SERVICES=192.168.3.100:11800

-DSW_AGENT_COLLECTOR_BACKEND_SERVICES 可以指定遠端位址，但是-javaagent必須綁定你本機實體路徑的skywalkingagent.jar。

3️⃣SkyWalking跨多個微服務跟蹤

Skywalking跨多個微服務跟蹤，隻需要每個微服務啟動時添加javaagent參數即可。

測試：

啟動微服務mall-gateway，mall-order，mall-user ，配置skywalking的jvm參數，

通路http://localhost:8888/user/findOrderByUserId/1

注意：此處存在bug，跟蹤鍊路不顯示gateway

拷貝agent/optional-plugins目錄下的gateway插件到agent/plugins目錄。

四、SkyWalking持久化跟蹤資料

預設使用的H2資料庫存儲，config/application.yml配置檔案如下：

基于mysql持久化：

（1）修改config目錄下的application.yml，使用mysql作為持久化存儲的倉庫

（2）修改mysql連接配接配置

storage:
  #選擇使用mysql 預設使用h2，不會持久化，重新開機skyWalking之前的資料會丢失
  selector: ${SW_STORAGE:mysql}
  #使用mysql作為持久化存儲的倉庫
  mysql:
    properties:
      #資料庫連接配接位址
      jdbcUrl: ${SW_JDBC_URL:"jdbc:mysql://1ocalhost:3306/swtest"}
      #使用者名
      dataSource.user: ${SW_DATA_SOURCE_USER:root}
      #密碼
      dataSource.password: ${SW_DATA_SOURCE_PASSWORD:root}

注意：需要添加mysql資料驅動包，因為在lib目錄下是沒有mysql資料驅動包的，是以修改完配置啟動是會報錯，啟動失敗的。

（3）添加mysql資料驅動包到oap-libs目錄下

（4）啟動Skywalking

檢視swtest資料庫，可以看到生成了很多表：

這說明啟動成功了，打開配置對應的位址http://192.168.3.100:8080/，j就可以看到skywalking的web界面。

（5）測試：重新開機skywalking，驗證跟蹤資料會不會丢失

五、自定義SkyWalking鍊路追蹤

如果我們希望對項目中的業務方法，實作鍊路追蹤，友善我們排查問題，可以使用如下的代碼引入依賴：

<!‐‐ SkyWalking 工具類 ‐‐>
<dependency>
  <groupId>org.apache.skywalking</groupId>
  <artifactId>apm‐toolkit‐trace</artifactId>
  <version>8.4.0</version>
</dependency>

1️⃣@Trace将方法加入追蹤鍊路

如果一個業務方法想在ui界面的跟蹤鍊路上顯示出來，隻需要在業務方法上加上@Trace注解即可：

測試：

2️⃣加入@Tags或@Tag

我們還可以為追蹤鍊路增加其他額外的資訊，比如記錄參數和傳回資訊。實作方式：在方法上增加@Tag或者@Tags。

@Tag 注解中 key = 方法名； value = returnedObj 傳回值 arg[0] 參數。

@Trace
@Tag(key = "list", value = "returnedObj")
public List<User> list(){
  return userMapper.list();
}

@Trace
@Tags({@Tag(key = "param", value = "arg[0]"),
@Tag(key = "user", value = "returnedObj")})
public User getById(Integer id){
  return userMapper.getById(id);
}

性能分析：

skywalking的性能分析，在根據服務名稱、端點名稱，以及相應的規則建立了任務清單後，在調用了此任務清單的端點後。skywalking會自動記錄，剖析目前端口，生成剖析結果，具體流程如圖：

六、SkyWalking內建日志架構

（1）引入依賴

<!‐‐ apm‐toolkit‐logback‐1.x ‐‐>
<dependency>
  <groupId>org.apache.skywalking</groupId>
  <artifactId>apm‐toolkit‐logback‐1.x</artifactId>
  <version>8.5.0</version>
</dependency>

（2）添加logback-spring.xml檔案，并配置 %tid 占位符

<?xml version="1.0" encoding="UTF‐8"?>
<configuration>
  <!‐‐ 引入 Spring Boot 預設的 logback XML 配置檔案 ‐‐>
  <include resource="org/springframework/boot/logging/logback/defaults.xml"/>
  
  <appender name="console" 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.TraceIdPatternLogbackLayout">
        <Pattern>${CONSOLE_LOG_PATTERN}</Pattern>
      </layout>
    </encoder>
  </appender>

  <!‐‐ 設定 Appender ‐‐>
  <root level="INFO">
    <appender‐ref ref="console"/>
  </root>

</configuration>

（3）測試

（4）Skywalking通過grpc上報日志（需要v8.4.0+）

gRPC報告程式可以将收集到的日志轉發到SkyWalking OAP伺服器上。

logback-spring.xml中添加：

<!‐‐ v8.4.0提供 ‐‐>
<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%n</Pattern>
    </layout>
  </encoder>
</appender>

<root level="info">
  <appender‐ref ref="grpc‐log" />
</root>

打開agent/config/agent.config配置檔案，添加如下配置資訊：

plugin.toolkit.log.grpc.reporter.server_host=${SW_GRPC_LOG_SERVER_HOST:192.168.3.100}
plugin.toolkit.log.grpc.reporter.server_port=${SW_GRPC_LOG_SERVER_PORT:11800}
plugin.toolkit.log.grpc.reporter.max_message_size=${SW_GRPC_LOG_MAX_MESSAGE_SIZE:10485760}
plugin.toolkit.log.grpc.reporter.upstream_timeout=${SW_GRPC_LOG_GRPC_UPSTREAM_TIMEOUT:30}

以上配置是預設配置資訊,agent與oap在本地的可以不配。

agent配置資訊：

Skywalking UI效果：

七、SkyWalking告警功能

SkyWalking 告警功能是在6.x版本新增的，其核心由一組規則驅動，這些規則定義在config/alarm-settings.yml檔案中。

告警規則的定義分為兩部分：

（1）告警規則：它們定義了應該如何觸發度量警報，應該考慮什麼條件。

（2）Webhook（網絡鈎子）：定義當警告觸發時，哪些服務終端需要被告知。

1️⃣告警規則

SkyWalking 的發行版都會預設提供config/alarm-settings.yml檔案，裡面預先定義了一些常用的告警規則。如下：

（1）過去 3 分鐘内服務平均響應時間超過 1 秒。
（2）過去 2 分鐘服務成功率低于80%。
（3）過去 3 分鐘内服務響應時間超過 1s 的百分比
（4）服務執行個體在過去 2 分鐘内平均響應時間超過 1s，并且執行個體名稱與正規表達式比對。
（5）過去 2 分鐘内端點平均響應時間超過 1 秒。
（6）過去 2 分鐘内資料庫通路平均響應時間超過 1 秒。
（7）過去 2 分鐘内端點關系平均響應時間超過 1 秒。

這些預定義的告警規則，打開config/alarm-settings.yml檔案即可看到。

告警規則配置項的說明：

Rule name：規則名稱，也是在告警資訊中顯示的唯一名稱。必須以_rule結尾，字首可自定義
Metrics name：度量名稱，取值為oal腳本中的度量名，目前隻支援long、double和int類型。詳見Official OAL script
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：告警消息

2️⃣Webhook（網絡鈎子）

Webhook可以簡單了解為是一種Web層面的回調機制，通常由一些事件觸發，與代碼中的事件回調類似，隻不過是Web層面的。由于是Web層面的，是以當事件發生時，回調的不再是代碼中的方法或函數，而是服務接口。例如，在告警這個場景，告警就是一個事件。當該事件發生時，SkyWalking就會主動去調用一個配置好的接口，該接口就是所謂的Webhook。

SkyWalking的告警消息會通過 HTTP 請求進行發送，請求方法為 POST，Content-Type 為 application/json，其JSON 資料實基于List<org.apache.skywalking.oap.server.core.alarm.AlarmMessage進行序列化的。JSON資料示例：

[{
  "scopeId": 1,
  "scope": "SERVICE",
  "name": "serviceA",
  "id0": "12",
  "id1": "",
  "ruleName": "service_resp_time_rule",
  "alarmMessage": "alarmMessage xxxx",
  "startTime": 1560524171000
}, {
  "scopeId": 1,
  "scope": "SERVICE",
  "name": "serviceB",
  "id0": "23",
  "id1": "",
  "ruleName": "service_resp_time_rule",
  "alarmMessage": "alarmMessage yyy",
  "startTime": 1560524171000
}]

字段說明：

scopeId、scope：所有可用的 Scope 詳見org.apache.skywalking.oap.server.core.source.DefaultScopeDefine
name：目标 Scope 的實體名稱
id0：Scope 實體的 ID
id1：保留字段，目前暫未使用
ruleName：告警規則名稱
alarmMessage：告警消息内容
startTime：告警時間，格式為時間戳

3️⃣郵件告警功能實踐

SkyWalking是不支援直接向郵箱、短信等服務發送告警資訊的，SkyWalking隻會在發生告警時将告警資訊發送至配置好的Webhook接口。

但我們總不能人工盯着該接口的日志資訊來得知服務是否發生了告警，是以我們需要在該接口裡實作發送郵件或短信等功能，進而達到個性化的告警通知。

接下來開始動手實踐，這裡基于Spring Boot進行實作。

（1）首先是添加依賴

<dependency>
  <groupId>org.springframework.boot</groupId>
  <artifactId>spring‐boot‐starter‐mail</artifactId>
</dependency>

（2）配置郵箱服務

server:
  port: 9134

  #郵箱配置
  spring:
    mail:
      host: smtp.163.com
      #發送者郵箱賬号
      username: 你的郵箱@163.com
      #發送者密鑰
      password: 你的郵箱服務密鑰
      default‐encoding: utf‐8
      port: 465 #端口号465或587
      protocol: smtp
  properties:
    mail:
      debug:
        false
    smtp:
      socketFactory:
        class: javax.net.ssl.SSLSocketFactory

（3）根據SkyWalking發送的JSON資料定義一個DTO，用于接口接收資料

@Data
public class SwAlarmDTO {
  private Integer scopeId;
  private String scope;
  private String name;
  private Integer id0;
  private Integer id1;
  private String ruleName;
  private String alarmMessage;
  private Long startTime;
}

（4）接着定義一個接口，實作接收SkyWalking的告警通知，并将資料發送至郵箱

@Slf4j
@RestController
@RequiredArgsConstructor
@RequestMapping("/alarm")
public class SwAlarmController {

  private final JavaMailSender sender;

  @Value("${spring.mail.username}")
  private String from;

  /**
  * 接收skywalking服務的告警通知并發送至郵箱
  **/
  @PostMapping("/receive")
  public void receive(@RequestBody List<SwAlarmDTO> alarmList) {
    SimpleMailMessage message = new SimpleMailMessage();
    // 發送者郵箱
    message.setFrom(from);
    // 接收者郵箱
    message.setTo(from);
    // 主題
    message.setSubject("告警郵件");
    String content = getContent(alarmList);
    // 郵件内容
    message.setText(content);
    sender.send(message);
    log.info("告警郵件已發送...");
  }
 
  private String getContent(List<SwAlarmDTO> alarmList) {
    StringBuilder sb = new StringBuilder();
    for (SwAlarmDTO dto : alarmList) {
      sb.append("scopeId: ").append(dto.getScopeId())
        .append("\nscope: ").append(dto.getScope())
        .append("\n目标 Scope 的實體名稱: ").append(dto.getName())
        .append("\nScope 實體的 ID: ").append(dto.getId0())
        .append("\nid1: ").append(dto.getId1())
        .append("\n告警規則名稱: ").append(dto.getRuleName())
        .append("\n告警消息内容: ").append(dto.getAlarmMessage())
        .append("\n告警時間: ").append(dto.getStartTime())
        .append("\n\n‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐\n\n");
    }
 
    return sb.toString();
  }
}

（5）最後将該接口配置到SkyWalking中，Webhook的配置位于config/alarm-settings.yml檔案的末尾，格式為http://{ip}:{port}/{uri}。

如下示例：

[root@ip‐236‐048 skywalking]# vim config/alarm‐settings.yml

webhooks:
  ‐ http://127.0.0.1:9134/alarm/receive

（6）測試告警功能

完成告警接口的開發及配置後，我們來進行一個簡單的測試。這裡有一條調用鍊路如下：

在/producer接口中增加一行睡2秒的代碼：

@Override
@Trace
@Tag(key="getAll",value="returnedObj")
public List<Order> all() throws InterruptedException {
  TimeUnit.SECONDS.sleep(2);
  return orderMapper.selectAll();
}

通路http://localhost:8072/order/all，執行完測試代碼，等待約兩分鐘後，告警接口的控制台輸出了一段日志資訊：

八、SkyWalking高可用

在大多數生産環境中，後端應用需要支援高吞吐量并且支援高可用來保證服務的穩定，是以你始終需要在生産環境進行叢集管理。

skywalking叢集是将skywalking oap作為一個服務注冊到nacos上，隻要skywalking oap服務沒有全部當機，保證有一個skywalking oap在運作，就能進行跟蹤。

搭建一個skywalking oap叢集需要：

（1）至少一個Nacos（也可以是nacos叢集）；
（2）至少一個ElasticSearch/mysql（也可以是es/msql叢集）；
（3）至少2個skywalking oap服務；
（4）至少1個UI（UI也可以叢集多個，用Nginx代理統一入口）。

（1）修改config/application.yml檔案

使用nacos作為注冊中心：

修改nacos配置：

可以選擇性修改監聽端口：

修改存儲政策，使用elasticsearch7作為storage：

（2）配置ui服務webapp.yml檔案的listOfServers，寫兩個位址

（3）啟動服務測試

啟動Skywalking服務，指定springboot應用的jvm參數：

‐DSW_AGENT_COLLECTOR_BACKEND_SERVICES=192.168.3.10:11800,192.168.3.12:11800

九、SkyWalking UI介紹

1️⃣菜單欄

儀表盤：檢視被監控服務的運作狀态；
拓撲圖：以拓撲圖的方式展現服務之間的關系，并以此為入口檢視相關資訊；
追蹤：以接口清單的方式展現，追蹤接口内部調用過程；
性能剖析：對端點進行采樣分析，并可檢視堆棧資訊；
告警：觸發告警的告警清單，包括服務失敗率，請求逾時等；
自動重新整理：重新整理目前頁面資料内容。

2️⃣控制欄

第一欄：不同内容主題的監控面闆，應用性能管理/資料庫/容器等；
第二欄：操作，包括編輯/導出目前資料/倒入展示資料/不同服務端點篩選展示；
第三欄：不同緯度展示，全局/服務/執行個體/端點。

3️⃣展示欄

Global全局次元：

第一欄：Global、Service、Instance、Endpoint不同展示面闆；
Services load：服務每分鐘請求數；
Slow Services：慢響應服務，機關ms；
Un-Health services(Apdex): Apdex性能名額，1為滿分；
Slow Endpoint：慢響應端點，機關ms；
Global Response Latency：百分比響應延時，不同百分比的延時時間，機關ms；
Global Heatmap：服務響應時間熱力分布圖，根據時間段内不同響應時間的數量顯示顔色深度；
底部欄：展示資料的時間區間，點選可以調整。

Service服務次元：

Service Apdex（數字）:目前服務的評分；
Service Apdex（折線圖）：不同時間的Apdex評分；
Service Avg Response Times：平均響應延時，機關ms；
Service Response Time Percentile：百分比響應延時；
Successful Rate（數字）：請求成功率；
Successful Rate（折線圖）：不同時間的請求成功率；
Servce Load（數字）：每分鐘請求數；
Service Load（折線圖）：不同時間的每分鐘請求數；
Service Instances Load：每個服務執行個體的每分鐘請求數；
Show Service Instance：每個服務執行個體的最大延時；
Service Instance Successful Rate：每個服務執行個體的請求成功率。

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：JVM線程數；
還有幾個是.NET的，類似于JVM虛拟機，暫時不做說明。

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：目前端點每個時間段的請求成功率；

4️⃣拓撲圖

1.選擇不同的服務關聯拓撲；
2.檢視單個服務相關内容；
3.服務間連接配接情況；
4.分組展示服務拓撲。

5️⃣追蹤

左側：api接口清單，紅色-異常請求，藍色-正常請求；
右側：api追蹤清單，api請求連接配接各端點的先後順序和時間。

6️⃣性能剖析

建立任務：建立需要分析的端點
左側清單：任務及對應的采樣請求
右側：端點鍊路及每個端點的堆棧資訊

服務：需要分析的服務；
端點：鍊路監控中端點的名稱，可以在鍊路追蹤中檢視端點名稱；
監控時間：采集資料的開始時間；
監控持續時間：監控采集多長時間；
起始監控時間：多少秒後進行采集；
監控間隔：多少秒采集一次；
最大采集數：最大采集多少樣本。

分析線程棧資訊：

8️⃣告警

不同次元告警清單，可分為服務、端點和執行個體。

Spring Cloud Alibaba全家桶——微服務鍊路追蹤SkyWalking

二、SkyWalking環境搭建部署

1️⃣下載下傳 SkyWalking

2️⃣搭建SkyWalking OAP 服務

2️⃣Windows環境——在IDEA中使用SkyWalking

四、SkyWalking持久化跟蹤資料

五、自定義SkyWalking鍊路追蹤

1️⃣@Trace将方法加入追蹤鍊路

2️⃣加入@Tags或@Tag

六、SkyWalking內建日志架構

九、SkyWalking UI介紹

1️⃣菜單欄

4️⃣拓撲圖

5️⃣追蹤

6️⃣性能剖析

8️⃣告警

後記

繼續閱讀

MyBatis-Plus 之AR模式

馴服爛代碼_馴服Tomcat：Tomcat 5的過濾技巧

基于Springboot+VUE+Mysql的大學生校園疫情防控管理系統

Using MessageConverter

馴服爛代碼_C＃中的馴服配置

Spring Cloud整合Sleuth，當請求完成後，Zipkin沒有鍊路資訊

JAVA自學之路——馬士兵

Rabbitmq指令行手動建立隊列

整合 Spring 開發架構及服務端技術

SSM整合02---Spring-SpringMVC層一、添加web架構支援二、web.xml三、spring-mvc.xml

SSM架構（二）------------表現層的SpringMVC

Intellij idea基于Maven 的SSM 架構整合

Spring資料和Redis

SpringMVC的啟動過程源碼分析1 SpringMVC 配置XML的方式啟動2 SpringMVC純注解模式啟動

Java Spring 架構

SpringCloud微服務（四）之ribbon筆記ribbon是什麼？入門案例自定義均衡負載算法