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

Gitaly 및 Gitaly Cluster 모니터링

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

메트릭 정의는 다음과 같이 제공됩니다:

• Gitaly에 구성된 Prometheus /metrics 엔드포인트에서 직접 제공됨.
• 프라페타가 구성된 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": 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": 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 적응형 동시성 제한 모니터링

• GitLab 16.6에서 소개됨.

Gitaly 로그 및 Prometheus를 사용하여 적응형 동시성 제한의 특정 동작을 관찰할 수 있습니다. 현재 제한이 조정될 때의 로그와 관련된 내용을 식별할 수 있습니다. 로그(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 모니터링

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 서버 측 백업 모니터링

• 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의 인증 동작을 모니터링하려면 다음 프로메테우스 쿼리를 사용하세요:

  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 프로토콜 버전을 관찰하려면 다음 프로메테우스 쿼리를 사용하세요:

  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, 노드별로 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에서 제거되었습니다.