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의 노출 형식 사양에 문서화되어 있습니다.

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

Prometheus에 대해 더 알아보기

이 HTTP 엔드포인트를 스크랩하고 수집된 지표를 활용하기 위해 Prometheus 서버를 설정하는 방법에 대해서는 Prometheus의 시작하기 가이드를 참조하십시오. 또한 Prometheus의 구성 섹션에서 Prometheus를 구성하는 방법에 대해 더 자세히 알아볼 수 있으며, 알림 규칙 섹션과 Alertmanager 설정에 대한 섹션도 참조하십시오.

사용 가능한 지표

구성 및 활성화된 후 메트릭스 엔드포인트를 curl하여 모든 사용 가능한 지표의 전체 목록을 찾으십시오. 예를 들어, 로컬 Runner가 듣는 포트인 9252로 구성된 경우: 

$ 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 특정 프로세스 지표가 포함됩니다. Go 특정 프로세스를 포함하지 않은 사용 가능한 지표 목록은 Runner 모니터링을 참조하십시오.

pprof HTTP 엔드포인트

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

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

pprof 엔드포인트는 다음의 문서에서 더 자세히 알아볼 수 있습니다.

메트릭스 HTTP 서버 설정

참고: 메트릭스 서버는 GitLab Runner 프로세스의 내부 상태에 대한 데이터를 노출하며, 공개적으로 사용할 수 없어야 합니다!

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

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

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

두 경우 모두 옵션은 [host]:<port> 형식의 문자열을 사용합니다.

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

리스닝 주소에 포트가 포함되어 있지 않은 경우 기본값은 9252입니다.

주소의 예시:

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

포트 1024 미만에 대한 리스닝은 (적어도 Linux/Unix 시스템에서) 루트/관리자 권한이 필요합니다.

선택한 host:port에서 HTTP 서버가 인증없이 열리게 됩니다. 메트릭 서버를 공개 인터페이스에 바인딩할 계획이라면 이 서버에 대한 액세스를 제한할 수 있도록 방화벽을 사용하거나 인증 및 액세스 제어 계층을 추가하는 HTTP 프록시를 추가하는 것을 고려해야 합니다.