简介Azkaban 是一款源自 LinkedIn 的开源工作流执行引擎常用于大数据处理任务的依赖调度与定时管理这份 azkaban-solo-server-0.1.0-SNAPSHOT.tar.gz 是其单服务器版本已编译打包解压后即可直接运行无需再走源码编译流程。它把 Web 服务、执行器与内嵌 H2 数据库集中在一台机器上安装配置相对轻量适合个人开发者、小型团队以及需要快速体验 Azkaban 工作流机制的初学者用来解决小规模作业编排与调度验证的问题。压缩包整体约 42.28MB上游未提供可统计的文件明细包内以解压即用的服务端目录、配置文件和启动脚本为主可直接用于本地搭建调试环境。资源页面显示已有 260 人浏览学习可作为入门参考。通过它读者能够实际练习项目创建、job 依赖定义、工作流设计与定时调度并借助 Web 界面观察执行状态与日志输出同时了解 SNAPSHOT 版本在稳定性上的局限与集群部署的适用边界。1. 解压就见效的错觉azkaban-solo-server-0.1.0-SNAPSHOT 装之前先认清它是什么第一次拿到azkaban-solo-server-0.1.0-SNAPSHOT.tar.gz是在一台测试机上解压、进目录、敲bin/azkaban-solo-start.sh回车之后终端安静了大概三秒然后进程没了日志里连一句像样的异常都没留下。做 azkaban 任务调度的人都听过 solo server 这个名字因为它是所有部署形态里最省事的一种Web 服务、执行器、内置 H2 数据库全挤在同一个 JVM 里一个 tar 包解压就能访问页面。省事的另一面是三个组件共用一套 JDK、一套配置、一个进程任何一处版本或路径不对表现都是“进程直接退出”连检查进程状态的命令都抓不到线索。这个包适合谁想在本地、测试机或者一台小机器上把调度跑起来验证 flow 的 DAG 写法和 shell 任务能不能正常收尾给团队演示一条流水线长什么样。它不适合直接当生产调度用多执行器、任务隔离、高可用这些能力 solo 模式给不了。所以装它之前得接受一个前提——这不是“解压即用”的软件而是一个需要你先把它运行所依赖的环境固定下来的老式 Java 应用。2. 装前定环境JDK、内存和端口三件事不确认后面全是白工我把这台机器上的安装顺序调过一次变成先看包、再看机器、最后解压。原因很简单这个 tar 包里没有安装脚本也没有依赖下载步骤所有 jar 都躺在lib/目录里它能不能跑完全取决于你有没有给它一个相容的 JVM。先解压再回头换 JDK等于把配置里写死的路径全部推倒重来多花的时间远超过前面这十分钟的预检。2.1 JDK 版本怎么定先看 lib 目录再决定装哪个不要凭感觉选 JDK先让包自己告诉你它是什么年代的产物。拿到 tar 包之后不用解压直接列内容cd /tmp # 看顶层目录结构确认解压出来是单层目录还是散开的 tar -tzf azkaban-solo-server-0.1.0-SNAPSHOT.tar.gz | sed -n 1,30p # 按关键字把关键依赖挑出来jetty 的版本最能说明问题 tar -tzf azkaban-solo-server-0.1.0-SNAPSHOT.tar.gz \ | grep -E lib/(jetty|servlet|h2|log4j) | head -n 20第一条命令看的是目录布局它决定了你后面cd到哪一层、配置文件里的相对路径怎么写。第二条是核心判断依据内嵌 Web 容器的版本号基本锁定了 JDK 的可用区间看到 jetty-6 或 jetty-7 这种编号就说明它是 JDK 7/8 时代的构建产物别拿 JDK 17 去试试了也是白试。我一般会直接把落点定在 JDK 8兼容性最宽踩坑概率最低。JDK 11 往上会遇到模块化访问限制表现是启动阶段就抛InaccessibleObjectException而日志里那一串反射堆栈跟“版本不兼容”四个字毫无关系新手很容易误判成包坏了。机器上可能已经装了多个版本确认和切换的动作是这样java -version 21 ls /usr/lib/jvm/ # 只对当前会话生效调通了再写进 /etc/profile.d/ export JAVA_HOME/usr/lib/jvm/java-8-openjdk-amd64 export PATH$JAVA_HOME/bin:$PATH java -versionJAVA_HOME是重点启动脚本里那行$JAVA_HOME/bin/java读的就是它很多人的启动脚本报JAVA_HOME is not set其实不是没装 JDK而是用 root 装过、又用普通用户跑。PATH只是让自己在当前 shell 里敲java方便对脚本没有影响。这两行写在终端里只对当前窗口有效验证通过之后记得落到/etc/profile.d/azkaban-jdk.sh里并确认运行 Azkaban 的那个用户能读到。注意不要在.bashrc里改JAVA_HOME然后指望 systemd 或者sudo起的进程能继承非交互式 shell 不会加载它。要长期生效就写/etc/profile.d/或者直接在启动脚本里写死绝对路径。2.2 内存、端口和文件句柄的预检solo server 是三个角色共用一个 JVMWeb 容器要线程、执行器要线程、H2 要缓冲区堆太小的时候不会在启动阶段报错而是在你跑第几个 flow 的时候突然 OOM日志里留下一坨 GC 信息就没了。先看机器资源free -m nproc ulimit -n df -h /optfree -m的可用内存至少要留 1G 给这个进程机器上还有别的东西在跑的话要往上加。ulimit -n看的是文件句柄上限老发行版默认 1024跑几十个并发 flow 加上日志文件很容易撞到上限表现是Too many open files改/etc/security/limits.conf或 systemd 的LimitNOFILE都行改完必须重新登录或者重启服务才生效。df -h /opt是给 H2 数据库和日志留空间H2 的库文件会随着执行历史一直长别放在只剩几百兆的分区上。端口预检同样要在解压之前做完ss -lntp | grep -E :(8081|8443)\b || echo 8081/8443 都空着8081 是 Web 端口8443 是 HTTPS 的默认占位没配证书的话它不会真的监听但先把两个都确认空出来省得后面改了端口又在防火墙、反向代理、浏览器书签三个地方来回对。有人喜欢把端口改到 8080结果跟机器上的 Tomcat 撞了Azkaban 起得来但访问的是别人的页面这种错排查起来最费劲。2.3 解压路径和目录规划路径这件事看起来最没技术含量实际上决定了后面所有相对路径能不能对上。我习惯统一放/opt/azkaban把版本号留在子目录里将来换版本只是改一个软链sudo mkdir -p /opt/azkaban sudo chown -R $USER:$USER /opt/azkaban tar -xzf /tmp/azkaban-solo-server-0.1.0-SNAPSHOT.tar.gz -C /opt/azkaban cd /opt/azkaban ls解压完先ls看一眼如果出来的是一层azkaban-solo-server-0.1.0-SNAPSHOT目录就cd进去继续如果文件是散开的说明打包方式不同自己建一个同名目录再解一次别在散开的目录里直接启动后面conf/的相对路径会全乱。进去之后花一分钟认清几个目录各自干什么目录作用装完要不要动bin/启动、停止脚本可能要加 JVM 参数conf/azkaban.properties、用户文件、全局属性必改lib/全部依赖 jar不动plugins/作业类型插件用 shell 任务就不用动projects/上传的工程和 flow 元数据确认可写h2/内置数据库文件首次启动自动生成logs/运行日志确认可写projects/和h2/可能一开始不存在很多包是首次启动时才创建。这里有个血泪经验如果启动用户对安装目录没有写权限这两个目录建不出来进程会以一个毫无信息量的异常退出。所以chown那一步不要省也不要为了省事直接用 root 跑root 跑出来的h2/目录后面换普通用户启动会直接报权限拒绝。3. 配置保存conf/azkaban.properties 里必须核对的那几行配置文件的每一行都有默认值问题在于默认值是按“开发机上跑一下”设计的搬到测试机上就有几处必须改。下面是我在 solo 模式下会逐行核对的一个版本注释写的是为什么这么填不是官方推荐的原文。3.1 azkaban.properties 的逐行核对# conf/azkaban.properties # 页面左上角显示的名字纯粹用于区分环境测试机建议带上机器标识 azkaban.nameazkaban-solo-test azkaban.labelSolo Server azkaban.color#FF3601 azkaban.default.servlet.path/index web.resource.dirweb/ # 时区必须改见下方说明 default.timezoneAsia/Shanghai # 用户管理默认就是读 xml路径相对启动目录 user.manager.classazkaban.user.XmlUserManager user.manager.xml.fileconf/azkaban-users.xml # 全局属性和工程存放目录 executor.global.propertiesconf/global.properties azkaban.project.dirprojects # 内置数据库 database.typeh2 h2.path./h2 h2.create.tablestrue # Web 容器 jetty.port8081 jetty.maxThreads25 jetty.ssl.port8443default.timezone是这份配置里最容易被忽略、又最容易让人怀疑人生的一行。不改成Asia/Shanghai页面上设置的“每天凌晨 2 点执行”会按服务器默认时区折算你会在早上八点看到任务跑完、或者干脆看不到它跑。判断方法很简单改完之后在页面上看调度列表里显示的下次执行时间跟你的预期差几个小时就是时区没对上。h2.path./h2里的点号是相对路径参照物是启动时的工作目录不是配置文件所在目录。这意味着你在安装根目录下执行bin/azkaban-solo-start.sh数据库落在./h2如果你cd bin之后再./azkaban-solo-start.sh数据库就落在bin/h2。两套目录、两份数据页面上看得到的工程完全不一样这个坑在第 5 章还会再提一次。h2.create.tablestrue负责首次启动时自动建表。第一次装保持 true建完之后不建议改回 false 再改回来中间如果表结构没建全表现是页面能打开、登录报 SQL 异常比启动失败更难查。jetty.maxThreads25在 solo 模式下够用调大没有意义因为执行器本身是串行处理能力的瓶颈Web 线程再多也只是排队更快而已。3.2 H2 数据库和 projects 目录的初始化配置文件里的相对路径能不能落地取决于目录是否存在、当前用户能不能写。启动前手动确认一遍比事后看日志省事cd /opt/azkaban/azkaban-solo-server-0.1.0-SNAPSHOT # 这三个目录要和 azkaban.properties 里的配置对得上 mkdir -p projects h2 logs ls -ld projects h2 logs touch projects/.wtest rm -f projects/.wtest echo projects 可写mkdir -p不报错就说明父目录权限没问题ls -ld看的是属主和权限位touch那一行是最直接的写权限验证——目录存在但不可写的情况太常见了尤其是从别人机器上打包拷过来的目录。h2目录首次启动会自动建表但目录本身最好先建好省得因为父目录只读导致建库失败。projects目录的另一个作用是容纳上传的 zip 包和解压后的 flow 文件磁盘增长基本上都发生在这里。测试机上跑久了会发现它涨到几个 G原因是每次上传都会留一份原始包。提示如果机器上有多个 Azkaban 实例务必让每个实例的h2.path和azkaban.project.dir指向不同目录。共用同一份 H2 文件的后果是后启动的那个直接拿不到锁而且报错信息里只有一行Database may be already in use看不出是哪个进程占着。3.3 登录账户与 azkaban-users.xml默认的用户文件在conf/下格式是 XML改之前先备份一份cp conf/azkaban-users.xml conf/azkaban-users.xml.bakazkaban-users !-- admin 角色能建工程、删工程、看所有人的执行记录 -- user usernameazkaban passwordazkaban rolesadmin groupsazkaban/ !-- 普通用户只用于演示权限隔离正式环境别用弱口令 -- user usernameops passwordOps2024 rolesuser/ group nameazkaban rolesadmin/ /azkaban-usersrolesadmin决定了他能看到 Projects 页面上的全部工程rolesuser只能看自己创建的。solo 模式下这套权限体系比较粗糙但用来区分“谁能上传 flow”足够了。密码在这个版本里是明文存储的这一点没法改能做的是别把 8081 直接暴露出去——用 firewalld 限制来源网段或者只监听内网地址都比在应用层想办法加密实在。改完 XML 不需要重启就能生效吗不行用户文件是在 Web 容器启动时加载的改完必须重启进程。这也是为什么我建议把用户一次性配好而不是边用边加。3.4 启动脚本里的 JVM 参数包里自带的启动脚本通常会读环境变量里的 JVM 参数也可能什么都没读直接写死了一行java命令。先看清楚再动手grep -n JAVA_OPTS\|Xmx\|exec java\|\$JAVA_HOME bin/azkaban-solo-start.sh如果脚本引用了JAVA_OPTS启动前导出就行export JAVA_OPTS-Xms256m -Xmx512m -Dfile.encodingUTF-8如果脚本里写死了java -classpath ...没有引用JAVA_OPTS就在那行java后面、-classpath前面手动插参数改成java -Xms256m -Xmx512m -Dfile.encodingUTF-8 -classpath ...。-Xms和-Xmx设成一样可以避免堆反复扩容测试机上 512M 够跑十几个简单 flow。-Dfile.encodingUTF-8这一条别省flow 里写中文注释、shell 任务输出中文的时候日志会变成乱码而乱码又会让你误判成任务执行失败属于典型的干扰项。4. 启动到首个 flow从 tar 包到能跑通一次任务调度配置改完接下来是让进程真正起来、并且跑通一次任务。这一步我拆成三段先以前台方式起一次看日志确认没问题再转后台然后登录、建工程、上传一个最小 flow最后看一眼执行记录确认调度链路是通的。4.1 第一次启动必须前台跑cd /opt/azkaban/azkaban-solo-server-0.1.0-SNAPSHOT # 前台启动报错会直接打在终端上方便第一时间看到 bin/azkaban-solo-start.sh第一次启动不要用nohup ... 也不要写 systemd就老老实实前台跑着看。启动成功的标志是日志里出现 Web 容器开始监听 8081 的那一行通常是Started SelectChannelConnector0.0.0.0:8081之类的输出之后进程会挂在前台不返回。这时候另开一个终端验证curl -sS -o /dev/null -w %{http_code}\n --max-time 5 http://127.0.0.1:8081/返回 200 或者 302 都说明 Web 层活着返回000就是没起来或者端口没通。确认没问题之后CtrlC停掉再转成后台方式mkdir -p logs nohup bin/azkaban-solo-start.sh logs/console.log 21 sleep 8 tail -n 50 logs/console.log这里我特意用了外部重定向而不是依赖包内的日志配置。原因是早期版本的日志输出位置不一定跟你想的一样有的打到标准输出、有的写到logs/azkaban.log启动失败时如果连控制台输出都没留下就只能靠猜。重定向到logs/console.log至少保证“黑匣子有记录”出问题时有东西可查。注意nohup启动的进程在当前 shell 退出后依然存活但机器重启就没了。测试机可以接受需要长期跑就补一个 systemd unit注意WorkingDirectory要设成安装根目录否则./h2的相对路径又对不上。4.2 建工程、上传 zip、flow 长什么样登录之后第一件事不是急着传业务 flow而是传一个最小可运行的任务把链路跑通。上传的 zip 包里至少要有一个.project文件和一个.flow文件两者主名保持一致mkdir -p /tmp/my-first-flow cd /tmp/my-first-flow cat demo.project EOF azkaban-flow-version: 2.0 EOF cat demo.flow EOF nodes: - name: start type: noop - name: greet type: command dependsOn: - start config: command: echo hello azkaban $(date) fail.on.error: true EOF # 打包时只打这两个文件不要在 zip 里再套一层目录 zip -r /tmp/my-first-flow.zip demo.project demo.flow.project文件里的版本声明决定 flow 用哪种语法解析写错了会在上传后报解析失败如果你的包里自带示例 flow直接照抄它的声明最稳。.flow用 nodes 列表描述 DAGtype: noop是一个空节点纯粹用来做起点type: command是 shell 任务dependsOn决定执行顺序写成列表就意味着可以挂多个前置节点。fail.on.error: true表示这个节点的命令返回非 0 时整条 flow 失败不加的话默认行为取决于版本容易在演示时出现“明明报错了页面还是绿的”。打包那一行是重点zip命令要在 flow 文件所在目录里执行只打文件本身。如果写成zip -r xxx.zip my-first-flow/包里就多了一层目录上传后页面上看不到任何 flow——这个坑我见过太多次第 5 章展开说。上传路径是 Projects 页面新建工程进入工程后点 Upload选择 zip。传完之后 Flows 列表里应该出现demo点进去能看到两个节点的依赖关系图点 Execute 就能跑。4.3 定时调度和执行记录怎么看手动跑通之后调度才是这个工具真正有用的地方。在 Flow 详情页点 Schedule填 cron 表达式0 0 2 * * ?六位字段依次是秒、分、时、日、月、周上面这行表示每天凌晨 2 点整执行。日和周两个字段通常有一个要写?让另一个生效两个都写具体值会因为冲突导致调度不触发——这类“表达式看起来对但不跑”的问题九成是这里写错了而不是 Azkaban 有 bug。执行记录在 Executions 页面重点看三列开始时间、状态、耗时。状态卡在Preparing不动通常是执行线程没起来或者上一条 flow 还没结束状态是Failed就点进去看具体节点的日志command类型的任务日志里会完整保留 stdout 和 stderr这是排查 shell 脚本问题最直接的材料。5. 排查记录solo server 起不来、flow 传不上的五类翻车5.1 现象脚本一执行就报 JAVA_HOME is not set原因有两个层次。浅层是当前 shell 里确实没有JAVA_HOME装 JDK 时只把bin加进了PATH。深层是你在终端里导出的变量没有被启动脚本所在的执行环境继承——用sudo执行、用 systemd 拉起、或者从一个没加载.bashrc的会话里跑都会丢失。解决方式是把绝对路径写进启动脚本而不是指望环境变量# 在 azkaban-solo-start.sh 顶部、引用 $JAVA_HOME 之前插入 export JAVA_HOME/usr/lib/jvm/java-8-openjdk-amd64改完用bash -x bin/azkaban-solo-start.sh跟一遍能看到每一行展开后的实际命令比读脚本猜要快。5.2 现象端口被占或者进程起来了访问 404Address already in use直接说明 8081 有别的进程在听用ss -lntp | grep 8081找到 PID 再决定是杀掉还是改端口。改端口只改jetty.port一行改完记得重启并重新验证。更迷惑的是“进程活着但页面 404”。这种情况一般是web.resource.dirweb/相对路径没对上——启动目录不在安装根目录时Web 容器找不到静态资源和页面模板能监听但不返回内容。解决办法是启动前pwd确认在安装根目录或者把这个路径改成绝对路径。我在脚本里加了一行cd $(dirname $0)/..就是干这个的属于花一分钟省两小时的操作。5.3 现象H2 报 Database may be already in use日志里出现这行说明同一份数据库文件被两个进程抢。solo 模式的 H2 是文件锁一个进程占着另一个就完全起不来。先确认是不是自己不小心起了两个ps -ef | grep -i azkaban | grep -v grep ss -lntp | grep -E :(8081|8443)\b如果只有一个进程却还是报锁那就去看h2.path指向的目录大概率是这个目录里留下了上次异常退出时的.lock.db文件。确认没有活进程之后删掉锁文件即可但删之前一定用ps确认过直接删正在使用的锁文件会损坏库。还有一种情况是路径不统一在根目录起过一次、在bin目录起过一次产生了./h2和./bin/h2两份。表现是“我明明建过工程怎么登上去是空的”。解决方式不是合并而是删掉多余的那份然后固定一个启动目录。5.4 现象上传 zip 成功了Flows 列表里什么都没有原因基本只有一个zip 结构不对。Azkaban 期望 flow 文件和 project 文件在压缩包根目录如果打包时把整个文件夹打进去它就找不到任何 flow 定义。检查方式是上传前先看包内结构unzip -l /tmp/my-first-flow.zip输出里应该是demo.project、demo.flow两个条目如果看到的是my-first-flow/demo.flow就重新打一次cd进目录再zip -r。另一个同源问题是.flow文件名和.project里的工程名对不上。solo 模式对命名比较宽容但 flow 名和文件名不一致时页面上显示的 flow 名会很奇怪后面做调度容易挂错对象。统一规则是主名保持一致demo.project配demo.flow。5.5 现象flow 一直停在 Preparing或者任务秒失败但看不出原因日志里没有任何异常页面上状态不动这是 solo 模式最玄学的一类问题。先看 JVM 内存——free -m加上jstat看老年代占用堆不够时执行线程申请不到资源状态就停在准备阶段。把-Xmx从默认值提到 512M 之后这类问题基本消失。第二种是命令本身的问题。command类型任务默认不走登录 shellPATH比你在终端里短得多脚本里直接写python3 xxx.py、node xxx.js就会报 command not found而这个报错藏在节点日志里页面上只看到红色。稳妥写法是在 flow 里用绝对路径或者在命令开头自己补一句export PATH/usr/local/bin:$PATH。我一般还会在命令末尾加echo exit$?让节点日志里留下明确的退出码比在页面上看图标猜要准。提示改完azkaban.properties里的任何一项都要重启进程配置文件不是热加载的。改完不生效先想这一条能省掉一大半自我怀疑。6. 装完怎么验四步自检和一份最小验收清单装到能启动只是第一步能稳定跑通一次调度才叫装完。我现在的验收顺序固定成四步前后不超过五分钟但能把第 5 章列的那些坑提前挡住。第一步进程和端口同时看不要只看页面能不能打开#!/usr/bin/env bash set -u BASEhttp://127.0.0.1:8081 code$(curl -sS -o /dev/null -w %{http_code} --max-time 5 $BASE/ || true) echo web_status$code if ps -ef | grep -q [a]zkaban.soloserver; then echo processalive else echo processdead fi ss -lntp | grep -q :8081 echo portlisten || echo portfree test -w projects echo projectswritable || echo projectsreadonly ls -1 h2/*.mv.db 2/dev/null | head -n 1 | grep -q . \ echo h2created || echo h2missingweb_status判断页面层processalive确认 JVM 还在portlisten排除端口漂移projectswritable和h2created确认落盘路径对得上。这五项里任何一项不对就不用往下走了先修这一项。第二步登录之后进 Projects 页面确认能新建工程、能看到自己刚建的工程这一步验的是用户文件和权限配置。第三步传一个只有noop节点和command节点的最小 flow手动执行一次看节点日志里有没有你写的 echo 输出。看到输出就说明执行器和 shell 环境是通的。第四步给这个 flow 配一个一分钟后的调度等它自动触发一次再回到 Executions 页面确认状态。这一步验的是时区和 cron 表达式手动能跑但调度不跑的情况九成出在这里。验收项通过标准不通过先查哪里端口监听8081 处于 listenjetty.port、端口冲突页面访问返回 200 或 302web.resource.dir、启动目录登录能进 Projects 页面azkaban-users.xml、重启手动执行节点日志有 echo 输出PATH、命令绝对路径定时触发到点后状态变绿default.timezone、cron 六位字段数据保存重启后工程还在h2.path是否稳定从那以后我每次装完 Azkaban都强制走一遍这个顺序curl 通、登录、传 flow、手动跑一次、配调度再跑一次。跳过任何一步后面都会以更贵的方式补回来——要么是演示当天调度不触发要么是重启之后工程全没了。希望帮到你。本文还有配套的精品资源点击获取
简介Azkaban 是一款源自 LinkedIn 的开源工作流执行引擎常用于大数据处理任务的依赖调度与定时管理这份 azkaban-solo-server-0.1.0-SNAPSHOT.tar.gz 是其单服务器版本已编译打包解压后即可直接运行无需再走源码编译流程。它把 Web 服务、执行器与内嵌 H2 数据库集中在一台机器上安装配置相对轻量适合个人开发者、小型团队以及需要快速体验 Azkaban 工作流机制的初学者用来解决小规模作业编排与调度验证的问题。压缩包整体约 42.28MB上游未提供可统计的文件明细包内以解压即用的服务端目录、配置文件和启动脚本为主可直接用于本地搭建调试环境。资源页面显示已有 260 人浏览学习可作为入门参考。通过它读者能够实际练习项目创建、job 依赖定义、工作流设计与定时调度并借助 Web 界面观察执行状态与日志输出同时了解 SNAPSHOT 版本在稳定性上的局限与集群部署的适用边界。1. 解压就见效的错觉azkaban-solo-server-0.1.0-SNAPSHOT 装之前先认清它是什么第一次拿到azkaban-solo-server-0.1.0-SNAPSHOT.tar.gz是在一台测试机上解压、进目录、敲bin/azkaban-solo-start.sh回车之后终端安静了大概三秒然后进程没了日志里连一句像样的异常都没留下。做 azkaban 任务调度的人都听过 solo server 这个名字因为它是所有部署形态里最省事的一种Web 服务、执行器、内置 H2 数据库全挤在同一个 JVM 里一个 tar 包解压就能访问页面。省事的另一面是三个组件共用一套 JDK、一套配置、一个进程任何一处版本或路径不对表现都是“进程直接退出”连检查进程状态的命令都抓不到线索。这个包适合谁想在本地、测试机或者一台小机器上把调度跑起来验证 flow 的 DAG 写法和 shell 任务能不能正常收尾给团队演示一条流水线长什么样。它不适合直接当生产调度用多执行器、任务隔离、高可用这些能力 solo 模式给不了。所以装它之前得接受一个前提——这不是“解压即用”的软件而是一个需要你先把它运行所依赖的环境固定下来的老式 Java 应用。2. 装前定环境JDK、内存和端口三件事不确认后面全是白工我把这台机器上的安装顺序调过一次变成先看包、再看机器、最后解压。原因很简单这个 tar 包里没有安装脚本也没有依赖下载步骤所有 jar 都躺在lib/目录里它能不能跑完全取决于你有没有给它一个相容的 JVM。先解压再回头换 JDK等于把配置里写死的路径全部推倒重来多花的时间远超过前面这十分钟的预检。2.1 JDK 版本怎么定先看 lib 目录再决定装哪个不要凭感觉选 JDK先让包自己告诉你它是什么年代的产物。拿到 tar 包之后不用解压直接列内容cd /tmp # 看顶层目录结构确认解压出来是单层目录还是散开的 tar -tzf azkaban-solo-server-0.1.0-SNAPSHOT.tar.gz | sed -n 1,30p # 按关键字把关键依赖挑出来jetty 的版本最能说明问题 tar -tzf azkaban-solo-server-0.1.0-SNAPSHOT.tar.gz \ | grep -E lib/(jetty|servlet|h2|log4j) | head -n 20第一条命令看的是目录布局它决定了你后面cd到哪一层、配置文件里的相对路径怎么写。第二条是核心判断依据内嵌 Web 容器的版本号基本锁定了 JDK 的可用区间看到 jetty-6 或 jetty-7 这种编号就说明它是 JDK 7/8 时代的构建产物别拿 JDK 17 去试试了也是白试。我一般会直接把落点定在 JDK 8兼容性最宽踩坑概率最低。JDK 11 往上会遇到模块化访问限制表现是启动阶段就抛InaccessibleObjectException而日志里那一串反射堆栈跟“版本不兼容”四个字毫无关系新手很容易误判成包坏了。机器上可能已经装了多个版本确认和切换的动作是这样java -version 21 ls /usr/lib/jvm/ # 只对当前会话生效调通了再写进 /etc/profile.d/ export JAVA_HOME/usr/lib/jvm/java-8-openjdk-amd64 export PATH$JAVA_HOME/bin:$PATH java -versionJAVA_HOME是重点启动脚本里那行$JAVA_HOME/bin/java读的就是它很多人的启动脚本报JAVA_HOME is not set其实不是没装 JDK而是用 root 装过、又用普通用户跑。PATH只是让自己在当前 shell 里敲java方便对脚本没有影响。这两行写在终端里只对当前窗口有效验证通过之后记得落到/etc/profile.d/azkaban-jdk.sh里并确认运行 Azkaban 的那个用户能读到。注意不要在.bashrc里改JAVA_HOME然后指望 systemd 或者sudo起的进程能继承非交互式 shell 不会加载它。要长期生效就写/etc/profile.d/或者直接在启动脚本里写死绝对路径。2.2 内存、端口和文件句柄的预检solo server 是三个角色共用一个 JVMWeb 容器要线程、执行器要线程、H2 要缓冲区堆太小的时候不会在启动阶段报错而是在你跑第几个 flow 的时候突然 OOM日志里留下一坨 GC 信息就没了。先看机器资源free -m nproc ulimit -n df -h /optfree -m的可用内存至少要留 1G 给这个进程机器上还有别的东西在跑的话要往上加。ulimit -n看的是文件句柄上限老发行版默认 1024跑几十个并发 flow 加上日志文件很容易撞到上限表现是Too many open files改/etc/security/limits.conf或 systemd 的LimitNOFILE都行改完必须重新登录或者重启服务才生效。df -h /opt是给 H2 数据库和日志留空间H2 的库文件会随着执行历史一直长别放在只剩几百兆的分区上。端口预检同样要在解压之前做完ss -lntp | grep -E :(8081|8443)\b || echo 8081/8443 都空着8081 是 Web 端口8443 是 HTTPS 的默认占位没配证书的话它不会真的监听但先把两个都确认空出来省得后面改了端口又在防火墙、反向代理、浏览器书签三个地方来回对。有人喜欢把端口改到 8080结果跟机器上的 Tomcat 撞了Azkaban 起得来但访问的是别人的页面这种错排查起来最费劲。2.3 解压路径和目录规划路径这件事看起来最没技术含量实际上决定了后面所有相对路径能不能对上。我习惯统一放/opt/azkaban把版本号留在子目录里将来换版本只是改一个软链sudo mkdir -p /opt/azkaban sudo chown -R $USER:$USER /opt/azkaban tar -xzf /tmp/azkaban-solo-server-0.1.0-SNAPSHOT.tar.gz -C /opt/azkaban cd /opt/azkaban ls解压完先ls看一眼如果出来的是一层azkaban-solo-server-0.1.0-SNAPSHOT目录就cd进去继续如果文件是散开的说明打包方式不同自己建一个同名目录再解一次别在散开的目录里直接启动后面conf/的相对路径会全乱。进去之后花一分钟认清几个目录各自干什么目录作用装完要不要动bin/启动、停止脚本可能要加 JVM 参数conf/azkaban.properties、用户文件、全局属性必改lib/全部依赖 jar不动plugins/作业类型插件用 shell 任务就不用动projects/上传的工程和 flow 元数据确认可写h2/内置数据库文件首次启动自动生成logs/运行日志确认可写projects/和h2/可能一开始不存在很多包是首次启动时才创建。这里有个血泪经验如果启动用户对安装目录没有写权限这两个目录建不出来进程会以一个毫无信息量的异常退出。所以chown那一步不要省也不要为了省事直接用 root 跑root 跑出来的h2/目录后面换普通用户启动会直接报权限拒绝。3. 配置保存conf/azkaban.properties 里必须核对的那几行配置文件的每一行都有默认值问题在于默认值是按“开发机上跑一下”设计的搬到测试机上就有几处必须改。下面是我在 solo 模式下会逐行核对的一个版本注释写的是为什么这么填不是官方推荐的原文。3.1 azkaban.properties 的逐行核对# conf/azkaban.properties # 页面左上角显示的名字纯粹用于区分环境测试机建议带上机器标识 azkaban.nameazkaban-solo-test azkaban.labelSolo Server azkaban.color#FF3601 azkaban.default.servlet.path/index web.resource.dirweb/ # 时区必须改见下方说明 default.timezoneAsia/Shanghai # 用户管理默认就是读 xml路径相对启动目录 user.manager.classazkaban.user.XmlUserManager user.manager.xml.fileconf/azkaban-users.xml # 全局属性和工程存放目录 executor.global.propertiesconf/global.properties azkaban.project.dirprojects # 内置数据库 database.typeh2 h2.path./h2 h2.create.tablestrue # Web 容器 jetty.port8081 jetty.maxThreads25 jetty.ssl.port8443default.timezone是这份配置里最容易被忽略、又最容易让人怀疑人生的一行。不改成Asia/Shanghai页面上设置的“每天凌晨 2 点执行”会按服务器默认时区折算你会在早上八点看到任务跑完、或者干脆看不到它跑。判断方法很简单改完之后在页面上看调度列表里显示的下次执行时间跟你的预期差几个小时就是时区没对上。h2.path./h2里的点号是相对路径参照物是启动时的工作目录不是配置文件所在目录。这意味着你在安装根目录下执行bin/azkaban-solo-start.sh数据库落在./h2如果你cd bin之后再./azkaban-solo-start.sh数据库就落在bin/h2。两套目录、两份数据页面上看得到的工程完全不一样这个坑在第 5 章还会再提一次。h2.create.tablestrue负责首次启动时自动建表。第一次装保持 true建完之后不建议改回 false 再改回来中间如果表结构没建全表现是页面能打开、登录报 SQL 异常比启动失败更难查。jetty.maxThreads25在 solo 模式下够用调大没有意义因为执行器本身是串行处理能力的瓶颈Web 线程再多也只是排队更快而已。3.2 H2 数据库和 projects 目录的初始化配置文件里的相对路径能不能落地取决于目录是否存在、当前用户能不能写。启动前手动确认一遍比事后看日志省事cd /opt/azkaban/azkaban-solo-server-0.1.0-SNAPSHOT # 这三个目录要和 azkaban.properties 里的配置对得上 mkdir -p projects h2 logs ls -ld projects h2 logs touch projects/.wtest rm -f projects/.wtest echo projects 可写mkdir -p不报错就说明父目录权限没问题ls -ld看的是属主和权限位touch那一行是最直接的写权限验证——目录存在但不可写的情况太常见了尤其是从别人机器上打包拷过来的目录。h2目录首次启动会自动建表但目录本身最好先建好省得因为父目录只读导致建库失败。projects目录的另一个作用是容纳上传的 zip 包和解压后的 flow 文件磁盘增长基本上都发生在这里。测试机上跑久了会发现它涨到几个 G原因是每次上传都会留一份原始包。提示如果机器上有多个 Azkaban 实例务必让每个实例的h2.path和azkaban.project.dir指向不同目录。共用同一份 H2 文件的后果是后启动的那个直接拿不到锁而且报错信息里只有一行Database may be already in use看不出是哪个进程占着。3.3 登录账户与 azkaban-users.xml默认的用户文件在conf/下格式是 XML改之前先备份一份cp conf/azkaban-users.xml conf/azkaban-users.xml.bakazkaban-users !-- admin 角色能建工程、删工程、看所有人的执行记录 -- user usernameazkaban passwordazkaban rolesadmin groupsazkaban/ !-- 普通用户只用于演示权限隔离正式环境别用弱口令 -- user usernameops passwordOps2024 rolesuser/ group nameazkaban rolesadmin/ /azkaban-usersrolesadmin决定了他能看到 Projects 页面上的全部工程rolesuser只能看自己创建的。solo 模式下这套权限体系比较粗糙但用来区分“谁能上传 flow”足够了。密码在这个版本里是明文存储的这一点没法改能做的是别把 8081 直接暴露出去——用 firewalld 限制来源网段或者只监听内网地址都比在应用层想办法加密实在。改完 XML 不需要重启就能生效吗不行用户文件是在 Web 容器启动时加载的改完必须重启进程。这也是为什么我建议把用户一次性配好而不是边用边加。3.4 启动脚本里的 JVM 参数包里自带的启动脚本通常会读环境变量里的 JVM 参数也可能什么都没读直接写死了一行java命令。先看清楚再动手grep -n JAVA_OPTS\|Xmx\|exec java\|\$JAVA_HOME bin/azkaban-solo-start.sh如果脚本引用了JAVA_OPTS启动前导出就行export JAVA_OPTS-Xms256m -Xmx512m -Dfile.encodingUTF-8如果脚本里写死了java -classpath ...没有引用JAVA_OPTS就在那行java后面、-classpath前面手动插参数改成java -Xms256m -Xmx512m -Dfile.encodingUTF-8 -classpath ...。-Xms和-Xmx设成一样可以避免堆反复扩容测试机上 512M 够跑十几个简单 flow。-Dfile.encodingUTF-8这一条别省flow 里写中文注释、shell 任务输出中文的时候日志会变成乱码而乱码又会让你误判成任务执行失败属于典型的干扰项。4. 启动到首个 flow从 tar 包到能跑通一次任务调度配置改完接下来是让进程真正起来、并且跑通一次任务。这一步我拆成三段先以前台方式起一次看日志确认没问题再转后台然后登录、建工程、上传一个最小 flow最后看一眼执行记录确认调度链路是通的。4.1 第一次启动必须前台跑cd /opt/azkaban/azkaban-solo-server-0.1.0-SNAPSHOT # 前台启动报错会直接打在终端上方便第一时间看到 bin/azkaban-solo-start.sh第一次启动不要用nohup ... 也不要写 systemd就老老实实前台跑着看。启动成功的标志是日志里出现 Web 容器开始监听 8081 的那一行通常是Started SelectChannelConnector0.0.0.0:8081之类的输出之后进程会挂在前台不返回。这时候另开一个终端验证curl -sS -o /dev/null -w %{http_code}\n --max-time 5 http://127.0.0.1:8081/返回 200 或者 302 都说明 Web 层活着返回000就是没起来或者端口没通。确认没问题之后CtrlC停掉再转成后台方式mkdir -p logs nohup bin/azkaban-solo-start.sh logs/console.log 21 sleep 8 tail -n 50 logs/console.log这里我特意用了外部重定向而不是依赖包内的日志配置。原因是早期版本的日志输出位置不一定跟你想的一样有的打到标准输出、有的写到logs/azkaban.log启动失败时如果连控制台输出都没留下就只能靠猜。重定向到logs/console.log至少保证“黑匣子有记录”出问题时有东西可查。注意nohup启动的进程在当前 shell 退出后依然存活但机器重启就没了。测试机可以接受需要长期跑就补一个 systemd unit注意WorkingDirectory要设成安装根目录否则./h2的相对路径又对不上。4.2 建工程、上传 zip、flow 长什么样登录之后第一件事不是急着传业务 flow而是传一个最小可运行的任务把链路跑通。上传的 zip 包里至少要有一个.project文件和一个.flow文件两者主名保持一致mkdir -p /tmp/my-first-flow cd /tmp/my-first-flow cat demo.project EOF azkaban-flow-version: 2.0 EOF cat demo.flow EOF nodes: - name: start type: noop - name: greet type: command dependsOn: - start config: command: echo hello azkaban $(date) fail.on.error: true EOF # 打包时只打这两个文件不要在 zip 里再套一层目录 zip -r /tmp/my-first-flow.zip demo.project demo.flow.project文件里的版本声明决定 flow 用哪种语法解析写错了会在上传后报解析失败如果你的包里自带示例 flow直接照抄它的声明最稳。.flow用 nodes 列表描述 DAGtype: noop是一个空节点纯粹用来做起点type: command是 shell 任务dependsOn决定执行顺序写成列表就意味着可以挂多个前置节点。fail.on.error: true表示这个节点的命令返回非 0 时整条 flow 失败不加的话默认行为取决于版本容易在演示时出现“明明报错了页面还是绿的”。打包那一行是重点zip命令要在 flow 文件所在目录里执行只打文件本身。如果写成zip -r xxx.zip my-first-flow/包里就多了一层目录上传后页面上看不到任何 flow——这个坑我见过太多次第 5 章展开说。上传路径是 Projects 页面新建工程进入工程后点 Upload选择 zip。传完之后 Flows 列表里应该出现demo点进去能看到两个节点的依赖关系图点 Execute 就能跑。4.3 定时调度和执行记录怎么看手动跑通之后调度才是这个工具真正有用的地方。在 Flow 详情页点 Schedule填 cron 表达式0 0 2 * * ?六位字段依次是秒、分、时、日、月、周上面这行表示每天凌晨 2 点整执行。日和周两个字段通常有一个要写?让另一个生效两个都写具体值会因为冲突导致调度不触发——这类“表达式看起来对但不跑”的问题九成是这里写错了而不是 Azkaban 有 bug。执行记录在 Executions 页面重点看三列开始时间、状态、耗时。状态卡在Preparing不动通常是执行线程没起来或者上一条 flow 还没结束状态是Failed就点进去看具体节点的日志command类型的任务日志里会完整保留 stdout 和 stderr这是排查 shell 脚本问题最直接的材料。5. 排查记录solo server 起不来、flow 传不上的五类翻车5.1 现象脚本一执行就报 JAVA_HOME is not set原因有两个层次。浅层是当前 shell 里确实没有JAVA_HOME装 JDK 时只把bin加进了PATH。深层是你在终端里导出的变量没有被启动脚本所在的执行环境继承——用sudo执行、用 systemd 拉起、或者从一个没加载.bashrc的会话里跑都会丢失。解决方式是把绝对路径写进启动脚本而不是指望环境变量# 在 azkaban-solo-start.sh 顶部、引用 $JAVA_HOME 之前插入 export JAVA_HOME/usr/lib/jvm/java-8-openjdk-amd64改完用bash -x bin/azkaban-solo-start.sh跟一遍能看到每一行展开后的实际命令比读脚本猜要快。5.2 现象端口被占或者进程起来了访问 404Address already in use直接说明 8081 有别的进程在听用ss -lntp | grep 8081找到 PID 再决定是杀掉还是改端口。改端口只改jetty.port一行改完记得重启并重新验证。更迷惑的是“进程活着但页面 404”。这种情况一般是web.resource.dirweb/相对路径没对上——启动目录不在安装根目录时Web 容器找不到静态资源和页面模板能监听但不返回内容。解决办法是启动前pwd确认在安装根目录或者把这个路径改成绝对路径。我在脚本里加了一行cd $(dirname $0)/..就是干这个的属于花一分钟省两小时的操作。5.3 现象H2 报 Database may be already in use日志里出现这行说明同一份数据库文件被两个进程抢。solo 模式的 H2 是文件锁一个进程占着另一个就完全起不来。先确认是不是自己不小心起了两个ps -ef | grep -i azkaban | grep -v grep ss -lntp | grep -E :(8081|8443)\b如果只有一个进程却还是报锁那就去看h2.path指向的目录大概率是这个目录里留下了上次异常退出时的.lock.db文件。确认没有活进程之后删掉锁文件即可但删之前一定用ps确认过直接删正在使用的锁文件会损坏库。还有一种情况是路径不统一在根目录起过一次、在bin目录起过一次产生了./h2和./bin/h2两份。表现是“我明明建过工程怎么登上去是空的”。解决方式不是合并而是删掉多余的那份然后固定一个启动目录。5.4 现象上传 zip 成功了Flows 列表里什么都没有原因基本只有一个zip 结构不对。Azkaban 期望 flow 文件和 project 文件在压缩包根目录如果打包时把整个文件夹打进去它就找不到任何 flow 定义。检查方式是上传前先看包内结构unzip -l /tmp/my-first-flow.zip输出里应该是demo.project、demo.flow两个条目如果看到的是my-first-flow/demo.flow就重新打一次cd进目录再zip -r。另一个同源问题是.flow文件名和.project里的工程名对不上。solo 模式对命名比较宽容但 flow 名和文件名不一致时页面上显示的 flow 名会很奇怪后面做调度容易挂错对象。统一规则是主名保持一致demo.project配demo.flow。5.5 现象flow 一直停在 Preparing或者任务秒失败但看不出原因日志里没有任何异常页面上状态不动这是 solo 模式最玄学的一类问题。先看 JVM 内存——free -m加上jstat看老年代占用堆不够时执行线程申请不到资源状态就停在准备阶段。把-Xmx从默认值提到 512M 之后这类问题基本消失。第二种是命令本身的问题。command类型任务默认不走登录 shellPATH比你在终端里短得多脚本里直接写python3 xxx.py、node xxx.js就会报 command not found而这个报错藏在节点日志里页面上只看到红色。稳妥写法是在 flow 里用绝对路径或者在命令开头自己补一句export PATH/usr/local/bin:$PATH。我一般还会在命令末尾加echo exit$?让节点日志里留下明确的退出码比在页面上看图标猜要准。提示改完azkaban.properties里的任何一项都要重启进程配置文件不是热加载的。改完不生效先想这一条能省掉一大半自我怀疑。6. 装完怎么验四步自检和一份最小验收清单装到能启动只是第一步能稳定跑通一次调度才叫装完。我现在的验收顺序固定成四步前后不超过五分钟但能把第 5 章列的那些坑提前挡住。第一步进程和端口同时看不要只看页面能不能打开#!/usr/bin/env bash set -u BASEhttp://127.0.0.1:8081 code$(curl -sS -o /dev/null -w %{http_code} --max-time 5 $BASE/ || true) echo web_status$code if ps -ef | grep -q [a]zkaban.soloserver; then echo processalive else echo processdead fi ss -lntp | grep -q :8081 echo portlisten || echo portfree test -w projects echo projectswritable || echo projectsreadonly ls -1 h2/*.mv.db 2/dev/null | head -n 1 | grep -q . \ echo h2created || echo h2missingweb_status判断页面层processalive确认 JVM 还在portlisten排除端口漂移projectswritable和h2created确认落盘路径对得上。这五项里任何一项不对就不用往下走了先修这一项。第二步登录之后进 Projects 页面确认能新建工程、能看到自己刚建的工程这一步验的是用户文件和权限配置。第三步传一个只有noop节点和command节点的最小 flow手动执行一次看节点日志里有没有你写的 echo 输出。看到输出就说明执行器和 shell 环境是通的。第四步给这个 flow 配一个一分钟后的调度等它自动触发一次再回到 Executions 页面确认状态。这一步验的是时区和 cron 表达式手动能跑但调度不跑的情况九成出在这里。验收项通过标准不通过先查哪里端口监听8081 处于 listenjetty.port、端口冲突页面访问返回 200 或 302web.resource.dir、启动目录登录能进 Projects 页面azkaban-users.xml、重启手动执行节点日志有 echo 输出PATH、命令绝对路径定时触发到点后状态变绿default.timezone、cron 六位字段数据保存重启后工程还在h2.path是否稳定从那以后我每次装完 Azkaban都强制走一遍这个顺序curl 通、登录、传 flow、手动跑一次、配调度再跑一次。跳过任何一步后面都会以更贵的方式补回来——要么是演示当天调度不触发要么是重启之后工程全没了。希望帮到你。本文还有配套的精品资源点击获取
