GitLab Runner 사용 모니터링

Tier: Free, Premium, Ultimate Offering: GitLab.com, Self-managed

GitLab Runner는 Prometheus를 사용하여 모니터링할 수 있습니다.

내장 Prometheus 메트릭

  • Prometheus 메트릭을 포함한 내장 HTTP 통계 서버는 GitLab Runner 1.8.0에서 도입되었습니다.

GitLab Runner는 네이티브 Prometheus 메트릭으로 계측되어 있으며, /metrics 경로에서 내장 HTTP 서버를 통해 노출될 수 있습니다. 서버가 활성화된 경우, Prometheus 모니터링 시스템에 의해 스크랩되거나 다른 HTTP 클라이언트로 접근할 수 있습니다.

노출된 정보에는 다음이 포함됩니다:

  • Runner 비즈니스 논리 메트릭 (예: 현재 실행 중인 작업 수)
  • Go 관련 프로세스 메트릭 (가비지 컬렉션 통계, 고루틴, 메모리 통계 등)
  • 일반 프로세스 메트릭 (메모리 사용량, CPU 사용량, 파일 디스크립터 사용량 등)
  • 빌드 버전 정보

메트릭 형식은 Prometheus의 Exposition formats 문서에 기록되어 있습니다.

이 메트릭은 운영자가 러너를 모니터링하고 통찰력을 얻는 방법을 제공하기 위한 것입니다. 예를 들어, 러너 호스트의 부하 평균 증가가 처리된 작업 증가와 관련이 있는지 알고 싶을 수 있습니다. 또는 클러스터의 머신을 실행 중이고, 인프라스트럭처에 대한 변경을 할 수 있도록 빌드 경향을 추적하고 싶을 수 있습니다.

Prometheus에 대해 더 알아보기

이 HTTP 끝점을 스크랩하고 수집된 메트릭을 사용하는 Prometheus 서버를 설정하는 방법을 배우려면 Prometheus의 시작하기 가이드를 참조하세요. Prometheus를 구성하는 방법에 대한 자세한 내용은 구성 섹션과 알림 규칙 및 알림을 발송하기 위한 Alertmanager 설정 섹션을 참조하세요.

사용 가능한 메트릭

사용 가능한 모든 메트릭의 전체 목록을 찾으려면, 메트릭 끝점을 구성하고 활성화한 후 curl 명령을 사용하세요. 예를 들어, 수신 포트 9252로 구성된 로컬 러너의 경우:

$ curl -s "http://localhost:9252/metrics" | grep -E "# HELP"  

# HELP gitlab_runner_api_request_statuses_total API 요청의 총 수 (러너, 끝점 및 상태로 구분됨).
# HELP gitlab_runner_autoscaling_machine_creation_duration_seconds 머신 생성 시간의 히스토그램.
# HELP gitlab_runner_autoscaling_machine_states 이 공급자에서 상태별 현재 머신 수.
# HELP gitlab_runner_concurrent 현재 동시 설정 값.
# HELP gitlab_runner_errors_total 발생한 오류 수.
# HELP gitlab_runner_limit 현재 제한 설정 값.
# HELP gitlab_runner_request_concurrency 새 작업에 대한 동시 요청 수.
# HELP gitlab_runner_request_concurrency_exceeded_total 구성된 request_concurrency 제한을 초과한 요청 수.
# HELP gitlab_runner_version_info 다양한 빌드 통계 필드로 레이블이 지정된 '1' 상수를 가진 메트릭.
...

목록에는 Go 관련 프로세스 메트릭이 포함됩니다. Go 관련 프로세스를 포함하지 않는 사용 가능한 메트릭의 목록은 모니터링 러너를 참조하세요.

pprof HTTP 엔드포인트

  • pprof 통합은 GitLab Runner 1.9.0에서 도입되었습니다.

GitLab Runner 프로세스의 내부 상태에 대한 메트릭을 갖는 것은 유용하지만,

일부 경우에는 실행 중인 프로세스 내부에서 발생하는 일을 실시간으로 확인하는 것이 좋습니다.

그래서 우리는 pprof HTTP 엔드포인트를 도입했습니다.

pprof 엔드포인트는 /debug/pprof/ 경로의 내장 HTTP 서버를 통해 사용할 수 있습니다.

pprof 사용에 대한 자세한 내용은 문서에서 확인할 수 있습니다.

메트릭 HTTP 서버 구성

참고: 메트릭 서버는 GitLab Runner 프로세스의 내부 상태에 대한 데이터를 내보내며 공개적으로 사용 가능해서는 안 됩니다!

메트릭 HTTP 서버는 다음과 같은 방법으로 구성할 수 있습니다:

  • config.toml 파일에 있는 listen_address 전역 구성 옵션으로,
  • run 명령을 위한 --listen-address 명령줄 옵션으로,
  • Helm Chart를 사용하는 러너를 위한 values.yaml에서 metrics 및 service 구성 옵션을 설정하여.

config.toml 파일에 주소를 추가하면, 메트릭 HTTP 서버를 시작하기 위해 러너 프로세스를 재시작해야 합니다.

두 경우 모두 옵션은 [host]:<port> 형식의 문자열을 받아들입니다.

여기서:

  • host는 IP 주소 또는 호스트 이름일 수 있습니다.
  • port는 유효한 TCP 포트 또는 기호 서비스 이름(예: http)입니다. 이미 Prometheus에서 할당된 포트 9252를 사용하는 것을 권장합니다.

전달된 listen 주소에 포트가 포함되어 있지 않으면 기본값은 9252입니다.

주소 예시:

  • :9252 - 포트 9252에서 모든 인터페이스의 모든 IP에서 수신 대기합니다.
  • localhost:9252 - 포트 9252에서 루프백 인터페이스에서만 수신 대기합니다.
  • [2001:db8::1]:http - HTTP 포트 80에서 IPv6 주소 [2001:db8::1]에서 수신 대기합니다.

포트 1024 이하에서 수신 대기하려면 - 적어도 Linux/Unix 시스템에서 - 루트/관리자 권한이 필요합니다.

선택한 host:port에서 HTTP 서버는 인증 없이 열립니다.

메트릭 서버를 공용 인터페이스에 바인딩할 계획이라면, 이 서버에 대한 접근을 제한하기 위해 방화벽을 사용하는 것을 고려하거나, 인증 및 접근 제어 계층을 추가할 HTTP 프록시를 추가해야 합니다.