在现有的微服务体系架构下,一套大型软件系统可能涵盖几十种服务单元,各服务之间的调用盘根错节,可能 1 个客户申请须要调用 N 个服务能力造成业务闭环。遇到 bug 时,开发人员不得不对各服务日志一一进行排查,整个过程耗时耗力、效率低下,甚至可能因而导致系统长时间处于不可用状态,间接造成一大笔业务损失。
针对这种景象,谷歌开发了开源 Dapper 链路追踪组件,并且在 2010 年发表了论文《Dapper, a Large-Scale Distributed Systems Tracing Infrastructure 大规模分布式系统的根底跟踪设施》。
链接:
https://static.googleusercont…
这篇文章自发表后,始终是业内实现链路追踪的标杆和实践根底,具备十分大的参考价值。像大家熟知的链路追踪组件—— Uber 的 Jeager,Twitter 的 Zipkin,阿里的 Eagleeye(鹰眼),Skywalking 与 ddtrace 等,都是基于这篇论文开发进去的。
简略来说,链路追踪即通过跟踪一个申请从公布到被响应的整个过程,理解到每个申请的具体通过,比方有哪些服务参加,参加程序是什么,各服务调用了多少次数据库等。如此一来,当出现异常问题,开发就能疾速定位问题本源,疾速解决问题。
链路追踪长处:
- 服务关系:能够很清晰地展示服务间的依赖或者调用关系;
- 故障定位:在零碎呈现故障时候能够疾速高效定位问题;
- 零碎监测:在零碎服务性能变差时能够及时发现,提前采取预防措施;
- 零碎瓶颈剖析与优化:基于全链路剖析,很容易找出零碎性能瓶颈点并作出优化改良,验证优化措施是否见效。
链路追踪技术受到市场的热烈欢迎,相干监测产品层出不穷,但因为技术细节的实现各有特点(比方数据编码格局不同 (json/protobuf/thrift 等)、数据传输方式不同 (http/udp/rpc 等)、雷同语言 SDK 的 API 不同等),各产品、各客户端的互操作性很差。为解决这个问题,OpenTracing 呈现了。OpenTracing 制订了一套无关平台、无关厂商的链路追踪 API 标准,只有每个实现链路追踪技术的厂家都恪守标准,当须要从一种技术实现切换到另一种时,并不会产生特地多的额定工作量。开发者只需在初始化局部进行大量配置批改即可。
OpenTracing GitHub 网址:
https://github.com/opentracing
OpenTracing 的呈现缩小了开发编码方面的工作量,然而随着云计算技术一直倒退,企业零碎、产品构造一直调整,企业依然无奈解脱因为数据格式转换、存储形式、前端 UI 界面风格等不同,而导致的 bug 难定位、数据难监测的倒退窘境。
那当初有没有一款产品,既能兼容市面上支流的链路追踪技术,又能多维度剖析与展现数据?
3 步玩转链路追踪,轻松定位 Bug!
来自国内的 DataFlux ——一站式数据监测云平台,岂但能够兼容 Jeager、Zipkin、Skywalking 与 ddtrace 等支流技术,而且能帮忙用户专一于业务开发,更直观、更业余、更高效地展现数据监测剖析后果。
在 DataFlux 上咱们能够按以下三个步骤进行分布式链路追踪:
- 在 Datakit 开启链路数据采集;
- 开启须要监控的利用 (有的须要代码埋点这具体取决于应用何种链路追踪技术);
- 在 DataFlux 前端页面查看链路数据。
DataKit 开启链路数据采集
在 DataFlux 中有专用于各种数据采集的工具—— DataKit。针对链路数据,它提供了四种类型的采集器别离对应不同技术实现:traceJaeger、traceZipkin、traceSkywalking 和 ddtrace。这里以 ddtrace 为例,其不须要代码埋点,咱们介绍下它在 Linux 平台的根本应用。
《3 分钟疾速装置 DataKit 采集器》
https://help.dataflux.cn/doc/…
装置好 DataKit 后,在 /usr/local/cloudcare/dataflux/datakit/conf.d/ddtrace/ 目录下,复制一份 ddtrace 链路数据采集配置。
$ sudo cp ddtrace.conf.sample ddtrace.conf
编辑 ddtrace.conf:
#[inputs.ddtrace]
# path = "/v0.4/traces" # ddtrace 链路数据接管门路,默认与 ddtrace 官网定义的门路雷同
# [inputs.ddtrace.tags] # 自定义标签组
# tag1 = "tag1" # 自定义标签 1
# tag2 = "tag2" # 自定义标签 2
# tag3 = "tag3" # 自定义标签 3
# env = "your_env_name" # 设置环境名
# version = "your_version" # 设置版本信息
至此,链路数据采集就配置好了,重新启动一下 DataKit 的即可。
https://help.dataflux.cn/doc/…
开启须要监控的利用
通过 ddtarce 采集数据须要依据以后我的项目开发语言参考对应帮忙文档 Datadog Tracing。
这里以 Python 利用作为示范:
第一步,装置相干依赖包
pip install ddtrace
第二步,在利用初始化时设置上报地址
import os
from ddtrace import tracer
#通过环境变量设置服务名 os.environ["DD_SERVICE"] = "your_service_name"
#通过环境变量设置我的项目名,环境名,版本号
os.environ["DD_TAGS"] = "project:your_project_name,env=test,version=v1"
#设置链路数据 datakit 接管地址,tracer.configure(
# datakit IP 地址 `
hostname="127.0.0.1",
# datakit http 服务端口号
port="9529",
)
第三步,开启利用
ddtrace-run python your_app.py
若通过 gunicorn 运行,须要在利用初始化时进行如下配置,否则会产生雷同的 traceID
patch(gevent=True)
其余语言利用与此相似,配置胜利后约 1-2 分钟即可在 DataFlux Studio 的「链路追踪」中查看相干的链路数据。
除了在利用初始化时设置我的项目名,环境名以及版本号外,还可通过如下两种形式设置:
- 通过环境变量设置
export DD_TAGS="project:your_project_name,env=test,version=v1"
- 通过采集器自定义标签设置
[inputs.ddtrace]
path = "/v0.4/traces" # ddtrace 链路数据接管门路,默认与 ddtrace 官网定义的门路雷同
[inputs.ddtrace.tags] # 自定义标签组
project = "your_project_name" # 设置我的项目名
env = "your_env_name" # 设置环境名
version = "your_version" # 设置版本信息 `
查看链路数据采集
接下来,咱们就能在 DataFlux 平台看到对应的链路数据了:
每个服务相干统计信息:
某次调用详细信息:
服务之间的调用关系:
随着科技的遍及与倒退,链路追踪技术将间接对企业或集体的零碎异样、业务 bug 等问题的解决产生重大影响,也将成为越来越多的企业或集体开发者的倒退共识。