集群体检：Plex-Remote-Transcoder sessions 与日志监控排错实战

集群体检Plex-Remote-Transcoder sessions 与日志监控排错实战【免费下载链接】Plex-Remote-TranscoderA distributed transcoding backend for Plex项目地址: https://gitcode.com/gh_mirrors/pl/Plex-Remote-TranscoderPlex-Remote-Transcoder简称 PRT是一个开源的分布式 Plex 转码后端它让一台主服务器master把最耗 CPU 的转码任务通过 SSH 分发到多台转码从机slave上并行执行。集群跑起来之后运维最常问的三个问题是现在谁在看片转码跑到了哪台机器出故障该看哪份日志这篇文章带你用 PRT 自带的命令做一次集群体检学会用sessions查看实时转码会话、用日志监控定位故障、用check_config排查配置错误全程零代码基础也能跟上。为什么需要集群体检先搞懂 PRT 的工作方式PRT 的思路和常见的多台 Plex 服务器做代理负载均衡完全不同。它只保留一台Plex Media Server主节点但在主节点上用包装脚本替换掉默认转码器。当用户发起转码请求时主节点拦截请求通过 SSH 把它发送给一台最闲的从机从机调用真正的转码器完成转码把视频分片写入网络共享存储主节点把分片回传给客户端播放体验和本地转码没有任何区别。因为转码通常是 Plex 服务器最吃 CPU 的环节把这份压力分摊出去主服务器就再也不会被几路高码率视频拖垮了。但机器一多问题排查的复杂度也翻倍——这正是一套体检方法论的价值所在。体检第一步认识 PRT 自带的诊断命令全家桶PRT 的命令行工具里内置了好几个体检仪器全部通过prt入口调用命令清单定义在 prt.py 的 usage 函数中命令作用适用场景prt get_load查看本机当前负载单机状态确认prt get_cluster_load查看集群内所有节点的负载一眼看清哪台从机在忙prt sessions列出当前正在进行的转码会话谁在看片、跑在哪台机prt check_config全面检查配置、SSH 连通性与权限装完报错时的第一排查手段prt overwritePlex 升级后修复被覆盖的转码器PMS 升级后转码突然失效建议把这几个命令写进你的运维备忘它们就是集群体检的基础套餐。其中get_cluster_load的实现很简单逐个节点远程执行prt get_load并把结果汇总打印见 prt.py。体检第二步用 prt sessions 查看实时转码会话prt sessions是排查卡顿、黑屏、没反应时最高频的命令也是 CHANGELOG 里明确记录的新特性。它做两件事问 Plex 要会话列表再问系统要进程列表把两者对上号。命令怎么用在主节点上直接执行prt sessions输出类似这样Session 1/2 Host: transcode-01 File: /mnt/media/movies/The.Matrix.1999.mkv Session 2/2 Host: transcode-02 File: /mnt/media/tv/Stranger.Things.S01E01.mkvHost告诉你这部片子的转码任务被分配到了哪台从机File告诉你具体是哪个媒体文件——两行信息就够你判断转码是否真的走了集群。背后是怎么找到会话的如果你好奇它的原理不想看可以跳过先通过http://localhost:32400/status/sessions拿到 Plex 当前的转码会话 ID实现见 get_plex_sessions再用psutil遍历系统进程找出父进程是 Plex Transcoder 的ssh进程说明该连接是 PRT 拉起的远程转码从命令行参数里用正则分别抠出PRT_ID、会话 ID 和 SSH 目标主机完整逻辑在 get_sessions展示在 sessions。小贴士sessions首次运行会提示输入 Plex 账号密码换取auth_token之后会保存在~/.prt.conf里无需重复输入。体检第三步日志监控/tmp/prt.log 里的故障密码转码失败时PRT 把所有运行细节都写进了日志默认位置是/tmp/prt.log。日志系统通过 Python 标准logging配置默认采用轮转文件单个文件最大 10MB、最多保留 20 个备份配置见 prt.py所以不用担心日志把磁盘撑爆。每条日志的格式是时间 - 模块 - 级别 - 内容下面这些关键日志行值得你重点盯日志内容含义是否异常Launching transcode_local转码在主节点本地执行正常但注意是否被迫本地Launching transcode_remote with args ...转码已发送到远程从机✅ 正常Host with minimum load is xxx负载均衡选定了某台从机✅ 正常Couldnt get load for host xxx某从机连不上或已离线⚠️ 需关注No hosts found...using local所有从机都不可用回退本地⚠️ 需关注Found orphaned PRT process...killing发现并清理了孤儿进程✅ 自动修复Found EAE is being used...forcing local transcode音频编码器场景强制本地转码ℹ️ 已知限制如何开启 DEBUG 级别日志默认配置里prt这个 logger 是 DEBUG 级别见 prt.py但如果你想看到更详细的 ffmpeg 输出在~/.prt.conf中把logging.loggers.prt.level保持为DEBUG即可。DEBUG 模式下转码进程的 ffmpeg 标准错误输出会被逐行写进日志对应 transcode_local 中的逻辑排查花屏、音画不同步等编码问题会非常有用。体检第四步五大高频故障排错实战下面这些场景是集群跑起来后最容易踩的坑全部可以用上面的命令和日志解决。场景一转码全部落到本地集群没生效日志里反复出现No hosts found...using local说明servers列表里没有一台从机能拿到负载数据。依次检查~/.prt.conf中servers是否配置了主机、端口、用户主节点能否免密 SSH 登录从机PRT 靠 SSH 远程执行命令从机上是否安装了prt命令负载数据是通过远程调用prt get_load获取的见 get_system_load_remote。场景二突然出现一堆残留的 ssh 进程客户端中途断开时远程转码的 ssh 进程可能变成孤儿进程霸占资源。PRT 在每次远程转码启动前会自动清理凡是命令行里带PLEX_MEDIA_SERVER且父进程已经是pid 1的 ssh 进程都会被识别并杀掉逻辑在 transcode_remote。你只要在日志里看到Found orphaned PRT process...killing说明自动修复已经生效。场景三音频转码时卡住/失败日志提示Found EAE is being used...forcing local transcode这是 EasyAudioEncoderEAE音频编码器的已知限制它依赖/tmp下的硬编码路径远程执行会出问题。所以 PRT 检测到eae_prefix参数时会主动把该次转码拉回主节点本地执行见 prt.py。这不是故障而是保护机制主节点扛得住就无需处理。场景四Plex 升级后转码全部失效这是 PRT 用户最常踩的坑PMS 升级会覆盖主节点上的转码器包装脚本导致远程分发彻底失效。README 明确警告过这一点。解决办法是重新执行prt overwrite该命令会对比当前转码器与 PRT 安装的版本发现被覆盖就自动修复实现见 overwrite_transcoder_after_upgrade。场景五装完就报错无从下手直接运行prt check_config做一次全面体检实现见 check_config它会自动检查当前运行用户是否是plex能否打开 PMS 的Preferences.xml设置文件每个从机的 SSH 连通性Connect: OK/FAIL媒体库路径与转码临时目录的文件归属和权限User/Mode是否合规。它会用红黄绿颜色标出ERROR、WARN和OK照着提示改权限、换用户、修 SSH基本能解决 90% 的装完跑不起来问题。体检清单速查表最后送上一份可以打印出来的体检清单照着做一遍集群状态尽在掌握prt get_cluster_load确认所有节点在线、负载均衡prt sessions确认转码会话正确分发到从机检查/tmp/prt.log有没有No hosts found/Couldnt get load告警留意孤儿进程清理日志确认资源没有泄漏遇到 Plex 升级第一时间跑prt overwrite复杂故障先用prt check_config做基线排查掌握这四步集群体检流程你就能从看片卡了不知道怪谁进阶到一眼定位是主节点、从机还是配置的问题。Plex-Remote-Transcoder 的转码集群从此不再是一台黑盒。【免费下载链接】Plex-Remote-TranscoderA distributed transcoding backend for Plex项目地址: https://gitcode.com/gh_mirrors/pl/Plex-Remote-Transcoder创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考