기계 번역으로 제공되는 번역입니다. 제공된 번역과 원본 영어의 내용이 상충하는 경우에는 영어 버전이 우선합니다.
# 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`. 응답을 유지합니다. 이후 단계에서는 이를 사용합니다.는 실행 로그(`runLogStream`) 및 엔진 로그()의 ARNs을 `logLocation` 제공합니다`engineLogStream`.
```
aws omics get-run --id {{run_id}}
```
에서의 값을 조회`failureReason`합니다[실행 실패 이유](workflows-run-errors.md). `status`이 아닌 경우 [실행 상태 값](monitoring-runs.md#run-status-values) 대신 단원을 `FAILED`참조하십시오.
일부 실패는 HealthOmics가 작업을 생성하기 전에 또는 모든 작업이 완료된 후에 발생하므로 다음 세 단계를 읽을 수 있도록 작업 레코드를 남기지 않습니다. 역할, 입력, 가져오기 또는 내보내기 실패가 하나이므로 HealthOmics가 작업을 생성하기 전에 거부하는 이미지입니다(ECR\_IMAGE\_NOT\_FOUND, ECR\_PERMISSION\_ERROR, ECR\_REPOSITORY\_NOT\_FOUND 또는 INVALID\_ECR\_IMAGE\_URI). 이 중 하나에 대해이 절차의 뒷부분에서 실행 로그로 건너뜁니다. 이미지 실패의 경우 이미지 URI의 `statusMessage` 이름을 지정하므로 [프라이빗 워크플로용 컨테이너 이미지](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. 실패한 각 작업에 대해 레코드를 검색합니다. 이전 단계에서 반환`logStream`한 항목에 `failureReason`, `statusMessage`, `imageDetails`,를 추가합니다. `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}}
```
태스크가 시작되기 전에 시작하도록 {{기간을}} 설정합니다. 명령은 그때부터 지금까지 읽으며 기본 기간은 지난 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은 1단계`logLocation.engineLogStream`부터에 있습니다. 해당 필드가 응답에 없으면 실행에 엔진 로그가 없는 것입니다.
엔진 이름 위치의 정의를 읽으려면 내보냅니다. 다음 명령은 실행에서 사용한 정의에 대한 다운로드 URL을 반환합니다.
```
aws omics get-workflow --id {{workflow_id}} --export DEFINITION
```
계속할 위치는 실패 이유에 따라 달라집니다. 다음 목록은 가장 일반적인 리소스 및 컨테이너 장애를 다룹니다. 실패가 크기 조정 문제인지 여부를 알려주는 작업이 소비한 내용은 섹션을 참조하세요[조사 결과를 비용 및 크기 변경으로 전환](#workflows-run-debug-cost).
**CANNOT\_START\_CONTAINER\_ERROR, CANNOT\_START\_CONTAINER\_SIZE\_ERROR 또는 IMAGE\_VERIFICATION\_FAILURE**
HealthOmics는 작업을 생성했으며 컨테이너를 시작할 수 없어 작업이 로그를 생성하지 않았습니다. 작업 레코드의에서 이미지를 가져온 `imageDetails`다음 단원을 참조하십시오[프라이빗 워크플로용 컨테이너 이미지](workflows-ecr.md).
**OUT\_OF\_MEMORY\_ERROR**
에 설명된 대로 실행 지표 또는가 [조사 결과를 비용 및 크기 변경으로 전환](#workflows-run-debug-cost) 찾는 실행 매니페스트 로그의 통계를 [워크플로의 컴퓨팅 및 스토리지 크기를 올바르게 조정하려면 어떻게 해야 하나요?](troubleshooting.md#troubleshooting-metrics-right-size)사용하여 작업의 메모리 사용량을 할당과 비교합니다. 그런 다음 워크플로 정의에서 메모리를 높이고에서 새 값이 선택하는 인스턴스 유형을 확인합니다[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).
실행 리소스 레이블을 사용하여 모든 쿼리의 범위를 한 번의 실행으로 지정합니다. 작업별 지표에는 시리즈를 작업 레코드 및 로그에 조인하는 작업 리소스 레이블도 포함됩니다. 두 레이블은 단원을 참조하십시오[공통 속성](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는 실행이 완료된 후 이를 기록하므로 작업 대신 실행 중지 시간에 도달하도록 {{기간을}} 설정합니다. 다른 스트림과 동일한 **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).