Prometheus를 사용한 GitLab 모니터링

Tier: Free, Premium, Ultimate Offering: 자체 관리

Prometheus은 유연한 플랫폼을 제공하여 GitLab 및 다른 소프트웨어 제품을 모니터링하는 강력한 시계열 모니터링 서비스입니다.

GitLab은 Prometheus를 통해 즉시 사용 가능한 모니터링을 제공하여 GitLab 서비스의 고품질 시계열 모니터링에 접근할 수 있습니다.

이 페이지에 나열된 Prometheus 및 다양한 익스포터는 Linux 패키지에 번들로 제공됩니다. 각 익스포터가 추가된 타임라인에 대한 자세한 내용은 해당 익스포터의 문서를 확인하십시오. 사용자 지정 설치의 경우 해당 익스포터를 직접 설치해야 합니다. 추가적인 GitLab 메트릭은 후속 릴리스에서 캡처됩니다.

Prometheus 서비스는 기본적으로 활성화되어 있습니다.

Prometheus 및 해당 익스포터는 사용자를 인증하지 않으며, 해당 서비스에 액세스할 수 있는 모든 사람에게 사용 가능합니다.

Prometheus 작동 방식

Prometheus는 주기적으로 데이터 소스에 연결하여 다양한 익스포터를 통해 성능 메트릭을 수집함으로써 작동합니다. 모니터링 데이터를 보거나 처리하려면 Prometheus에 직접 연결하거나 Grafana와 같은 대시보드 도구를 사용할 수 있습니다.

Prometheus 구성

사용자 지정 설치의 경우 직접 설치 및 구성해야 합니다.

Prometheus 및 해당 익스포터는 기본적으로 활성화되어 있습니다. Prometheus는 gitlab-prometheus 사용자로 실행되며 http://localhost:9090에서 수신 대기합니다. 기본적으로 Prometheus는 GitLab 서버에서만 액세스할 수 있습니다. 각 익스포터는 Prometheus의 모니터링 대상으로 자동 설정되어 있으며, 개별적으로 비활성화되지 않는 한 해당 대상으로 간주됩니다.

모든 추가된 Prometheus 및 해당 익스포터를 비활성화하려면 다음 단계를 수행하십시오.

  1. /etc/gitlab/gitlab.rb 파일을 편집합니다.

  2. 아래 내용을 찾거나 주석 처리 해제하며 해당 줄이 false로 설정되어 있는지 확인합니다. 

    prometheus_monitoring['enable'] = false
sidekiq['metrics_enabled'] = false

# 기본적으로 `false`로 설정되어 있지만 명시적으로 비활성화하여 확인합니다.
puma['exporter_enabled'] = false
  3. 파일을 저장하고 변경 사항이 적용되도록 GitLab을 다시 구성합니다.

Prometheus 수신 대기 포트 및 주소 변경

경고: Prometheus의 수신 대기 포트를 변경하는 것은 다른 GitLab 서버에서 실행 중인 다른 서비스에 영향을 줄 수 있으므로 권장되지 않습니다. 진행하는 경우 개인 책임하에 진행하십시오.

GitLab 서버 외부에서 Prometheus에 액세스하려면 Prometheus의 수신 대기 주소/포트를 변경하십시오.

  1. /etc/gitlab/gitlab.rb 파일을 편집합니다.

  2. 아래 내용을 찾거나 주석 처리 해제하며 아래의 내용으로 변경합니다. 

    prometheus['listen_address'] = 'localhost:9090'

    localhost:9090을 원하는 주소 혹은 포트로 변경합니다. localhost 외의 호스트에서 Prometheus에 액세스하려면 호스트를 생략하거나 0.0.0.0을 사용하여 공개 액세스를 허용합니다. 

    prometheus['listen_address'] = ':9090'
# 또는
prometheus['listen_address'] = '0.0.0.0:9090'
  3. 파일을 저장하고 변경 사항이 적용되도록 GitLab을 다시 구성합니다.

사용자 지정 스크래이프 구성 추가

Linux 패키지에 번들로 제공된 Prometheus에 대해 추가 스크래이프 대상을 구성할 수 있으며, 이를 위해 /etc/gitlab/gitlab.rb에서 prometheus['scrape_configs']를 편집하여 Prometheus 스크래이프 대상 구성 구문을 사용합니다.

다음은 http://1.1.1.1:8060/probe?param_a=test&param_b=additional_test를 스크래이핑하는 예시 구성입니다. 

prometheus['scrape_configs'] = [
  {
    'job_name': 'custom-scrape',
    'metrics_path': '/probe',
    'params' => {
      'param_a' => ['test'],
      'param_b' => ['additional_test'],
    },
    'static_configs' => [
      'targets' => ['1.1.1.1:8060'],
    ],
  },
]

Linux 패키지를 사용한 독립형 Prometheus

Linux 패키지를 사용하여 Prometheus를 실행하는 독립형 모니터링 노드를 구성할 수 있습니다. 외부 Grafana는 이 모니터링 노드에 구성하여 대시보드를 표시할 수 있습니다.

독립형 모니터링 노드는 다중 노드를 사용하는 GitLab 배포에 추천됩니다.

다음 단계는 Linux 패키지를 사용하여 Prometheus가 실행되는 모니터링 노드를 구성하는 데 필요한 최소한의 단계입니다.

  1. 모니터링 노드로 SSH합니다.
  2. GitLab 다운로드 페이지의 단계 1과 2를 사용하여 원하는 Linux 패키지를 설치하나, 남은 단계는 따르지 않습니다.
  3. 다음 단계를 위해 Consul 서버 노드의 IP 주소 또는 DNS 레코드를 수집합니다.

  4. /etc/gitlab/gitlab.rb를 편집하고 다음 내용을 추가합니다. 

    roles ['monitoring_role']

external_url 'http://gitlab.example.com'

# Prometheus
prometheus['listen_address'] = '0.0.0.0:9090'
prometheus['monitor_kubernetes'] = false

# Prometheus의 서비스 검색 활성화
consul['enable'] = true
consul['monitoring_service_discovery'] = true
consul['configuration'] = {
   retry_join: %w(10.0.0.1 10.0.0.2 10.0.0.3), # 주소는 IP 또는 FQDN일 수 있습니다.
}

# Nginx - Grafana 액세스를 위해
nginx['enable'] = true
  5. 구성을 컴파일하기 위해 sudo gitlab-ctl reconfigure를 실행합니다.

다음 단계는 다른 모든 노드에게 모니터링 노드의 위치를 알려주어야 합니다.

  1. /etc/gitlab/gitlab.rb를 편집하고 다음 내용을 추가하거나 찾아서 주석 처리를 해제합니다. 

    # FQDN 또는 IP를 사용할 수 있습니다
gitlab_rails['prometheus_address'] = '10.0.0.1:9090'

    10.0.0.1:9090은 Prometheus 노드의 IP 주소와 포트입니다.

  2. 파일을 저장하고 변경 사항이 적용되도록 GitLab을 다시 구성합니다.

Service Discovery를 사용하여 모니터링을 수행하는 경우 consul['monitoring_service_discovery'] = true가 되어 있는지 확인한 후 /etc/gitlab/gitlab.rb에서 prometheus['scrape_configs']가 설정되지 않았는지 확인합니다. consul['monitoring_service_discovery'] = true 및 prometheus['scrape_configs']를 동시에 /etc/gitlab/gitlab.rb에 설정하면 오류가 발생합니다.

외부 프로메테우스 서버 사용

경고: 프로메테우스 및 대부분의 익스포터는 인증을 지원하지 않습니다. 로컬 네트워크 외부에 노출하는 것을 권장하지 않습니다.

외부 프로메테우스 서버에서 GitLab을 모니터링하려면 몇 가지 구성 변경이 필요합니다.

외부 프로메테우스 서버를 사용하려면 다음을 수행하세요:

  1. /etc/gitlab/gitlab.rb 파일을 편집합니다.

  2. 번들된 프로메테우스를 비활성화합니다: 

    prometheus['enable'] = false

  3. 각 번들된 서비스의 익스포터를 네트워크 주소에서 수신하도록 설정합니다. 예를 들어: 

    node_exporter['listen_address'] = '0.0.0.0:9100'
gitlab_workhorse['prometheus_listen_addr'] = "0.0.0.0:9229"

# Rails 노드
gitlab_exporter['listen_address'] = '0.0.0.0'
gitlab_exporter['listen_port'] = '9168'
registry['debug_addr'] = '0.0.0.0:5001'

# Sidekiq 노드
sidekiq['listen_address'] = '0.0.0.0'

# Redis 노드
redis_exporter['listen_address'] = '0.0.0.0:9121'

# PostgreSQL 노드
postgres_exporter['listen_address'] = '0.0.0.0:9187'

# Gitaly 노드
gitaly['configuration'] = {
   # ...
   prometheus_listen_addr: '0.0.0.0:9236',
}

# Pgbouncer 노드
pgbouncer_exporter['listen_address'] = '0.0.0.0:9188'

  4. 필요한 경우 공식 설치 지침을 사용하여 전용 프로메테우스 인스턴스를 설치하고 설정합니다.

  5. 모든 GitLab Rails(Puma, Sidekiq) 서버에서 프로메테우스 서버 IP 주소 및 수신 포트를 설정합니다. 예를 들어: 

    gitlab_rails['prometheus_address'] = '192.168.0.1:9090'

  6. NGINX 메트릭을 수집하려면 NGINX가 프로메테우스 서버의 IP를 허용하도록 설정해야 합니다. 예를 들어: 

    nginx['status']['options'] = {
      "server_tokens" => "off",
      "access_log" => "off",
      "allow" => "192.168.0.1",
      "deny" => "all",
}

    여러 프로메테우스 서버가 있는 경우 둘 이상의 IP 주소를 지정할 수도 있습니다: 

    nginx['status']['options'] = {
      "server_tokens" => "off",
      "access_log" => "off",
      "allow" => ["192.168.0.1", "192.168.0.2"],
      "deny" => "all",
}

  7. 프로메테우스 서버에서 GitLab 메트릭 엔드포인트를 가져올 수 있도록 하려면 모니터링 IP 화이트리스트에 프로메테우스 서버 IP 주소를 추가합니다: 

    gitlab_rails['monitoring_whitelist'] = ['127.0.0.0/8', '192.168.0.1']
  8. 각 번들된 서비스의 익스포터를 네트워크 주소에서 수신하도록 설정했으므로 인스턴스의 방화벽을 업데이트하여 활성화된 익스포터에 대해 프로메테우스 IP에서의 트래픽만 허용하도록 합니다. 활성화된 익스포터 서비스 및 해당 포트에 대한 전체 참조 목록은 여기에서 찾을 수 있습니다.
  9. 변경 사항을 적용하려면 GitLab을 재구성합니다.
  10. 프로메테우스 서버의 구성 파일을 편집합니다.
  11. 각 노드의 익스포터를 프로메테우스 서버의 수집 대상 구성에 추가합니다. 예를 들어, static_configs를 사용한 샘플 스니펫: 
   scrape_configs:
     - job_name: nginx
       static_configs:
         - targets:
           - 1.1.1.1:8060
     - job_name: redis
       static_configs:
         - targets:
           - 1.1.1.1:9121
     - job_name: postgres
       static_configs:
         - targets:
           - 1.1.1.1:9187
     - job_name: node
       static_configs:
         - targets:
           - 1.1.1.1:9100
     - job_name: gitlab-workhorse
       static_configs:
         - targets:
           - 1.1.1.1:9229
     - job_name: gitlab-rails
       metrics_path: "/-/metrics"
       scheme: https
       static_configs:
         - targets:
           - 1.1.1.1
     - job_name: gitlab-sidekiq
       static_configs:
         - targets:
           - 1.1.1.1:8082
     - job_name: gitlab_exporter_database
       metrics_path: "/database"
       static_configs:
         - targets:
           - 1.1.1.1:9168
     - job_name: gitlab_exporter_sidekiq
       metrics_path: "/sidekiq"
       static_configs:
         - targets:
           - 1.1.1.1:9168
     - job_name: gitaly
       static_configs:
         - targets:
           - 1.1.1.1:9236
     - job_name: registry
       static_configs:
         - targets:
           - 1.1.1.1:5001

경고: 스니펫의 gitlab-rails 작업은 GitLab이 HTTPS를 통해 접근 가능하다고 가정합니다. 배포가 HTTPS를 사용하지 않는 경우 작업 구성을 http 스키마와 포트 80을 사용하도록 적응시켜야 합니다.

  1. 프로메테우스 서버를 다시 로드합니다.

저장 보존 크기 구성

프로메테우스에는 로컬 스토리지를 구성하는 데 사용하는 여러 사용자 정의 플래그가 있습니다.

  • storage.tsdb.retention.time: 오래된 데이터를 제거하는 시점. 기본값은 15d입니다. 이 플래그가 기본값 이외의 값을 설정하면 storage.tsdb.retention을 재정의합니다.
  • storage.tsdb.retention.size: (실험적) 유지할 스토리지 블록의 최대 바이트 수. 가장 오래된 데이터가 먼저 제거됩니다. 기본값은 0(비활성화)입니다. 이 플래그는 실험적이며 향후 릴리스에서 변경될 수 있습니다. 지원되는 단위: B, KB, MB, GB, TB, PB, EB. 예: 512MB.

저장 보존 크기를 구성하려면 다음을 수행하세요:

  1. /etc/gitlab/gitlab.rb 파일을 편집합니다. 

    prometheus['flags'] = {
  'storage.tsdb.path' => "/var/opt/gitlab/prometheus/data",
  'storage.tsdb.retention.time' => "7d",
  'storage.tsdb.retention.size' => "2GB",
  'config.file' => "/var/opt/gitlab/prometheus/prometheus.yml"
}

  2. GitLab을 다시 구성합니다. 

    sudo gitlab-ctl reconfigure

성능 메트릭 보기

기본적으로 Prometheus가 제공하는 대시보드를 보려면 http://localhost:9090을 방문할 수 있습니다.

GitLab 인스턴스에 SSL이 활성화되어 있는 경우, 동일한 FQDN을 사용하는 경우 GitLab과 동일한 브라우저에서 Prometheus에 액세스할 수 없을 수 있습니다. 이는 HSTS 때문입니다. 테스트 프로젝트가 존재하여 GitLab을 통해 액세스할 수 있지만, 일시적으로는 별도의 FQDN 사용, 서버 IP 사용, Prometheus용 별도의 브라우저 사용, HSTS 재설정 또는 NGINX가 프록시로 사용하는 것과 같은 해결책이 있습니다.

Prometheus가 수집한 성능 데이터는 Prometheus 콘솔이나 호환되는 대시보드 도구를 통해 직접 볼 수 있습니다. Prometheus 인터페이스는 수집된 데이터와 함께 작업할 수 있는 유연한 쿼리 언어를 제공하여 결과를 시각화할 수 있습니다. 더 많은 기능을 갖춘 대시보드를 원하는 경우 Grafana를 사용할 수 있으며, Prometheus에 대해 공식 지원이 가능합니다.

샘플 Prometheus 쿼리

다음은 사용할 수 있는 일부 샘플 Prometheus 쿼리입니다.

참고: 이것들은 예시이며 모든 설정에서 작동하지 않을 수 있습니다. 추가적인 조정이 필요할 수 있습니다.

  • % CPU 이용률: 1 - avg without (mode,cpu) (rate(node_cpu_seconds_total{mode="idle"}[5m]))
  • % 사용 가능한 메모리: ((node_memory_MemAvailable_bytes / node_memory_MemTotal_bytes) or ((node_memory_MemFree_bytes + node_memory_Buffers_bytes + node_memory_Cached_bytes) / node_memory_MemTotal_bytes)) * 100
  • 전송된 데이터: rate(node_network_transmit_bytes_total{device!="lo"}[5m])
  • 받은 데이터: rate(node_network_receive_bytes_total{device!="lo"}[5m])
  • 디스크 읽기 IOPS: sum by (instance) (rate(node_disk_reads_completed_total[1m]))
  • 디스크 쓰기 IOPS: sum by (instance) (rate(node_disk_writes_completed_total[1m]))
  • GitLab 트랜잭션 횟수별 RPS: sum(irate(gitlab_transaction_duration_seconds_count{controller!~'HealthController|MetricsController|'}[1m])) by (controller, action)

Grafana에서 Prometheus 데이터소스로서의 Prometheus

Grafana를 사용하면 Prometheus 성능 메트릭을 데이터 소스로 가져와 그래프와 대시보드로 렌더링할 수 있으며, 시각화에 도움이 됩니다.

단일 서버 GitLab 설정에 대한 Prometheus 대시보드를 추가하려면:

  1. Grafana에서 새 데이터 소스를 생성합니다.
  2. 유형에서 Prometheus를 선택합니다.
  3. 데이터 소스에 이름을 지정합니다(예: GitLab).
  4. Prometheus 서버 URL에 Prometheus 수신 주소를 추가합니다.
  5. HTTP 방법을 GET으로 설정합니다.
  6. 구성을 저장하고 테스트하여 작동하는지 확인합니다.

GitLab 메트릭

GitLab은 자체 내부 서비스 메트릭을 모니터링하고, /-/metrics 엔드포인트에서 이를 사용할 수 있도록 합니다. 다른 내보내기와 달리 이 엔드포인트는 사용자 트래픽과 동일한 URL 및 포트에서 제공되므로 인증이 필요합니다.

GitLab Metrics에 대해 자세히 알아보기

번들된 소프트웨어 메트릭

Linux 패키지에 번들된 많은 GitLab 종속성은 Prometheus 메트릭을 내보내도록 사전 구성되어 있습니다.

노드 익스포터

노드 익스포터를 사용하면 메모리, 디스크 및 CPU 이용률과 같은 다양한 기계 리소스를 측정할 수 있습니다.

노드 익스포터에 대해 자세히 알아보기

웹 익스포터

웹 익스포터는 트래픽을 엔드 사용자 및 Prometheus로 분리하여 성능과 가용성을 향상시키기 위해 두 개의 별도 응용프로그램으로 측정할 수 있는 전용 메트릭 서버입니다.

웹 익스포터에 대해 자세히 알아보기

레디스 익스포터

레디스 익스포터를 사용하면 다양한 레디스 메트릭을 측정할 수 있습니다.

레디스 익스포터에 대해 자세히 알아보기

PostgreSQL 익스포터

포스트그레SQL 익스포터를 사용하면 다양한 포스트그레SQL 메트릭을 측정할 수 있습니다.

포스트그레SQL 익스포터에 대해 자세히 알아보기

PgBouncer 익스포터

PgBouncer 익스포터를 사용하면 다양한 PgBouncer 메트릭을 측정할 수 있습니다.

PgBouncer 익스포터에 대해 자세히 알아보기

레지스트리 익스포터

레지스트리 익스포터를 사용하면 다양한 레지스트리 메트릭을 측정할 수 있습니다.

레지스트리 익스포터에 대해 자세히 알아보기

GitLab 익스포터

GitLab 익스포터를 사용하면 레디스와 데이터베이스로부터 가져온 다양한 GitLab 메트릭을 측정할 수 있습니다.

GitLab 익스포터에 대해 자세히 알아보기

문제 해결

/var/opt/gitlab/prometheus이 너무 많은 디스크 공간을 사용함

만약 프로메테우스 모니터링을 사용하지 않는다면:

  1. 프로메테우스 비활성화합니다.
  2. /var/opt/gitlab/prometheus 아래의 데이터를 삭제합니다.

프로메테우스 모니터링을 사용하는 경우:

  1. 프로메테우스를 중지합니다 (실행 중에 데이터를 삭제하면 데이터 손상이 발생할 수 있습니다): 

    gitlab-ctl stop prometheus
  2. /var/opt/gitlab/prometheus/data 아래의 데이터를 삭제합니다.

  3. 서비스를 다시 시작합니다: 

    gitlab-ctl start prometheus

  4. 서비스가 실행 중인지 확인합니다: 

    gitlab-ctl status prometheus
  5. 선택 사항. 저장 유지 크기 구성.

모니터링 노드가 데이터를 받지 못하는 경우

모니터링 노드가 어떤 데이터도 받지 못하면, 내보내기가 데이터를 캡처하는지 확인합니다: 

curl "http[s]://localhost:<내보내기 수신 대기 포트>/metrics"

또는 

curl "http[s]://localhost:<내보내기 수신 대기 포트>/-/metrics"