Byzer 做 Jira 数据分析时问题排查案例

文章来源于 朱加川 @Byzer Team Github ID: chncaesar

Byzer 认为万物皆可加载成表

自然，任何 SaaS 服务的 API 也都能被加载成 Byzer 的表，从而实现灵活的 ETL， 数据Fenix。 今天，这篇文章主要以使用 Byzer 分析 Jira 数据时遇到的一些问题来教会大家在使用 Byzer 套件时遇到问题的时候，如何进行问题排查。

问题描述

Byzer 团队一位小伙伴发现，在准生产环境下，以下 Rest 请求代码长时间运行，但不报错。时间可达 1小时以上，但是本机部署的 Byzer 开发环境则没有这个问题：

load Rest.`$issue_url` 
where `config.method`="get"
and `header.content-type`="application/json"
and `header.Authorization`='''Bearer $acc_ko'''
and `form.jql` = "${jql}"
and `form.expand` = "${expand}"
and `form.fields` = "${fields}"
and `form.maxResults` = "${maxResults}"
and `config.page.next` = "https://api.atlassian.com/ex/jira/xxxxxx/rest/api/xxx/search?startAt={0}"
and `config.page.values` = "offset:100,100"
and `config.page.limit` = "30"
as sr_1;

代码的含义是拉取 Jira issue 的数据结合 工时 系统里的数据进行分析。

我们简单解释下这段代码的使用， Byzer 支持 Rest 数据源，该数据源具备：

1. 完善的 Rest 请求支持
2. 分页支持
3. 重试支持（包括分页请求）

在上面的例子中，header.* 配置 Rest 请求头。 form.* 配置请求参数，无论是 Get/Post。 config.* 则是配置诸如翻页，重试次数等等信息。

此外，除了数据源支持以外， Byzer 也支持 rest_request UDF 函数，示例用法如下：

select  rest_request(
"https://www.byzer.org/home","get", -- url/method
map("foo","bar","foo1","bar"), -- params
map("Content-Type" , "application/x-www-form-urlencoded"), -- headers
map("config.debug","true") -- config
) as resp as output;

两者结合，可以实现很强的 API 数据获取能力。

Byzer Notebook 和 Engine 交互流程

知己知彼 百战不殆

Byzer Notebook 提供了一个良好的 Byzer 编程环境。

Byzer Notebook 和 Engine 通过 HTTP 协议进行互通，下面是两者的执行时序图。

1. Frontend 表示 Notebook 前端
2. Notebook 则是后端
3. Engine 是指 Byzer 语言的执行引擎

根据上图，用户在 Notebook 前端提交 Byzer 代码， 会通过 /api/script/execution 发送给 Notebook 后端， Notebook 后端会将代码进行一定的预处理，然后发送给 Engine 端执行， Engine 会异步执行，先返回一个 job 标记符，避免阻塞 Notebook, 然后后台行。执行完成(无论失败或者成功)后，再通过 /api/job/callback 接口回调 Notebook 后端，将状态和结果发回给 Notebook。

此时前端会进入一个 Loop， 定时询问 Notebook 后端当前提交任务的状态，这包括，进度，是否结束完成等。其中：

1. 进度(Progress)是 notebook 后端去询问 Engine 的才能得到的。
2. 是否完成，以及响应结果，则是 Engine 通过 /api/job/callback 接口回调 主动告知 Notebook , Notebook 会将这些数据存储到数据库。

根据上面的原理，我们有时候会遇到 Byzer notebook 一直在转圈圈运行， 然后你再跑过去看 Engine 侧，却又发现任务已经运行完了。

这个时候，大概率就是 Engine 回调 /api/job/callback 失败了。 这里有三种可能：

1. 如果是常态，那么是 Engine 拿到了错误的回调地址，无法正常回调 Notebook 后端。如果是偶发，则可能是网络问题，Engine 回调一般失败了会重试。用户可以看看 Engine 日志，如果发现总是重试，可能是网络不好。
2. Notebook 侧接受到了回调，但因为某种原因失败了，没有成功更新数据库。
3. Engine 侧可能因为某种未知异常或者太繁忙，从而没有正常发起回调。

所以，根据现有的知识，虽然用户看到的是任务一直不能完成，但实际上只可能是两种情况：

1. Engine 侧任务真的执行了那么久
2. Engine 回调 Notebook 后端失败了

现在让我们结合日志，实际排查下看。

日志最重要

Byzer Notebook的日志位于安装目录下的 logs ，大体结构如下：

具体而言就是 logs/notebook.log， 主要是 SQL 日志, access 则是具体的访问日志。我们主要看access日志。

Byzer Engine 的日志也位于安装目录的 logs, 大体结构如下：

我们主要关注 mlsql_engine.log。

现在我们结合日志来看看排查过程。

排查过程

1. 本地运行，确保代码，启动参数等环境完全一致，但不报错 ( select status 状态码为 200, 不获取数据 )
2. 准生产环境再次执行。跟踪 Byzer Engine && Byzer Notebook log 有如下发现：

• Notebook 执行 load parquet 读取 Rest 结果集，Notebook 报 connection reset 错误；但 Engine 9003 端口执行不报错(需要写文件全路径) 。结论：调用 Notebook 回调接口，发送数据到 Notebook 时报错。
• Notebook log 报 Data too long for column 'job_progress' at row 1； 且 engine log 报 RestController: Succeeded SQL callback request failed after 1 attempts, the last response status is: 500 。 结论： Engine 端已经完成，但回调失败，Notebook 依然为运行中。

做出以下调整：

• 设置 Notebook tomcat 参数 server.tomcat.keep-alive-timeout 100 分钟 ; Engine 调用 notebook回调接口 socketTimeOut 20 分钟。重启 Engine & Notebook。
• 修改 job_progress 字段为 longText.

重启 Notebook & Engine，再次运行代码，OK。

排查手段

Engine 执行问题

• 以 Notebook 显示的 jobId 去 Spark UI 查看状态
• 先在 Engine Log 打印 Notebook 用户名 脚本，再找 exception / error

回调问题

1. 在 Engine log 找关键字 callback
2. 在 Notebook log 找异常

MySQL 查看任务状态

select id, content, status from job_info

问题和改进

• Byzer Notebook 异常处理需要改进。 参考讨论： [Discussion] Byzer-notebook 运行失败策略
• Byzer 需要支持回显功能，可以极大的方便问题排查。参考 讨论： [Discussion] job_info.job_progress 字段精简 - 缺乏 Log 回显功能，增加排查难度。 Notebook 中需要能够将 cell 执行的日志回显至前端