关于云计算:3步玩转链路追踪快速排查微服务各种问题

4次阅读

共计 3019 个字符，预计需要花费 8 分钟才能阅读完成。

在现有的微服务体系架构下，一套大型软件系统可能涵盖几十种服务单元，各服务之间的调用盘根错节，可能 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 难定位、数据难监测的倒退窘境。

那当初有没有一款产品，既能兼容市面上支流的链路追踪技术，又能多维度剖析与展现数据？

来自国内的 DataFlux ——一站式数据监测云平台，岂但能够兼容 Jeager、Zipkin、Skywalking 与 ddtrace 等支流技术，而且能帮忙用户专一于业务开发，更直观、更业余、更高效地展现数据监测剖析后果。

在 DataFlux 上咱们能够按以下三个步骤进行分布式链路追踪：

在 Datakit 开启链路数据采集；
开启须要监控的利用 (有的须要代码埋点这具体取决于应用何种链路追踪技术)；
在 DataFlux 前端页面查看链路数据。

在 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 等问题的解决产生重大影响，也将成为越来越多的企业或集体开发者的倒退共识。

正文完