资讯动态

Ceph 分布式追踪实战:基于 LTTng 的事件追踪与 Blkin/Zipkin 端到端请求链路分析

发布时间:2026/9/21 17:04:21 来源:尧图企业网站定制
存储分布式文件系统对象存储后端高可用【免费下载链接】cephCeph is a distributed object, block, and file storage platform项目地址https://gitcode.com/gh_mirrors/ce/ceph点击查看免费下载Ceph 作为统一的分布式对象、块与文件存储平台其 I/O 请求会跨越客户端librados/librbd、消息层Messenger、Objecter、OSD 主处理线程直至底层对象存储等多个阶段。本指南围绕 doc/dev/blkin.rst 展开系统讲解如何用 LTTng 用户态追踪Userspace Tracing为 Ceph 埋点、如何借助 Blkin 实现基于 Dapper 语义的跨阶段请求链路追踪以及最终如何用 Zipkin 将追踪结果可视化。读完本文你将掌握从编译开关、ceph.conf配置、vstart.sh本地集群验证到 Zipkin 展示的完整操作链路并理解其底层 tracepoint 与 span 传播机制。一、Ceph 追踪体系总览tracepoint 是骨架Blkin 是链路Ceph 的追踪能力建立在两个层次上LTTng 事件追踪第一层Ceph 在关键代码路径中插入 LTTng-UST tracepoint用户态静态探针用于观察某一阶段发生了什么如 OSD 处理一个 op 的进入/退出。所有 tracepoint 定义文件.tp与对应的 provider 共享库源码集中在 src/tracing 目录包括bluestore.tp、objectstore.tp、osd.tp、oprequest.tp、pg.tp、librados.tp、librbd.tp、rgw_op.tp、rgw_rados.tp、mgroprequest.tp、eventtrace.tp等。Blkin 分布式追踪第二层Blkin 是 Marios Kogias 等人创建的库它实现 Dapper 追踪语义trace_id/span_id/parent_span_id用于把一个请求从高层进入系统、到最终由 RADOS 服务完成的因果链路串联起来配合每个阶段的时延信息实现端到端的请求路径可视化。由于底层仍由 LTTng 承载开销很低且可实时采集采集到的数据最终可交给 Twitter 的 Zipkin 展示。需要特别留意的是Blkin 功能在 Squid 版本中已被标记为弃用deprecated并将在后续版本中移除见 doc/dev/blkin.rst 中的.. deprecated::声明。而 LTTng 事件追踪仍是 Ceph 长期维护的能力因此本文先完整展开 LTTng 部分再讲解 Blkin/Zipkin 链路。二、使用 LTTng 追踪 Ceph2.1 编译通过-DWITH_LTTNGON启用默认开启LTTng 支持是 Ceph 默认编译选项default: ON。从源码编译时显式指定./do_cmake -DWITH_LTTNGON在构建系统中WITH_LTTNG会驱动 src/tracing/CMakeLists.txt 生成各 provider 共享库。该文件对每个.tp文件调用lttng-gen-tp生成头文件并通过add_tracing_library打包出多个*.soosd_tp由oprequest.tp、osd.tp、pg.tp组成rados_tplibrados.tpos_tpobjectstore.tpbluestore_tpbluestore.tprgw_op_tp、rgw_rados_tpmgr_op_tpmgroprequest.tprbd_tp仅当WITH_RBD时构建cyg_profile_tp仅当WITH_OSD_INSTRUMENT_FUNCTIONS时构建见 2.5eventtrace_tp仅当WITH_EVENTTRACE时构建这些共享库最终安装到${CMAKE_INSTALL_LIBDIR}运行时会由目标进程通过动态加载方式绑定到对应 tracepoint。2.2 包安装为什么缺少 tracepoint.so会导致 coredump如果 Ceph 是通过 YUM / DNF / APT 等包管理器安装的而非容器化部署必须根据你要追踪的模块安装对应的开发包。文档明确列出librbd-devel librgw-devel librados-devel原因在于当进程如ceph-osd、radosgw在运行时遇到缺失的 LTTng tracepoint 共享库*.so文件时会因无法解析符号而直接 coredump。因此编译时开了追踪、运行环境却没装齐 provider 库是一个典型的崩溃场景务必按需把三个-devel包装齐。2.3 配置选项在ceph.conf中开启对应追踪开关编译启用只是第一步追踪行为默认是关闭的。必须在ceph.conf中把目标开关设为true。下表汇总了当前可用的选项并对照仓库中的配置定义src/common/options/global.yaml.in、src/common/options/rbd.yaml.in、src/common/options/rgw.yaml.in给出默认值所有选项均为bool类型、advanced级别默认false配置项默认值含义仓库配置位置bluestore_tracingfalse启用 BlueStore 事件追踪global.yaml.inevent_tracingfalse通用事件追踪需-DWITH_EVENTTRACE编译global.yaml.inosd_function_tracingfalseOSD 函数级插桩追踪需-DWITH_OSD_INSTRUMENT_FUNCTIONSglobal.yaml.inosd_objectstore_tracingfalse对象存储层追踪实际即 filestore 追踪global.yaml.inrbd_tracingfalseRBDlibrbdLTTng-UST tracepointrbd.yaml.inosd_tracingfalseOSD LTTng-UST tracepointglobal.yaml.inrados_tracingfalselibrados LTTng-UST tracepointglobal.yaml.inrgw_op_tracingfalseRGW 操作级追踪rgw.yaml.inrgw_rados_tracingfalseRGW 调用 RADOS 层追踪rgw.yaml.in从配置定义看两个选项还可细读bluestore_tracing有配套的bluestore_throttle_trace_ratefloat默认 0单位每秒采样的 BlueStore 事务数可用于控制追踪采样率、降低开销见 global.yaml.in。文档中括号标注了部分选项与编译开关的对应关系event_tracing需要-DWITH_EVENTTRACEosd_function_tracing需要-DWITH_OSD_INSTRUMENT_FUNCTIONS。2.4 测试 Trace从启动 LTTng 会话到查看结果完整的测试流程如下命令均来自 doc/dev/blkin.rst。第一步启动 LTTng 会话守护进程lttng-sessiond --daemonize第二步用 vstart 启动本地集群并注入追踪配置../src/vstart.sh -d -n -l -e -o osd_tracing true其中-o是核心机制它会把后面的键值对作为额外配置注入到生成的ceph.conf当前 src/vstart.sh 中-o将参数追加进extra_conf。其他常用开关如-n新建集群、-e启用纠删码池创建名为ec的池在 src/vstart.sh 中有对应实现-ddebug 模式与-l等参数的具体含义以你所检出版本的./vstart.sh --help为准。如果你用的版本不支持某个短选项直接通过-o注入osd_tracing true也能达到同样的追踪开启效果。第三步列出用户态可用 tracepointlttng list --userspace可以看到类似如下的输出每个运行中的进程列出其绑定的 UST 事件UST events: ------------- PID: 100859 - Name: /path/to/ceph-osd pg:queue_op (loglevel: TRACE_DEBUG_LINE (13)) (type: tracepoint) osd:do_osd_op_post (loglevel: TRACE_DEBUG_LINE (13)) (type: tracepoint) osd:do_osd_op_pre_unknown (loglevel: TRACE_DEBUG_LINE (13)) (type: tracepoint) osd:do_osd_op_pre_copy_from (loglevel: TRACE_DEBUG_LINE (13)) (type: tracepoint) osd:do_osd_op_pre_copy_get (loglevel: TRACE_DEBUG_LINE (13)) (type: tracepoint) ...第四步创建会话、启用事件并开始追踪lttng create trace-test lttng enable-event --userspace osd:* lttng startosd:*会一次性启用osdprovider 下的全部事件你也可以按需只启用某个事件例如lttng enable-event --userspace osd:do_osd_op_pre_write。第五步制造负载rados bench -p ec 5 write向ec池执行 5 秒的写入基准测试产生真实的 OSD 操作流。第六步停止追踪并查看结果lttng stop lttng view第七步销毁会话lttng destroy2.5 源码视角tracepoint 长什么样以 src/tracing/osd.tp 为例osdprovider 定义了非常细粒度的探针。每个TRACEPOINT_EVENT包含参数TP_ARGS与字段TP_FIELDS两部分例如osd:prepare_tx_enter/osd:prepare_tx_exit一次 OSD 事务准备阶段的进入/退出字段为osd_reqid_t的四个分量type、num、tid、incosd:ms_fast_dispatch、osd:opwq_process_start/osd:opwq_process_finish消息快速分发与 op 工作队列处理的起止osd:do_osd_op_pre_*系列按操作类型细分的op 执行前探针覆盖read、write、writefull、writesame、zero、truncate、delete、create、append、setxattr、omap*、copy_from、call、watch、checksum等字段通常包含对象名oid、快照snap、偏移offset、长度length、操作码op与操作名opnameosd:do_osd_op_postop 执行完成后的探针除上述字段外还携带执行结果result。也就是说osd:*这一组事件足以还原一个对象操作在 OSD 内被解析、排队、执行、返回的全过程。如果你需要做函数级的火焰图分析可参考 src/tracing/README.mdCeph 支持 GCC 的-finstrument-functions插桩-DWITH_OSD_INSTRUMENT_FUNCTIONSON目前仅 GCC 生效进入/退出探针为lttng_ust_cyg_profile:func_enter与lttng_ust_cyg_profile:func_exitpayload 中的addr与call_site可通过nm解析为函数名后续可用 TraceCompass 生成火焰图或用 libbabeltrace 编写自定义分析。三、Blkin端到端的请求链路追踪3.1 Blkin 是什么Blkin 的作用是追踪一个请求从进入系统的高层客户端开始直到被 RADOS 最终服务的完整路径。其核心思想是实现 Dapper 的追踪语义通过trace_id一次请求的唯一标识、span_id每个处理阶段的标识与parent_span_id父阶段标识表达各处理阶段之间的因果关系目标是端到端可视化请求在系统中的路由并附带每个阶段的时延信息。借助 LTTng这一切可以以极小开销、实时地完成LTTng 采集的 trace 再由 Twitter 的 Zipkin 做可视化。再次强调该功能在 Squid 版本中被标记为弃用后续版本将移除见 doc/dev/blkin.rst 的 deprecation 声明本文按文档内容完整呈现其用法供仍在旧版本上的维护者参考。3.2 编译与配置编译WITH_BLKIN依赖WITH_LTTNG二者需同时开启./do_cmake -DWITH_LTTNGON -DWITH_BLKINON从构建系统看WITH_BLKINON时会执行add_subdirectory(blkin/blkin-lib)见 src/CMakeLists.txt把 Blkin 的 ztracer 库编入构建。相应地src/common/zipkin_trace.h 在WITH_BLKIN宏下会#include ztracer.hpp引入真实实现未开启时则退化为全空的 stubTrace、Endpoint所有方法均为 no-opvalid()恒为false从而在关闭 Blkin 的构建中做到零开销。配置在ceph.conf中把以下选项设为true均为bool、advanced、默认false配置项默认值含义仓库配置位置rbd_blkin_trace_allfalse为所有 RBD 请求创建 blkin tracerbd.yaml.inosd_blkin_trace_allfalse为所有 OSD 请求创建 blkin traceglobal.yaml.inosdc_blkin_trace_allfalse为所有 Objecter客户端侧请求转发层请求创建 blkin traceglobal.yaml.in3.3 源码结构zipkin_trace.h与 span 传播src/common/zipkin_trace.h 定义了追踪的核心数据结构与接口struct blkin_trace_info三个int64_t字段trace_id、span_id、parent_span_id并配套encode/decode使其可以随 Ceph 的消息buffer::list跨进程序列化传递——这正是链路跨节点传播的基础ZTracer::Trace提供init()初始化 span、keyval()记录整数/字符串键值对对应zipkin:keyval_integer/zipkin:keyval_string探针、event()记录事件对应zipkin:timestamp探针等方法ZTracer::Endpoint表示服务端点名称、IP、端口。3.4 调用链示例Objecter 侧如何打 span以客户端 Objecter 为例src/osdc/Objecter.cc 在组装 MOSDOp 消息前有如下逻辑if (!op-trace.valid() cct-_conf-osdc_blkin_trace_all) { op-trace.init(op, trace_endpoint); }即当osdc_blkin_trace_all true且该 op 尚未携带 trace 时以服务名op和本地 endpoint 初始化一个新的 span。随后在发送消息时if (op-trace.valid()) { m-trace.init(op msg, nullptr, op-trace); }把父 span 挂到消息上随请求发出src/osdc/Objecter.cc从而让 OSD 端能延续同一trace_id生成子 span。期间还会记录op submit、post op complete、osd op reply等关键事件src/osdc/Objecter.cc、src/osdc/Objecter.cc、src/osdc/Objecter.cc。可见osdc_blkin_trace_all打开的是一条客户端发起 → 消息携带 → OSD 处理 → 回复的完整链路。3.5 测试 Blkin完整操作流程假设 Ceph 尚未运行、且你已编译出带 Blkin 支持但未安装的版本按文档在src目录用vstart.sh启动OSD3 MON3 RGW1表示 3 个 OSD、3 个 MON、1 个 RGWOSD3 MON3 RGW1 ../src/vstart.sh -n -o rbd_blkin_trace_all lttng list --userspace此时lttng list --userspace会看到每个进程都注册了 Blkin 的 zipkin 探针例如UST events: ------------- PID: 8987 - Name: ./ceph-osd zipkin:timestamp (loglevel: TRACE_WARNING (4)) (type: tracepoint) zipkin:keyval_integer (loglevel: TRACE_WARNING (4)) (type: tracepoint) zipkin:keyval_string (loglevel: TRACE_WARNING (4)) (type: tracepoint) lttng_ust_tracelog:TRACE_DEBUG (loglevel: TRACE_DEBUG (14)) (type: tracepoint) PID: 8407 - Name: ./ceph-mon zipkin:timestamp (loglevel: TRACE_WARNING (4)) (type: tracepoint) zipkin:keyval_integer (loglevel: TRACE_WARNING (4)) (type: tracepoint) zipkin:keyval_string (loglevel: TRACE_WARNING (4)) (type: tracepoint) lttng_ust_tracelog:TRACE_DEBUG (loglevel: TRACE_DEBUG (14)) (type: tracepoint) ...下一步是先停掉 Ceph以便 tracepoint 能被 LTTng 会话启用避免进程运行期间动态库绑定影响事件启用../src/stop.sh创建 LTTng 会话并启用 zipkin 相关事件lttng create blkin-test lttng enable-event --userspace zipkin:timestamp lttng enable-event --userspace zipkin:keyval_integer lttng enable-event --userspace zipkin:keyval_string lttng start重新启动 CephOSD3 MON3 RGW1 ../src/vstart.sh -n -o rbd_blkin_trace_all确认集群状态正常ceph status然后通过rados做一轮写入 → 列出 → 定位 → 读回 → 校验 → 删除的完整对象操作ceph osd pool create test-blkin rados put test-object-1 ../src/vstart.sh --pooltest-blkin rados -p test-blkin ls ceph osd map test-blkin test-object-1 rados get test-object-1 ./vstart-copy.sh --pooltest-blkin md5sum vstart* rados rm test-object-1 --pooltest-blkin也可以直接使用 examples/librados 中的示例程序或用rados bench制造持续负载。停止追踪并查看采集结果lttng stop lttng view输出形如每条记录都带有trace_id、span_id、parent_span_id三件套这正是还原链路的依据[15:33:08.884275486] (0.000225472) ubuntu zipkin:timestamp: { cpu_id 53 }, { trace_name op, service_name Objecter, port_no 0, ip 0.0.0.0, trace_id 5485970765435202833, span_id 5485970765435202833, parent_span_id 0, event osd op reply } [15:33:08.884614135] (0.000002839) ubuntu zipkin:keyval_integer: { cpu_id 10 }, { trace_name , service_name Messenger, port_no 6805, ip 0.0.0.0, trace_id 7381732770245808782, span_id 7387710183742669839, parent_span_id 1205040135881905799, key tid, val 2 } [15:33:08.884616431] (0.000002296) ubuntu zipkin:keyval_string: { cpu_id 10 }, { trace_name , service_name Messenger, port_no 6805, ip 0.0.0.0, trace_id 7381732770245808782, span_id 7387710183742669839, parent_span_id 1205040135881905799, key entity type, val client }解读要点zipkin:timestamp记录的是某个事件发生的时间点与 span 归属如 Objecter 收到osd op replyzipkin:keyval_integer/zipkin:keyval_string记录附加键值如tid、entity type client丰富 span 上下文时间戳前的(0.000xxx)是相对上一条记录的时间增量可用于估算阶段时延。四、用 Zipkin 可视化 Blkin 追踪结果4.1 安装 ZipkinBlkin 的价值在于可视化。Zipkin 同时作为 tracepoint 收集器与 Web 服务运行可执行 jar 在9410端口启动 collector在9411端口提供 Web 界面。方式一下载并运行 jargit clone https://github.com/openzipkin/zipkin cd zipkin wget -O zipkin.jar https://search.maven.org/remote_content?gio.zipkin.javaazipkin-servervLATESTcexec java -jar zipkin.jar方式二Docker 镜像docker run -d -p 9411:9411 openzipkin/Zipkin4.2 使用 babeltrace-zipkin 把 LTTng 数据送入 Zipkinbabeltrace-zipkin 项目负责读取 Blkin 产生的 LTTng trace并通过 scribe 协议发送给 Zipkin collectorgit clone https://github.com/vears91/babeltrace-zipkin cd babeltrace-zipkin发送命令的格式为python3 babeltrace_zipkin.py ${lttng-traces-dir}/${blkin-test}/ust/uid/0/64-bit/ -p ${zipkin-collector-port(9410 by default)} -s ${zipkin-collector-ip}其中-p指定 Zipkin collector 端口默认 9410-s指定 collector 的 IP。实际示例python3 babeltrace_zipkin.py ~/lttng-traces-dir/blkin-test-20150225-160222/ust/uid/0/64-bit/ -p 9410 -s 127.0.0.1注意~/lttng-traces-dir/...中的目录名blkin-test-时间戳由lttng create blkin-test自动生成ust/uid/0/64-bit/是 UST trace 在 trace 目录下的标准存放路径请以实际目录为准。4.3 在 Zipkin Web 上查看链路浏览器访问 Zipkin Web 界面http://${zipkin-collector-ip}:9411点击Find traces即可看到按trace_id聚合的请求链路。Zipkin 会以时间轴形式展示trace_name如op、service_name如Objecter、Messenger、OSD 等以及各 span 的父子关系与耗时从而直观地定位请求在哪个阶段出现瓶颈。五、注意事项与后续方向版本与弃用状态Blkin 在 Squid 版本中被标记为弃用并将被移除新项目请评估该约束LTTng 事件追踪第二节内容不受影响。当前仓库配置中还保留了jaeger_tracing_enable等新一代追踪选项见 global.yaml.in可作为迁移/后续方向的参考。编译与运行环境必须一致编译时开启WITH_LTTNG/WITH_BLKIN后运行环境必须安装对应的 tracepoint 共享库librbd-devel、librgw-devel、librados-devel否则进程可能因缺少*.so而 coredump。配置开关默认关闭所有追踪相关配置项默认均为false无论编译是否开启都需在ceph.conf或 vstart 的-o注入中显式开启且建议只在排障窗口期开启避免常驻性能开销。调试闭环lttng list --userspace是确认探针是否注册的第一手段lttng view输出的三件套trace_id/span_id/parent_span_id是人工校验链路是否完整的最快途径。若需程序化分析可参照 src/tracing/README.md 使用 libbabeltrace 编写分析工具或用 TraceCompass 生成火焰图。参考路径速查本文档源doc/dev/blkin.rsttracepoint 定义与构建src/tracing、src/tracing/CMakeLists.txt、src/tracing/osd.tpLTTng/函数插桩说明src/tracing/README.mdBlkin 追踪头文件src/common/zipkin_trace.hBlkin 编译开关src/CMakeLists.txt配置项定义src/common/options/global.yaml.in、src/common/options/rbd.yaml.in、src/common/options/rgw.yaml.inObjecter 端 span 传播src/osdc/Objecter.ccvstart 本地集群脚本src/vstart.sh赞分享存储分布式文件系统对象存储后端高可用【免费下载链接】cephCeph is a distributed object, block, and file storage platform项目地址https://gitcode.com/gh_mirrors/ce/ceph点击查看免费下载相关推荐终极指南如何用CKAN一键管理你的坎巴拉太空计划模组终极指南如何用CKAN一键管理你的坎巴拉太空计划模组 你是否曾经因为坎巴拉太空计划Kerbal Space Program的模组管理而头疼手动下载、版本开发工具包管理器游戏开发Ceph 分布式追踪实践基于 Jaeger 与 OpenTracing 的链路追踪集成指南Ceph 分布式追踪实践基于 Jaeger 与 OpenTracing 的链路追踪集成指南 本文是 Ceph 开发者指南系列中关于分布式追踪Distribu存储分布式文件系统对象存储后端高可用终极指南如何快速实现Dubbo集成Zipkin全链路追踪终极指南如何快速实现Dubbo集成Zipkin全链路追踪 在分布式微服务架构中全链路追踪是排查问题、优化性能的关键工具。Dubbo作为一款高性能、轻量级的分后端RPC框架微服务服务注册发现创作声明:本文部分内容由AI辅助生成(AIGC),仅供参考

读完文章,也想定制专属网站?

尧图设计师 24 小时内与您沟通定制方案

免费获取报价