简述分布式跟踪系统实现原理

问题来源

互联网项目通常都是大用户量,大并发,因此从技术架构上大多采用分布式架构构建成大型分布式系统,SOA或者是微服务,一个请求涉及到多个子系统,如果某个请求的处理不正常,怎么排查定位问题呢?如果没有合适的手段,排查问题无异大海捞针,为了提高解决问题的效率,迫切需要有一个技术手段能跟踪整个处理环节,并能够快速定位。一种可行的方案就是跟踪这个调用链,把每次请求的完整处理环节串联起来,这样就可以实现对调用路径的全程监控。

技术实现要点

采用日志埋点技术,在请求的处理入口处为该次请求分配一个TraceId(跟踪Id),将此TraceId依次传递给下一个处理环节,在每一个处理环节记录日志,通过这个TraceId就可以查询到从起始到处理完毕整个处理路径中的日志信息。

埋点日志记录的内容

TraceId、RPCId、调用的开始时间,调用类型,协议类型,调用方ip和端口,请求的服务名等信息;

调用耗时,调用结果,异常信息,消息报文等;

预留可扩展字段,为将来的扩展做预留;

记录内容可以根据业务的需要详细设计,原则就是要方便将来排查定位问题。

收集查询的实现

把埋点日志数据收集起来,再搭建一个查询系统就可以方便定位问题了,简单的查询分析系统可以采用ELK(Elasticsearch + Logstash + Kibana)来搭建。

参考文献,谷歌的Dapper论文:https://bigbully.github.io/Dapper-translation

原文地址:https://www.cnblogs.com/aiandbigdata/p/10046983.html

时间: 2024-10-23 09:14:35

简述分布式跟踪系统实现原理的相关文章

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

上一篇文章我们搭建了基于SkyWalking分布式跟踪环境,今天聊聊使用SkyWalking监控我们的微服务(DUBBO) 服务案例 假设你有个订单微服务,包含以下组件 MySQL数据库分表分库(2台) 生产者(2台) dubbo-provider 消费者 dubbo-consumer 网络拓扑图如下 生产者的关键代码 @Service public class OrderServiceImpl implements OrderService { @Autowired protected Ord

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

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

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

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

设计和应用分布式调用跟踪系统

分布式追踪系统dapper 分布式调用跟踪系统的设计和应用 >>为什么需要分布式调用跟踪系统 随着分布式服务架构的流行,特别是微服务等设计理念在系统中的应用,业务的调用链越来越复杂, 可以看到,随着服务的拆分,系统的模块变得越来越多,不同的模块可能由不同的团队维护, 一个请求可能会涉及到几十个服务的协同处理, 牵扯到多个团队的业务系统,那么如何快速准确的定位到线上故障?同时,缺乏一个自上而下全局的调用id,如何有效的进行相关的数据分析工作? 对于大型网站系统,如淘宝.京东等电商网站,这些问题尤

分布式服务跟踪系统

一个分布式服务跟踪系统主要由三部分构成: 数据收集 数据存储 数据展示 根据系统大小不同,每一部分的结构又有一定变化.譬如,对于大规模分布式系统,数据存储可分为实时数据和全量数据两部分,实时数据用于故障排查(Trouble Shooting),全量数据用于系统优化:数据收集除了支持平台无关和开发语言无关系统的数据收集,还包括异步数据收集(需要跟踪队列中的消息,保证调用的连贯性),以及确保更小的侵入性:数据展示又涉及到数据挖掘和分析.虽然每一部分都可能变得很复杂,但基本原理都类似. 服务追踪的追踪

Dapper,大规模分布式系统的跟踪系统--转

原文地址:http://bigbully.github.io/Dapper-translation/ 概述 当代的互联网的服务,通常都是用复杂的.大规模分布式集群来实现的.互联网应用构建在不同的软件模块集上,这些软件模块,有可能是由不同的团队开发.可能使用不同的编程语言来实现.有可能布在了几千台服务器,横跨多个不同的数据中心.因此,就需要一些可以帮助理解系统行为.用于分析性能问题的工具. Dapper--Google生产环境下的分布式跟踪系统,应运而生.那么我们就来介绍一个大规模集群的跟踪系统,

分布式调用跟踪系统的设计和应用

分布式调用跟踪系统的设计和应用 https://www.cnblogs.com/binyue/p/5703812.html 淘宝的鹰眼 google的Drapper Twitter的zipkin 新浪的watchman 京东的hydra 原文地址:https://www.cnblogs.com/stono/p/9454912.html

【架构设计】分布式文件系统 FastDFS的原理和安装使用

本文地址 分享提纲: 1.概述 2. 原理 3. 安装 4. 使用 5. 参考文档 1. 概述 1.1)[常见文件系统] Google了一下,流行的开源分布式文件系统有很多,介绍如下: -- mogileFS:Key-Value型元文件系统,不支持FUSE,应用程序访问它时需要API,主要用在web领域处理海量小图片,效率相比mooseFS高很多. -- fastDFS:国人 余庆老师(GitHub)在mogileFS的基础上进行改进的key-value型文件系统,同样不支持FUSE,提供比mo

kafka--高性能的分布式消息系统

kafka是一个分布式的,高吞吐量的.信息分片存储,消息同步复制的开源消息服务,它提供了消息系统的功能,但是采用了独特的设计. kafka最初由LinkedIn设计开发,使用Scala语言编写,用作LinkedIn网站的活动流数据和运营数据处理工具,这其中活动流数据是指页面访问量.被查看内容方面的信息以及搜索情况等内容,运营数据是指服务器的性能数据(CPU.IO使用率.请求时间.服务日志等数据). 现在kafka已被多家不同类型的公司采用,作为其内部各种数据的处理工具或消息队列服务.如今kafk