背景

ray 简介

Ray 提供的能力

Ray 解决的问题

例如以下问题:

传统的做法是写多线程/多进程,但管理起来非常复杂,而且无法扩展到多台机器。

Ray 就是为了解决这些问题而生的。它提供了一个简单直观的 API,是能够用最少的代码修改,就能获得分布式计算的能力。

核心优势

对 trace 的需求

主要是用于 debug 和 monitor,以及打通现有服务之间的 trace。

目前 Ray 支持了 OpenTelemetry 协议的 trace,这很好,但是考虑到公司目前 trace 体系基于 skywalking,需要考虑兼容的问题。

初步构想的一些方案

后续主要目标是

能够采集在 ray 上部署的 python 服务或大模型产生的 trace,并融合到公司目前的 trace 体系中去

具体需要做的事

探索历程

skywalking-python

项目地址:skywalking-python

直接 clone 到本地启动 demo(commit id:fb3fb005650e2489164978b7804117c7ade1529a

找到 /demo/docker-compose.yaml

经测试,需将其中的 kafka.image 修改为 confluentinc/cp-kafka:7.2.15 否则启动会报错

启动所有 service:

启动所有 services

docker 容器列表

启动 /demo/flask_provider_single.py

发起请求:

 

打开 oap-ui,查看 trace:

单 http 节点 trace

ray + skywalking-python

执行 demo

创建 demo 程序并启动:

 

 

执行请求:

 

仅显示 upstream trace

可以看到,只有一个 upstream 程序的 span 信息,并未看到 downstream 相关的数据

这可能是由于 self.downstream.hello.remote() 指令内部未被 skywalking agent 拦截或是其他原因导致

理论上 ray 内部服务是通过 gRPC 调用的,而且 skwaylking-python 也对 gRPC 进行了增强,那么为什么会采集不到 downstream 的 trace 数据呢?

需进一步排查和定位问题

ray remote() 函数解析

ray remote 函数声明

此函数中的 kwargs 代表关键字参数,将通过底层 rpc 框架传递至下游函数

非常适合用来传递 skywalking 的 trace 信息

sw-ray-plugin

切点

插件代码

插件测试

 

完整 trace

打通 trace

TODO

 

总结

TODO