GitLab Runner 사용량 모니터링

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

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

내장된 프로메테우스 지표

  • 내장 HTTP 통계 서버에 프로메테우스 지표가 GitLab Runner 1.8.0에서 소개되었습니다.

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

노출된 정보는 다음을 포함합니다:

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

이러한 지표는 운영자가 Runner를 모니터링하고 통찰력을 얻는 방법으로 의도되었습니다. 예를 들어, Runner 호스트의 부하 평균 증가와 처리된 작업의 증가 사이의 관련성을 파악하고 싶을 수 있습니다. 또는 여러 대의 머신 클러스터를 실행 중이며 인프라에 변경을 가할 수 있도록 빌드 트렌드를 추적하려고 할 수 있습니다.

프로메테우스에 대해 더 알아보기

이 HTTP 엔드포인트를 스크랩하여 수집한 지표를 활용하기 위해 프로메테우스 서버를 설정하는 방법을 알아보려면 프로메테우스의 시작하기 가이드를 참조하세요. 또한, 프로메테우스를 구성하는 방법에 대한 더 많은 세부 정보는 구성 섹션과 알림 규칙 및 Alertmanager 설정 섹션을 참조하세요.

사용 가능한 지표

설정 및 활성화된 후 메트릭스 엔드포인트를 curl하여 사용 가능한 모든 지표의 전체 디렉터리을 찾을 수 있습니다. 예를 들어, 리스닝 포트 9252로 구성된 로컬 Runner의 경우: 

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

# HELP gitlab_runner_api_request_statuses_total The total number of api requests, partitioned by runner, endpoint and status.
# HELP gitlab_runner_autoscaling_machine_creation_duration_seconds Histogram of machine creation time.
# HELP gitlab_runner_autoscaling_machine_states The current number of machines per state in this provider.
# HELP gitlab_runner_concurrent The current value of concurrent setting
# HELP gitlab_runner_errors_total The number of caught errors.
# HELP gitlab_runner_limit The current value of limit setting
# HELP gitlab_runner_request_concurrency The current number of concurrent requests for a new job
# HELP gitlab_runner_request_concurrency_exceeded_total Count of excess requests above the configured request_concurrency limit
# HELP gitlab_runner_version_info A metric with a constant '1' value labeled by different build stats fields.
...

이 디렉터리에는 Go 고유 프로세스 지표가 포함됩니다. 고유 프로세스를 포함하지 않은 사용 가능한 지표 디렉터리에 대한 정보는 Runner 모니터링을 참조하세요.

pprof HTTP 엔드포인트

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

GitLab Runner 프로세스의 내부 상태에 대한 메트릭을 가지고 있는 것은 유용합니다만, 경우에 따라 실행 중인 프로세스 내부에서 실시간으로 무엇이 발생하고 있는지 확인하는 것이 좋을 수 있다는 것을 발견했습니다. 이에 따라 pprof HTTP 엔드포인트를 소개했습니다.

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

pprof 사용에 대한 자세한 내용은 문서를 참조하세요.

메트릭스 HTTP 서버의 구성

note
메트릭스 서버는 GitLab Runner 프로세스의 내부 상태 데이터를 노출하며, 공개적으로 사용 가능하게 설정해서는 안 됩니다!

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

  • config.toml 파일의 listen_address 글로벌 구성 옵션으로,
  • run 명령어의 --listen-address 커맨드 라인 옵션으로,
  • Helm Chart를 사용하는 Runner의 values.yaml에서 metrics 및 service 구성 옵션으로.

config.toml 파일에 주소를 추가한 경우, 메트릭스 HTTP 서버를 시작하려면 Runner 프로세스를 다시 시작해야 합니다.

두 경우 모두 선택한 호스트와 포트를 포맷이 [호스트]:<포트>인 문자열로 받아 들입니다.

  • 호스트는 IP 주소 또는 호스트명이 될 수 있습니다.
  • 포트는 유효한 TCP 포트 또는 http와 같은 symbolic 서비스 이름이 될 수 있습니다. 이미 프로메테우스에 할당된 포트 9252를 사용하는 것을 권장합니다.

포트가 포함되지 않은 경우, 기본값으로 9252로 설정됩니다.

주소의 예:

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

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

선택한 호스트:포트에 HTTP 서버가 무단으로 열리며, 메트릭스 서버를 공용 인터페이스에 바인딩할 계획이라면 방화벽을 사용하여이 서버에 대한 액세스를 제한하거나 인증 및 액세스 제어 레이어를 추가하는 HTTP 프록시를 고려해야 합니다.