为复杂云原生场景而生的 Apache DolphinScheduler 远程日志存储机制 | 附案例

首先，我会简单介绍一下Apache DolphinScheduler的架构，这对于我们理解远程日志存储的目的非常有帮助。我们可以参考Apache DolphinScheduler官方网站上的架构图。从上至下，最上面是用户交互的前端页面，即UI层。

紧接着的是API server层，它提供了restful的接口供外部请求服务。

下面是master server层，它的主要功能是切分工作流的DAG，并监控任务状态等。然后是worker server层，它主要执行任务，同时提供日志服务。

远程日志存储简单来说就是将任务执行的日志存储在远端存储上。远端存储的target可以是多种类型的，如AWS的S3，Google的Cloud Storage (GCS)，以及阿里云的对象存储OSS等。

在进入远程日志存储的细节之前，我们先看一下Apache DolphinScheduler目前的日志获取机制。

在Apache DolphinScheduler中，日志分为两部分：

一是组件日志，包括API server、master server、worker server等组件的日志；

二是任务日志，包括worker上和master上的任务日志。

任务日志的获取路径如下：用户在Apache DolphinScheduler前端点击查看或下载任务日志，请求首先发送给API server，然后API server通过worker server提供的netty接口读取日志。

那么我们为什么需要远程日志存储呢？首先，在一些特定场景，尤其是云原生场景下，我们可能需要将任务日志存储在远端。例如，在K8s环境下，如果没有挂载持久卷，worker pod重启后任务日志就会丢失。通过远程日志存储，我们可以将任务日志发送到远端存储，从而避免这个问题。

其次，远程日志存储支持K8S executor场景下的任务日志读取。在这种情况下，scheduler会在k8s集群上动态拉起一个worker pod执行任务，任务结束后，pod就会被销毁，此时任务日志需要通过远程日志存储进行收集。

第二，远程日志存储可以用作备份存储，我们可以将本地任务日志上传到远端存储，然后删除本地文件，避免占用过多的本地磁盘资源。

最后，远程日志存储提供了集中式存储，所有worker上的任务日志都可以发送到远程存储，进行统一查询和分析。

接下来，我们看一下远程日志存储的设计目标。我列出了三点：

首先是轻量级，因为Apache DolphinScheduler的日志模块在设计之初就考虑到了轻量级。我们知道，日志获取并不是大数据调度的核心模块或功能，所以我们不希望引入复杂的功能，增加Apache DolphinScheduler的复杂性。

第二是可扩展性，我们期望Apache DolphinScheduler的远程日志存储能够支持各种不同类型的远程存储。为此，我们采用插件式设计，使得增加新类型的远程存储变得方便。

第三是易用性，我们期望用户只需进行一些简单的配置，就可以轻松地使用远程日志存储。

接下来，我们会详细探讨远程日志存储的具体实现细节。

首先，我们来看日志写入。写入操作的时机是在任务完成后，无论任务执行成功，执行失败，还是发生异常，worker都会将日志发送到远程存储。这个过程是通过异步方式进行的，我们会用一个线程池异步地写入远程存储，避免日志写入影响任务执行流程。

还计划支持分段上传日志的功能，通过缓存机制，可以分段地将日志通过追加方式发送到远程存储。这种方式可以在一定程度上避免在写入日志时，worker出现问题导致无法发送完整的日志到远程存储的情况。

第二部分是日志读取，也就是如何从远程日志中读取日志。当用户在前端界面上下载或浏览任务日志时，API服务器会请求worker提供日志。如果涉及到远程日志，可能会有两条路径。

第一条路径是API服务器首先按照正常流程请求worker提供日志。worker会首先读取本地文件系统，如果本地文件中有任务日志，那么它就直接返回给API服务器。如果本地没有这个任务日志，worker会请求远程存储提供任务日志。

第二条路径是在worker不存在或者已销毁的情况下，worker返回给API服务器的日志是空的。在这种情况下，API服务器需要直接从远程存储获取任务日志。

这两条路径的设计初衷是尽可能减少Apache DolphinScheduler系统对外的IO消耗。我们的原则是，如果本地有日志，我们就直接返回本地的日志给用户。如果本地没有，我们才会一步一步地从外部请求。我们也计划支持从远程存储滚动读取任务日志的功能。这可以避免由于日志过大导致的内存溢出问题。

第三部分，我们要讨论的是任务日志的留存机制。我们之前提到过，我们的设计目标是保持轻量级，所以我们选择利用远端存储本身的日志留存机制，而没有将日志留存机制集成到Apache DolphinScheduler中。

比如，目前我们支持的S3、GCS、OSS这三种存储类型都有自己的日志留存机制，它们都支持设置对象的生命周期，例如，我们可以设置30天后自动删除任务日志，以此来实现我们的日志留存。

远端日志存储目前是以插件式设计的，目前支持S3、GCS、OSS作为远端存储。

如果你想贡献一个新的存储类型插件，其实非常简单，只需要实现两个函数，一个是sendRemoteLog，将日志发送到远程存储，另一个是getRemoteLog，从远程存储中获取日志。

接下来是关于如何使用远程日志存储的示例。

配置主要分为两部分，一部分是通用配置，无论你使用何种存储类型，都需要进行的配置。首先，有一个开关选项，可以开启或关闭远程日志功能。启用后，你可以设置目标类型，目前支持的有三种。

然后，你可以设置日志存放的基目录，以及我们之前提到的异步发送日志的线程池大小。

另一部分是特定于存储类型的配置。比如，如果你的目标是Google Cloud Storage，你需要设置GCS的凭证以完成鉴权，以及存储日志的bucket名称。

可以看出，用户只需要进行简单的配置，就能使用远程日志功能。在Apache DolphinScheduler的界面上，如果你开启了远程日志功能，你会看到一条消息，表明日志已经被发送到远程存储。同时，在GCS的文件列表中，你也可以找到对应的任务日志。

以上就是关于Apache DolphinScheduler远程日志存储机制的分享。

接下来，我会分享我在参与Apache DolphinScheduler开源社区的一些贡献经

历。我第一次提交PR是在去年的8月，是一个与文档相关的简单更新。

通过这次PR，我初步了解了贡献的流程，也学会了如何为开源社区做出贡献。到现在，我已经提交了40多个PR，主要内容包括远程日志存储机制，不同类型的存储插件，资源中心对GCS的支持，以及一些其他的改进，比如权限检查，单元测试，k8s任务类型等等。