Gitaly 및 Gitaly 클러스터 모니터링

가용한 로그 및 Prometheus 메트릭을 사용하여 Gitaly 및 Gitaly 클러스터(Praefect)를 모니터링할 수 있습니다.

메트릭 정의:

  • 직접 Gitaly에 구성된 /metrics 엔드포인트에서 Prometheus에서 사용 가능합니다.
  • Prometheus에 구성된 Grafana 인스턴스에서 Grafana Explore를 사용할 수 있습니다.

Gitaly 속도 제한 모니터링

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

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

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

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

Gitaly 동시성 제한 모니터링

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

Gitaly 로그에서는 pack-objects 동시성 제한과 관련된 항목과 관련된 로그를 확인할 수 있습니다.

로그 필드 설명
limit.concurrency_queue_length 진행 중인 호출의 RPC 유형에 특정된 큐의 현재 길이를 나타냅니다. 이는 동시성 제한으로 요청이 처리되기를 기다리는 요청의 수에 대한 통찰력을 제공합니다.
limit.concurrency_queue_ms RPC의 동시성에 대한 제한으로 인해 대기 중인 요청이 큐에서 대기한 시간(밀리초)을 나타냅니다. 이 필드는 요청 처리 시간에 대한 동시성 제한의 영향을 이해하는 데 도움이 됩니다.
limit.concurrency_dropped 제한이 도달되어 요청이 삭제된 경우, 이 필드는 그 이유를 지정합니다: max_time (요청이 최대 허용 시간보다 길게 대기) 또는 max_size (큐가 최대 크기에 도달함).
limit.limiting_key 제한에 사용된 키를 식별합니다.
limit.limiting_type 제한되는 프로세스 유형을 지정합니다. 이 문맥에서는 per-rpc로 설정되어 RPC당 동시성 제한이 적용됨을 나타냅니다.

예시: 

{
  "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 pack-objects 동시성 제한 모니터링

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

Gitaly 로그에서는 pack-objects 동시성 제한과 관련된 항목과 관련된 로그를 확인할 수 있습니다.

로그 필드 설명
limit.concurrency_queue_length pack-objects 프로세스의 큐의 현재 길이입니다. 동시 프로세스에 대한 제한으로 인해 처리 대기 중인 요청 수를 나타냅니다.
limit.concurrency_queue_ms 요청이 대기한 시간(밀리초)을 나타냅니다. 동시성의 제한으로 인해 요청이 얼마나 오래 대기했는지를 나타냅니다.
limit.limiting_key 보내는 사람의 원격 IP입니다.
limit.limiting_type 제한되는 프로세스 유형을 나타냅니다. 이 경우 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-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_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

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

  • 다음 프로메테우스 쿼리를 사용하여 프로덕션 환경에서 사용되는 Git 프로토콜 버전을 확인합니다: 

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

Gitaly 클러스터 모니터링

Gitaly 클러스터(Praefect)를 모니터링하려면 다음 프로메테우스 메트릭을 사용할 수 있습니다. 메트릭을 가져올 수 있는 두 개의 별도 메트릭 엔드포인트가 있습니다:

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

기본 Prometheus /metrics 엔드포인트

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

  • gitaly_praefect_read_distribution: 읽기 분배를 추적하기 위한 카운터입니다. 두 가지 라벨이 있습니다:
    • virtual_storage.
    • storage.

    이는 Praefect 인스턴스에서 정의된 구성을 반영합니다.

  • gitaly_praefect_replication_latency_bucket: 복제가 시작된 후 복제가 완료되기까지 걸리는 시간을 측정하는 히스토그램입니다.
  • gitaly_praefect_replication_delay_bucket: 복제 작업이 생성된 후 시작되기까지 걸리는 시간을 측정하는 히스토그램입니다.
  • gitaly_praefect_connections_total: Praefect에 대한 총 연결 수
  • gitaly_praefect_method_types: 노드별 accessor 및 mutator RPC 수를 카운트합니다.

강력한 일관성을 모니터링하기 위해 다음 프로메테우스 메트릭을 사용할 수 있습니다:

  • 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: 트랜잭션이 커밋되기를 기다리는 데 클라이언트 측 지연 시간입니다.

저장소 확인를 모니터링하기 위해 다음 프로메테우스 메트릭을 사용할 수 있습니다:

  • gitaly_praefect_verification_jobs_dequeued_total: 워커에 의해 집중된 확인 작업 수입니다.
  • gitaly_praefect_verification_jobs_completed_total: 워커에 의해 완료된 확인 작업 수입니다. result 라벨은 작업의 최종 결과를 나타냅니다:
    • valid: 예상하는 복제본이 저장소에 존재함을 나타냅니다.
    • invalid: 기대하는 복제본이 저장소에 존재하지 않음을 나타냅니다.
    • error: 작업이 실패하고 다시 시도해야 함을 나타냅니다.
  • gitaly_praefect_stale_verification_leases_released: 유효하지 않은 확인 임대를 해제한 횟수입니다.

또한 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에서 제거되었습니다.