Prometheus 메트릭 개발 지침
라이브러리에 추가하기
우리는 Prometheus를 지원하는 각 공통 시스템 서비스에 대해 2-4가지 가장 중요한 메트릭을 지원하기 위해 노력합니다. 라이브러리에 아직 추가되지 않은 특정 익스포터의 지원을 찾고 있다면, common_metrics.yml 파일에 추가할 수 있습니다.
쿼리 식별자
새로운 메트릭을 추가하는 요구 사항은 변경 시 메트릭을 나중에 업데이트하는 데 사용되는 각 쿼리에 고유한 식별자를 만드는 것입니다:
- 그룹: 응답 메트릭 (NGINX Ingress)
메트릭:
- 제목: "처리량"
y축:
이름: "초당 요청"
형식: "숫자"
정밀도: 2
쿼리:
- id: response_metrics_nginx_ingress_throughput_status_code
query_range: 'sum(rate(nginx_upstream_responses_total{upstream=~"%{kube_namespace}-%{ci_environment_slug}-.*"}[2m])) by (status_code)'
단위: req / sec
라벨: 상태 코드
기존 메트릭 업데이트
공통 메트릭을 추가하거나 변경한 후, 모든 기존 메트릭을 쿼리하고 업데이트하는 import script를 다시 실행해야 합니다.
또는 데이터베이스 마이그레이션을 생성할 수 있습니다:
class ImportCommonMetrics < Gitlab::Database::Migration[2.1]
def up
::Gitlab::DatabaseImporters::CommonMetrics::Importer.new.execute
end
def down
# 무작위 작업
end
end
쿼리 메트릭 (id:
로 식별)이 제거된 경우, 기본적으로 데이터베이스에서 제거되지 않습니다.
제거된 메트릭에 대한 결정을 내리는 추가 데이터베이스 마이그레이션을 추가하는 것이 좋습니다.
예를 들어: 종속 데이터를 다른 메트릭으로 마이그레이션하는 것이 관심사일 수 있습니다.
GitLab Prometheus 메트릭
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
등)에 대한 경우, 크론 기반의 Sidekiq 작업에서 생성합니다:
- Geo 관련 메트릭의 경우,
Geo::MetricsUpdateService
를 확인하세요. - 다른 “전역” / 인스턴스 전체 메트릭의 경우,
Metrics::GlobalMetricsUpdateService
를 확인하세요.
여러 Sidekiq 인스턴스가 있는 설치에서 Sidekiq에서 데이터를 익스포트하는 경우, 항상 동일한 익스포터가 쿼리될 것이라는 보장은 없습니다.
이슈 406583에서 더 많은 정보를 읽고 주의 사항을 이해하실 수 있으며, 푸시 게이트웨이를 사용하여 가능한 해결책에 대해 논의합니다.