• 1단계: 사용할 프로젝트 결정하기
• 2단계: 오류 추적으로 애플리케이션 오류 추적하기
• 3단계: 트레이싱, 메트릭 및 로그로 애플리케이션 성능 모니터링하기
  • 베타 기능 활성화하기
  • OpenTelemetry를 사용하여 애플리케이션 계측하기
    • 직접 계측
    • OpenTelemetry Collector 사용 (권장)
  • 설정 테스트
• 4단계: 메트릭과 로그로 인프라 모니터링
• 5단계: 경고 및 사고 관리
• 6단계: 분석 및 개선

GitLab에서 애플리케이션 모니터링 시작하기

모니터링은 애플리케이션을 유지하고 최적화하는 데 중요한 부분입니다.

GitLab의 가시성 기능은 오류를 추적하고, 애플리케이션 성능을 분석하며, 사건에 대응하는 데 도움을 줍니다.

이 기능들은 더 큰 DevOps 워크플로의 일부입니다:

이 모든 기능은 독립적으로 사용할 수 있습니다. 예를 들어, 오류 추적 없이 트레이싱이나 사건을 사용할 수 있습니다. 그러나 최상의 경험을 위해 이 모든 기능을 함께 사용하는 것이 좋습니다.

1단계: 사용할 프로젝트 결정하기

모니터링을 위해 애플리케이션 소스 코드를 저장하는 데 이미 사용하는 동일한 프로젝트를 사용할 수 있습니다.

여러 서비스와 리포지토리를 가진 대규모 애플리케이션의 경우, 시스템의 다양한 구성 요소에서 수집된 모든 원시 데이터(telemetry data)를 중앙화하기 위해 전용 프로젝트를 만드는 것이 좋습니다.

이 접근 방식은 몇 가지 장점을 제공합니다:

• 데이터는 모든 개발 및 운영 팀이 접근할 수 있어 협업을 촉진합니다.
• 서로 다른 소스의 데이터가 한 곳에서 쿼리되고 상관관계가 있을 수 있어 조사가 가속화됩니다.
• 모든 가시성 데이터에 대한 단일 진실 출처가 제공되어 유지 관리 및 업데이트가 용이합니다.
• 관리자는 단일 프로젝트에서 사용자 권한을 중앙화하여 액세스 관리를 단순화할 수 있습니다.

가시성 기능을 활성화하려면 해당 프로젝트에 대한 관리자 또는 소유자 역할이 필요합니다.

자세한 내용은 다음을 참조하세요:

• 프로젝트 생성하기

2단계: 오류 추적으로 애플리케이션 오류 추적하기

오류 추적은 애플리케이션의 오류를 식별, 우선 순위 지정 및 디버그하는 데 도움을 줍니다.

애플리케이션에서 생성된 오류는 Sentry SDK에 의해 수집되어 GitLab 또는 Sentry 백엔드에 저장됩니다.

자세한 내용은 다음을 참조하세요:

• 오류 추적 작동 방식

3단계: 트레이싱, 메트릭 및 로그로 애플리케이션 성능 모니터링하기

베타 기능 활성화하기

다음 기능은 닫힌 베타에서 제공됩니다:

• 분산 트레이싱: 여러 서비스에서 애플리케이션 요청을 추적합니다.
• 메트릭: 요청 지연, 트래픽, 오류 비율 또는 포화와 같은 애플리케이션 및 인프라 성능 메트릭을 모니터링합니다.
• 로그: 애플리케이션 및 인프라 로그를 중앙 집중화하고 분석합니다.

이 기능을 사용할 수 있도록 하려면 관리자가 귀하의 프로젝트 또는 그룹에 대해 observability_features라는 기능 플래그를 활성화해야 합니다. 이러한 기능이 활성화된 후, 데이터 수집을 설정할 수 있습니다.

OpenTelemetry를 사용하여 애플리케이션 계측하기

트레이스, 메트릭 및 로그는 애플리케이션에서 생성되어 OpenTelemetry에 의해 수집된 후 GitLab 백엔드에 저장됩니다.

OpenTelemetry는 텔레메트리 데이터를 생성, 수집 및 내보내는 데 필요한 도구, API 및 SDK 집합을 제공하는 오픈 소스 가시성 프레임워크입니다.

OpenTelemetry Collector는 이 프레임워크의 주요 구성 요소입니다.

직접 계측 또는 OpenTelemetry Collector를 사용하여 GitLab에 텔레메트리 데이터를 수집하고 전송할 수 있습니다. 다음 표는 두 가지 방법을 비교합니다:

방법	장점	단점
직접 계측	- 설정이 간단함 - 인프라 변경 없음	- 덜 유연함 - 데이터 샘플링이나 처리 없음 - 높은 볼륨의 데이터 생성 가능
OpenTelemetry Collector	- 중앙 집중식 구성 - 데이터 샘플링 및 처리 가능 - 데이터 볼륨 제어 가능	- 설정이 더 복잡함 - 인프라 변경 필요

대부분의 설정에서 OpenTelemetry Collector를 사용하는 것이 좋습니다, 특히 애플리케이션이 복잡해질 가능성이 높은 경우에는 더욱 그렇습니다.

그러나 작은 애플리케이션과 테스트 목적으로는 직접 계측이 더 간단할 수 있습니다.

직접 계측

애플리케이션 코드를 계측하여 수집기를 사용하지 않고 GitLab에 원격 데이터 텔레메트리를 직접 보낼 수 있습니다.

프로그래밍 언어나 프레임워크에 따라 가이드를 선택하세요:

• Ruby on Rails

• Node JS

• Python Django

• Java Spring

• .NET

다른 언어의 경우 적절한 OpenTelemetry API 또는 SDK를 사용하세요.

OpenTelemetry Collector 사용 (권장)

복잡한 애플리케이션 설정의 경우 OpenTelemetry Collector를 사용해야 합니다.

OpenTelemetry Collector란 무엇인가요?

OpenTelemetry Collector는 애플리케이션에서 모니터링 도구인 GitLab Observability로 텔레메트리 데이터를 수신, 처리 및 내보내는 프록시 역할을 합니다. 오픈 소스이며 벤더 중립적이므로 호환되는 모든 도구와 함께 사용할 수 있으며 벤더 종속성을 피할 수 있습니다.

Collector를 사용하여 얻는 이점:

• 단순성: 애플리케이션 서비스는 단일 목적지(Collector)로만 데이터를 전송합니다.

• 유연성: 단일 위치에서 데이터 목적지를 추가하거나 변경할 수 있습니다(여러 벤더를 사용하는 경우).

• 고급 기능: 데이터 샘플링, 배치, 압축.

• 일관성: 균일한 데이터 처리.

• 거버넌스: 중앙 집중식 구성.

OpenTelemetry Collector 구성하기

1. 빠른 시작 설치

2. 배포 방법 선택하기 (에이전트 또는 게이트웨이)

3. 데이터 수집 구성
   Collector의 config.yaml 파일에 GitLab 엔드포인트를 내보내기로 추가합니다:

   exporters:
     otlphttp/gitlab:
       endpoint: https://gitlab.com/api/v4/projects/<project_id>/observability/
       headers:
         "private-token": "<your_token>"
   
   service:
     pipelines:
       traces:
         exporters: [spanmetrics, otlphttp/gitlab]
       metrics:
         exporters: [otlphttp/gitlab]
       logs:
         exporters: [otlphttp/gitlab]
   

   다음 값으로 자리 표시자를 바꿉니다:

   • <project_id>: 프로젝트 ID. 프로젝트 홈페이지에서, 오른쪽 상단 모서리에서 수직 생략 기호 ()를 선택한 다음 프로젝트 ID 복사를 선택합니다.

   • <your_token>: Developer 역할과 api 범위로 프로젝트에서 생성된 액세스 토큰입니다. 프로젝트의 설정 > 액세스 토큰에서 토큰을 생성합니다.

   • gitlab.com: 자가 관리 인스턴스를 실행하는 경우 GitLab 호스트로 바꿉니다.

4. 애플리케이션을 계측하여 Collector로 데이터를 전송합니다.
   위의 언어별 가이드를 사용하되 GitLab 대신 Collector를 지정하세요.
   예를 들어, 애플리케이션과 Collector가 동일한 호스트에 있는 경우, 애플리케이션을 이 URL로 전송하세요:

   OTEL_EXPORTER_OTLP_ENDPOINT=http://localhost:4318 \
   

설정 테스트

데이터 수집을 설정한 후, 모니터 탐색 메뉴를 통해 프로젝트에서 수집된 데이터를 시각화할 수 있습니다.

Tracing, Metrics, 및 Logs 페이지를 사용하여 이 정보를 접근할 수 있습니다. 이러한 기능은 함께 작동하여 애플리케이션의 상태와 성능에 대한 포괄적인 보기를 제공하며, 발견된 문제를 해결하는 데 도움을 줍니다.

자세한 내용은 다음을 참조하세요:

• 분산 추적
• 지표
• 로그

4단계: 메트릭과 로그로 인프라 모니터링

애플리케이션의 인프라 성능과 가용성을 모니터링하려면, 먼저 이전에 설명한 대로 OpenTelemetry Collector를 설치합니다. 그러면, 설정에 따라 메트릭 및 로그 데이터를 수집하는 다양한 방법을 사용할 수 있습니다:

• 호스트 수준의 OS 메트릭: OpenTelemetry Collector와 Host Metrics와 같은 수신기를 사용하세요. 이 수신기는 호스트 시스템에서 CPU, 메모리, 디스크 및 네트워크 메트릭을 수집합니다.
• 클라우드 기반 인프라: OpenTelemetry와 통합된 공급자의 모니터링 솔루션을 사용하세요. 예를 들어, AWS CloudWatch 또는 Azure Monitor와 같은 수신기를 사용할 수 있습니다.
• 컨테이너화된 애플리케이션: Docker stats 또는 Kubelet stats와 같은 수신기를 사용하세요.
• Kubernetes 클러스터: 외부 Kubernetes 가이드를 따르세요.

5단계: 경고 및 사고 관리

사고 관리 기능을 설정하여 문제를 해결하고 사건을 공동으로 해결하세요.

자세한 내용은 다음을 참조하세요:

• 사고 관리

6단계: 분석 및 개선

수집된 데이터와 통찰력을 사용하여 애플리케이션과 모니터링 프로세스를 지속적으로 개선하세요:

1. 문제 또는 사건 작성 및 종료를 분석하고 사건 대응 성능을 평가하기 위해 통찰력 대시보드를 생성하세요.

2. 엔지니어가 자율적으로 사건을 해결할 수 있도록 도움이 되는 실행 가능한 런북을 만드세요.

3. 모니터링 설정을 정기적으로 검토하고 샘플링 임계값을 조정하거나 애플리케이션이 발전함에 따라 새로운 메트릭을 추가하세요.

4. 사건 후 검토를 수행하여 애플리케이션과 사건 대응 프로세스 모두의 개선이 필요한 영역을 식별하세요.

5. 모니터링에서 얻은 통찰력을 사용하여 개발 우선 순위와 기술 부채 감소 노력을 알리세요.

자세한 내용은 다음을 참조하세요:

• 통찰력 대시보드
• 실행 가능한 런북