云和安全管理服务专家新钛云服 祝祥翻译

什么是分布式跟踪？

分布式跟踪是用来查看和了解复杂的微服务间交互中的整个活动链。

现代的云原生软件开发十分依赖微服务，因为每个独立的服务都提供不同的核心功能。当用户在应用中发出请求时，许多单独的服务都会做出响应，产生相应的结果。

应用中的一个调用可能会涉及几十项彼此交互的服务。当出现问题或某个请求变慢时，开发人员和工程师该如何查明问题所在？所以我们需要一种能跟踪所有连接的方法。

这就是分布式跟踪的意义所在。它通常是作为服务网格（管理和监控微服务的一种方式）的一部分运行。

Jaeger 使用分布式跟踪来了解不同微服务的请求路径。我们可以直观地看到调用流，无需凭猜测工作。

整理有序的事务信息对于调试和优化而言非常有用。Jaeger 内含的工具可用于监控分布式事务、优化性能和延迟，以及执行根本原因分析（RCA）（一种问题解决方法）。

Jaeger 组件及相关术语

作为一个开源项目，一个由数百个贡献者组成的社区不断改进完善着 Jaeger。Jaeger 基于与供应商无关的 OpenTracing API 和工具。

共享出行公司 Uber 在 2015 年开发了开源项目 Jaeger。2017 年，Jaeger 纳入云原生计算基金会（CNCF）的孵化项目，2019 年，Jaeger 正式毕业。

Jaeger 将执行请求显示为一条条迹线（trace）。迹线代表系统中的数据/执行路径。

一个迹线包含一个或多个跨度（span）。跨度是 Jaeger 中作业的逻辑单元。每个跨度都由作业名称、开始时间和持续时间组成。跨度可以进行嵌套和排序。

Jaeger 内含多个组件，这些组件可以协同工作，一起收集、存储和可视化跨度与迹线。

Jaeger 客户端包括含用于分布式跟踪的 OpenTracing API 的特定语言实施。您可以手动使用这些实施，也可以将其与各种开源框架一起使用。

Jaeger 代理是一个网络守护进程，可侦听通过用户数据报协议发送的跨度。该代理应与所检测的应用放置在同一主机上。这通常是通过 Kubernetes 等容器环境中的 sidecar 实现的。

Jaeger 收集器可接收跨度并将它们放在队列中等待处理。

收集器需要持久的存储后端，因此 Jaeger 还具有可插拔的跨度存储机制。

查询是一项从存储中检索迹线的服务。

Jaeger 控制台是一个用于可视化分布式跟踪数据的用户界面。

Ceph与Jaeger

Ceph是一个统一的分布式存储系统，设计初衷是提供较好的性能、可靠性和可扩展性。

Ceph项目最早起源于Sage就读博士期间的工作（最早的成果于2004年发表），并随后贡献给开源社区。在经过了数年的发展之后，目前已得到众多云计算厂商的支持并被广泛应用。RedHat及OpenStack都可与Ceph整合以支持虚拟机镜像的后端存储。

像 Ceph 这样的分布式系统可能是调试的噩梦，因为它们没有单点故障。为了解决这个问题，我们一直致力于向 Ceph 添加一个标准的分布式跟踪解决方案Jaeger。Jaeger 是一个分布式追踪开源库，是 CNCF 下的一个项目。Jaeger 将提供对 Ceph 分布式后台进程的更多可见性，并帮助用户识别异常，从而“使 Ceph 更加透明”。

本文提供了一个学习使用跟踪调试 Ceph 的机会——非常适合那些希望识别分布式事务中的性能瓶颈、延迟优化和异常的人。

我们很高兴地宣布在 Ceph Pacific版中对 Jaeger 的初步支持！

它是如何工作的？

Jaeger(https://www.jaegertracing.io/docs)（跟踪后端）与Opentracing(https://opentracing.io/docs/supported-tracers/) (API ) 一起为分布式系统提供即用型跟踪服务，并因其简单性而成为广泛使用的事实上的标准。

Jaeger 负责收集 span。这些跨度是使用智能指针制作的。它们包括时间戳、TraceID 和其他元信息，例如与跨度关联的特定标签/日志，以便在分布式系统中唯一标识。然后将这些相关联以生成请求生命周期的可视化（跟踪）。

让我们试试吧！

让我们来看看跟踪 Ceph 的输入-输出事务中涉及的核心功能。如果您设置了 jaeger 后端以使用 Ceph，请跳过下一节。

有关如何设置的信息，请参阅文档：https://docs.ceph.com/en/latest/dev/developer_guide/jaegertracing/

部署 Jaeger 服务

我们将使用 vstart 开始跟踪。

为此，请确保您有：

Ceph 配置了WITH_JAEGER=ON.部署 jaeger 后端服务 - 要使用 vstart 开发集群部署 Jaeger 后端服务，您只需要传递--jaeger选项。

$ ../src/vstart.sh --jaeger

按照上述步骤，您应该能够设置所有 Jaeger 服务并通过http://localhost:16686访问JaegerUI。

更多可以阅读：https://www.jaegertracing.io/docs/1.20/getting-started/#all-in-one

（JaegerUI 在http://localhost:16686）

如果由于某种原因您无法访问 JaegerUI，请使用以下命令重试手动运行 Jaeger 服务：

$ docker run -d --name jaeger \-e COLLECTOR_ZIPKIN_HTTP_PORT=9411 \-p 5775:5775/udp \-p 6831:6831/udp \-p 6832:6832/udp \-p 5778:5778 \-p 16686:16686 \-p 14268:14268 \-p 14250:14250 \-p 9411:9411 \jaegertracing/all-in-one:1.20

追踪核心服务

现在我们已经启动并运行了 Jaeger 服务，让我们来看看 Ceph 的核心服务跟踪。

Ceph 目前可以跟踪 OSD I/O 路径中的操作，我们将在这里演示：

我们将执行一个简单的写操作，为此我们使用 rados bench write。您可以使用您选择的任何其他可用的写入接口。

[ideepika@vossi03 build]$ bin/ceph osd pool create test; //create a pool[ideepika@vossi03 build]$ bin/rados -p test bench 5 write --no-cleanup //perform a rados bench write for 5 sec

在刷新 JaegerUI ( http://localhost:16686 ) 时，您应该能够在 services 字段中看到 osd-services，它指定了请求生命周期中跟踪的 OSD 进程。

正下方是“操作”字段，其中列出了收集的跨度，单击该字段将为您提供包含它的跟踪。

我们看到了我们最近的写操作收集的轨迹列表，以及一个 x(time)-y(duration) 图，轨迹作为数据点。

当您单击任何跟踪时，它应该扩展到存储在其中的所有跨度和元数据。

我们可以在创建跨度时以标签和日志的形式存储 Ceph 的元数据，如下所示；携带 Ceph 相关元数据的日志字段。

在那里你可以看到你的内部流程！

将跟踪导出为 JSON

这些痕迹是便携式的！它们可以转换为 JSON 输出，可以使用 JaegerUI 在其他系统上呈现。

下一步任务

这个项目仍在进行中，但是有了作为实时跟踪的正确信息的编排，我们将有一个端到端跟踪，这可以使调试更加容易，从而了解Ceph的内部结构！

我们期待提高 Ceph 的整体可观察性。

我们准备了一些任务来改进跟踪支持，将跟踪支持扩展到客户端（RGW、CEPFS、RBD），并与OSD跟踪集成，改进部署策略，从而能够实时监控系统运行状态以及服务部署情况。

原文：https://ceph.com/en/news/blog/2021/distributed-tracing-in-ceph-using-jaeger/