- 필수 기능
- 시작하기
- Glossary
- 표준 속성
- Guides
- Agent
- 통합
- 개방형텔레메트리
- 개발자
- API
- Datadog Mobile App
- CoScreen
- Cloudcraft
- 앱 내
- 서비스 관리
- 인프라스트럭처
- 애플리케이션 성능
- APM
- Continuous Profiler
- 스팬 시각화
- 데이터 스트림 모니터링
- 데이터 작업 모니터링
- 디지털 경험
- 소프트웨어 제공
- 보안
- AI Observability
- 로그 관리
- 관리
이 가이드에서는 CI Visibility에서 파이프라인 실행을 프로그래밍 방식으로 설정하는 방법과 CI Visibility가 지원하는 파이프라인 실행 유형을 정의합니다.
이 가이드는 공개 CI Visibility 파이프라인 API를 사용하여 만든 파이프라인에 적용됩니다. 다른 CI 공급자와의 통합은 다를 수 있습니다.
파이프라인 실행은 APM 분산 트레이스와 유사하게 트레이스로 모델링되며, 여기서 스팬은 파이프라인의 여러 부분의 실행을 나타냅니다. 파이프라인 실행을 표현하기 위한 CI Visibility 데이터 모델은 네 가지 레벨로 구성됩니다:
| 레벨 이름 | 설명 |
|---|---|
| 파이프라인 (필수) | 다른 모든 레벨을 하위 레벨로 포함하는 최상위 레벨 루트 스팬입니다. 파이프라인의 전체 실행을 처음부터 끝까지 나타냅니다. 이 레벨은 일부 CI 공곱자에서 build 또는 workflow로 칭하기도 합니다. |
| 스테이지 | 사용자 정의 이름으로 작업을 그룹화하는 역할을 합니다. 일부 CI 공급자에는 이 레벨이 없습니다. |
| 작업 | 명령이 실행되는 가장 작은 작업 단위입니다. 이 레벨의 모든 작업은 단일 노드에서 수행되어야 합니다. |
| 단계 | 일부 CI 공급자에서 이 레벨은 셸 스크립트 또는 작업 내에서 실행되는 액션을 나타냅니다. |
파이프라인, 스테이지, 작업 또는 단계가 완료되면 실행 데이터가 Datadog으로 전송됩니다. Pipeline Visibility를 설정하려면 지원되는 CI 공급자 목록을 참조하세요. CI 공급자 또는 워크플로가 지원되지 않는 경우, 공용 API 엔드포인트를 사용하여 파이프라인 실행을 CI Visibility로 전송할 수 있습니다.
레벨의 모든 파이프라인 실행에는 고유 식별자가 필요합니다. 예를 들어, 파이프라인과 작업은 동일한 고유 ID를 가질 수 있지만 두 개의 파이프라인은 가질 수 없습니다.
타임스탬프가 다른 ID를 반복적으로 전송하면 사용자 인터페이스가 원하지 않는 동작을 나타낼 수 있습니다. 예를 들어, 프레임 그래프에 다른 파이프라인 실행의 스팬 태그가 표시될 수 있습니다. 동일한 타임 스탬프의 ID가 중복 전송되면 하나의 파이프라인 실행만 저장되고 나머지는 무시됩니다.
파이프라인 실행의 일반적인 실행은 아래 그림과 같은 흐름을 따릅니다:
제공자에 따라 일부 레벨이 누락될 수 있습니다. 예를 들어 단계가 존재하지 않을 수 있으며, 작업이 병렬 또는 순차적으로 실행되거나 두 가지를 조합하여 실행될 수 있습니다.
각 구성 요소가 완료되면 실행을 나타내는 데 필요한 모든 데이터가 포함된 페이로드를 Datadog으로 전송해야 합니다. Datadog은 이 데이터를 처리하고 파이프라인 이벤트로 저장한 후 CI Visibility에 표시합니다. 파이프라인 실행은 Datadog으로 보내기 전에 종료되어야 합니다.
파이프라인의 전체 재시도는 다른 파이프라인 고유 ID를 가져야 합니다.
공용 API 엔드포인트에서 previous_attempt 필드를 입력해 이전 재시도에 연결할 수 있습니다. 재시도는 Datadog에서 별도의 파이프라인 실행으로 취급되며, 시작 및 종료 시간은 해당 재시도만 포함해야 합니다.
파이프라인 내에서 작업의 하위 집합을 다시 시도할 때는 새 파이프라인 고유 ID를 사용하여 새 파이프라인 이벤트를 보내야 합니다. 새 작업의 페이로드는 새 파이프라인 고유 ID에 연결되어야 합니다. 이전 재시도에 연결하려면 previous_attempt 필드를 추가하세요.
부분 재시도도 별도의 파이프라인으로 취급됩니다. 시작 및 종료 시간에 원래 재시도 시간이 포함되지 않아야 합니다. 부분 재시도의 경우 이전 시도에서 실행된 작업에 대한 페이로드를 보내지 마세요. 또한 부분 재시도에서 partial_retry 필드를 true로 설정하여 실행 시간을 계산할 때 집계에서 제외할 수 있습니다.
예를 들어, P라는 이름의 파이프라인에는 J1, J2, J3의 세 가지 작업이 순차적으로 실행됩니다. 첫 번째 P의 실행에서는 J1 및 J2만 실행되고 J2는 실패합니다.
따라서 총 3개의 페이로드를 전송해야 합니다:
J1에 대한 작업 페이로드(ID J1_1 및 파이프라인 ID P_1 포함).J2에 대한 작업 페이로드(ID J2_1 및 파이프라인 ID P_1 포함).P에 대한 파이프라인 페이로드 (ID P_1 포함).J2에서 시작된 파이프라인의 부분적 재시도에서 나머지 작업이 모두 성공했다고 가정해 봅시다.
페이로드 3개를 추가로 전송해야 합니다:
J2에 대한 작업 페이로드(ID J2_2 및 파이프라인 ID P_2 포함).J3에 대한 작업 페이로드(ID J3_1 및 파이프라인 ID P_2 포함).P에 대한 파이프라인 페이로드 (ID P_2 포함).ID의 실제 값은 중요하지 않습니다. 중요한 것은 위에 명시된 대로 파이프라인 실행에 따라 올바르게 수정되었는지 여부입니다.
수동 개입이 필요하여 파이프라인이 무기한 차단된 경우, 파이프라인이 차단된 상태에 도달하는 즉시 파이프라인 이벤트 페이로드를 전송해야 합니다. 파이프라인 상태는 blocked로 설정되어야 합니다.
나머지 파이프라인 데이터는 다른 파이프라인 고유 ID를 사용하여 별도의 페이로드로 전송해야 합니다. 두 번째 파이프라인에서는 is_resumed를 true로 설정하여 차단된 파이프라인에서 실행이 재개되었음을 알릴 수 있습니다.
파이프라인이 다른 파이프라인의 하위 파이프라인으로 트리거되는 경우 parent_pipeline 필드는 상위 파이프라인의 세부 정보로 채워져야 합니다.
파이프라인이 수동으로 트리거되는 경우 is_manual 필드를 true로 설정해야 합니다.
모든 페이로드에는 파이프라인 실행을 트리거한 커밋의 Git 정보가 포함되어야 합니다. 공개 API 엔드포인트 사양에 명시된 대로 리포지토리 URL, 커밋 SHA 및 작성자 이메일을 제공해야 합니다.
추가 유용한 문서, 링크 및 기사:
| |
