• Gitaly 요청 제한 모니터링
• Gitaly 동시성 제한 모니터링
• Gitaly 패키지 객체 동시성 제한 모니터링
• Gitaly 적응형 동시성 제한 모니터링
• Gitaly cgroups 모니터링
• pack-objects 캐시
• Gitaly 서버 측 백업 모니터링
• 쿼리
• Gitaly 클러스터 모니터링
  • 기본 Prometheus /metrics 엔드포인트
  • 데이터베이스 메트릭 /db_metrics 엔드포인트

Gitaly 및 Gitaly 클러스터 모니터링

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

메트릭 정의는 다음에서 사용할 수 있습니다:

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

Gitaly 요청 제한 모니터링

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

• 요청의 동시성.
• 비율 제한.

gitaly_requests_dropped_total Prometheus 메트릭으로 Gitaly 요청 제한을 모니터링하세요. 이 메트릭은 요청 제한으로 인해 드롭된 요청의 총 수를 제공합니다. reason 레이블은 요청이 드롭된 이유를 나타냅니다:

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

Gitaly 동시성 제한 모니터링

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

Gitaly 로그에서 다음과 같은 항목으로 패키지 객체 동시성 제한과 관련된 로그를 식별할 수 있습니다:

예를 들어:

{
  "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 패키지 객체 동시성 제한 모니터링

Gitaly 로그와 Prometheus를 사용하여 패키지 객체 제한의 특정 동작을 관찰할 수 있습니다.

Gitaly 로그에서 패키지 객체 동시성 제한과 관련된 로그를 다음과 같은 항목으로 식별할 수 있습니다:

예시 구성:

{
  "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은 현재 얼마나 많은 패키지 객체 프로세스가 동시에 처리되고 있는지를 나타냅니다.
• gitaly_pack_objects_queued는 동시성 제한이 도달했기 때문에 대기 중인 패키지 객체 프로세스 요청 수를 나타냅니다.
• gitaly_pack_objects_acquiring_seconds는 처리되기 전에 패키지 객체 프로세스 요청이 동시성 제한으로 인해 대기해야 하는 시간을 나타냅니다.

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_current_limit는 적응형 동시성 제한의 현재 제한 값을 나타냅니다.
• gitaly_concurrency_limiting_watcher_errors_total는 리소스 메트릭을 가져오는 동안 발생한 총 감시자 오류 수를 나타냅니다.
• gitaly_concurrency_limiting_backoff_events_total는 리소스 압력으로 인해 제한이 조정되는 경우의 총 백오프 이벤트 수를 나타냅니다.

Gitaly cgroups 모니터링

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

• 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 모니터링을 위한 쿼리입니다:

• 다음 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
  

  비율이 0인 다른 숫자도 있을 수 있지만, 비제로 숫자만 주의하면 됩니다.

  유일한 비제로 숫자는 enforced="true",status="ok" 여야 합니다. 다른 비제로 숫자가 있다면 구성에 뭔가 잘못된 것입니다.

  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.

기본 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, 노드별 접근자 및 변형 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에서.