지원되는 GitLab 버전:
GitLab.com (SaaS)
GitLab >= 14.1 (자체 호스팅)
datadog_ci_integration 기능 플래그를 활성화한 GitLab >= 13.7.0 (자체 호스팅)
Partial pipelines: 부분 재시도 및 다운스트림 파이프라인 실행 표시
Manual steps: 수동으로 트리거된 파이프라인 표시
Queue time: 파이프라인 작업이 처리되기 전 대기열에서 대기하는 시간 표시
Logs correlation: 파이프라인 스팬을 로그와 상호 연관 시키고 작업 로그 수집 활성화
Infrastructure metric correlation: 자체 호스팅 GitLab 러너를 위해 파이프라인을 인프라스트럭처 호스트 메트릭과 상호 연관 시킴
Custom pre-defined tags: 생성된 모든 파이프라인, 단계 및 작업 스팬에 커스텀 태그 설정
Custom tags and metrics at runtime: 런타임에 커스텀 태그 및 메트릭 설정
Parameters: 커스텀 env 또는 service 파라미터 설정
Pipeline failure reasons: 오류 메시지에서 파이프라인 오류 원인 파악
계측하려는 각 프로젝트 또는 그룹에 대해 Settings > Integrations > Datadog으로 이동하여 프로젝트 또는 그룹에서 통합을 설정합니다.
또는 Admin > Settings > Integrations > Datadog으로 이동하여 GitLab 인스턴스 레벨에서 통합을 활성화할 수도 있습니다.
datadog_ci_integration 기능 플래그를 활성화하여 통합을 설정합니다. 설치 유형에 따라 GitLab의 RailsRunner를 사용하여 다음 명령 중 하나를 실행합니다:
Omnibus 설치
sudo gitlab-rails runner "Feature.enable(:datadog_ci_integration)"*소스 설치로부터
sudo -u git -H bundle exec rails runner \
-e production \
"Feature.enable(:datadog_ci_integration)"Kubernetes 설치
kubectl exec -it <task-runner-pod-name>-- \
/srv/gitlab/bin/rails runner "Feature.enable(:datadog_ci_integration)"그런 다음 계측할 각 프로젝트에 대해 Settings > Integrations > Datadog으로 이동하여 프로젝트에 대한 통합을 설정합니다.
통합 구성 설정을 입력합니다:
datadoghq.comgitlab-cienv 태그)을 지정합니다. 이를 통해 GitLab 인스턴스 그룹을 구분할 수 있습니다 (예: 스테이징 또는 프로덕션).nonekey:value 형식의 태그를 한 줄에 하나씩 입력합니다.Test settings 버튼을 사용하여 (프로젝트에서 통합을 설정하는 경우에만 사용 가능) 통합을 테스트할 수 있습니다.성공적으로 완료되면 Save changes를 클릭하여 통합 설정을 완료합니다.
네이티브 Datadog 통합을 사용하는 대신 웹후크를 사용하여 파이프라인 데이터를 Datadog으로 전송할 수 있습니다.
리포지토리 (또는 GitLab 인스턴스 설정)에서 Settings > Webhooks로 이동하여 새 웹후크를 추가합니다:
https://webhook-intake./api/v2/webhook/?dd-api-key=<API_KEY> 여기서 <API_KEY>는 Datadog API 키입니다.Job events 및 Pipeline events를 선택합니다.커스텀 env 또는 service 파라미터를 설정하려면 웹후크 URL에 쿼리 파라미터를 추가합니다:&env=<YOUR_ENV>&service=<YOUR_SERVICE_NAME>
통합으로 생성된 모든 파이프라인과 작업 스팬에 커스텀 태그를 설정하려면 URL에 쉼표로 구분된 key:value 쌍을 사용하여 URL 인코딩된 쿼리 파라미터 tags를 추가합니다 키:값 쌍에 쉼표가 포함되어 있으면 따옴표로 묶어야 합니다. 예를 들어, key1:value1,"key2: value with , comma",key3:value3를 추가하려면 Webhook URL에 다음 문자열을 추가해야 합니다:
?tags=key1%3Avalue1%2C%22key2%3A+value+with+%2C+comma%22%2Ckey3%3Avalue3
통합이 성공적으로 설정된 후 파이프라인이 완료되면 Pipelines와 Pipeline Executions 페이지가 데이터로 채워집니다.
참고: 파이프라인 페이지에는 각 리포지토리의 기본 브랜치에 대한 데이터만 표시됩니다.
Pipeline Executions 페이지의 검색창에서 아래 필터를 사용할 수 있습니다:
Downstream Pipelinetrue,falseManually Triggeredtrue,falsePartial Pipelineretry,paused,resumed이러한 필터는 페이지 왼쪽의 패싯 패널을 통해 적용할 수도 있습니다.
자체 호스팅 GitLab 러너를 사용하는 경우 실행 중인 인프라스트럭처와 작업을 상호 연관시킬 수 있습니다. 이 기능이 작동하려면 GitLab 러너에 host:<hostname> 양식의 태그가 있어야 합니다. 새 러너를 등록하는 동안 태그를 추가할 수 있습니다. 기존 러너의 경우, 러너의 config.toml를 업데이트하여 태그를 추가하거나, Settings > CI/CD > Runners로 이동해 적절한 러너를 편집하여 UI를 통해 태그를 추가하세요.
이러한 단계가 끝나면 CI Visibility가 각 작업에 호스트 이름을 추가합니다. 메트릭을 보려면 트레이스 보기에서 작업 스팬을 클릭하세요. 드로어에 호스트 메트릭이 포함된 Infrastructure라는 이름의 새 탭이 나타납니다.
오류 메시지는 GitLab 버전 15.2.0 이상에서 지원됩니다.
실패한 GitLab 파이프라인 실행의 경우 특정 파이프라인 실행 내 Errors 탭 아래에 있는 각 오류에 GitLab의 오류 유형과 관련된 메시지가 표시됩니다.
각 오류 유형과 관련된 메시지 및 도메인은 아래 표를 참조하세요. 나열되지 않은 오류 유형은 Job failed의 오류 메시지와 unknown의 오류 도메인으로 이어집니다.
| 오류 유형 | 오류 메시지 | 오류 도메인 |
|---|---|---|
| unknown_failure | 알 수 없는 이유로 인한 실패 | 알 수 없음 |
| config_error | CI/CD 설정 파일 오류로 인한 실패 | 사용자 |
| external_validation_failure | 외부 파이프라인 유효성 검사로 인한 실패 | 알 수 없음 |
| user_not_verified | 사용자가 확인되지 않아 파이프라인 실패 | 사용자 |
| activity_limit_exceeded | 파이프라인 활동 한도 초과 | 프로바이더 |
| size_limit_exceeded | 파이프라인 크기 제한 초과 | 프로바이더 |
| job_activity_limit_exceeded | 파이프라인 작업 활동 한도 초과 | 프로바이더 |
| deployments_limit_exceeded | 파이프라인 배포 제한 초과 | 프로바이더 |
| project_deleted | 해당 파이프라인과 관련된 프로젝트가 삭제됨 | 프로바이더 |
| api_failure | API 실패 | 프로바이더 |
| stuck_or_timeout_failure | 파이프라인이 멈췄거나 시간 초과됨 | 알 수 없음 |
| runner_system_failure | 러너 시스템 실패로 인한 실패 | 프로바이더 |
| missing_dependency_failure | 종속성 누락으로 인한 실패 | 알 수 없음 |
| runner_unsupported | 지원되지 않는 러너로 인한 실패 | 프로바이더 |
| stale_schedule | 오래된 스케줄로 인한 실패 | 프로바이더 |
| job_execution_timeout | 작업 시간 초과로 인한 실패 | 알 수 없음 |
| archived_failure | 보관된 실패 | 프로바이더 |
| unmet_prerequisites | 전제조건이 충족되지 않아 실패 | 알 수 없음 |
| scheduler_failure | 스케줄 실패로 인한 실패 | 프로바이더 |
| data_integrity_failure | 데이터 무결성으로 인한 실패 | 프로바이더 |
| forward_deployment_failure | 디플로이먼트 실패 | 알 수 없음 |
| user_blocked | 사용자에 의해 차단 | 사용자 |
| ci_quota_exceeded | CI 할당량 초과 | 프로바이더 |
| pipeline_loop_detected | 파이프라인 루프가 감지됨 | 사용자 |
| builds_disabled | 빌드 비활성화 | 사용자 |
| deployment_rejected | 디플로이먼트 거부됨 | 사용자 |
| protected_environment_failure | 환경 실패 | 프로바이더 |
| secrets_provider_not_found | 비밀 프로바이더를 찾을 수 없음 | 사용자 |
| reached_max_descendant_pipelines_depth | 최대 하위 파이프라인에 도달 | 사용자 |
| ip_restriction_failure | IP 제한 실패 | 프로바이더 |
다음 GitLab 버전은 작업 로그 수집을 지원합니다:
작업 로그 수집을 실행하려면:
datadog_integration_logs_collection 기능 플래그를 활성화합니다. 그러면 Datadog 통합에서 Enable logs collection 옵션이 표시됩니다.Enable logs collection 옵션을 활성화하고 변경 내용을 저장합니다.작업 로그는 Logs 제품에서 수집되며 CI Visibility 내에서 GitLab 파이프라인과 자동으로 연결됩니다.
1GiB를 초과하는 로그 파일은 잘립니다.
Additional helpful documentation, links, and articles:
