GitLab은 자체 모니터링을 위해 Prometheus 메트릭을 제공합니다.

새 메트릭 추가#

이 섹션에서는 자체 모니터링을 위한 새 메트릭을 추가하는 방법을 설명합니다 (예시).

• 메트릭 유형을 선택합니다:

  Gitlab::Metrics.counter

  • Gitlab::Metrics.gauge

  • Gitlab::Metrics.histogram

  • Gitlab::Metrics.summary

• 메트릭에 적절한 이름을 선택합니다. Prometheus 메트릭 이름에 대한 가이드라인을 참고하세요.

• GitLab Prometheus 메트릭 목록을 업데이트합니다.

• 메트릭에 추가할 라벨을 신중하게 선택합니다. project_path나 project_id와 같이 카디널리티가 높은 값은 강력히 권장하지 않습니다. 이러한 값은 라벨 조합마다 /metrics 엔드포인트에 새 항목으로 노출되기 때문에 서비스 가용성에 영향을 줄 수 있습니다. 예를 들어, 버킷이 10개이고 값이 100개인 라벨을 가진 히스토그램은 익스포트 엔드포인트에 1000개의 항목을 생성합니다.

• 새 메트릭을 기록하는 관련 페이지나 코드를 실행합니다.

• /-/metrics에 새 메트릭이 나타나는지 확인합니다.

특정 컨텍스트(request, process, machine, namespace 등)에 종속되지 않은 메트릭의 경우, cron 기반 Sidekiq job에서 생성하세요:

• Geo 관련 메트릭은 Geo::MetricsUpdateService를 확인하세요.

• 그 외 "전역" / 인스턴스 전체 메트릭은 Metrics::GlobalMetricsUpdateService를 확인하세요.

멀티 인스턴스 배포 환경에서 Sidekiq을 통해 메트릭을 내보낼 때:

• 동일한 익스포터가 일관되게 쿼리된다는 보장이 없습니다.

• 이는 게이지 메트릭에서 특히 문제가 됩니다. 각 Sidekiq 워커는 해당 워커가 메트릭 수집 코드를 다시 실행할 때까지 마지막으로 기록된 값을 계속 보고하기 때문입니다.

• 이로 인해 모니터링 시스템 전반에 걸쳐 메트릭 데이터가 일관성이 없거나 오래된 데이터로 남을 수 있습니다.

더 안정적인 메트릭 수집을 위해서는 gitlab-exporter에 커스텀 익스포터를 생성하는 것을 고려하세요.

자세한 내용은 이슈 406583을 참고하세요. 해당 이슈에서는 푸시 게이트웨이를 사용한 가능한 해결책도 논의하고 있습니다.