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

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

모니터링은 애플리케이션을 유지보수하고 최적화하는 데 중요한 부분입니다. GitLab의 가시성 기능은 오류를 추적하고 애플리케이션 성능을 분석하며 사건에 대응하는 데 도움이 됩니다.

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

이러한 모든 기능은 독립적으로 사용할 수 있습니다. 예를 들어, 추적 또는 사건 추적 없이 오류 추적을 사용할 수 있습니다. 그러나 가장 좋은 경험을 위해서는 이러한 모든 기능을 함께 사용하세요.

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

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

여러 서비스와 저장소가 있는 대규모 애플리케이션의 경우 시스템의 여러 구성 요소에서 수집된 모든 텔레메트리 데이터를 중앙 집중화하기 위해 전용 프로젝트를 만들어야 합니다. 이 방식은 여러 가지 이점을 제공합니다.

• 데이터는 모든 개발 및 운영 팀이 액세스할 수 있으므로 협업이 용이합니다.
• 다양한 소스에서 수집된 데이터를 한 곳에서 질의하고 연관시킬 수 있어 조사를 가속화합니다.
• 모든 가시성 데이터에 대한 단일 정보원을 제공하여 유지 및 업데이트를 더 쉽게 만듭니다.
• 단일 프로젝트에서 사용자 권한을 중앙 집중화함으로써 관리자의 액세스 관리를 간소화합니다.

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

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

• 프로젝트 생성

단계 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 등에 내보내는 프록시 역할을 합니다. 이는 오픈소스이며 벤더에 중립적으로 사용 가능하여 호환되는 도구로 사용하여 벤더 락인을 방지할 수 있습니다.

수집기 사용의 장점:

• 단숨성: 애플리케이션 서비스는 하나의 대상(수집기)으로 데이터를 전송합니다.
• 유연성: 단일 위치에서 데이터 대상을 추가하거나 변경합니다(다중 벤더 사용 시).
• 고급 기능: 데이터 샘플링, 일괄 처리, 데이터 압축.
• 일관성: 일관된 데이터 처리.
• 관리: 중앙 집중구성.

OpenTelemetry Collector 구성

1. 빠른 시작 설치
2. 배포 방법 선택 (에이전트 또는 게이트웨이)

3. 데이터 수집 구성 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로 데이터를 전송하세요. 애플리케이션 및 수집기가 동일한 호스트에 있는 경우 애플리케이션을 다음과 같이 전송하세요.

   OTEL_EXPORTER_OTLP_ENDPOINT=http://localhost:4318 \
   

설정 테스트

데이터 수집 설정을 완료한 후에는 Monitor 탐색 메뉴에서 수집된 데이터를 시각화할 수 있습니다. 추적(Tracing), 메트릭(Metrics) 및 로그(Logs) 페이지를 사용하여 이 정보에 액세스할 수 있습니다. 이러한 기능들은 애플리케이션의 건강상태와 성능을 종합적으로 파악하여 발견된 문제를 해결하는 데 도움이 됩니다.

더 많은 정보는 다음을 참조하십시오:

• 분산 추적
• 메트릭
• 로그

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

애플리케이션 인프라의 성능과 가용성을 모니터링하기 위해, 먼저 이전에 설명한 대로 OpenTelemetry Collector를 설치하십시오. 그런 다음, 설정에 따라 여러 방법을 사용하여 메트릭과 로그 데이터를 수집할 수 있습니다:

• 호스트 수준, OS 메트릭의 경우: 호스트 시스템에서 CPU, 메모리, 디스크 및 네트워크 메트릭을 수집하는 호스트 메트릭와 같은 수신기와 함께 OpenTelemetry Collector를 사용하십시오.
• 클라우드 기반 인프라의 경우: OpenTelemetry과 통합된 제공 업체의 모니터링 솔루션을 사용하십시오. 예를 들어, AWS CloudWatch나 Azure Monitor와 같은 수신기 등.
• 컨테이너화된 애플리케이션의 경우: Docker stats나 Kubelet stats와 같은 수신기를 사용하십시오.
• Kubernetes 클러스터의 경우: 외부 Kubernetes 가이드에 따르십시오.

단계 5: 경보 및 사건 관리

문제를 해결하고 공동으로 사건을 처리하기 위해 사건 관리 기능을 설정합니다.

더 많은 정보는 다음을 참조하십시오:

• 사건 관리

단계 6: 분석 및 개선

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

1. 문제를 분석하는 통찰 대시보드를 만들어 사건을 생성하고 종료하며, 인시던트 대응의 성능을 평가하십시오.
2. 당직 엔지니어가 자율적으로 인시던트를 해결하는 데 도움이 되는 실행 가능한 런북을 만듭니다.
3. 정기적으로 모니터링 설정을 검토하고 샘플링 임계값을 조정하거나 새로운 메트릭을 추가하십시오.
4. 사건 이후 리뷰를 실시하여 애플리케이션 및 인시던트 대응 프로세스를 개선할 수 있는 영역을 식별하십시오.
5. 모니터링에서 얻은 통찰을 활용하여 개발 우선 순위와 기술 부채 감소 노력에 정보를 제공하십시오.

더 많은 정보는 다음을 참조하십시오:

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