로컬에서 Service Ping 설정 및 테스트#

Service Ping을 로컬에서 설정하려면 다음을 수행해야 합니다:

• 로컬 리포지터리 설정.

• 로컬 설정 테스트.

• 선택 사항. Prometheus 기반 Service Ping 테스트.

로컬 리포지터리 설정#

• GitLab을 클론하고 시작합니다.

• Versions Application을 클론하고 시작합니다. PostgreSQL 및 Redis 인스턴스를 시작하려면 docker-compose up을 실행해야 합니다.

• 기본 엔드포인트 대신 Versions Application 엔드포인트를 가리키도록 GitLab을 설정합니다:

service_ping/submit_service.rb를 로컬에서 열고 STAGING_BASE_URL을 수정합니다.

• 로컬 Versions Application URL로 설정합니다: http://localhost:3000.

로컬 설정 테스트#

• gitlab Rails 콘솔을 사용하여 Service Ping을 수동으로 트리거합니다:

GitlabServicePingWorker.new.perform('triggered_from_cron' => false)

• versions Rails 콘솔을 사용하여 Service Ping이 성공적으로 수신되고, 파싱되어 Versions 데이터베이스에 저장되었는지 확인합니다:

UsageData.last

Prometheus 기반 Service Ping 테스트#

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

• Prometheus 서버가 로컬에서 실행 중인지 확인합니다.

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

Prometheus에서 오는 데이터를 테스트할 필요가 없다면 추가 작업은 필요하지 않습니다. Service Ping은 Prometheus 서버가 실행되지 않는 경우에도 정상적으로 성능이 저하됩니다.

Prometheus로 데이터를 내보낼 수 있는 세 가지 유형의 구성 요소가 있으며, Service Ping에 포함됩니다:

• node_exporter: 호스트 머신에서 노드 메트릭을 내보냅니다.

• gitlab-exporter: 다양한 GitLab 구성 요소에서 프로세스 메트릭을 내보냅니다.

• Sidekiq 및 Rails 서버와 같은 기타 다양한 GitLab 서비스로, 자체 메트릭을 내보냅니다.

Omnibus 컨테이너로 테스트#

Prometheus 기반 Service Ping을 테스트하는 데 권장되는 방법입니다.

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

• 머지 리퀘스트에서 qa Stage를 선택한 다음 e2e:test-on-omnibus-ee job을 트리거합니다. 이 job은 omnibus-gitlab-mirror 프로젝트의 다운스트림 파이프라인에서 Omnibus 빌드를 트리거합니다.

• 다운스트림 파이프라인에서 gitlab-docker job이 완료될 때까지 기다립니다.

• job 로그를 열고 버전을 포함한 전체 컨테이너 이름을 찾습니다. 형식은 다음과 같습니다: registry.gitlab.com/gitlab-org/build/omnibus-gitlab-mirror/gitlab-ee:.

• 로컬 머신에서 GitLab Docker 레지스트리에 로그인되어 있는지 확인합니다. 관련 지침은 GitLab 컨테이너 레지스트리 인증에서 확인할 수 있습니다.

• 로그인 후 docker pull registry.gitlab.com/gitlab-org/build/omnibus-gitlab-mirror/gitlab-ee:을 사용하여 새 이미지를 다운로드합니다.

• 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 구성 요소와 함께 프로세스로 실행되는 프로덕션 설정에서 노드 메트릭이 보고되는 방식과 다릅니다. Service Ping의 경우, 노드 데이터 중 어느 것도 실행 중인 서비스와 연결된 것으로 나타나지 않습니다. 모두 다른 호스트에서 실행되는 것으로 보이기 때문입니다. 이 문제를 완화하기 위해 GCK의 node_exporter는 임의로 web 서비스에 "할당"되었으며, 이 서비스에 대해서만 node_* 메트릭이 Service Ping에 표시됩니다.

Service Ping 생성#

Rails 콘솔에서 캐시된 Service Ping 생성 또는 가져오기#

Rails 콘솔에서 다음 메서드를 사용합니다.

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

새 Service Ping 생성#

Rails 콘솔에서 다음 메서드를 사용합니다.

이 작업은 Admin 영역에 표시된 캐시된 Service Ping도 새로 고칩니다.

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

오늘의 사용 데이터를 포함한 새 Service Ping 생성#

Rails 콘솔에서 다음 메서드를 사용합니다.

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

ServicePingHelpers.get_current_service_ping_payload

# To get a single metric's value, provide the metric's key_path like so:
ServicePingHelpers.get_current_usage_metric_value('counts.count_total_render_duo_pro_lead_page')

생성 및 출력#

Service Ping 데이터를 JSON 형식으로 생성합니다.

gitlab-rake gitlab:usage_data:generate

Service Ping 데이터를 YAML 형식으로 생성합니다:

gitlab-rake gitlab:usage_data:dump_sql_in_yaml

Service Ping 생성 및 전송#

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

gitlab-rake gitlab:usage_data:generate_and_send