基于SkyWalking的分布式跟踪系统 - 微服务监控

上一篇文章我们搭建了基于SkyWalking分布式跟踪环境,今天聊聊使用SkyWalking监控我们的微服务(DUBBO)

服务案例

假设你有个订单微服务,包含以下组件

  • MySQL数据库分表分库(2台)
  • 生产者(2台) dubbo-provider
  • 消费者 dubbo-consumer

网络拓扑图如下

生产者的关键代码

@Service
public class OrderServiceImpl implements OrderService {

    @Autowired
    protected OrderMapper orderMapper;

    @Override
    public OrderVO getById(long id) {
        OrderVO orderVO = new OrderVO();
        Order order = orderMapper.selectById(id);
        BeanUtils.copyProperties(order,orderVO);
        return orderVO;
    }
}

消费者的关键代码

@RestController
public class OrderController {

    @Reference(retries = 0)
    private OrderService orderService;

    @GetMapping("/order/{id}")
    public OrderVO getOrder(@PathVariable long id){
        return orderService.getById(id);
    }

}

监控启动

  • 使用 javaagent 启动生产者

    -javaagent:E:\讯飞开发工具\skywalking\agent\skywalking-agent.jar -Dskywalking.agent.service_name=dubbo-provider -Dskywalking.collector.backend_service=192.168.136.129:11800

    -javaagent:E:\讯飞开发工具\skywalking\agent\skywalking-agent.jar -Dskywalking.agent.service_name=dubbo-provider2 -Dskywalking.collector.backend_service=192.168.136.129:11800

  • 启动消费者
    -javaagent:E:\讯飞开发工具\skywalking\agent\skywalking-agent.jar -Dskywalking.agent.service_name=dubbo-consumer -Dskywalking.collector.backend_service=192.168.136.129:11800
  • 模拟请求
    在浏览器访问http://localhost:9090/order/1184489161562816511,多次调用使负载生效;修改订单id参数,让调用覆盖不同的数据库
  • 效果查看
    访问skywalking监控地址http://192.168.136.129:8080/查看监控效果

    仪表盘

    网络拓扑图

    错误日志

    Trace查询

日志集成

这部分我们先看下调用链的原理:

  • 请求到来生成一个全局TraceID,通过TraceID可以串联起整个调用链,一个TraceID代表一次请求。
  • 除了TraceID外,还需要SpanID用于记录调用父子关系。每个服务会记录下Parent id和Span id,通过他们可以组织一次完整调用链的父子关系。
  • 要查看某次完整的调用则只要根据TraceID查出所有调用记录,然后通过Parent id和Span id组织起整个调用父子关系。

正是由于TraceID如此重要,所以我们希望这个调用链的TraceID能输出在日志文件中,一旦观察到有异常调用,我们在日志分析平台直接搜索TraceID即可将关联的日志全部检索出来,大大提高我们解决问题的效率。

集成过程(log4j2)

  • 引入日志包log4j2
    ```

    org.springframework.boot
    spring-boot-starter

    org.springframework.boot
    spring-boot-starter-logging

    org.springframework.boot
    spring-boot-starter-log4j2

    ```

  • 引入SW工具包
    <!--SW trace 跟踪--> <dependency> <groupId>org.apache.skywalking</groupId> <artifactId>apm-toolkit-log4j-2.x</artifactId> <version>6.4.0</version> </dependency>
  • 修改日志显示格式 log4j2.xml
    %d [%traceId] %-5p %c{1}:%L - %m%n
  • 启动应用,观察控制台

    刚启动时候获取不到TraceID,所以TID显示为N/A,启动完成后调用请求再次观察控制台,发现所有链路上的日志都打上了TraceID。

很简单的几步就让你的微服务加上了调用链监控,你还不赶紧试试?

相关文章:
基于SkyWalking的分布式跟踪系统 - 环境搭建

SpringBoot2.1.9+dubbo2.7.3+Nacos1.1.4构建你的微服务体系

请关注个人公众号:JAVA日知录

原文地址:https://www.cnblogs.com/jianzh5/p/11809875.html

时间: 2024-10-13 01:28:14

基于SkyWalking的分布式跟踪系统 - 微服务监控的相关文章

基于SkyWalking的分布式跟踪系统 - 异常告警

通过前面2篇文章我们搭建了SW的基础环境,监控了微服务,能了解所有服务的运行情况.但是当出现服务响应慢,接口耗时严重时我们需要立即定位到问题,这就需要我们今天的主角--监控告警,同时此篇也是SW系列的最后一篇. UI参数 首先我们认识一下SW DashBoard上的几个关键参数,如下图所示 告警配置 告警流程 skywalking发送告警的基本原理是每隔一段时间轮询skywalking-collector收集到的链路追踪的数据,再根据所配置的告警规则(如服务响应时间.服务响应时间百分比)等,如果

微服务之分布式跟踪系统(springboot+zipkin)

微服务之分布式跟踪系统(springboot+zipkin) 一.zipkin是什么 zipkin是一个开放源代码分布式的跟踪系统,由Twitter公司开源,它致力于收集服务的定时数据,以解决微服务架构中的延迟问题,包括数据的收集.存储.查找和展现.它的理论模型来自于Google Dapper 论文. 每个服务向zipkin报告计时数据,zipkin会根据调用关系通过Zipkin UI生成依赖关系图,显示了多少跟踪请求通过每个服务,该系统让开发者可通过一个 Web 前端轻松的收集和分析数据,例如

系统微服务架构

v\:* {behavior:url(#default#VML);} o\:* {behavior:url(#default#VML);} w\:* {behavior:url(#default#VML);} .shape {behavior:url(#default#VML);} table.MsoNormalTable {mso-style-name:普通表格; mso-tstyle-rowband-size:0; mso-tstyle-colband-size:0; mso-style-n

从本地事务到分布式事务到微服务下事务

从本地事务到分布式事务到微服务下事务 一.传统本地事务 传统单服务器,单关系型数据库下事务比较简单,完全可用很简单的实现ACID,实际中我们实现一个业务时只需要:开启一个事务-操作数据库-提交/回滚这个事务,这样就完美的实现了一次事务操作,更简单点我们通常会通过spring集成事务直接指定在哪些服务什么样的方法执行什么样的事务即可,更甚至我们业务实现基本都忽略了事务,具体图如下: 二.传统分布式事务 在传统一服务,一个关系数据库架构基础上,随着访问量的增大,单机很明显已满足不了现状,于是我们顺其

实现一个基于WCF的分布式缓存系统

前言: 用到分布式的东西很多了,一直想做一个简单的分布式小项目练练手学习下.后来决定来一个简单的分布式缓存的系统. 在企业应用开发中缓存的用例不胜枚举,但是每次更多的是单机的部署与使用,没有对应的需求是一个原因,另一个原因总是好高骛远做过的总是不想再进行修正. 这次的分布式就从最简单的分布式缓存开始.说简单是因为没有实现分布式缓存高深的寻址,或者对备份处理的牛X实现.只是实现了“分布”这个目的,不足之处还请大家指导. 分布的实现方式有哪些? 既然做“分布”,当然要看看主流的“分布”实现方式.小弟

微服务监控案例之一

     首先,您需要了解什么是微服务架构设计,同时了解相关微服务与Docker介绍, 微服务架构的本质,是把整体的业务拆分成很多有特定明确功能的服务,通过很多分散的小服务之间的配合,去解决更大,更复杂的问题.对被拆分后的服务进行分类和管理,彼此之间使用统一的接口来进行交互.      微服务的特点决定了功能模块的部署是分布式的,以往在单应用环境下,所有的业务都在同一个服务器上,如果服务器出现错误和异常,我们只要盯住一个点,就可以快速定位和处理问题,但是在微服务的架构下,大部分功能模块都是单独部

微服务监控zipkin+asp.net core

0.目录 整体架构目录:ASP.NET Core分布式项目实战-目录 监控目录:微服务监控zipkin.skywalking以及日志ELK监控系列 一.zipkin介绍 zipkin是一种分布式跟踪系统,有助于收集微服务架构中的延迟问题所需要的时序数据(收集查找),收集微服务之间的调用情况,然后处理调用之间数据延迟等问题. 如下图:微服务调用情况深度.(官方文档图) 以及依赖图分析,会展示出微服务之间的调用关系.当然下图展示的是我案例中的图片 二.zipkin作用 1.全链路追踪工具(查看依赖关

Java高并发高性能分布式框架从无到有微服务架构设计

微服务架构模式(Microservice Architect Pattern).近两年在服务的疯狂增长与云计算技术的进步,让微服务架构受到重点关注 微服务架构是一种架构模式,它提倡将单一应用程序划分成一组小的服务,服务之间互相协调.互相配合,为用户提供最终价值.每个服务运行在其独立的进程中,服务与服务间采用轻量级的通信机制互相沟通(通常是基于HTTP的RESTful API).每个服务都围绕着具体业务进行构建,并且能够被独立地部署到生产环境.类生产环境等.另外,应尽量避免统一的.集中式的服务管理

基于OpenResty和Node.js的微服务架构实践

什么是微服务? 传统的单体服务架构是单独服务包,共享代码与数据,开发成本较高,可维护性.伸缩性较差,技术转型.跨语言配合相对困难.而微服务架构强调一个服务负责一项业务,服务可以单独部署,独立进行技术选型和开发,服务间松耦合,服务依赖的数据也独立维护管理.虽然微服务存在部署复杂.运维难度较大.分布式事务控制难.容错要求高等缺点,但总体而言,微服务的优点远大于其复杂性. 微服务架构需要注意哪些问题? 微服务架构,首先考虑客户端与服务端之间的通信问题.有两种解决办法,一是客户端与多个服务端直接进行通信