Gitaly 및 Gitaly Cluster 모니터링

사용 가능한 로그 및 Prometheus 지표를 사용하여 Gitaly 및 Gitaly Cluster (Praefect)를 모니터링할 수 있습니다.

메트릭 정의 사용 가능:

  • 직접 Gitaly에 구성된 /metrics 엔드포인트에서 Prometheus를 통해.
  • 프로메테우스에 대해 구성된 Grafana 인스턴스에 대해 Grafana Explore를 사용합니다.

Gitaly 속도 제한 모니터링

Gitaly는 다음을 기반으로 요청을 제한하도록 구성할 수 있습니다:

  • 요청의 동시성.
  • 속도 제한.

gitaly_requests_dropped_total 프로메테우스 지표를 사용하여 Gitaly 요청 제한을 모니터링할 수 있습니다. 이 메트릭은 요청이 제한으로 인해 삭제된 총 수를 제공합니다. reason 레이블은 요청이 삭제된 이유를 나타냅니다:

  • rate, 속도 제한으로 인해.
  • max_size, 동시성 큐 크기가 도달했기 때문에.
  • max_time, Gitaly에서 구성된 최대 대기 시간을 초과했기 때문에.

Gitaly 동시성 제한 모니터링

Gitaly 로그 및 프로메테우스를 사용하여 동시성 대기 중인 요청의 특정 동작을 관찰할 수 있습니다.

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"
}

프로메테우스에서 다음 메트릭을 찾습니다:

  • gitaly_concurrency_limiting_in_progress는 현재 처리 중인 동시 요청 수를 나타냅니다.
  • gitaly_concurrency_limiting_queued는 동시성 제한으로 인해 대기 중인 특정 저장소의 RPC에 대한 요청 수를 나타냅니다.
  • gitaly_concurrency_limiting_acquiring_seconds는 처리되기 전에 동시성 제한으로 대기해야하는 시간을 나타냅니다.

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

Gitaly 로그 및 프로메테우스를 사용하여 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"
}

프로메테우스에서 다음 메트릭을 찾습니다:

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

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

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

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

로그 필드 설명
limit 조정되는 제한의 이름입니다.
previous_limit 증가되거나 감소되기 전 이전 제한입니다.
new_limit 증가되거나 감소된 새 제한입니다.
watcher 노드가 압력을 받았다고 결정한 리소스 감시자입니다. 예: CgroupCpu 또는 CgroupMemory
reason 제한 조정의 이유입니다.
stats.* 조정 결정 뒤의 일부 통계입니다. 디버깅 목적으로 사용됩니다.

예시 로그: 

{
  "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_current_limit : 적응형 동시성 한계의 현재 한계 값입니다.
  • gitaly_concurrency_limiting_watcher_errors_total : 리소스 지표를 가져오는 동안 발생한 감시자 오류의 총 수를 나타냅니다.
  • gitaly_concurrency_limiting_backoff_events_total : 리소스 압력으로 제한이 조정된 백오프 이벤트의 총 수를 나타냅니다.

Gitaly cgroups 모니터링

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

  • gitaly_cgroups_reclaim_attempts_total : 메모리 회수 시도의 총 횟수에 대한 게이지입니다. 이 수는 서버를 다시 시작할 때마다 재설정됩니다.
  • gitaly_cgroups_cpu_usage : cgroup 당 CPU 사용량을 측정하는 게이지입니다.
  • gitaly_cgroup_procs_total : cgroups 제어 아래에서 Gitaly에서 생성된 프로세스의 총 수를 측정하는 게이지입니다.
  • 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 서버 측 백업 모니터링

다음 메트릭을 사용하여 서버 측 저장소 백업을 모니터링합니다.

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

특히 GitLab 인스턴스에 대규모 저장소가 포함되어 있는 경우 이러한 메트릭을 사용하십시오.

쿼리

다음은 Gitaly를 모니터링하기 위한 일부 쿼리입니다:

  • 다음 Prometheus 쿼리를 사용하여 Gitaly가 프로덕션 환경에서 제공하는 연결 유형을 확인하십시오: 

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

  • 다음 Prometheus 쿼리를 사용하여 GitLab 설치의 인증 동작을 모니터링하십시오: 

    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개의 요청을 처리하고 있습니다.

  • 다음 Prometheus 쿼리를 사용하여 프로덕션 환경에서 사용되는 Git 프로토콜 버전을 확인하십시오: 

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

Gitaly 클러스터 모니터링

Gitaly 클러스터(Praefect)를 모니터링하기 위해 다음 Prometheus 메트릭을 사용할 수 있습니다. 메트릭을 가져올 수 있는 두 개별 메트릭 엔드포인트가 있습니다:

  • 기본 /metrics 엔드포인트
  • 데이터베이스 쿼리를 필요로 하는 메트릭을 포함하는 /db_metrics

기본 프로메테우스 /metrics 엔드포인트

/metrics 엔드포인트에서 다음 메트릭을 사용할 수 있습니다:

  • gitaly_praefect_read_distribution: 읽기 분산을 추적하는 카운터입니다. virtual_storage 및 storage 두 가지 레이블을 가지고 있으며, 이는 Praefect의 이 인스턴스에 정의된 구성을 반영합니다.

  • gitaly_praefect_replication_latency_bucket: 복제 작업이 시작된 후 복제를 완료하는 데 걸리는 시간을 측정하는 히스토그램입니다. GitLab 12.10 이후에 사용할 수 있습니다.

  • gitaly_praefect_replication_delay_bucket: 복제 작업이 생성된 후 시작까지 걸리는 시간을 측정하는 히스토그램입니다. GitLab 12.10 이후에 사용할 수 있습니다.

  • gitaly_praefect_connections_total: Praefect에 대한 총 연결 수 (GitLab 14.7에서 도입되었습니다).

  • gitaly_praefect_method_types: 노드 당 accessor 및 mutator RPC 수를 카운트합니다.

강력한 일관성을 모니터링하려면 다음 Prometheus 메트릭을 사용할 수 있습니다:

  • gitaly_praefect_transactions_total: 생성되고 투표된 트랜잭션의 수
  • gitaly_praefect_subtransactions_per_transaction_total: 단일 트랜잭션에 대해 노드가 투표한 횟수. 단일 트랜잭션에서 여러 참조가 업데이트되는 경우 여러 번 발생할 수 있습니다.
  • gitaly_praefect_voters_per_transaction_total: 트랜잭션에 참여하는 Gitaly 노드의 수
  • gitaly_praefect_transactions_delay_seconds: 트랜잭션이 커밋되기를 기다리는 데 서버 측 지연
  • gitaly_hook_transaction_voting_delay_seconds: 트랜잭션이 커밋되기를 기다리는 데 클라이언트 측 지연

저장소 검증을 모니터링하려면 다음 Prometheus 메트릭을 사용할 수 있습니다:

  • gitaly_praefect_verification_jobs_dequeued_total: 워커에 의해 가져온 검증 작업 수
  • gitaly_praefect_verification_jobs_completed_total: 워커에 의해 완료된 검증 작업 수. result 레이블은 작업의 최종 결과를 나타냅니다:
    • valid: 예상되는 복제본이 저장소에 존재함을 나타냅니다.
    • invalid: 기대되는 복제본이 저장소에 존재하지 않음을 나타냅니다.
    • error: 작업이 실패하고 다시 시도해야 함을 나타냅니다.
  • gitaly_praefect_stale_verification_leases_released_total: 만료된 검증 리스를 해제한 수

또한 Praefect 로그를 모니터링할 수 있습니다.

데이터베이스 지표 /db_metrics 엔드포인트

다음과 같은 지표가 /db_metrics 엔드포인트에서 사용할 수 있습니다:

  • gitaly_praefect_unavailable_repositories, 건강하고 최신 상태의 레플리카가 없는 저장소의 수입니다.
  • gitaly_praefect_replication_queue_depth, 복제 대기열에 있는 작업의 수입니다.
  • gitaly_praefect_verification_queue_depth, 검증 대기 중인 레플리카의 총 수입니다.
  • gitaly_praefect_read_only_repositories, 가상 저장소에서 읽기 전용 모드인 저장소의 수입니다.
    • 이 지표는 GitLab 15.4에서 제거되었습니다.