서비스 핑 문제 해결

서비스 핑을 로컬에서 설정하고 테스트하기

로컬에서 서비스 핑을 설정하려면 다음 작업을 수행해야 합니다:

  1. 로컬 저장소 설정하기.
  2. 로컬 설정 테스트하기.
  3. 선택 사항. Prometheus 기반 서비스 핑 테스트하기.

로컬 저장소 설정하기

  1. GitLab을 클론하고 시작합니다.
  2. 버전 애플리케이션을 클론하고 시작합니다. PostgreSQL과 Redis 인스턴스를 시작하려면 docker-compose up을 실행해야 합니다.
  3. GitLab을 기본 엔드포인트 대신 버전 애플리케이션 엔드포인트로 지정합니다:
    1. service_ping/submit_service.rb를 로컬에서 열고 STAGING_BASE_URL을 수정합니다.
    2. 로컬 버전 애플리케이션 URL로 설정합니다: http://localhost:3000.

로컬 설정 테스트하기

  1. gitlab 레일스 콘솔을 사용하여 서비스 핑을 수동으로 트리거합니다:

    GitlabServicePingWorker.new.perform('triggered_from_cron' => false)
    
  2. versions 레일스 콘솔을 사용하여 서비스 핑이 성공적으로 수신되었는지, 구문 분석되었는지 및 버전 데이터베이스에 저장되었는지 확인합니다:

    UsageData.last
    

Prometheus 기반 서비스 핑 테스트하기

제출된 데이터에 Prometheus에서 쿼리한 메트릭이 포함되어 검사하고 확인하려면 다음 작업을 수행해야 합니다:

  • Prometheus 서버가 로컬에서 실행되고 있는지 확인합니다.
  • 해당 GitLab 구성 요소가 Prometheus 서버에 메트릭을 내보내고 있는지 확인합니다.

Prometheus에서 오는 데이터를 테스트할 필요가 없다면 추가 작업은 필요하지 않습니다.

서비스 핑은 실행 중인 Prometheus 서버가 없을 때 우아하게 저하되어야 합니다.

세 가지 종류의 구성 요소가 Prometheus에 데이터를 내보낼 수 있으며, 서비스 핑에 포함됩니다:

  • node_exporter: 호스트 머신의 노드 메트릭을 내보냅니다.
  • gitlab-exporter: 다양한 GitLab 구성 요소의 프로세스 메트릭을 내보냅니다.
  • Sidekiq 및 레일스 서버와 같은 기타 다양한 GitLab 서비스가 자신의 메트릭을 내보냅니다.

Omnibus 컨테이너로 테스트하기

이는 Prometheus 기반 서비스 핑을 테스트하기 위한 권장 접근 방식입니다.

변경 사항을 확인하려면, CI/CD를 사용하여 코드 브랜치에서 새로운 Omnibus 이미지를 빌드한 다음, 이미지를 다운로드하고 로컬 컨테이너 인스턴스를 실행합니다:

  1. 병합 요청에서 qa 단계를 선택한 다음, e2e:test-on-omnibus 작업을 트리거합니다. 이 작업은 omnibus-gitlab-mirror 프로젝트의 다운스트림 파이프라인에서 Omnibus 빌드를 트리거합니다.
  2. 다운스트림 파이프라인에서 gitlab-docker 작업이 완료될 때까지 기다립니다.
  3. 작업 로그를 열고 버전을 포함한 전체 컨테이너 이름을 찾습니다. 형식은 다음과 같습니다: registry.gitlab.com/gitlab-org/build/omnibus-gitlab-mirror/gitlab-ee:<VERSION>.
  4. 로컬 머신에서 GitLab Docker 레지스트리에 로그인되어 있는지 확인합니다. 이와 관련된 지침은 GitLab 컨테이너 레지스트리에 인증하기에서 찾을 수 있습니다.
  5. 로그인한 후, docker pull registry.gitlab.com/gitlab-org/build/omnibus-gitlab-mirror/gitlab-ee:<VERSION>을 사용하여 새로운 이미지를 다운로드합니다.
  6. Docker에서 Omnibus GitLab 컨테이너를 사용하고 실행하는 방법에 대한 더 많은 정보는 GitLab Docker 이미지 문서를 참조하세요.

GitLab 개발 툴킷으로 테스트

이것은 실제 GitLab 배포를 에뮬레이션할 때 여러 가지 어려움이 있기 때문에 권장되지 않는 접근 방식입니다.

GDK는 다른 GitLab 구성 요소와 함께 Prometheus 서버나 node_exporter를 실행하도록 설정되어 있지 않습니다. 그렇게 하고 싶다면, Prometheus로 GDK 모니터링하기가 좋은 시작점입니다.

GCK는 Prometheus 기반 서비스 핑(Service Ping) 테스트에 대한 지원이 제한적입니다.

기본적으로 여러 구성 요소에서 데이터를 스크랩하도록 설정된 완전히 구성된 Prometheus 서비스가 제공됩니다.

그러나 다음과 같은 제한 사항이 있습니다:

  • gitlab-exporter 인스턴스를 실행하지 않기 때문에 Gitaly와 같은 서비스에서 process_* 메트릭이 누락될 수 있습니다.
  • node_exporter를 실행하지만, docker-compose 서비스는 호스트를 에뮬레이트하므로 보통 다른 실행 중인 서비스와 연관되지 않은 것으로 보고됩니다. 이는 프로덕션 설정에서 node_exporter가 항상 다른 GitLab 구성 요소와 함께 프로세스로 실행되는 방식과 다릅니다. 따라서 서비스 핑의 경우 모든 노드 데이터가 실행 중인 서비스와 연관되지 않게 됩니다. 이 문제를 완화하기 위해, GCK의 node_exporter는 임의로 web 서비스에 “할당”되어, 이 서비스에 대해서만 node_* 메트릭이 서비스 핑에 나타납니다.

서비스 핑 생성

Rails 콘솔에서 캐시된 서비스 핑 생성 또는 가져오기

다음 방법을 사용하여 rails 콘솔에서 수행합니다.

Gitlab::Usage::ServicePingReport.for(output: :all_metrics_values, cached: true)

새로운 서비스 핑 생성

다음 방법을 사용하여 rails 콘솔에서 수행합니다.

이 방법은 관리자 영역에 표시되는 캐시된 서비스 핑을 새로 고칩니다.

Gitlab::Usage::ServicePingReport.for(output: :all_metrics_values)

오늘의 사용 데이터가 포함된 새로운 서비스 핑 생성

다음 방법을 사용하여 rails 콘솔에서 수행합니다.

require_relative 'spec/support/helpers/service_ping_helpers.rb'

ServicePingHelpers.get_current_service_ping_payload

# 단일 메트릭의 값을 가져오려면, 메트릭의 key_path를 다음과 같이 제공하십시오:
ServicePingHelpers.get_current_usage_metric_value('counts.count_total_render_duo_pro_lead_page')

생성 및 출력

JSON 형식으로 서비스 핑 데이터를 생성합니다.

gitlab-rake gitlab:usage_data:generate

YAML 형식으로 서비스 핑 데이터를 생성합니다:

gitlab-rake gitlab:usage_data:dump_sql_in_yaml

서비스 핑 생성 및 전송

conversational_development_index_metrics에 저장된 메트릭을 출력합니다.

gitlab-rake gitlab:usage_data:generate_and_send