本文属于机器翻译版本。若本译文内容与英语原文存在差异，则一律以英文原文为准。
# 调试 HealthOmics 工作流程运行
HealthOmics 通过多个来源报告跑步的行为，每个来源都回答了不同的问题。对于失败的运行，请按以下顺序读取它们，而不是从日志开始：
1. 阅读运行记录，了解运行是否失败以及原因。
1. 如果任务失败、哪些任务失败以及在哪些实例类型上失败，请读取任务记录。在创建任何任务之前或每个任务完成之后，运行也可能会失败。
1. 阅读日志：任务报告内容的任务日志、任何任务之外的运行报告内容的运行日志以及引擎报告内容的引擎日志。
1. 阅读运行指标和运行清单日志，了解任务消耗的内容。
对于已完成但比预期慢或更昂贵的运行，请从以下位置开始 [比较同一工作流程的运行情况](#workflows-run-debug-compare)。
本主题中的资源和成本指南适用于私有工作流程，原因请参见 [为私有用户运行优化 HealthOmics 工作流程](workflows-run-optimize.md)。有关以下步骤使用的 API 操作和响应字段，请参阅 [获取跑步信息](getinfo-about-runs.md)。
在本主题的命令中，将以下值替换为你自己的值：
`{{run_id}}`
您正在调试的运行的 ID。
`{{duration}}`
那个窗户 **aws logs tail** 读取：相对时间，例如 `2h` 对于最近完成的运行，或时间戳，例如 `2026-03-26T22:00:00` 对于较旧的。
`{{run_uuid}}`
这个 `uuid` 该跑步记录的字段。
`{{task_id}}`
该次运行中失败的任务的 ID。
`{{workflow_id}}`
您要列出其运行次数的工作流程的 ID。
**Topics**
+ [诊断运行失败](#workflows-run-debug-failed)
+ [使用运行指标检查资源使用情况](#workflows-run-debug-metrics)
+ [比较同一工作流程的运行情况](#workflows-run-debug-compare)
+ [将调查结果转化为成本和规模的变化](#workflows-run-debug-cost)
## 诊断运行失败
**诊断运行失败**
1. 检索运行记录，然后读取 `status`， `failureReason`， `statusMessage`，以及 `logLocation`。保留响应：后续步骤使用它。 `logLocation` 给出运行日志的 ARN (`runLogStream`) 和引擎日志 (`engineLogStream`）。
```
aws omics get-run --id {{run_id}}
```
查一查的值 `failureReason` 在 [运行失败原因](workflows-run-errors.md)。如果 `status` 不是 `FAILED`，参见 [运行状态值](monitoring-runs.md#run-status-values) 取而代之。
以前发生过一些故障 HealthOmics 创建任何任务，或者在每个任务完成后创建，因此他们不会留下任何任务记录供接下来的三个步骤阅读。角色、输入、导入或导出失败就是其中之一；映像也是如此 HealthOmics 在创建任务之前拒绝 (ECR\_IMAGE\_NOT\_FOUND， ECR\_PERMISSION\_ERROR， ECR\_REPOSITORY\_NOT\_FOUND，或 INVALID\_ECR\_IMAGE\_URI）。对于其中任何一个，请跳到本过程后面的运行日志。对于映像故障， `statusMessage` 命名图像 URI，因此请继续 [私有工作流程的容器镜像](workflows-ecr.md) 和 [Amazon ECR 权限](permissions-ecr.md)。如果下一步确实返回了失败的任务，请改为阅读该任务。
1. 列出失败的任务。每个项目都包含任务的 `taskId`，下一步使用它，再加上它的名字，它的 `creationTime`，而且，一旦到达他们，它的实例类型， `startTime`，以及 `stopTime`。
```
aws omics list-run-tasks --id {{run_id}} --status FAILED
```
如果这不返回任何任务，则运行是步骤 1 中的一种情况：跳过接下来的两个步骤并阅读运行日志。
1. 对于每个失败的任务，检索其记录。它补充说 `failureReason`， `statusMessage`， `imageDetails`，以及 `logStream` 恢复到上一步的回归。 `logStream` 是下一步读取的日志流的 ARN，其后是该流的名称 `log-stream:` 在里面。
```
aws omics get-run-task --id {{run_id}} --task-id {{task_id}}
```
1. 阅读任务日志。解释失败的事件位于直播的末尾。
```
aws logs tail /aws/omics/WorkflowLog \
--log-stream-names run/{{run_id}}/task/{{task_id}} \
--since {{duration}}
```
设置 {{duration}} 在任务完成之前启动：该命令从那时起一直读取，其默认窗口是最近 10 分钟，因此先前完成的运行不会返回任何事件。有关日志组和每个直播的格式，请参阅 [登录 CloudWatch](monitoring-cloudwatch-logs.md#cloudwatch-logs)。
**注意**
要了解为什么任务可能根本没有日志，以及提高任务可调试性的方法，请参阅 [工作流任务疑难解答](workflow-run-tasks.md#debugging-tasks)。
1. 阅读跑步的另外两条日志中的任何一个都能回答带你来到这里的问题。两者都使用不同的数据流执行步骤 4 命令。
```
aws logs tail /aws/omics/WorkflowLog \
--log-stream-names run/{{run_id}} \
--since {{duration}}
```
运行没有失败的任务
阅读运行日志， `run/{{run_id}}`，如前面的命令所示。它会报告自己的运行进度，包括在没有任务的情况下失败的导入和导出步骤。有关其报告的内容，请参阅 [的日志类型 HealthOmics 工作流](monitoring-cloudwatch-logs.md#log-descriptions)。
任务失败了，其日志没有解释原因
阅读引擎日志， `run/{{run_id}}/engine`，它报告引擎对故障的影响，例如工作流定义中的位置。它的 ARN 已进入 `logLocation.engineLogStream` 从第 1 步开始；如果该字段不在响应中，则运行没有引擎日志。
要读取引擎名称位置的定义，请将其导出。以下命令返回运行所用定义的下载网址。
```
aws omics get-workflow --id {{workflow_id}} --export DEFINITION
```
在哪里继续取决于失败原因。以下列表涵盖了最常见的资源和容器故障。要了解所消耗的任务（它告诉您失败是否是规模问题），请参阅 [将调查结果转化为成本和规模的变化](#workflows-run-debug-cost)。
**无法启动容器错误， 无法启动容器大小错误，或 图像验证失败**
HealthOmics 创建了任务但无法启动其容器，因此该任务没有生成任何日志。从任务记录中获取图像 `imageDetails`，然后看看 [私有工作流程的容器镜像](workflows-ecr.md)。
**内存不足错误**
将任务的内存使用量与其分配进行比较，如中所述 [如何合理调整工作流程的计算和存储大小？](troubleshooting.md#troubleshooting-metrics-right-size)，使用其运行指标或运行清单日志中的统计数据，其中 [将调查结果转化为成本和规模的变化](#workflows-run-debug-cost) 定位。然后增加工作流程定义中的内存，并检查新值选择了哪种实例类型 [HealthOmics 任务的计算和内存要求](memory-and-compute-tasks.md)。
**TASK\_TIMED\_OUT 要么 RUN\_TIMED\_OUT**
确认超时到期后任务是否仍在运行。如果不是，则将其视为无响应而不是缓慢，然后看看 [无响应运行指南](workflows-run-errors.md#workflows-guidance-unresponsive-runs)。如果结束运行的限制来自某个运行组，请参阅 [使用 HealthOmics 跑步组](creating-run-groups.md)。
## 使用运行指标检查资源使用情况
运行指标涵盖仍在进行的运行，因此您可以在运行完成之前使用它们。哪个系列可供运行取决于其运行存储类型、暂存存储模式以及其任务是否需要加速器，因此请查看中的条件 [可用指标](monitoring-run-metrics.md#monitoring-run-metrics-available) 在得出缺少指标的结论之前。如果跑步根本没有系列，请检查其角色是否可以发布这些系列，如中所述 [为跑步启用指标](monitoring-run-metrics.md#monitoring-run-metrics-enabling)。有关查询语法和控制台过程，请参见 [正在查询 HealthOmics 运行指标](monitoring-run-metrics.md#monitoring-run-metrics-viewing)。
使用运行资源标签将每个查询限定为一次运行。 Per-task 指标还带有任务资源标签，该标签与任务记录及其日志相连。有关这两个标签，请参见 [通用 属性](monitoring-run-metrics.md#monitoring-run-metrics-common-attributes)。
**注意**
CloudWatch 对 PromQL 查询返回的时间序列数及其跨越的时间范围都设置了上限。对于每个任务的每个指标，每次运行都会产生至少一个序列，如果指标按方向或按GPU拆分，则会产生更多序列。对于包含许多任务的运行，请在查询本身中聚合序列，或筛选到一个任务、一个方向或一个 GPU。将长跑分成连续的窗口。有关当前限制，请参见 [PromQL 的限制和限制](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch-PromQL.html#CloudWatch-PromQL-Limits)。
## 比较同一工作流程的运行情况
当一次运行比同一工作流程的先前运行速度慢或更昂贵时，请逐个任务比较这两次运行。按名称而不是按任务 ID 对齐任务：检索两次运行的任务，按任务分组 `name`，然后比较每个名称的持续时间和峰值。读取每次运行的清单日志即可获得每项任务的时间安排以及峰值（条目报告这些任务的位置）； **ListRunTasks** 为你提供了仍在进行的跑步的时机，没有 `--status FAILED` 前面的过程使用的过滤器。
比较每个任务的两个跨度： `startTime` 到 `stopTime` 是任务的持续时间，以及 `creationTime` 到 `startTime` 是它等了多久才开始，这涵盖了其待处理和启动阶段 [任务状态值](workflow-run-tasks.md#task-status-values)。当每个任务的持续时间都匹配时，一次运行可能会比另一次运行慢得多，因为没有任务指标可以涵盖等待时间。
**注意**
一次运行中的多个任务可以共享一个名称，并且名称中的散点索引不一定在两次运行中涵盖相同的输入数据。比较共享同名任务（例如最长持续时间或最高峰值）的聚合情况，而不是逐个索引将它们配对。
要确定工作流程的正常运行情况，而不是比较两次运行，请聚合一组已完成的运行。Run Analyzer 可以这样做 `--batch` 模式，如中所述 [两次运行之间文件大小差异的影响](workflows-run-optimize.md#workflows-run-file-variance)。要自己收集运行次数，请筛选以下的响应 **ListRuns** 上 `workflowId`。该操作没有自己的工作流程过滤器，所以 **ListRuns** 在筛选器缩小运行范围之前，逐页浏览每一次已完成的运行。
```
aws omics list-runs --status COMPLETED \
--query "items[?workflowId=='{{workflow_id}}'].id"
```
一组运行而不是任何单次运行的分布显示了任务的分配是否符合数据的方差，以及看上去很慢的运行是否超出正常范围。
## 将调查结果转化为成本和规模的变化
所消耗的任务在运行清单日志中，其流是 `manifest/run/{{run_id}}/{{run_uuid}}`。 HealthOmics 运行完成后写入，所以设置 {{duration}} 以达到运行的停止时间而不是任务的停止时间。用同样的话来读 **aws logs tail** 像其他直播一样命令。有关其报告的统计数据，请参阅 [的日志类型 HealthOmics 工作流](monitoring-cloudwatch-logs.md#log-descriptions)。
清单任务条目报告任务预留的内容、其实例类型和持续时间。它会报告任务与这些任务一起使用的内容，但不报告每项任务的使用情况。如果条目未报告使用情况，或者报告的使用量少于任务的工作量可以考虑的范围，则根据任务的运行指标来衡量大小，原因如所示 [标注](monitoring-run-metrics.md#monitoring-run-metrics-callouts)。
三 HealthOmics 行为限制了更改保存的内容：
+ 任务的成本遵循以下实例类型 HealthOmics 选择您请求的资源，而不是任务使用的资源。请参阅[HealthOmics 任务的计算和内存要求](memory-and-compute-tasks.md)。
+ 任务收费有最低计费时长，因此缩短本已很短的任务不会节省任何费用。请参阅[运行状态对定价的影响](monitoring-runs.md#run-status-billing)。
+ 静态运行存储的大小是固定的，因此只有在减少到较小的支持大小时，减少才会改变账单。请参阅[静态运行存储](workflows-run-types.md#workflows-run-type-static)。
有关这些发现所依据的优化方法，请参见 [优化运行的方法](workflows-run-optimize.md#run-optimize-methods)。