排查 Dataflow 错误

使用集合让一切井井有条 根据您的偏好保存内容并对其进行分类。

如果您在使用 Dataflow 流水线或作业时遇到问题,本页面列出了您可能会看到的错误消息,并提供了有关如何修复每个错误的建议。

日志类型 dataflow.googleapis.com/worker-startupdataflow.googleapis.com/harness-startupdataflow.googleapis.com/kubelet 中的错误表明作业存在配置问题。还可能表示存在导致正常日志记录路径无法正常使用的条件。

您的流水线在处理数据时可能会抛出异常。其中一些错误是暂时性的,例如暂时无法访问外部服务。其中一些错误是永久性的,例如因输入数据损坏或无法解析引发的错误,或者计算期间的 NULL 指针。

Dataflow 会处理任意软件包中的元素,并会在针对该软件包中的任何元素抛出错误时重试整个软件包。以批量模式运行时,含有失败项的软件包将重试四次。单个软件包失败四次后,流水线会完全失败。以流式模式运行时,含有失败项的软件包会无限地重试,这可能会导致您的流水线永久性停滞。

Dataflow 监控界面会报告用户代码(例如 DoFn 实例)中的异常。如果使用 BlockingDataflowPipelineRunner 运行流水线,您还可在控制台或终端窗口中看到输出的错误消息。

考虑通过添加异常处理程序来防止代码中的错误。例如,如果您因为某些元素未能通过在 ParDo 中执行的一些自定义输入验证而要舍弃它们,请在 ParDo 中使用 try/catch 块,以便处理异常并记录和舍弃这些元素。对于生产工作负载,请实现未处理的消息模式。要跟踪错误计数,请使用聚合转换

缺失日志文件

如果您没有看到作业的任何日志,请从所有 Cloud Logging 日志路由器接收器中移除任何包含 resource.type="dataflow_step" 的排除项过滤条件。

转到日志路由器

如需详细了解如何移除日志排除项,请参阅移除排除项指南。

流水线错误

以下部分介绍了您可能会遇到的常见流水线错误,以及解决或排查这些错误的步骤。

某些 Cloud API 需要启用

尝试运行 Dataflow 作业时,会发生以下错误:

Some Cloud APIs need to be enabled for your project in order for Cloud Dataflow to run this job.

出现此问题的原因是项目中未启用某些必需的 API。

要解决此问题并运行 Dataflow 作业,请在项目中启用以下 Google Cloud API:

  • Compute Engine API (Compute Engine)
  • Cloud Logging API
  • Cloud Storage
  • Cloud Storage JSON API
  • BigQuery API
  • Pub/Sub
  • Datastore API

如需了解详细说明,请参阅有关启用 Google Cloud API 的“使用入门”部分

错误请求

当您运行 Dataflow 作业时,Cloud Monitoring 日志显示如下所示的一系列警告:

Unable to update setup work item STEP_ID error: generic::invalid_argument: Http(400) Bad Request
Update range task returned 'invalid argument'. Assuming lost lease for work with id LEASE_ID
with expiration time: TIMESTAMP, now: TIMESTAMP. Full status: generic::invalid_argument: Http(400) Bad Request

如果工作器状态信息因处理延迟而过时或不同步,则会出现错误请求警告。通常情况下,尽管出现错误请求警告,Dataflow 作业仍会成功。如果出现这种情况,请忽略此类警告。

无法在不同位置执行读写操作

运行 Dataflow 作业时,您可能会在日志文件中看到以下错误:

message:Cannot read and write in different locations: source: SOURCE_REGION, destination: DESTINATION_REGION,reason:invalid

当来源和目标位于不同的区域时,会发生此错误。当暂存位置和目标位置位于不同区域时,也可能发生此错误。例如,如果作业从 Pub/Sub 读取数据,将数据写入 Cloud Storage temp 存储桶,然后再写入 BigQuery 表,则 Cloud Storage temp 存储桶和 BigQuery 表必须位于同一区域。

多区域和单区域被视为不同的位置,即使单区域位置在多区域位置范围内也是如此。例如,us (multiple regions in the United States)us-central1 是不同的区域。

要解决此问题,请将目标位置、来源位置和暂存位置设置在同一区域。Cloud Storage 存储桶位置无法更改,因此您可能需要在正确的区域中创建新的 Cloud Storage 存储桶。

无此类对象

运行 Dataflow 作业时,您可能会在日志文件中看到以下错误:

..., 'server': 'UploadServer', 'status': '404'}>, <content <No such object:...

如果某些正在运行的 Dataflow 作业使用同一个 temp_location 来暂存流水线运行时创建的临时作业文件,则通常会发生这些错误。如果多个并发作业共用同一个 temp_location,则这些作业可能会步入彼此的临时数据,并且可能会出现竞态条件。为避免这种情况,建议您为每个作业使用唯一的 temp_location

DEADLINE_EXCEEDED 或服务器无响应

运行作业时,您可能会遇到 RPC 超时异常或以下错误之一:

DEADLINE_EXCEEDED

或:

Server Unresponsive

这些错误通常是由于以下某种原因造成的:

  • 用于您的作业的 VPC 网络可能缺少防火墙规则。防火墙规则需要允许您在流水线选项中指定的 VPC 网络的虚拟机之间的所有 TCP 流量。如需了解详情,请参阅指定网络和子网

  • 您的作业受 shuffle 限制

如需解决此问题,请进行以下一项或多项更改。

    • 如果作业未使用基于服务的 Shuffle,请设置 --experiments=shuffle_mode=service 以切换到使用基于服务的 Dataflow Shuffle。如需了解详情和可用性,请参阅 Dataflow Shuffle
    • 添加更多工作器。在运行流水线时尝试设置具有更高值的 --numWorkers
    • 增加工作器挂接的磁盘的大小。在运行流水线时尝试设置具有更高值的 --diskSizeGb
    • 使用支持 SSD 的永久性磁盘。在运行流水线时尝试设置 --workerDiskType="compute.googleapis.com/projects/<project>/zones/<zone>/diskTypes/pd-ssd"
    {Java}

    • 如果作业未使用基于服务的 Shuffle,请设置 --experiments=shuffle_mode=service 以切换到使用基于服务的 Dataflow Shuffle。如需了解详情和可用性,请参阅 Dataflow Shuffle
    • 添加更多工作器。在运行流水线时尝试设置具有更高值的 --num_workers
    • 增加工作器挂接的磁盘的大小。在运行流水线时尝试设置具有更高值的 --disk_size_gb
    • 使用支持 SSD 的永久性磁盘。在运行流水线时尝试设置 --worker_disk_type="compute.googleapis.com/projects/<project>/zones/<zone>/diskTypes/pd-ssd"
    {Python}

    • 如果作业未使用基于服务的 Shuffle,请设置 --experiments=shuffle_mode=service 以切换到使用基于服务的 Dataflow Shuffle。如需了解详情和可用性,请参阅 Dataflow Shuffle
    • 添加更多工作器。在运行流水线时尝试设置具有更高值的 --num_workers
    • 增加工作器挂接的磁盘的大小。在运行流水线时尝试设置具有更高值的 --disk_size_gb
    • 使用支持 SSD 的永久性磁盘。在运行流水线时尝试设置 --disk_type="compute.googleapis.com/projects/<project>/zones/<zone>/diskTypes/pd-ssd"
    {Go}

用户代码中的编码错误、IO 异常或意外行为

Apache Beam SDK 和 Dataflow 工作器依赖于常见的第三方组件。而这些组件又会导入其他依赖项。版本冲突可能导致服务出现意外行为。如果您在代码中使用任何这类的软件包,请注意有些库不向前兼容。您可能需要固定到执行过程的范围内列出的版本。SDK 和工作器依赖项包含依赖项及其所需版本的列表。

运行 LookupEffectiveGuestPolicies 时出错

运行 Dataflow 作业时,您可能会在日志文件中看到以下错误:

OSConfigAgent Error policies.go:49: Error running LookupEffectiveGuestPolicies:
error calling LookupEffectiveGuestPolicies: code: "Unauthenticated",
message: "Request is missing required authentication credential.
Expected OAuth 2 access token, login cookie or other valid authentication credential.

如果为整个项目启用了 OS Configuration Management,则会发生此错误。

要解决此问题,请停用应用于整个项目的虚拟机管理器政策。如果无法为整个项目停用虚拟机管理器政策,您可以放心地忽略此错误并将其从日志监控工具中过滤掉。

资源池已耗尽

创建 Google Cloud 资源时,您可能会看到耗尽的资源池发生以下错误:

ERROR: ZONE_RESOURCE_POOL_EXHAUSTED

特定可用区中的特定资源的临时缺乏情况会发生此错误。

要解决此问题,您可以等待一段时间,也可以在另一个可用区创建相同的资源。我们建议的最佳实践是,将资源分布到多个可用区和区域,以应对服务中断情况。

Java 运行时环境检测到严重错误

工作器启动期间,系统会发生以下错误:

A fatal error has been detected by the Java Runtime Environment

如果流水线使用 Java 原生接口 (JNI) 运行非 Java 代码,并且该代码或 JNI 绑定包含错误,则系统会发生此错误。

检测到热键 ...

发生以下错误:

A hot key HOT_KEY_NAME was detected in...

如果您的数据包含热键,则会发生这些错误。热键是具有很多元素并对流水线性能造成不利影响的键。这些键会限制 Dataflow 并行处理元素的能力,从而增加执行时间。

如需在流水线中检测到热键时将简单易懂的键输出到日志,请使用热键流水线选项

要解决此问题,请检查您的数据是否均匀分布。如果某个键具有异常多的值,请考虑执行以下操作流程:

如需在 Dataflow 监控界面中查看热键,请参阅排查批量作业中的 Straggler 问题

Data Catalog 中的表规范无效

使用 Dataflow SQL 创建 Dataflow SQL 作业时,作业可能会失败,并且日志文件中会显示以下错误:

Invalid table specification in Data Catalog: Could not resolve table in Data Catalog

如果 Dataflow 服务帐号无权访问 Data Catalog API,则会发生此错误。

为解决此问题,请在您用于编写和运行查询的 Google Cloud 项目启用 Data Catalog API

或者,将 roles/datacatalog.viewer 角色分配给 Dataflow 服务帐号

作业图过大

您的作业可能会失败,并显示以下错误:

The job graph is too large. Please try again with a smaller job graph,
or split your job into two or more smaller jobs.

如果作业图大小超过 10 MB,则会出现此错误。流水线中的某些情况可能会导致作业图超出此上限。常见情况包括:

  • 包含大量内存数据的 Create 转换。
  • 大型 DoFn 实例(进行序列化处理后传输给远程工作器)。
  • 作为匿名内部类实例的 DoFn,该实例(可能无意中)引入了大量要序列化的数据。
  • 在枚举大型列表的编程循环中使用有向无环图 (DAG)。

为了避免这些情况,请考虑重新构造您的流水线。

密钥提交过大

运行流式作业时,工作器日志文件中会显示以下错误:

KeyCommitTooLargeException

如果在不使用 Combine 转换的情况下将大量数据分组,或者如果通过单个输入元素生成大量数据,则在流式传输场景中会发生此错误。

为了降低发生此错误的可能性,请使用以下策略:

  • 确保处理单个元素不会导致输出或状态修改超出限制。
  • 如果按一个键分组了多个元素,请考虑增加键空间以减少按键分组的元素。
  • 如果某个键的元素在短时间内以高频率发出,这可能会导致在时间范围内产生该键的大量事件(以 GB 为单位)。请重新编写流水线以检测此类键,并仅发出指明相应键在时间范围中频繁出现的输出。
  • 务必将次线性空间 Combine 转换用于交换和关联操作。如果一个组合器不能减少空间,请不要使用它。例如,没有必要使用只是将字符串连接起来的字符串组合器。

Request Entity Too Large

提交作业时,控制台或终端窗口中显示以下错误之一:

413 Request Entity Too Large
The size of serialized JSON representation of the pipeline exceeds the allowable limit
Failed to create a workflow job: Invalid JSON payload received
Failed to create a workflow job: Request payload exceeds the allowable limit

如果您在提交作业时遇到有关 JSON 载荷的错误,则流水线的 JSON 表示法会超过 20 MB 的请求大小上限。

作业的大小与流水线的 JSON 表示法明确关联。流水线越大,意味着请求越大。Dataflow 目前的请求大小上限为 20 MB。

如需估算流水线的 JSON 请求大小,请使用以下选项运行您的流水线:

  • --dataflowJobFile=PATH_TO_OUTPUT_FILE {Java}

  • --dataflow_job_file=PATH_TO_OUTPUT_FILE {Python}

  • Go 不支持以 JSON 格式输出作业。{Go}

此命令会将作业的 JSON 表示写入文件中。您最好根据序列化文件的大小来估算请求大小。由于请求中包含一些其他信息,实际大小将会略大一些。

流水线中的某些情况可能会导致 JSON 表示法超出限额。常见情况包括:

  • 包含大量内存数据的 Create 转换。
  • 大型 DoFn 实例(进行序列化处理后传输给远程工作器)。
  • 作为匿名内部类实例的 DoFn,该实例(可能无意中)引入了大量要序列化的数据。

为了避免这些情况,请考虑重新构造您的流水线。

SDK 流水线选项或暂存文件列表超出大小限制

运行流水线时,会发生以下错误:

SDK pipeline options or staging file list exceeds size limit.
Please keep their length under 256K Bytes each and 512K Bytes in total.

如果由于超出 Google Compute Engine 元数据限制而无法启动流水线,则会出现此错误。这些限制无法更改。 Dataflow 为流水线选项使用 Compute Engine 元数据。Compute Engine 自定义元数据限制中记录了此限制。

暂存 JAR 文件过多可能会导致 JSON 表示法超出限制。

如需估算流水线的 JSON 请求大小,请使用以下选项运行您的流水线:

  • --dataflowJobFile=PATH_TO_OUTPUT_FILE {Java}

  • --dataflow_job_file=PATH_TO_OUTPUT_FILE {Python}

  • Go 不支持以 JSON 格式输出作业。{Go}

此命令的输出文件的大小必须小于 256 KB。错误消息中的 512 KB 是指上述输出文件和 Compute Engine 虚拟机实例的自定义元数据选项的总大小。

您可以通过项目中正在运行的 Dataflow 作业来粗略估计虚拟机实例的自定义元数据选项。选择任何正在运行的 Dataflow 作业,获取虚拟机实例,然后进入该虚拟机的 Compute Engine 虚拟机实例详情页面,以检查自定义元数据部分。自定义元数据和文件的总长度应小于 512 KB。无法准确估计失败的作业,因为虚拟机不会为失败的作业启动。

如果您的 JAR 列表达到了 256 KB 的限制,请进行检查并减少任何不必要的 JAR 文件。如果该列表仍然太大,请尝试使用超级 JAR 执行 Dataflow 作业。本文档的 Cloud Functions 函数部分介绍了有关如何创建和使用超级 JAR 的示例

重排键过大

工作器日志文件中出现以下错误:

Shuffle key too large

在应用相应编码器后,如果发送到特定 (Co-)GroupByKey 的序列化键太大,则会出现此错误。Dataflow 对序列化 shuffle 键有限制。

如需解决此问题,请减小键的大小或使用更节省空间的编码器。

BoundedSource 对象总数 ... 大于允许的限额

使用 Java 运行作业时,可能会发生以下错误之一:

Total number of BoundedSource objects generated by splitIntoBundles() operation is larger than the allowable limit

或:

Total size of the BoundedSource objects generated by splitIntoBundles() operation is larger than the allowable limit
  • 如果您通过 TextIOAvroIO 或其他一些基于文件的来源读取大量文件,则可能会出现此错误。特定的上限取决于来源的细节,但一个流水线中大约有数万个文件。例如,在 AvroIO.Read 中嵌入架构可允许较少的文件。 {Java}

    如果您为流水线创建了自定义数据源,并且来源的 splitIntoBundles 方法返回了一个序列化后占用的空间超过 20 MB 的 BoundedSource 对象列表,则也会发生此错误。

    自定义来源的 splitIntoBundles() 操作生成的 BoundedSource 对象总大小的允许上限为 20 MB。

    如需解决此限制,请修改自定义 BoundedSource 子类,以使生成的 BoundedSource 对象的总大小小于 20 MB 上限。例如,来源最初可能会生成较少的分块,并依赖动态工作负载再平衡来按需进一步拆分输入。

名称错误

使用 Dataflow 服务执行流水线时,会发生以下错误:

NameError

本地执行时(例如使用 DirectRunner 执行时),不会发生此错误。

如果 DoFn 使用的全局命名空间中的值在 Dataflow 工作器上不可用,则会出现此错误。

默认情况下,在 Dataflow 作业序列化期间,系统不会保存在主会话中定义的全局导入项、函数和变量。

如需解决此问题,请使用以下方法之一。如果 DoFn 是在主文件中定义的,并且在全局命名空间中引用了导入项和函数,请将 --save_main_session 流水线选项设置为 True。此更改会将全局命名空间的状态 pickle 和加载到 Dataflow 工作器上。

如果全局命名空间中的对象无法进行 pickle,则会出现 pickling 错误。如果此错误与 Python 发行版中应提供的模块有关,请在使用该模块的位置本地导入该模块。

“处理卡在/操作运行在步骤 <step_id> 中至少 <time_interval> 且未输出,或在 <stack_trace> 处进入完成状态”

如果 Dataflow 执行 DoFn 的时间超过 <time_interval> 中指定的时间且未返回,则会显示此消息。

此行为有两个可能的原因:

  • 您的 DoFn 代码运行很慢,或在等待一些缓慢的外部操作完成。
  • 您的 DoFn 代码可能被卡住、出现死锁或运行异常缓慢,难以完成处理。

要确定是哪种情况,请展开 Cloud Monitoring 日志条目以查看堆栈轨迹。查找表明 DoFn 代码卡住或出现其他问题的消息。如果不存在消息,则可能是 DoFn 代码的执行速度有问题。请考虑使用 Cloud Profiler 或其他工具来调查代码的性能。

如果您的流水线是在 Java 虚拟机上构建的(使用 Java 或 Scala),您可以进一步调查卡住代码的原因;按照以下步骤对整个 JVM(不仅仅是卡住的线程)进行完整的线程转储:

  1. 记下日志条目中的工作器名称。
  2. 在 Google Cloud 控制台的 Compute Engine 部分中,通过您记下的工作器名称找到 Compute Engine 实例。
  3. 通过 SSH 登录到具有该名称的实例。
  4. 运行以下命令:

    curl http://localhost:8081/threadz
    

Pub/Sub 配额错误

从 Pub/Sub 运行流式流水线时,会出现以下错误:

429 (rateLimitExceeded)

或:

Request was throttled due to user QPS limit being reached

如果您的项目没有足够的 Pub/Sub 配额,则会出现这些错误。

要了解您的项目是否配额不足,请按照以下步骤检查客户端错误:

  1. 前往 Google Cloud Console
  2. 在左侧菜单中,选择 API 和服务
  3. 搜索框中,搜索 Cloud Pub/Sub
  4. 点击用量标签页。
  5. 检查响应代码并查找 (4xx) 客户端错误代码。

Pub/Sub 无法确定积压

从 Pub/Sub 运行流式流水线时,会出现以下错误:

Dataflow is unable to determine the backlog for Pub/Sub subscription

当 Dataflow 流水线从 Pub/Sub 拉取数据时,Dataflow 需要反复向 Pub/Sub 请求有关订阅的信息积压量以及最早的未确认消息存在时长的信息。此信息是自动扩缩和使流水线水印前进所必需的。有时,Dataflow 会因内部系统问题而无法从 Pub/Sub 中检索此信息,在这种情况下,流水线可能无法正确自动扩缩,并且水印可能无法前进。如果问题仍然存在,请与客户服务团队联系。

如需了解详情,请参阅使用 Cloud Pub/Sub 进行流式传输

组织的政策禁止请求

运行流水线时,会发生以下错误:

Error trying to get gs://BUCKET_NAME/FOLDER/FILE:
{"code":403,"errors":[{"domain":"global","message":"Request is prohibited by organization's policy","reason":"forbidden"}],
"message":"Request is prohibited by organization's policy"}

如果 Cloud Storage 存储桶位于服务边界外部,则会出现此错误。

如需解决此问题,请创建出站规则以允许访问服务边界外的存储桶。

暂存的软件包...无法访问

过去成功的作业可能会失败,并显示以下错误:

Staged package...is inaccessible

要解决此问题,请执行以下操作:

  • 验证用于暂存的 Cloud Storage 存储桶是否没有导致暂存软件包被删除的 TTL 设置
  • 验证您的 Dataflow 项目的控制器服务帐号是否有权访问用于暂存的 Cloud Storage 存储桶。权限不足可能是由以下原因造成的:

    • 用于暂存的 Cloud Storage 存储桶位于其他项目中。
    • 用于暂存的 Cloud Storage 存储桶已从精细访问权限迁移到统一存储桶级访问权限。 由于 IAM 政策与 ACL 政策存在不一致,因此使暂存存储桶改用统一存储桶级访问权限会禁止对 Cloud Storage 资源使用 ACL,其中包括 Dataflow 项目的控制器服务帐号对暂存存储桶拥有的权限。

如需了解详情,请参阅跨 Google Cloud 项目访问 Cloud Storage 存储桶

工作项失败 4 次

当作业失败时,会发生以下错误:

a work item failed 4 times

如果单个操作导致工作器代码失败四次,则会出现此错误。Dataflow 使作业失败,并且系统会显示此消息。

您无法配置此失败阈值。如需了解详情,请参阅流水线错误和异常处理

如需解决此问题,请在作业的 Cloud Monitoring 日志中查看这四次失败情况。在工作器日志中查找显示异常或错误的错误级别严重级别日志条目。异常或错误应至少出现四次。如果日志仅包含与访问外部资源(例如 MongoDB)相关的一般超时错误,请验证工作器服务帐号有权访问资源的子网。

轮询结果文件中超时

当作业失败时,会出现以下情况:

Timeout in polling result file:  PATH. Possible causes are:
1. Your launch takes too long time to finish. Please check the logs on stackdriver.
2. Service account SERVICE_ACCOUNT may not have enough permissions to pull
container image IMAGE_PATH or create new objects in PATH.
3. Transient errors occurred, please try again.

该问题通常与通过 requirements.txt 文件安装 Python 依赖项的方式相关。Apache Beam 暂存器从 PyPi 下载所有依赖项的来源,包括传递依赖项的来源。然后,在 pip 下载命令期间,作为 apache-beam 依赖项的一些 Python 软件包发生显式的 wheel 编译。这可能会导致 requirements.txt 文件发生超时问题。

这是 Apache Arrow 团队的一个已知问题建议的解决方法是直接在 Dockerfile 中安装 apache-beam。这样就不会发生 requirements.txt 文件的超时。

容器映像错误

以下部分介绍了使用自定义容器时您可能会遇到的常见错误,以及解决或排查这些错误的步骤。这些错误通常前面带有以下消息:

Unable to pull container image due to error: DETAILED_ERROR_MESSAGE

自定义容器流水线失败,或者启动工作器的速度较慢

已知问题可能会导致 Dataflow 将工作器标记为无响应,并且在工作器使用下载时间很长的大型自定义容器(约 10 GB)时重启工作器。这个问题可能会导致流水线启动缓慢,或者在一些极端情况下会导致工作器完全无法启动。

如需确认此已知问题导致了问题,请在 dataflow.googleapis.com/kubelet 中查找显示多次尝试拉取容器失败的工作器日志,并确认 kubelet 未在工作器上启动。例如,拉取所有映像后,日志可能包含 Pulling image <URL>,但没有相应的 Successfully pulled image <URL>Started Start kubelet

如需解决此问题,请使用 --experiments=disable_worker_container_image_prepull 流水线选项运行流水线。

同步 pod 时出错 ...“StartContainer”失败

工作器启动期间,系统会发生以下错误:

Error syncing pod POD_ID, skipping: [failed to "StartContainer" for CONTAINER_NAME with CrashLoopBackOff: "back-off 5m0s restarting failed container=CONTAINER_NAME pod=POD_NAME].

pod 是 Dataflow 工作器上运行的位于同一位置的 Docker 容器组。当 pod 中的一个 Docker 容器无法启动时,会发生此错误。如果故障不可恢复,则 Dataflow 工作器将无法启动,并且 Dataflow 批量作业最终会失败,并显示如下错误:

The Dataflow job appears to be stuck because no worker activity has been seen in the last 1h.

某个容器在启动期间连续崩溃时通常会出现此错误。如需了解根本原因,请查找在失败前立即捕获的日志。如需分析日志,请使用日志浏览器

在日志浏览器中,将日志文件限制为发生容器启动错误的工作器发出的日志条目。如需限制日志条目,请完成以下步骤:

  1. 在日志浏览器中,找到 Error syncing pod 日志条目。
  2. 如需查看与日志条目关联的标签,请展开日志条目。
  3. 点击与 resource_name 关联的标签,然后点击显示匹配条目

突出显示了限制日志文件的步骤的“日志浏览器”页面。

在日志浏览器中,Dataflow 日志被整理到多个日志流中。Error syncing pod 消息在名为 kubelet 的日志中发出。但是,来自故障容器的日志可能位于不同的日志流中。每个容器都有一个名称。请使用下表确定哪个日志流可能包含与故障容器相关的日志。

容器名称 日志名称
sdk、sdk0、sdk1、sdk-0-0 等 docker
harness harness、harness-startup
python、java-batch、java-streaming worker-startup、worker
artifact 工件

查询日志浏览器时,请确保查询在查询构建器界面中包含相关日志名称,或者对日志名称没有限制。

包含相关日志名称的日志浏览器查询。

选择相关日志后,查询结果可能如以下示例所示:

resource.type="dataflow_step"
resource.labels.job_id="2022-06-29_08_02_54-JOB_ID"
labels."compute.googleapis.com/resource_name"="testpipeline-jenkins-0629-DATE-cyhg-harness-8crw"
logName=("projects/apache-beam-testing/logs/dataflow.googleapis.com%2Fdocker"
OR
"projects/apache-beam-testing/logs/dataflow.googleapis.com%2Fworker-startup"
OR
"projects/apache-beam-testing/logs/dataflow.googleapis.com%2Fworker")

由于报告容器故障症状的日志有时报告为 INFO,因此请在分析中包含 INFO 日志。

容器故障的典型原因包括:

  1. Python 流水线在运行时安装了其他依赖项,并且安装失败。您可能会看到 pip install failed with error 等错误。出现此问题的原因可能是要求存在冲突,或者网络配置受限而导致 Dataflow 工作器无法通过互联网从公共代码库拉取外部依赖项。
  2. 由于内存不足错误,工作器在流水线运行过程中失败。您可能会看到如下错误:

    • java.lang.OutOfMemoryError: Java heap space
    • Shutting down JVM after 8 consecutive periods of measured GC thrashing. Memory is used/total/max = 24453/42043/42043 MB, GC last/max = 58.97/99.89 %, #pushbacks=82, gc thrashing=true. Heap dump not written.

    如需调试内存不足问题,请参阅排查 Dataflow 内存不足错误

  3. Dataflow 无法拉取容器映像。如需了解详情,请参阅映像拉取请求因错误而失败

在确定导致容器失败的错误后,请尝试解决该错误,然后重新提交流水线。

映像拉取请求失败,发生错误

在工作器启动期间,工作器或作业日志中显示以下错误之一:

Image pull request failed with error
pull access denied for IMAGE_NAME
manifest for IMAGE_NAME not found: manifest unknown: Failed to fetch
Get IMAGE_NAME: Service Unavailable

如果工作器因无法拉取 Docker 容器映像而无法启动,则会发生这些错误。此问题发生在以下情况:

  • 自定义 SDK 容器映像网址不正确
  • 工作器缺少凭据或对远程映像的网络访问权限

要解决此问题,请执行以下操作:

  • 如果您为作业使用自定义容器映像,请验证映像网址是否正确、是否具有有效的标记或摘要,以及 Dataflow 工作器是否可以访问该映像。
  • 通过从未经身份验证的机器运行 docker pull $image,验证是否可以在本地拉取公共映像。

对于私有映像或私有工作器:

  • Dataflow 仅支持 Container Registry 上托管的私有容器映像。如果您使用 Container Registry 托管容器映像,则默认 Google Cloud 服务帐号可以访问同一项目中的映像。如果您使用的映像所在的项目与用于运行 Google Cloud 作业的项目不同,请务必为默认 Google Cloud 服务帐号配置访问权限控制
  • 如果使用共享 Virtual Private Cloud (VPC),请确保工作器可以访问自定义容器代码库主机。
  • 使用 ssh 连接到正在运行的作业工作器虚拟机,并运行 docker pull $image 以直接确认工作器已正确配置。

如果工作器由于错误在行中多次失败,并且在作业上启动了工作,则作业可能会因如下所示的错误而失败:

Job appears to be stuck.

如果您在作业运行时移除了对映像的访问权限(通过移除映像本身、撤消 Dataflow 工作器服务帐号凭据或撤销映像的互联网访问权限),则 Dataflow 仅会记录错误而不执行操作,导致作业失败。Dataflow 还会避免使长时间运行的流式流水线失败,以免丢失流水线状态。

其他错误可能是由代码库配额问题或服务中断造成的。 如果您遇到拉取公共映像时超出 Docker Hub 配额或常规第三方代码库服务中断问题,请考虑使用 Container Registry 作为映像代码库。

SystemError:未知操作码

您的 Python 自定义容器流水线可能会在作业提交后立即失败,并出现以下错误:

SystemError: unknown opcode

此外,堆栈轨迹可能包括

apache_beam/internal/pickler.py

要解决此问题,请验证您在本地使用的 Python 版本是否与容器映像中的版本匹配(主要版本和次要版本均匹配)。补丁程序版本不同(如 3.6.7 与 3.6.8)不会导致兼容性问题,但次要版本不同(例如 3.6.8 与 3.8.2)可能导致流水线失败。

工作器错误

以下部分介绍了您可能会遇到的常见工作器错误,以及解决或排查这些错误的步骤。

Java 工作器自动化测试框架对 Python DoFn 的调用失败并显示错误

如果 Java 工作器自动化测试框架对 Python DoFn 的调用失败,则会显示相关错误消息。

如需调查错误,请展开 Cloud Monitoring 错误日志条目并查看错误消息和回溯。它会显示失败的代码,以便您根据需要进行更正。如果您确定这是 Apache Beam 或 Dataflow 中的 bug,请报告此 bug

EOFError:编组数据太短

工作器日志中会显示以下错误:

EOFError: marshal data too short

当 Python 流水线工作器的磁盘空间不足时,有时会发生此错误。

要解决此问题,请参阅设备上已没有剩余空间

设备上已没有剩余空间

当作业的磁盘空间用尽时,工作器日志中可能会出现以下错误:

No space left on device

此错误可能是由以下某种原因造成的:

  • 工作器永久性存储的可用空间用尽,这可能是由于以下某个原因造成的:
    • 作业在运行时下载大型依赖项
    • 作业使用大型自定义容器
    • 作业将大量临时数据写入本地磁盘
  • 使用 Dataflow Shuffle 时,Dataflow 会设置较低的默认磁盘大小。因此,从基于工作器的 shuffle 迁移的作业可能会发生此错误。
  • 工作器启动磁盘已填满,因为它每秒记录的条目超过 50 个。

要解决此问题,请按以下问题排查步骤操作:

如需查看与单个工作器关联的磁盘资源,请查找与作业关联的工作器虚拟机的虚拟机实例详情。部分磁盘空间供操作系统、二进制文件、日志和容器使用。

要增加永久性磁盘或启动磁盘空间,请调整磁盘大小流水线选项

使用 Cloud Monitoring 跟踪工作器虚拟机实例上的磁盘可用空间使用情况。如需了解如何进行此设置,请参阅从 Monitoring 代理接收工作器虚拟机指标

通过在工作器虚拟机实例上查看串行端口输出并查找如下消息来查找启动磁盘空间问题:

Failed to open system journal: No space left on device

如果您有大量工作器虚拟机实例,则可以创建一个脚本,以便同时在所有这些实例上运行 gcloud compute instances get-serial-port-output 并查看该命令的输出。

如需了解详情,请参阅永久性磁盘资源

Python 流水线在工作器处于非活跃状态一小时后失败

在具有大量 CPU 核心的工作器机器上将 Python 版 Apache Beam SDK 与 Dataflow Runner V2 结合使用时,如果流水线在启动时执行 Python 依赖项安装,则 Dataflow 作业可能需要很长时间才能启动。

如果 Runner V2 在运行 Python 流水线的同时,按工作器上的每个 CPU 核心启动一个容器,就会出现此问题。在具有许多核心的工作器上,同时启动容器和初始化可能会导致资源耗尽。

要解决此问题,请预构建 Python 容器。此步骤可以缩短虚拟机启动时间和横向自动扩缩性能。如需使用此实验性功能,请在项目上启用 Cloud Build API,并使用以下参数提交流水线:

‑‑prebuild_sdk_container_engine=cloud_build

如需了解详情,请参阅 Dataflow Runner V2

或者,使用预安装了所有依赖项的自定义容器映像

如需解决此问题,您可以使用 ‑‑experiments=disable_runner_v2 流水线选项运行流水线,或升级到 Beam SDK 2.35.0 或更高版本,并使用 ‑‑dataflow_service_options=use_sibling_sdk_workers 流水线选项运行流水线。

在可用区中启动工作器池无法启动任何所需的工作器

发生以下错误:

Startup of the worker pool in zone ZONE_NAME failed to bring up any of the desired NUMBER workers.
The project quota may have been exceeded or access control policies may be preventing the operation;
review the Cloud Logging 'VM Instance' log for diagnostics.

发生此错误是由以下某种原因造成的:

  • 已超出创建 Dataflow 工作器所依赖的其中一个 Compute Engine 配额。
  • 您的组织已设置限制,以禁止虚拟机实例创建过程的某些方面,例如使用帐号或以可用区为目标。

要解决此问题,请按以下问题排查步骤操作:

查看虚拟机实例日志

  1. 前往 Cloud Logging 查看器 {: target="console" class="button button-primary"}
  2. 已审核的资源下拉列表中,选择虚拟机实例
  3. 所有日志下拉列表中,选择 compute.googleapis.com/activity_log
  4. 扫描日志以查找与虚拟机实例创建失败相关的任何条目。

检查 Compute Engine 配额的使用情况

  1. 在本地机器命令行上或在 Cloud Shell 中,运行以下命令,以查看与目标可用区的 Dataflow 配额相比 Compute Engine 资源的使用情况:

    gcloud compute regions describe [REGION]

  2. 查看以下资源的结果,了解是否有任何资源超出配额:

    • CPUS
    • DISKS_TOTAL_GB
    • IN_USE_ADDRESSES
    • INSTANCE_GROUPS
    • INSTANCES
    • REGIONAL_INSTANCE_GROUP_MANAGERS
  3. 如果需要,请申请更改配额

查看组织政策限制

  1. 进入“组织政策”页面 {: target="console" class="button button-primary"}
  2. 查看可能会限制以下行为的限制:限制为您使用的帐号(默认为 Dataflow 服务帐号)或在您设为目标的可用区中创建虚拟机实例。

工作器与服务失去了联系

当 Dataflow 作业失败时,会发生以下错误:

Root cause: The worker lost contact with the service.

在某些情况下,当工作器内存不足或交换空间时,会发生此错误。在这种情况下,如需解决此问题,首先请尝试再次运行该作业。如果该作业仍然失败,并且发生相同的错误,请尝试使用内存和磁盘空间更大的工作器。例如,添加以下流水线启动选项:

--worker_machine_type=m1-ultramem-40 --disk_size_gb=500

请注意,更改工作器类型可能会影响结算费用。 如需了解详情,请参阅排查 Dataflow 内存不足错误

如果您的数据包含热键,也可能会发生此错误。在这种情况下,某些工作器的 CPU 利用率在作业的大部分持续时间内都较高,但工作器的数量并未达到允许的最大值。 如需详细了解热键和可能的解决方案,请参阅编写 Dataflow 流水线时将可伸缩性考虑在内

如需了解此问题的其他解决方案,请参阅检测到热键...

Streaming Engine 错误

以下部分介绍了您可能会遇到的常见 Streaming Engine 错误,以及解决或排查这些错误的步骤。

## BigQuery 连接器错误

以下部分介绍了您可能会遇到的常见 BigQuery 连接器错误,以及解决或排查这些错误的步骤。

quotaExceeded

使用 BigQuery 连接器通过流式插入将数据写入 BigQuery 时,写入吞吐量低于预期,并且可能会发生以下错误:

quotaExceeded

此吞吐量可能由于您的流水线超出可用的 BigQuery 流式插入配额。如果是这种情况,来自 BigQuery 的配额相关错误消息会显示在 Dataflow 工作器日志中(查找 quotaExceeded 错误)。

如果出现 quotaExceeded 错误,请执行以下操作解决此问题:

  • 如果使用 Java 版 Apache Beam SDK,请设置 BigQuery 接收器选项 ignoreInsertIds()
  • 如果使用 Python 版 Apache Beam SDK,请使用 ignore_insert_ids 选项。

这些设置让您可以为每个项目每秒处理 1 GB 的 BigQuery 流式插入吞吐量。如需详细了解与自动删除重复消息相关的注意事项,请参阅 BigQuery 文档。如需将 BigQuery 流式插入配额增加到 1 GB/秒以上,您需要通过 Google Cloud 控制台提交请求

如果您在工作器日志中没有看到与配额相关的错误,则问题在于,默认捆绑或批处理相关参数无法提供流水线的扩缩能力。使用流式插入功能将数据写入 BigQuery 时,您可以调整多个 Dataflow BigQuery 连接器相关的配置以实现预期的性能。例如,对于 Java 版 Apache Beam SDK,调整 numStreamingKeys 以匹配最大工作器数量,并考虑增加 insertBundleParallelism 以将 BigQuery 连接器配置为使用更多并行线程来将数据写入 BigQuery。

如需获取 Java 版 Apache Beam SDK 中提供的配置,请参阅 BigQueryPipelineOptions {:.external};如需获取 Python 版 Apache Beam SDK 中提供的配置,请参阅 WriteToBigQuery 转换

rateLimitExceeded

使用 BigQuery 连接器时,会发生以下错误:

rateLimitExceeded

如果 BigQuery 在短时间内发送的 API 请求过多,则会发生此错误。BigQuery 存在需遵循的短期配额限制。Dataflow 流水线可能会暂时超出此类配额。无论何时发生这种情况,从 Dataflow 流水线到 BigQuery 的 API 请求都可能会失败,这可能会导致工作器日志出现 rateLimitExceeded 错误。

Dataflow 会重试此类失败,因此您可以放心地忽略这些错误。如果您确信流水线由于 rateLimitExceeded 错误而受到影响,请与 Google Cloud 支持团队联系。

建议

如需查看有关 Dataflow 数据分析生成的建议的指导,请参阅数据分析