GitLab Runner 사용량 모니터링

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

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

내장 Prometheus 지표

  • 내장 HTTP 통계 서버와 Prometheus 지표가 도입되었습니다. 버전: 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하여 사용 가능한 모든 지표의 전체 디렉터리을 찾을 수 있습니다. 예를 들어, 리스닝 포트가 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.
...

사용 가능한 지표의 전체 디렉터리을 보려면 Runner 모니터링을 참조하십시오.

pprof HTTP 엔드포인트

  • pprof 통합이 소개되었습니다. 버전: GitLab Runner 1.9.0.

GitLab Runner 프로세스 내부 상태에 대한 메트릭을 갖는 것은 유용하지만, 일부 경우에는 실행 중인 프로세스 내부에서 무엇이 일어나고 있는지 확인하는 것이 좋을 것으로 판단되어 pprof HTTP 엔드포인트를 소개했습니다.

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

pprof의 사용에 대해 더 알아보려면 문서를 참조하십시오.

메트릭 HTTP 서버 구성

note
메트릭 서버는 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 프록시를 추가하는 것을 고려해야 합니다.