• 분산 요청을 조사하기 위한 상관 ID 사용
  • 상관 ID 작업을 위한 개발자 가이드라인
• 분산 추적 활성화
• GitLab 개발 키트에서 Jaeger 사용하기
• GitLab 개발자 키트 없이 Jaeger 사용하기
  • 1. Jaeger 시작하기
    • Docker 사용하기
    • Jaeger 프로세스 사용하기
  • 2. GITLAB_TRACING 환경 변수 설정
  • 3. GitLab 애플리케이션 시작하기
  • 4. Jaeger 검색 UI 열기

분산 추적 개발 가이드라인

GitLab은 분산 추적을 위해 계측되어 있습니다. GitLab의 분산 추적은 현재 실험적으로 간주되며, GitLab.com에서 대규모로 테스트되지 않았습니다.

Open Tracing에 따르면:

분산 추적, 즉 분산 요청 추적은 마이크로서비스 아키텍처를 사용하여 구축된 애플리케이션을 프로파일링하고 모니터링하는 데 사용되는 방법입니다. 분산 추적은 실패가 발생하는 위치와 성능 저하의 원인을 정확하게 찾아내는 데 도움을 줍니다.

분산 추적은 요청이 GitLab 애플리케이션의 다양한 구성 요소를 통과할 때 생애 주기를 이해하는 데 특히 유용합니다. 현재 Workhorse, Rails, Sidekiq 및 Gitaly가 추적 계측을 지원합니다.

분산 추적은 비활성화할 때 최소한의 오버헤드를 추가하지만, 활성화할 때는 소량의 오버헤드만 발생하므로 생산 환경을 포함한 모든 환경에서 사용 가능합니다. 이러한 이유로, 이는 특히 성능 문제를 포함한 생산 문제를 진단하는 데 유용할 수 있습니다.

서비스마다 분산 추적에 대한 지원 수준이 다릅니다. 가장 일반적인 라이브러리에 대한 사전 구축된 계측 외에도 애플리케이션 계층에 사용자 정의 계측 코드를 추가해야 합니다.

서비스별 정보는 다음을 참조하세요:

• Gitaly 로컬 개발을 위한 Jaeger 사용

분산 요청을 조사하기 위한 상관 ID 사용

GitLab 애플리케이션은 요청의 다양한 구성 요소 간에 상관 ID를 전달합니다. 상관 ID는 단일 요청에 고유한 토큰으로, 서로 다른 GitLab 하위 시스템 간에 단일 요청을 연결하는 데 사용됩니다 (예: Rails, Workhorse). 상관 ID는 로그 출력에 포함되므로, 엔지니어는 상관 ID를 사용하여 서로 다른 하위 시스템의 로그를 연결하고 시스템을 통한 요청의 종단 간 경로를 더 잘 이해할 수 있습니다. 요청이 프로세스 경계를 가로지를 때, 상관 ID는 아웃고잉 요청에 삽입됩니다. 이렇게 하면 각 다운스트림 하위 시스템으로의 상관 ID 전달이 가능해집니다.

상관 ID는 일반적으로 특정 웹 요청에 대한 응답으로 Rails 애플리케이션에서 생성됩니다. 일부 사용자 대면 시스템은 사용자 요청에 응답으로 상관 ID를 생성하지 않습니다 (예: SSH를 통한 Git 푸시).

상관 ID 작업을 위한 개발자 가이드라인

새 시스템에 추적을 통합할 때, 개발자는 상관 ID에 대한 특정 가정을 피해야 합니다. 다음 지침은 GitLab의 모든 하위 시스템에 적용됩니다:

• 상관 ID는 항상 선택 사항입니다.
  • 비추적 기능이 업스트림 시스템의 상관 ID 존재에 의존하지 않도록 하십시오.
• 상관 ID는 항상 자유 텍스트입니다.
  • 상관 ID는 컨텍스트를 전달하는 데 사용되지 않아야 합니다 (예: 사용자 이름 또는 IP 주소).
  • 상관 ID는 절대 _구문 분석_되거나 다른 방식으로 조작되어서는 안 됩니다 (예: 분할).

LabKit 라이브러리는 Go 프로그래밍 언어에서 GitLab 상관 ID를 사용하기 위한 표준화된 인터페이스를 제공합니다. LabKit은 비-Go GitLab 하위 시스템에서 추적 및 상관 ID 작업을 수행하는 개발자를 위한 참조 구현으로 사용할 수 있습니다.

분산 추적 활성화

GitLab은 GITLAB_TRACING 환경 변수를 사용하여 분산 추적을 구성합니다. 동일한 설정이 모든 구성 요소(예: Workhorse, Rails 등)에 사용됩니다.

GITLAB_TRACING가 설정되지 않으면 애플리케이션이 계측되지 않으며, 즉 오버헤드가 전혀 발생하지 않습니다.

GITLAB_TRACING를 활성화하려면 유효한 “configuration-string” 값을 설정해야 하며, URL 형식과 유사해야 합니다:

GITLAB_TRACING=opentracing://<driver>?<param_name>=<param_value>&<param_name_2>=<param_value_2>

이 예시에서는 다음과 같은 가상의 값이 있습니다:

• driver: Jaeger와 같은 드라이버.
• param_name, param_value: 이들은 드라이버 특정 구성 값입니다. Jaeger에 대한 구성 매개변수는 문서의 다음 부분에서 문서화되어 있으며, URL 인코딩되어야 합니다. 여러 값은 URL처럼 & 문자로 구분해야 합니다.

GitLab Rails는 요청의 상세한 보기를 제공하는 일반 유형의 작업에 대해 미리 구현된 계측을 제공합니다. 그러나 상세 정보는 대가를 필요로 합니다. 결과적으로 생성된 추적은 길고 처리하기 어려워져, 더 큰 근본 문제를 식별하기 어렵게 만듭니다. 이 문제를 해결하기 위해, 일부 계측은 기본적으로 비활성화되어 있습니다. 이러한 비활성화된 계측을 활성화하려면, 다음 환경 변수를 설정하십시오:

• GITLAB_TRACING_TRACK_CACHES: 캐시 읽기, 쓰기 또는 삭제와 같은 캐시 작업 추적 활성화.
• GITLAB_TRACING_TRACK_REDIS: Redis 작업 추적 활성화. 대부분의 Redis 작업은 캐싱을 위한 것입니다.

GitLab 개발 키트에서 Jaeger 사용하기

GitLab이 지원하는 첫 번째 트레이싱 구현은 Jaeger이며, GitLab 개발 키트는 Jaeger와 함께 분산 트레이싱을 기본적으로 지원합니다. GDK는 서비스 추가를 위해 GITLAB_TRACING 환경 변수를 자동으로 추가합니다.

gdk.yml 파일을 편집하고 다음 설정을 추가하여 Jaeger에 대한 GDK를 구성하세요:

tracer:
  build_tags: tracer_static tracer_static_jaeger
  jaeger:
    enabled: true
    listen_address: 127.0.0.1
    version: 1.43.0

gdk.yml 파일을 수정한 후, gdk reconfigure 명령어를 실행하여 GDK를 재구성합니다. 이렇게 하면 GDK가 적절하게 구성되고 사용할 준비가 됩니다.

위의 구성은 처음으로 Go로 작성된 서비스를 재빌드할 때 tracer_static 및 tracer_static_jaeger 빌드 태그를 설정합니다. 그 이후에 변경된 사항은 이러한 빌드 태그로 재빌드해야 합니다. 다음 중 하나를 선택할 수 있습니다:

• 기본 빌드 태그 세트에 이러한 빌드 태그를 추가합니다.
• 빌드 명령어에 수동으로 추가합니다. 예를 들어, Gitaly는 기본적으로 빌드 태그 추가를 지원합니다. 다음과 같이 실행할 수 있습니다: make all WITH_BUNDLED_GIT=YesPlease BUILD_TAGS="tracer_static tracer_static_jaeger".

재구성이 완료되면 Jaeger 대시보드에 http://localhost:16686에서 접근할 수 있습니다. GDK 환경에서 트레이싱에 접근하는 또 다른 방법은 performance-bar를 통해 이루어질 수 있습니다. 브라우저 창에서 p b를 입력하여 표시할 수 있습니다.

성능 바가 활성화되면 성능 바에서 Trace를 선택하여 Jaeger UI로 이동하세요.

Jaeger 검색 UI는 현재 요청의 Correlation-ID에 대한 쿼리를 반환합니다. 이 검색은 단일 트레이스 결과를 반환해야 합니다. 이 결과를 선택하면 계층적 타임라인에서 트레이스의 세부 정보를 보여줍니다.

GitLab 개발자 키트 없이 Jaeger 사용하기

분산 트레이싱은 비-GDK 개발 환경과 생산 또는 스테이징 환경에서도 트러블슈팅을 위해 활성화할 수 있습니다. 현재 이 기능은 실험적이며, 현재 생산 환경에서는 지원되지 않습니다. 이번 첫 출시에서는 개발 환경에서 디버깅 용도로만 사용하도록 의도되었습니다.

Jaeger 트레이싱은 세 단계의 과정을 통해 활성화할 수 있습니다:

1. Jaeger 시작하기.
2. GITLAB_TRACING 환경 변수 구성하기.
3. GitLab 애플리케이션 시작하기.
4. 브라우저에서 Jaeger 검색 UI 열기.

1. Jaeger 시작하기

Jaeger는 많은 구성 옵션이 있지만, 트레이스 저장을 위해 메모리를 사용하는 “all-in-one” 모드에서 시작하는 것이 매우 쉽습니다(따라서 비영구적입니다). “all-in-one” 모드의 주요 이점은 사용의 용이성입니다.

자세한 구성 옵션은 Jaeger 문서를 참조하세요.

Docker 사용하기

Docker가 가능하다면, Jaeger all-in-one을 실행하는 더 쉬운 방법은 다음 명령어를 사용하여 Docker를 통해 하는 것입니다:

$ docker run \
  --rm \
  -e COLLECTOR_ZIPKIN_HTTP_PORT=9411  \
  -p 5775:5775/udp \
  -p 6831:6831/udp \
  -p 6832:6832/udp \
  -p 5778:5778 \
  -p 16686:16686 \
  -p 14268:14268 \
  -p 9411:9411 \
  jaegertracing/all-in-one:latest

Jaeger 프로세스 사용하기

Docker 없이도, 올인원 프로세스 설정이 여전히 쉽습니다.

1. 플랫폼에 맞는 최신 Jaeger 릴리즈를 다운로드합니다.
2. 아카이브를 추출하고 bin/all-in-one 프로세스를 실행합니다.

이렇게 하면 기본 수신 포트로 프로세스가 시작되어야 합니다.

2. GITLAB_TRACING 환경 변수 설정

Jaeger가 실행된 후, 적절한 구성 문자열로 GITLAB_TRACING 변수를 설정합니다.

모든 구성 요소가 동일한 호스트에서 실행되고 있다면, 다음 값을 사용하세요:

export GITLAB_TRACING="opentracing://jaeger?http_endpoint=http%3A%2F%2Flocalhost%3A14268%2Fapi%2Ftraces&sampler=const&sampler_param=1"

이 구성 문자열은 다음 옵션을 가진 Jaeger 드라이버 opentracing://jaeger를 사용합니다:

기타 매개변수 값도 가능합니다:

참고:

같은 GITLAB_TRACING 값을 모든 GitLab 프로세스의 환경 변수에 구성해야 합니다. 여기에는 Workhorse, Gitaly, Rails 및 Sidekiq가 포함됩니다.

3. GitLab 애플리케이션 시작하기

GITLAB_TRACING 환경 변수가 모든 GitLab 서비스에 내보내지면 애플리케이션을 시작합니다.

GITLAB_TRACING가 올바르게 구성되면, 애플리케이션은 시작 시 다음과 같이 로그를 기록합니다:

13:41:53 gitlab-workhorse.1      | 2019/02/12 13:41:53 Tracing enabled
...
13:41:54 gitaly.1                | 2019/02/12 13:41:54 Tracing enabled
...

GITLAB_TRACING가 올바르게 구성되지 않으면, 다음과 같은 문제 로그가 기록됩니다:

13:43:45 gitaly.1                | 2019/02/12 13:43:45 skipping tracing configuration step: tracer: unable to load driver mytracer

기본적으로 GitLab은 Jaeger 트레이서를 포함하지만, 다른 트레이서를 컴파일 시간에 포함할 수 있습니다. 이를 수행하는 방법에 대한 자세한 내용은 LabKit 트레이싱 문서를 참조하세요.

트레이싱에 대한 로그 메시지가 출력되지 않으면, GITLAB_TRACING 환경 변수가 설정되지 않은 것일 수 있습니다.

4. Jaeger 검색 UI 열기

기본적으로, Jaeger 검색 UI는 http://localhost:16686/search에서 사용할 수 있습니다.

참고: Jaeger UI에 트레이스가 나타나기 전에 애플리케이션을 사용하여 트레이스를 생성해야 한다는 것을 잊지 마세요.