10_SkyWalking

本文介绍了SkyWalking,一款强大的APM工具,帮助解决微服务架构中的问题,如调用链路追踪、依赖分析和性能优化。讲解了服务端搭建、接入多个服务、MySQL持久化、自定义链路追踪和性能剖析等内容,还涉及日志同步与告警设置。

SkyWalking—前言

对于一个大型的几十个、几百个微服务构成的微服务架构系统,通常会遇到下面一些问题,比如:
1.如何串联整个调用链路,快速定位问题?

2.如何缕清各个微服务之间的依赖关系?

3.如何进行各个微服务接口的性能分析?

4.如何跟踪整个业务流程的调用处理顺序?

作用 : 快速定位问题

介绍SkyWalkingmp4

SkyWalking是一个国产开源框架,是一款优秀的**APM(Application Performance Management)**工具,包括了分布式追踪、性能指标分析、应用和服务依赖分析等

非侵入性的 优于其他链路框架

主要功能特性

1、多种监控手段,可以通过语言探针和service mesh获得监控的数据;

2、支持多种语言自动探针,包括Java,.NET Core和Node.JS;

3、轻量高效,无需大数据平台和大量的服务器资源;

4、模块化,UI、存储、集群管理都有多种机制可选;

5、支持告警;

6、优秀的可视化解决方案;

SkyWalking—服务端搭建

在这里插入图片描述

  • skywalking agent和业务系统绑定在一起,负责收集各种监控数据
  • Skywalking oapservice是负责处理监控数据的,比如接受skywaking agent的监控数据,并存储在数据库中:接受skywalking webapp的前端请求,从数据库查询数据,并返回数据给前端。Skywalking oapservice通常以集群的形式存在。
  • skywalking webapp,前端界面,用于展示数据。
  • 用于存储监控数据的数据库,比如mysql、elasticsearch等。

下载地址

解压 修改一下webapp中webapp.yml中的端口 8868 (本来是8080 为了防止冲突)

启动 bin/startup.bat

启动成功后会启动两个服务,一个是skywalking-oap-server,一个是skywalking-web-ui : 8868
skywalking-oap-serva;服务启动后会暴露11800和12800两个端口,分别为收集监控数据的端口11800和接受前端请求的端口12800

访问 localhost:8868

在这里插入图片描述

SkyWalking—接入多个微服务

Skywalking跨多个微服务跟踪,只需要每个微服务启动时添加javaagent参数即可。

gateway模块

在这里插入图片描述

gateway模块 alibaba-order-seata 和 alibaba-stock-seata 两个添加javaagent参数

在这里插入图片描述

-javaagent:D:\apache-skywalking-apm-bin8.5.0\agent\skywalking-agent.jar
-Dskywalking.agent.service_name=order-service
-Dskywalking.collector.backend_service=localhost:11800
参数描述
javaagent-配置 skywalking-agent.jar 的地址,需要修改
service_name-配置 需要监控的服务名,需要修改
javaagent-skywalking收集器服务的地址,照抄

nacos seata先启动 然后启动项目 alibaba-order-seata 和 alibaba-stock-seata 和gateway

此处有一个bug看不到gateway服务的

去到 D:\apache-skywalking-apm-bin8.5.0\agent\optional-plugins 把 apm-spring-cloud-gateway-2.1.x-plugin-8.5.0.jar复制到 D:\apache-skywalking-apm-bin8.5.0\agent\plugins当中 重启

在这里插入图片描述

SkyWalking—使用mysql持久化

默认使用的H2数据库存储

服务启动 关闭SkyWalking再启动服务没了

基于mysql的持久化

修改 config/application.yml

在这里插入图片描述

创建数据库swtest(不用创建表)

然后把mysql的依赖复制到 D:\apache-skywalking-apm-bin8.5.0\oap-libs 下

重启 skywalking

发现数据库swtest多了很多表

这个时候服务启动访问 关闭SkyWalking再启动服务 数据还在

SkyWalking—自定义链路追踪

如果我们希望对项目中的业务方法,实现链路追踪,方便我们排查问题,可以使用如下的代码引入依赖

order-nacos模块

<!--     skywalking工具类  跟服务版本一致  -->
<dependency>
    <groupId>org.apache.skywalking</groupId>
    <artifactId>apm-toolkit-trace</artifactId>
    <version>8.5.0</version>
</dependency>

service层 方法中加上@Trace

在这里插入图片描述

我们还可以为追踪链路增加其他额外的信息,比如记录参数和返回信息。实现方式:在(service层)方法上增加@Tag或者@Tags。

必须要有@Trace 后 @Tag才有用

@Trace
@Tag(key ="list",value="returnedObj")
//key = 方法名  value 也是固定的
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—日志

springboot默认实现的日志框架是logback,这里也就拿logback举例

1.order-nacos模块引入依赖

<!-- skywalking 日志记录  -->
<dependency>
    <groupId>org.apache.skywalking</groupId>
    <artifactId>apm-toolkit-logback-1.x</artifactId>
    <version>8.5.0</version>
</dependency>

2.在项目中resources目录下创建logback-spring.xml文件

主要就是在日志的输出格式中添加[%tid] 这个就是调用链路的id。

<?xml version="1.0" encoding="UTF-8"?>
<configuration>

    <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>%d{HH:mm:ss.SSS} [%thread] %-5level logger_name:%logger{36} - [%tid] - message:%msg%n</pattern>
            </layout>
        </encoder>
    </appender>

    <root level="INFO">
        <appender-ref ref="console" />
    </root>

</configuration>

3.测试,重启微服务后调用接口,就会在控制台的日志中看到调用链路tid

刚开始服务启动时,没有调用接口,也就肯定没有链路追踪id,然后调用接口后就会在日志中有显示了

在这里插入图片描述

在SkyWalking的追踪菜单中,如果链路很多,我们就可以通过这个TID来进行搜索

在这里插入图片描述

但现在日志菜单中还没有任何内容,如果想要服务的日志同步到SkyWalking中,并在日志菜单中显示就还需要在logback-spring.xml文件中添加配置 grpc-log

<?xml version="1.0" encoding="UTF-8"?>
<configuration>

    <!--  控制台日志输出的格式中添加tid  -->
    <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>%d{HH:mm:ss.SSS} [%thread] %-5level logger_name:%logger{36} - [%tid] - message:%msg%n</pattern>
            </layout>
        </encoder>
    </appender>

    <!-- skywalking grpc 日志收集 8.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} [%tid] [%thread] %-5level %logger{36} -%msg%n</Pattern>
            </layout>
        </encoder>
    </appender>

    <root level="INFO">
        <appender-ref ref="console" />
        <appender-ref ref="grpc-log" />
    </root>

</configuration>

重启访问 现在日志菜单中就会有我们为微服务打印的日志了

在这里插入图片描述

注意:如果SkyWalking的服务端不是部署在本地,也就是SkyWalking没有和微服务部署在同一台服务器中的话,需要修改agent\config\agent.config文件,在结尾添加以下配置,主要就是修改SkyWalking服务的ip和端口

plugin.toolkit.log.grpc.reporter.server_host=${SW_GRPC_LOG_SERVER_HOST:127.0.0.1}
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在本地的可以不配

在这里插入图片描述

SkyWalking完结—告警

在这里插入图片描述

这个自己去了解吧~ 完结撒花

SkyWalking 提供了灵活且可扩展的告警机制,允许用户根据监控指标定义告警规则,并通过多种方式发送告警通知。告警模块的配置主要包括告警规则(alert rules)、告警通知渠道(notification channels)以及告警配置文件(如 `alarm-settings.yml`)的设置。 ### 告警规则配置 SkyWalking 的告警规则主要定义在 `alarm-settings.yml` 文件中,该文件通常位于 `agent/config` 或 `backend` 模块的配置目录下。告警规则由一系列条件组成,当这些条件被满足时,系统将触发相应的告警事件。 告警规则的基本结构包括: - **服务名称(service)**:指定监控的服务。 - **指标名称(indicator)**:定义要监控的指标,如响应时间、成功率等。 - **阈值(threshold)**:定义触发告警的阈值。 - **时间窗口(window)**:定义评估指标的时间窗口大小。 - **告警级别(level)**:定义告警的严重程度,如 `CRITICAL`、`WARNING` 等。 示例告警规则如下: ```yaml rules: - name: "response_time_rule" metrics-name: "service_resp_time" threshold: 1000 op: ">" period: 10 silence-period: 5 level: "CRITICAL" message: "Response time of service {name} is over {threshold}ms in the last {period} minutes" ``` 在该规则中,如果服务的响应时间在过去10分钟内超过1000毫秒,则会触发一个严重级别的告警,并附带自定义的告警信息[^1]。 ### 告警通知配置 SkyWalking 支持多种告警通知方式,包括 Webhook、邮件、Slack、钉钉、企业微信等。告警通知的配置通常也在 `alarm-settings.yml` 中定义,通过 `webhooks` 或 `notifiers` 部分进行设置。 示例 Webhook 配置如下: ```yaml webhooks: - name: "dingtalk" url: "https://oapi.dingtalk.com/robot/send?access_token=your_token" headers: Content-Type: application/json ``` 在该配置中,SkyWalking 会将告警信息通过 HTTP POST 请求发送到指定的 Webhook URL,支持 JSON 格式的消息体。用户可以根据需要定义多个通知渠道,并在告警规则中指定使用哪个通知方式[^2]。 ### 告警模块的启动与运行 SkyWalking 的告警模块由 `AlarmModuleProvider` 提供支持,负责加载告警规则、初始化告警核心组件并启动告警检查线程。告警检查过程主要由 `AlarmCore` 类完成,其 `startRunningRule()` 方法会定期执行规则检查。 告警检查流程如下: 1. **数据写入**:监控数据通过 OAP 模块写入 `RunningRule` 的时间窗口中。 2. **窗口移动**:每个时间窗口(`Window`)会根据时间滑动,更新当前窗口的统计数据。 3. **规则检查**:`RunningRule.check()` 方法会评估当前窗口中的数据是否满足告警条件。 4. **告警触发**:如果条件满足,则调用 `NotifyHandler` 将告警信息发送到配置的通知渠道。 ```java public class AlarmCore { public void startRunningRule() { ScheduledExecutorService scheduler = Executors.newScheduledThreadPool(1); scheduler.scheduleAtFixedRate(() -> { for (RunningRule rule : rules) { if (rule.check()) { notifyHandler.send(rule.generateAlert()); } } }, 0, 1, TimeUnit.MINUTES); } } ``` 上述代码展示了告警核心的启动逻辑,定时任务每隔一分钟检查所有规则,并在满足条件时发送告警通知[^2]。 ### 告警配置的扩展点 SkyWalking 的告警模块设计为可插拔架构,用户可以通过实现 `AlarmNotifier` 接口来扩展新的通知渠道。例如,定义一个新的邮件通知器: ```java public class EmailNotifier implements AlarmNotifier { @Override public void send(Alert alert) { // 实现邮件发送逻辑 } } ``` 然后在配置文件中注册该通知器,即可在告警规则中使用它。这种设计允许用户根据实际需求灵活扩展告警通知机制[^1]。 ---
评论
成就一亿技术人!
拼手气红包6.0元
还能输入1000个字符
 
红包 添加红包
表情包 插入表情
 条评论被折叠 查看
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值