Gitaly와 Gitaly 클러스터 모니터링

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

메트릭 정의는 다음과 같습니다:

  • Gitaly에 구성된 Prometheus /metrics 엔드포인트에서 직접 제공됩니다.
  • Prometeheus에 구성된 Grafana 인스턴스의 Grafana 탐색을 사용할 수도 있습니다.

Gitaly 속도 제한 모니터링

Gitaly는 요청의 동시성 및 속도 제한을 기반으로 구성할 수 있습니다.

gitaly_requests_dropped_total 프로메테우스 메트릭을 사용하여 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-object 프로세스에 대한 요청이 기다린 시간을 나타냅니다.

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

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

예: 

{
  "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, cgroup 제어 하에 생성된 총 프로세스 수를 메트릭하는 게이지입니다.
  • 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 모니터링을 위한 몇 가지 질의 사례는 다음과 같습니다:

  • 프로덕션 환경에서 Gitaly가 제공하는 연결 유형을 관찰하려면 다음 Prometheus 질의를 사용하세요: 

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

  • GitLab 설치의 인증 동작을 모니터링하려면 다음 Prometheus 질의를 사용하세요: 

    sum(rate(gitaly_authentications_total[5m])) by (enforced, status)

    올바르게 구성된 인증 및 실시간 트래픽이 있는 시스템에서는 다음과 같은 결과가 표시됩니다: 

    {enforced="true",status="ok"}  4424.985419441742

    rate 0이 아닌 다른 숫자도 있을 수 있지만, 0이 아닌 숫자만 주의하여 살펴봐야 합니다.

    rate 0이 아닌 숫자 중에는 enforced="true",status="ok"만 있어야 합니다. 다른 rate 0이 아닌 숫자가 있는 경우 구성에 문제가 있습니다.

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

  • 프로덕션 환경에서 사용되는 Git 프로토콜 버전을 관찰하려면 다음 Prometheus 질의를 사용하세요: 

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

Gitaly 클러스터 모니터링

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

  • 기본 /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, 노드당 액세서 및 뮤테이터 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에서 제거되었습니다.