Ray VM 集群日志持久化完整指南日志目录、采集工具与日志生命周期管理【免费下载链接】rayRay is an AI compute engine. Ray consists of a core distributed runtime and a set of AI Libraries for accelerating ML workloads.项目地址: https://gitcode.com/gh_mirrors/ra/ray导读在 VM虚拟机/物理机集群上运行 Ray 时日志是排查应用与集群故障的第一手依据——例如节点异常终止时你可能需要系统日志来定位根因。但 Ray 本身不提供日志数据的原生存储方案日志生命周期需要用户自行管理。本指南基于 Ray 官方文档 doc/source/cluster/vms/user-guides/logging.md系统讲解 Ray 日志在 VM 集群上的落盘目录结构、日志轮转配置、主流日志处理工具选型以及采集 → 解析 → 投递的完整日志收集流水线帮助你构建一套可落地的 VM 集群日志持久化方案。为什么 VM 集群上的日志需要持久化Ray 默认将日志以文件形式写入每个节点文件系统的/tmp/ray/session_*/logs目录这些日志同时包含应用日志与系统日志。问题的关键在于日志目录位于tmp文件系统下机器一旦重启临时目录通常会被清理日志文件可能随之丢失当集群或部分节点被停止时未及时处理的日志将无法再被检索。因此在 VM 集群场景下日志持久化不是一个可选项而是保证可观测性与故障可排查性的必要环节。Kubernetes 场景KubeRay下的日志持久化与此类似但本文聚焦 VM 部署。开始采集前建议先熟悉 Ray 的 日志目录结构与日志文件说明 以及 日志轮转配置。Ray 日志目录与日志文件类型默认日志目录与 session 目录结构默认情况下Ray 将日志写入/tmp/ray/session_*/logs。每个新的 Ray session 都会在临时目录下新建一个 session 文件夹并将最新 session 软链到/tmp/ray/session_latest├── tmp/ray │ ├── session_latest │ │ ├── logs │ │ ├── ... │ ├── session_2023-05-14_21-19-58_128000_45083 │ │ ├── logs │ │ ├── ... │ ├── session_2023-05-15_21-54-19_361265_24281 │ ├── ...需要说明的几点在 Linux 与 macOS 上Ray 默认使用/tmp/ray作为临时目录如需修改临时目录及日志目录可在调用ray start或ray.init()时显式指定Ray 会在机器重启时清理临时目录因此 session 停止后日志可能丢失——这正是需要引入采集与持久化的原因Ray 官方不保证日志目录的向后兼容性升级版本后日志文件布局可能变化。日志文件清单应用日志与系统日志Ray 日志目录中的文件大致分为应用日志与系统组件日志两大类。注意.out文件来自 stdout/stderr.err文件来自 stderr。应用日志日志文件说明job-driver-[submission_id].log通过 Ray Jobs API 提交的任务Job驱动进程的 stdoutworker-[worker_id]-[job_id]-[pid].[out\|err]Ray 驱动与 worker 的 Python/Java 部分Task 与 Actor 的所有 stdout/stderr 都会被流式写入这些文件。其中job_id是驱动driver的 Job ID系统/组件日志日志文件说明dashboard.[log\|out\|err]Ray Dashboard 日志。.log来自 dashboard logger.out/.err是其 stdout/stderr通常为空仅当 dashboard 异常崩溃时才有内容dashboard_agent.[log\|out\|err]每个 Ray 节点都有一个 dashboard agent含义同上dashboard_[module_name].[log\|out\|err]Dashboard 各子进程按模块划分的日志gcs_server.[out\|err]GCS Server管理集群元数据的无状态服务仅存在于 head 节点io-worker-[worker_id]-[pid].[out\|err]IO worker 日志。Ray 1.3 默认创建 IO worker 用于将对象溢出spill/恢复restore到外部存储log_monitor.[log\|out\|err]Log Monitor 负责将日志流式传输到 drivermonitor.[log\|out\|err]Autoscaler 的日志python-core-driver-[worker_id]_[pid].logRay 驱动由 C core 与 Python/Java 前端组成此文件来自 C 部分python-core-worker-[worker_id]_[pid].logRay worker 的 C core 部分日志raylet.[out\|err]Raylet 的日志runtime_env_agent.[log\|out\|err]每个节点上管理 Runtime Environment 创建、删除与缓存的 agent 日志。实际pip install的安装日志见下方runtime_env_setup-[job_id].logruntime_env_setup-ray_client_server_[port].log通过 Ray Client 连接时安装 Runtime Environment 的日志runtime_env_setup-[job_id].log为 Task、Actor 或 Job 安装 Runtime Environment 的日志仅在安装了 runtime env 时出现值得注意系统日志中也可能包含应用相关信息例如runtime_env_setup-[job_id].log可能包含应用环境与依赖的信息。日志轮转配置为避免日志文件无限增长耗尽磁盘Ray 支持日志轮转log rotation。需要注意并非所有组件都支持轮转——Raylet、Python worker 与 Java worker 的日志不参与轮转。默认轮转参数默认单文件最大 512 MBmaxBytes默认最多保留 5 个备份文件backupCount备份文件带索引后缀例如raylet.out.1。以上默认值可在 python/ray/_common/ray_constants.py 中确认LOGGING_ROTATE_BYTES 512 * 1024 * 1024 # 512MB. LOGGING_ROTATE_BACKUP_COUNT 5 # 5 Backup files at max.通过环境变量调整轮转在启动 Ray 之前设置环境变量即可覆盖默认值RAY_ROTATION_MAX_BYTES1024; ray start --head # 单文件上限 1KB RAY_ROTATION_BACKUP_COUNT1; ray start --head # 备份数 1单个日志文件含其备份的总大小上界为RAY_ROTATION_MAX_BYTES * RAY_ROTATION_BACKUP_COUNT RAY_ROTATION_MAX_BYTES。源码实现印证Python 侧日志轮转参数在 python/ray/_private/node.py 中从环境变量读取并校验max_bytes 0、backup_count 0C 侧RayLog 的轮转参数解析位于 src/ray/util/logging.cc其中RAY_ROTATION_MAX_BYTES与RAY_ROTATION_BACKUP_COUNT仅在__APPLE__或__linux__平台生效backup_count需大于 0 才被接受否则回退为默认值 1。日志处理工具选型Ray 社区常见的做法是选用成熟的开源日志处理工具来完成采集、解析与投递。官方文档明确提及的候选工具包括Vector高性能、统一的日志/指标采集与转发管道支持丰富的数据源与 sinkFluentBit轻量级、插件化的日志采集器适合在资源受限的节点上作为 agent 运行Fluentd功能全面的日志采集与聚合器插件生态庞大FilebeatElastic 官方轻量采集器天然对接 Elasticsearch/LogstashPromtailGrafana Loki 的官方日志采集客户端适合与 Loki 检索栈搭配。选型时可以从以下维度权衡节点资源占用sidecar/daemon 形式、解析能力是否支持多行、JSON 结构化、投递目标Elasticsearch、Loki、S3、Kafka 等、以及团队已有的可观测性栈。日志采集三步流程选定工具后对 VM 集群上的每个 Ray 节点执行以下三个步骤即可完成日志收集Ingest采集源将每个节点上 Ray 集群的日志文件作为采集源。由于日志位于/tmp/ray/session_*/logssession 目录动态变化建议以/tmp/ray/session_latest/logs作为稳定入口或在采集器配置中监听通配符路径并处理目录切换注意多 session 并存时避免重复采集。Parse and transform解析与转换对采集到的原始日志做解析与清洗。Ray 提供结构化日志能力可以显著简化这一环节应用侧通过ray.LoggingConfig(encodingJSON, ...)或RAY_LOGGING_CONFIG_ENCODINGJSON让应用日志输出 JSON 结构化格式日志中自动携带job_id、worker_id、node_id、actor_id、task_id等 Ray 特有字段详见 结构化日志配置系统侧设置RAY_BACKEND_LOG_JSON1可使后端系统日志如 Job Supervisor、Raylet、GCS以 JSON 格式输出若选择从 driver 的 stdout/stderr 集中采集可配合RAY_DISABLE_WORKER_LOG_PREFIX1去掉每行日志的前缀避免破坏 JSON 等结构化格式如 newline-delimited JSON。Ship投递将转换后的日志投递到日志存储或管理系统中例如 Elasticsearch、Loki、S3、Kafka或集中式日志平台从而在集群停止后仍可检索历史日志。结合 Ray 日志机制设计采集方案为了让采集方案更贴合 Ray 的实际行为还需了解以下与日志相关的默认机制Worker 日志默认回流 driverTask 与 Actor 的 stdout/stderr 默认会流式传输到 Ray driver便于在单点聚合分布式应用日志大规模场景下可用ray.init(log_to_driverFalse)关闭避免 driver 成为瓶颈。日志去重Ray 默认对跨进程重复出现的日志做去重同一模式的消息会聚合最多 5 秒后批量输出并以[repeated Nx across cluster]标注通过RAY_DEDUP_LOGS0可关闭。若采集端解析的是结构化日志建议同时关闭前缀与去重否则去重注解会破坏行式 JSON 格式。日志文件与流式输出的关系无论是否回流 driverRay 都会将 stdout/stderr 写入 worker 日志文件采集工具既可以直接以文件为源推荐路径稳定且无前缀污染也可以采集 driver 的 stdout。小结VM 集群上的 Ray 日志持久化本质上是理解默认落盘结构 合理轮转 工具化采集投递的组合日志默认位于/tmp/ray/session_*/logs临时目录、重启即失可通过环境变量调整轮转策略再借助 Vector / FluentBit / Fluentd / Filebeat / Promtail 等开源工具按采集 → 解析优先使用结构化日志→ 投递三步把日志送达到集中存储。配合 Ray 日志配置指南 中的轮转、结构化日志与去重开关即可构建一套可持续、可检索的 VM 集群日志持久化方案。【免费下载链接】rayRay is an AI compute engine. Ray consists of a core distributed runtime and a set of AI Libraries for accelerating ML workloads.项目地址: https://gitcode.com/gh_mirrors/ra/ray创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考