抱歉,添麻烦了。
Dataflow 启动 VM 实例,然后在这些 VM 上启动代理。然后,这些代理执行您的代码(例如 ParDo,读取和写入)您的数据的繁重工作。
该错误表明作业失败,因为没有代理请求工作。结果,该服务将作业标记为失败,因为它没有取得任何进展,而且永远不会取得任何进展,因为没有任何代理来处理您的数据。
所以我们需要弄清楚代理启动过程中的哪些地方失败了。
首先要检查的是虚拟机是否真的启动了。当你运行你的工作时,你是否看到在你的项目中创建了任何虚拟机?虚拟机启动可能需要一两分钟,但它们应该会在运行器打印出消息“正在启动工作池设置”后不久出现。虚拟机应该被命名为
<PREFIX-OF-JOB-NAME>-<TIMESTAMP>-<random hexadecimal number>-<instance number>
仅使用作业名称的前缀来确保我们不超过 GCE 名称限制。
如果 VM 启动,接下来要做的是检查工作日志以查找指示启动代理时出现问题的错误。
访问日志的最简单方法是使用 UI。转到 Google Cloud Console,然后选择左侧框架中的 Dataflow 选项。您应该会看到一份工作列表。您可以点击相关工作。这应该向您显示您的工作图表。在右侧,您应该会看到一个“查看日志”按钮。请点击那个。然后,您应该会看到用于导航日志的 UI,并且可以查找错误。
第二个选项是在 GCS 上查找日志。寻找的位置是:
gs://PATH TO YOUR STAGING DIRECTORY/logs/JOB-ID/VM-ID/LOG-FILE
您可能会看到多个日志文件。我们最感兴趣的是以“start_java_worker”开头的那个。如果该日志文件不存在,则工作人员没有取得足够的进展来实际上传文件;否则上传日志文件可能存在权限问题。
在这种情况下,最好的办法是在其中一个 VM 被拆除之前尝试通过 ssh 连接到它。在作业失败并删除虚拟机之前,您应该有大约 15 分钟的时间。
登录虚拟机后,您可以找到所有登录信息
/var/log/dataflow/...
此时我们最关心的日志是:
/var/log/dataflow/taskrunner/harness/start_java_worker-SOME ID.log
如果启动在 VM 上运行的代码时出现问题,该日志应该会告诉我们。该日志和其他日志还应该告诉我们是否存在阻止工作人员上运行的代码能够访问 Dataflow 的权限问题。
如果您发现任何问题,请查看并告诉我们。