- Gitaly 정도 제한 모니터링
- Gitaly 동시성 제한 모니터링
- Gitaly pack-objects 동시성 제한 모니터링
- Gitaly 적응형 동시성 제한 모니터링
- Gitaly cgroups 모니터링
pack-objects
캐시- Gitaly 서버 측 백업 모니터링
- 쿼리
- Gitaly 클러스터 모니터링
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
| 진행 중인 호출의 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 적응형 동시성 제한 모니터링
- GitLab 16.6에서 소개됨.
Gitaly 로그 및 Prometheus를 사용하여 적응형 동시성 제한의 특정 동작을 관찰할 수 있습니다. 현재 제한이 조정될 때의 로그와 관련된 내용을 식별할 수 있습니다.
로그(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 서버 측 백업 모니터링
- 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에서 제거되었습니다.