GitLab 모니터링 with Prometheus

Tier: Free, Premium, Ultimate Offering: Self-managed

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가 수신 대기하는 포트 및 주소 변경

caution
변경 가능하지만, GitLab 서버에서 실행 중인 다른 서비스와 충돌할 수 있으므로 Prometheus가 수신 대기하는 포트를 변경하는 것은 권장되지 않습니다. 본인 위험 부담 하에 진행하세요.

GitLab 서버 외부에서 Prometheus에 접근하려면, Prometheus가 수신 대기하는 주소/포트를 변경합니다:

  1. /etc/gitlab/gitlab.rb를 편집합니다.

  2. 다음 줄을 추가하거나 찾아 주석을 제거합니다:

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

    localhost:9090을 Prometheus가 수신 대기할 주소 또는 포트로 교체합니다. 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'],  
    ],  
  },  
]

독립형 Prometheus 사용하기 - 리눅스 패키지

리눅스 패키지를 사용하여 Prometheus를 실행하는 독립형 모니터링 노드를 구성할 수 있습니다.

외부 Grafana를 이 모니터링 노드에 구성하여 대시보드를 표시할 수 있습니다.

독립형 모니터링 노드는 여러 노드로 구성된 GitLab 배포에 권장됩니다.

아래 단계는 리눅스 패키지로 Prometheus를 실행하는 모니터링 노드를 구성하는 데 필요한 최소한의 과정입니다:

  1. 모니터링 노드에 SSH로 접속합니다.
  2. GitLab 다운로드 페이지에서 단계 1 및 2를 사용하여 원하는 리눅스 패키지를 설치합니다. 나머지 단계는 따르지 마십시오.
  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']가 설정되지 않았는지 확인하십시오. /etc/gitlab/gitlab.rb에서 consul['monitoring_service_discovery'] = true와 prometheus['scrape_configs']를 동시에 설정하면 오류가 발생합니다.

외부 Prometheus 서버 사용하기

경고:

Prometheus와 대부분의 익스포터는 인증을 지원하지 않습니다. 로컬 네트워크 외부에 노출하는 것은 권장하지 않습니다.

GitLab이 외부 Prometheus 서버에 의해 모니터링될 수 있도록 몇 가지 구성 변경이 필요합니다.

외부 Prometheus 서버를 사용하려면:

  1. /etc/gitlab/gitlab.rb를 편집합니다.

  2. 번들된 Prometheus를 비활성화합니다:

    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. 필요할 경우 공식 설치 지침을 사용하여 전용 Prometheus 인스턴스를 설치 및 설정합니다.

  5. 모든 GitLab Rails (Puma, Sidekiq) 서버에서 Prometheus 서버의 IP 주소와 수신 포트를 설정합니다. 예를 들어:

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

  6. NGINX 메트릭을 수집하려면 NGINX가 Prometheus 서버 IP를 허용하도록 구성해야 합니다. 예를 들어:

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

    여러 Prometheus 서버가 있는 경우 여러 개의 IP 주소를 지정할 수도 있습니다:

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

  7. Prometheus 서버가 GitLab 메트릭 엔드포인트에서 가져올 수 있도록 Prometheus 서버 IP 주소를 모니터링 IP 허용 목록에 추가합니다:

    gitlab_rails['monitoring_whitelist'] = ['127.0.0.0/8', '192.168.0.1']

  8. 번들된 서비스의 익스포터가 네트워크 주소에서 수신 대기하도록 설정하고 있으므로, 익스포터를 활성화한 경우 Prometheus IP에서만 트래픽을 허용하도록 인스턴스의 방화벽을 업데이트합니다. 익스포터 서비스 및 해당 포트에 대한 전체 참조 목록은 여기에서 확인할 수 있습니다.

  9. GitLab 재구성을 수행하여 변경 사항을 적용합니다.

  10. Prometheus 서버의 구성 파일을 편집합니다.

  11. 각 노드의 익스포터를 Prometheus 서버의 스크랩 대상 구성에 추가합니다. 예를 들어, 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을 사용하도록 조정됩니다.

  12. Prometheus 서버를 다시 로드합니다.

스토리지 유지 관리 크기 구성

Prometheus는 로컬 스토리지를 구성하기 위한 여러 사용자 지정 플래그를 제공합니다:

  • 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 쿼리입니다.

note
이는 예시일 뿐이며 모든 설정에서 작동하지 않을 수 있습니다. 추가 조정이 필요할 수 있습니다.
  • % 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 데이터 소스

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

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

  1. Grafana에서 새로운 데이터 소스를 생성합니다.

  2. Type에서 Prometheus를 선택합니다.

  3. 데이터 소스의 이름을 지정합니다(예: GitLab).

  4. Prometheus server URL에서 Prometheus 수신 주소를 추가합니다.

  5. HTTP method를 GET으로 설정합니다.

  6. 구성을 저장하고 테스트하여 작동하는지 확인합니다.

GitLab 메트릭

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

GitLab Metrics에 대해 자세히 알아보세요.

번들된 소프트웨어 메트릭

리눅스 패키지에 번들된 많은 GitLab 의존성은 Prometheus 메트릭을 내보내도록 사전 구성되어 있습니다.

Node exporter

Node exporter는 메모리, 디스크 및 CPU 사용량과 같은 다양한 기계 리소스를 측정할 수 있게 해줍니다.

Node exporter에 대해 더 알아보기.

Web exporter

Web exporter는 최종 사용자와 Prometheus 트래픽을 두 개의 개별 애플리케이션으로 분리하여 성능과 가용성을 향상시키는 전용 메트릭 서버입니다.

Web exporter에 대해 더 알아보기.

Redis exporter

Redis exporter는 다양한 Redis 메트릭을 측정할 수 있게 해줍니다.

Redis exporter에 대해 더 알아보기.

PostgreSQL exporter

PostgreSQL exporter는 다양한 PostgreSQL 메트릭을 측정할 수 있게 해줍니다.

PostgreSQL exporter에 대해 더 알아보기.

PgBouncer exporter

PgBouncer exporter는 다양한 PgBouncer 메트릭을 측정할 수 있게 해줍니다.

PgBouncer exporter에 대해 더 알아보기.

Registry exporter

Registry exporter는 다양한 Registry 메트릭을 측정할 수 있게 해줍니다.

Registry exporter에 대해 더 알아보기.

GitLab exporter

GitLab exporter는 Redis와 데이터베이스에서 가져온 다양한 GitLab 메트릭을 측정할 수 있게 해줍니다.

GitLab exporter에 대해 더 알아보기.

문제 해결

/var/opt/gitlab/prometheus의 디스크 공간 소비가 너무 많음

Prometheus 모니터링을 사용하지 않는 경우:

  1. Prometheus 비활성화합니다.

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

Prometheus 모니터링을 사용하는 경우:

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

    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:<EXPORTER LISTENING PORT>/metrics"

또는

curl "http[s]://localhost:<EXPORTER LISTENING PORT>/-/metrics"