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
   
   # Already set to `false` by default, but you can explicitly disable it to be sure
   puma['exporter_enabled'] = false
   

3. 파일을 저장하고 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'
   # or
   prometheus['listen_address'] = '0.0.0.0:9090'
   

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

사용자 정의 스크랩 구성 추가#

Prometheus 스크랩 대상 구성 구문을 사용해 /etc/gitlab/gitlab.rb의 prometheus['scrape_configs']를 편집하면 Linux 패키지에 번들로 제공되는 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
   
   # Enable service discovery for 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), # The addresses can be IPs or FQDNs
   }
   
   # Nginx - For Grafana access
   nginx['enable'] = true
   

5. sudo gitlab-ctl reconfigure를 실행해 구성을 컴파일합니다.

다음 단계는 다른 모든 노드에 모니터링 노드의 위치를 알리는 것입니다:

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

   # can be FQDN or IP
   gitlab_rails['prometheus_address'] = '10.0.0.1:9090'
   

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

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

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 서버를 사용하려면 다음과 같이 진행합니다:

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 nodes
   gitlab_exporter['listen_address'] = '0.0.0.0'
   gitlab_exporter['listen_port'] = '9168'
   registry['debug_addr'] = '0.0.0.0:5001'
   
   # Sidekiq nodes
   sidekiq['listen_address'] = '0.0.0.0'
   
   # Redis nodes
   redis_exporter['listen_address'] = '0.0.0.0:9121'
   
   # PostgreSQL nodes
   postgres_exporter['listen_address'] = '0.0.0.0:9187'
   
   # Gitaly nodes
   gitaly['configuration'] = {
      # ...
      prometheus_listen_addr: '0.0.0.0:9236',
   }
   
   # Pgbouncer nodes
   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 메트릭을 스크랩하려면 Prometheus 서버 IP를 허용하도록 NGINX도 구성해야 합니다. 예를 들어 다음과 같습니다:

   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 메트릭 엔드포인트에서 데이터를 가져올 수 있도록 모니터링 IP 허용 목록에 Prometheus 서버 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
    

    [!warning] 스니펫의 gitlab-rails job은 GitLab에 HTTPS로 연결할 수 있다고 가정합니다. 배포 환경에서 HTTPS를 사용하지 않는 경우 job 구성은 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을 사용하면 HSTS 때문에 GitLab과 같은 브라우저에서 Prometheus에 액세스할 수 없을 수 있습니다. 액세스를 제공하기 위한 GitLab 테스트 프로젝트가 있습니다. 그동안 쓸 수 있는 몇 가지 우회 방법이 있습니다. 별도의 FQDN 사용, 서버 IP 사용, Prometheus용 별도 브라우저 사용, HSTS 재설정, NGINX가 프록시하도록 설정하는 방법입니다.

Prometheus가 수집한 성능 데이터는 Prometheus 콘솔에서 직접 확인하거나 호환되는 대시보드 도구를 통해 확인할 수 있습니다. Prometheus 인터페이스는 수집된 데이터를 다루는 유연한 쿼리 언어를 제공하며, 그 결과를 시각화할 수 있습니다. 기능이 더 풍부한 대시보드가 필요하면 Grafana를 사용할 수 있고, 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#

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 메트릭에 대해 자세히 알아볼 수 있습니다.

번들 소프트웨어 메트릭#

Linux 패키지에 번들로 제공되는 GitLab 의존성 중 다수는 Prometheus 메트릭을 내보내도록 미리 구성되어 있습니다.

노드 익스포터#

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

노드 익스포터에 대해 자세히 알아봅니다.

웹 익스포터#

웹 익스포터는 최종 사용자 트래픽과 Prometheus 트래픽을 두 개의 애플리케이션으로 분리해 성능과 가용성을 개선할 수 있는 전용 메트릭 서버입니다.

웹 익스포터에 대해 자세히 알아봅니다.

Redis 익스포터#

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

Redis 익스포터에 대해 자세히 알아봅니다.

PostgreSQL 익스포터#

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

PostgreSQL 익스포터에 대해 자세히 알아봅니다.

PgBouncer 익스포터#

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

PgBouncer 익스포터에 대해 자세히 알아봅니다.

레지스트리 익스포터#

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

레지스트리 익스포터에 대해 자세히 알아봅니다.

GitLab 익스포터#

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

GitLab 익스포터에 대해 자세히 알아봅니다.

문제 해결#

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

또는

curl "http[s]://localhost:/-/metrics"