사용 가능한 로그와 Prometheus 메트릭을 사용하여 Gitaly를 모니터링합니다.

메트릭 정의는 다음에서 사용 가능합니다:

• Gitaly에 대해 구성된 Prometheus /metrics 엔드포인트에서 직접.
• Prometheus에 대해 구성된 Grafana 인스턴스에서 Grafana Explore를 사용하여.

Gitaly는 요청 동시성(적응형 또는 비적응형)에 따라 요청을 제한하도록 구성할 수 있습니다.

Gitaly 동시성 제한 모니터링#

Gitaly 로그와 Prometheus를 사용하여 동시성 대기 요청의 특정 동작을 관찰할 수 있습니다.

Gitaly 로그에서 다음과 같은 항목으로 pack-objects 동시성 제한과 관련된 로그를 식별할 수 있습니다:

예:

{
  "limit.concurrency_queue_length": 1,
  "limit.concurrency_queue_ms": 0,
  "limit.limiting_key": "@hashed/79/02/7902699be42c8a8e46fbbb450172651786b22c56a189f7625a6da49081b2451.git",
  "limit.limiting_type": "per-rpc"
}

Prometheus에서 다음 메트릭을 확인합니다:

• gitaly_concurrency_limiting_in_progress는 처리 중인 동시 요청 수를 나타냅니다.
• gitaly_concurrency_limiting_queued는 동시성 제한에 도달하여 특정 리포지터리에 대한 RPC 요청이 대기 중인 수를 나타냅니다.
• gitaly_concurrency_limiting_acquiring_seconds는 처리되기 전에 동시성 제한으로 인해 요청이 대기해야 하는 시간을 나타냅니다.
• gitaly_requests_dropped_total은 요청 제한으로 인해 삭제된 요청의 총 수를 제공합니다. reason 레이블은 요청이 삭제된 이유를 나타냅니다:
  • max_size: 동시성 큐 크기에 도달했기 때문입니다.
  • max_time: 요청이 Gitaly에서 구성된 최대 큐 대기 시간을 초과했기 때문입니다.

Gitaly pack-objects 동시성 제한 모니터링#

Gitaly 로그와 Prometheus를 사용하여 pack-objects 제한의 특정 동작을 관찰할 수 있습니다.

Gitaly 로그에서 다음과 같은 항목으로 pack-objects 동시성 제한과 관련된 로그를 식별할 수 있습니다:

구성 예:

{
  "limit.concurrency_queue_length": 1,
  "limit.concurrency_queue_ms": 0,
  "limit.limiting_key": "1.2.3.4",
  "limit.limiting_type": "pack-objects"
}

Prometheus에서 다음 메트릭을 확인합니다:

• gitaly_pack_objects_in_progress는 동시에 처리 중인 pack-objects 프로세스 수를 나타냅니다.
• gitaly_pack_objects_queued는 동시성 제한에 도달하여 대기 중인 pack-objects 프로세스 요청 수를 나타냅니다.
• gitaly_pack_objects_acquiring_seconds는 처리되기 전에 동시성 제한으로 인해 pack-object 프로세스 요청이 대기해야 하는 시간을 나타냅니다.

Gitaly 적응형 동시성 제한 모니터링#

히스토리

• GitLab 16.6에서 도입되었습니다.

Gitaly 로그와 Prometheus를 사용하여 적응형 동시성 제한의 특정 동작을 관찰할 수 있습니다.

적응형 동시성 제한은 정적 동시성 제한의 확장이므로 정적 동시성 제한에 적용 가능한 모든 메트릭과 로그는 적응형 제한을 모니터링할 때도 관련이 있습니다. 또한 적응형 제한은 제한의 동적 조정을 모니터링하는 데 도움이 되는 몇 가지 특정 메트릭을 도입합니다.

적응형 제한 로그#

Gitaly 로그에서 현재 제한이 조정될 때 적응형 동시성 제한과 관련된 로그를 식별할 수 있습니다. 로그 내용(msg)을 "Multiplicative decrease" 및 "Additive increase" 메시지로 필터링할 수 있습니다.

이러한 디버그 로그는 디버그 심각도 수준에서만 사용 가능하며 장황할 수 있지만 적응형 제한 조정에 대한 자세한 통찰력을 제공합니다.

로그 예:

{
  "msg": "Multiplicative decrease",
  "limit": "pack-objects",
  "new_limit": 14,
  "previous_limit": 29,
  "reason": "cgroup CPU throttled too much",
  "watcher": "CgroupCpu",
  "stats.time_diff": 15.0,
  "stats.throttled_duration": 13.0,
  "stat.sthrottled_threshold": 0.5
}

적응형 제한 메트릭#

Prometheus에서 다음 메트릭을 확인합니다:

정적 및 적응형 제한 모두에 적용 가능한 일반 동시성 제한 메트릭:

• gitaly_concurrency_limiting_in_progress - 처리 중인 요청 수.
• gitaly_concurrency_limiting_queued - 동시성 제한으로 인해 큐에서 대기 중인 요청 수.
• gitaly_concurrency_limiting_acquiring_seconds - 처리 시작 전에 동시성 제한으로 인해 요청이 대기하는 시간.

적응형 동시성 제한 특정 메트릭:

• gitaly_concurrency_limiting_current_limit - 각 RPC 유형에 대한 적응형 동시성 제한의 현재 제한 값을 보여주는 게이지. 이 메트릭에는 적응형 제한만 포함됩니다.
• gitaly_concurrency_limiting_backoff_events_total - 리소스 압박으로 인해 제한이 감소할 때와 이유를 나타내는 백오프 이벤트의 총 수를 나타내는 카운터.
• gitaly_concurrency_limiting_watcher_errors_total - Gitaly가 리소스 데이터를 검색하는 데 실패하여 Gitaly가 현재 리소스 상황을 평가하는 능력에 영향을 미칠 수 있는 오류를 추적하는 카운터.

적응형 제한 문제를 조사할 때 이러한 메트릭을 일반 동시성 제한 메트릭 및 로그와 연관시켜 시스템 동작의 전체 그림을 파악합니다.

Gitaly cgroups 모니터링#

Prometheus를 사용하여 제어 그룹(cgroups) 상태를 관찰할 수 있습니다:

• gitaly_cgroups_reclaim_attempts_total: 메모리 회수 시도 횟수의 합계를 위한 게이지. 이 수는 서버가 재시작될 때마다 초기화됩니다.
• gitaly_cgroups_cpu_usage: cgroup별 CPU 사용량을 측정하는 게이지.
• gitaly_cgroup_procs_total: Gitaly가 cgroups의 제어 하에 생성한 총 프로세스 수를 측정하는 게이지.
• gitaly_cgroup_cpu_cfs_periods_total: nr_periods 값을 위한 카운터.
• gitaly_cgroup_cpu_cfs_throttled_periods_total: nr_throttled 값을 위한 카운터.
• gitaly_cgroup_cpu_cfs_throttled_seconds_total: 초 단위의 throttled_time 값을 위한 카운터.

pack-objects 캐시#

다음 pack-objects 캐시 메트릭이 사용 가능합니다:

• gitaly_pack_objects_cache_enabled: 캐시가 활성화되면 1로 설정되는 게이지. 사용 가능한 레이블: dir 및 max_age.
• gitaly_pack_objects_cache_lookups_total: 캐시 조회를 위한 카운터. 사용 가능한 레이블: result.
• gitaly_pack_objects_generated_bytes_total: 캐시에 작성된 바이트 수를 위한 카운터.
• gitaly_pack_objects_served_bytes_total: 캐시에서 읽은 바이트 수를 위한 카운터.
• gitaly_streamcache_filestore_disk_usage_bytes: 캐시 파일의 총 크기를 위한 게이지. 사용 가능한 레이블: dir.
• gitaly_streamcache_index_entries: 캐시의 항목 수를 위한 게이지. 사용 가능한 레이블: dir.

이러한 메트릭 중 일부는 Gitaly의 streamcache 내부 라이브러리 패키지에서 생성되기 때문에 gitaly_streamcache로 시작합니다.

예:

gitaly_pack_objects_cache_enabled{dir="/var/opt/gitlab/git-data/repositories/+gitaly/PackObjectsCache",max_age="300"} 1
gitaly_pack_objects_cache_lookups_total{result="hit"} 2
gitaly_pack_objects_cache_lookups_total{result="miss"} 1
gitaly_pack_objects_generated_bytes_total 2.618649e+07
gitaly_pack_objects_served_bytes_total 7.855947e+07
gitaly_streamcache_filestore_disk_usage_bytes{dir="/var/opt/gitlab/git-data/repositories/+gitaly/PackObjectsCache"} 2.6200152e+07
gitaly_streamcache_filestore_removed_total{dir="/var/opt/gitlab/git-data/repositories/+gitaly/PackObjectsCache"} 1
gitaly_streamcache_index_entries{dir="/var/opt/gitlab/git-data/repositories/+gitaly/PackObjectsCache"} 1

Gitaly 서버 측 백업 모니터링#

히스토리

• GitLab 16.7에서 도입되었습니다.

다음 메트릭으로 서버 측 리포지터리 백업을 모니터링합니다:

• gitaly_backup_latency_seconds: 서버 측 백업의 각 단계가 소요하는 시간(초)을 측정하는 히스토그램. 다양한 단계는 refs, bundle, custom_hooks이며 각 단계에서 처리되는 데이터 유형을 나타냅니다.
• gitaly_backup_bundle_bytes: Gitaly 백업 서비스가 오브젝트 스토리지로 푸시하는 Git 번들의 업로드 데이터 속도를 측정하는 히스토그램.

GitLab 인스턴스에 대규모 리포지터리가 포함된 경우 특히 이러한 메트릭을 사용합니다.

쿼리#

다음은 Gitaly 모니터링을 위한 몇 가지 쿼리입니다:

• 프로덕션 환경에서 Gitaly가 제공하는 연결 유형을 관찰하기 위해 다음 Prometheus 쿼리를 사용합니다:

  sum(rate(gitaly_connections_total[5m])) by (type)
  

• GitLab 설치의 인증 동작을 모니터링하기 위해 다음 Prometheus 쿼리를 사용합니다:

  sum(rate(gitaly_authentications_total[5m])) by (enforced, status)
  

  인증이 올바르게 구성되고 라이브 트래픽이 있는 시스템에서는 다음과 같은 결과를 볼 수 있습니다:

  {enforced="true",status="ok"}  4424.985419441742
  

  rate가 0인 다른 숫자도 있을 수 있지만 0이 아닌 숫자에만 주목하면 됩니다.

  유일한 0이 아닌 숫자는 enforced="true",status="ok"를 가져야 합니다. 다른 0이 아닌 숫자가 있으면 구성에 문제가 있는 것입니다.

  status="ok" 숫자는 현재 요청 속도를 반영합니다. 이전 예에서 Gitaly는 초당 약 4000개의 요청을 처리하고 있습니다.

• 프로덕션 환경에서 사용 중인 Git 프로토콜 버전을 관찰하기 위해 다음 Prometheus 쿼리를 사용합니다:

  sum(rate(gitaly_git_protocol_requests_total[1m])) by (grpc_method,git_protocol,grpc_service)