Linux 패키지 설치에 대한 로그

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

GitLab에는 GitLab의 모든 서비스 및 구성 요소에서 시스템 로그를 출력하는 고급 로그 시스템이 포함되어 있습니다. 이는 Linux 패키지 설치에서 로그를 관리하기 위한 구성 설정 및 도구입니다.

서버에서 콘솔에서 로그 보기

GitLab 로그의 실시간 로그 업데이트를 보려면 ‘tail’로, 즉 ‘tail’하려는 경우 gitlab-ctl tail을 사용할 수 있습니다. 

# 모든 로그 tail; 종료하려면 Ctrl-C를 누르세요
sudo gitlab-ctl tail

# /var/log/gitlab의 하위 디렉토리로 이동
sudo gitlab-ctl tail gitlab-rails

# 개별 파일로 이동
sudo gitlab-ctl tail nginx/gitlab_error.log

콘솔에서 로그 보기 및 파일로 저장

때로는 콘솔에 로그를 표시하고 나중에 디버깅/분석을 위해 파일로 저장하는 것이 유용합니다. 이를 위해 tee 유틸리티를 사용할 수 있습니다. 

# 'tee'를 사용하여 모든 로그를 표준 출력으로 테일하고 동시에 파일에 작성
sudo gitlab-ctl tail | tee --append /tmp/gitlab_tail.log

기본 로그 디렉터리 구성

/etc/gitlab/gitlab.rb 파일에서 다양한 종류의 로그를위한 많은 log_directory 키가 있습니다. 이동할 로그의 모든 값을 주석 처리하여 업데이트하세요. 

# 예:
gitlab_rails['log_directory'] = "/var/log/gitlab/gitlab-rails"
puma['log_directory'] = "/var/log/gitlab/puma"
registry['log_directory'] = "/var/log/gitlab/registry"
...

Gitaly 및 Mattermost에는 다른 로그 디렉터리 구성이 있습니다. 

gitaly['configuration'] = {
   logging: {
    dir: "/var/log/gitlab/registry"
   }
}
mattermost['log_file_directory'] = "/var/log/gitlab/registry"

이러한 설정을 사용하여 인스턴스를 구성하려면 sudo gitlab-ctl reconfigure를 실행하세요.

runit 로그

Linux 패키지 설치의 runit-managed 서비스는 svlogd를 사용하여 로그 데이터를 생성합니다.

  • 로그는 current라는 파일에 작성됩니다.
  • 일정 기간마다이 로그는 TAI64N 형식을 사용하여 압축되고 이름이 바뀝니다. 예: @400000005f8eaf6f1a80ef5c.s.
  • 압축된 로그의 파일 시스템 날짜 캠프는 GitLab가 해당 파일에 마지막으로 쓴 시간과 일치합니다.
  • zmore 및 zgrep를 사용하여 압축 또는 압축 해제 된 로그를 볼 수 있습니다.

더 많은 정보를 보려면 svlogd 설명서를 참조하세요.

다음 설정을 사용하여 /etc/gitlab/gitlab.rb를 통해 svlogd 설정을 수정할 수 있습니다. 

# 아래는 기본 값입니다.
logging['svlogd_size'] = 200 * 1024 * 1024 # 로그 데이터가 200MB 이상이면 로테이트
logging['svlogd_num'] = 30 # 30개의 로테이트된 로그 파일 유지
logging['svlogd_timeout'] = 24 * 60 * 60 # 24시간 후에 로테이트
logging['svlogd_filter'] = "gzip" # 로그를 gzip으로 압축
logging['svlogd_udp'] = nil # UDP를 통해 로그 메시지 전송
logging['svlogd_prefix'] = nil # 로그 메시지의 사용자 정의 접두어

# 선택적으로 Nginx용 접두사를 재정의할 수 있습니다.
nginx['svlogd_prefix'] = "nginx"

로그로테이션

GitLab에 내장 된 logrotate 서비스는 runit에서 캡처되지 않는 모든 로그를 관리합니다. 이 서비스는 /etc/gitlab/gitlab.rb를 사용하여 공통 로그로테이트 설정, 서비스 별 로그로테이트 설정을 구성하거나 로그로테이트를 완전히 비활성화할 수 있습니다.

공통 로그로테이트 설정 구성

모든 logrotate 서비스에 대한 공통 설정은 /etc/gitlab/gitlab.rb 파일에 설정할 수 있습니다. 이러한 설정은 각 서비스의 logrotate 구성 파일의 구성 옵션에 해당합니다. 세부 사항은 각 서비스에 대한 logrotate 매뉴얼 페이지 (man logrotate)를 참조하세요. 

logging['logrotate_frequency'] = "daily" # 일일 로그 로테이트
logging['logrotate_maxsize'] = nil # `maxsize`에 지정된 크기보다 크게 로그가 증가하면 로테이트됩니다.
logging['logrotate_size'] = nil # 기본적으로 크기별로 로테이트하지 않음
logging['logrotate_rotate'] = 30 # 30개의 로테이트된 로그 유지
logging['logrotate_compress'] = "compress" # 'man logrotate' 참조
logging['logrotate_method'] = "copytruncate" # 'man logrotate' 참조
logging['logrotate_postrotate'] = nil # 기본적으로 후회전 명령 없음
logging['logrotate_dateformat'] = nil # 회전 된 파일에 날짜 확장자 사용

개별 서비스 로그로테이트 설정 구성

각 개별 서비스에 대한 로그로테이트 설정을 커스터 마이즈할 수 있습니다. 예를 들어, nginx 서비스에 대한 로그로테이트 빈도와 크기를 사용자 정의하려면 다음을 사용하세요. 

nginx['logrotate_frequency'] = nil
nginx['logrotate_size'] = "200M"

로그로테이트 비활성화

다음 설정을 사용하여 내장 된 logrotate 서비스를 비활성화할 수 있습니다. /etc/gitlab/gitlab.rb에서 다음 설정을 사용하십시오. 

logrotate['enable'] = false

Logrotate notifempty 설정

로그로테이트 서비스는 구성할 수없는 기본 notifempty로 실행되어 다음 문제를 해결합니다.

  • 불필요하게 회전 된 빈 로그 및 종종 많은 빈 로그가 저장됩니다.
  • 장기적인 문제 해결에 유용한 일회용 로그가 삭제됩니다.

Logrotate 일회용 및 빈 로그 처리

로그는 이제 필요할 때만 회전되고 다시 생성됩니다. 이러한 설정이 있으면 다음과 같이 정리할 수 있습니다.

  • gitlab-rails/gitlab-rails-db-migrate*.log와 같은 빈 일회용 로그를 삭제할 수 있습니다.
  • 이전 버전의 GitLab에 의해 회전 및 압축 된 빈 로그. 이러한 빈 로그의 크기는 일반적으로 20 바이트입니다.

logrotate 수동 실행

Logrotate는 예약된 작업이지만 필요에 따라 수동으로 트리거할 수도 있습니다.

GitLab 로그 로테이션을 수동으로 트리거하려면 다음 명령을 사용하십시오. 

/opt/gitlab/embedded/sbin/logrotate -fv -s /var/opt/gitlab/logrotate/logrotate.status /var/opt/gitlab/logrotate/logrotate.conf

logrotate 트리거 주기 증가

logrotate 스크립트는 모든 50분마다 트리거하고 로그를 로테이션하기 전에 10분을 대기합니다.

이러한 값을 수정하려면:

  1. /etc/gitlab/gitlab.rb 파일을 편집하십시오. 

    logrotate['pre_sleep'] = 600   # 시작 후 10분 대기
logrotate['post_sleep'] = 3000 # 로테이션 후 50분 대기

  2. GitLab을 재구성하십시오: 

    sudo gitlab-ctl reconfigure

UDP 로그 포워딩

Tier: Premium, Ultimate Offering: Self-managed

Linux 패키지 설치에서는 svlogd의 UDP 로깅 기능과 UDP를 사용하여 syslog와 호환되는 원격 시스템으로 non-svlogd 로그를 보낼 수 있습니다. Linux 패키지 설치에서 syslog 프로토콜 메시지를 UDP로 보내도록 구성하려면 다음 설정을 사용하십시오. 

logging['udp_log_shipping_host'] = '1.2.3.4' # 사용 중인 syslog 서버
# logging['udp_log_shipping_hostname'] = nil # 선택 사항, 기본값은 시스템 호스트명입니다.
logging['udp_log_shipping_port'] = 1514 # 선택 사항, 기본값은 514(syslog)입니다.

참고: udp_log_shipping_host 설정은 각 runit 관리 서비스에 대해 지정된 호스트명과 서비스에 대한 svlogd_prefix를 추가합니다.

예시 로그 메시지: 

Jun 26 06:33:46 ubuntu1204-test production.log: Started GET "/root/my-project/import" for 127.0.0.1 at 2014-06-26 06:33:46 -0700
Jun 26 06:33:46 ubuntu1204-test production.log: Processing by ProjectsController#import as HTML
Jun 26 06:33:46 ubuntu1204-test production.log: Parameters: {"id"=>"root/my-project"}
Jun 26 06:33:46 ubuntu1204-test production.log: Completed 200 OK in 122ms (Views: 71.9ms | ActiveRecord: 12.2ms)
Jun 26 06:33:46 ubuntu1204-test gitlab_access.log: 172.16.26.1 - - [26/Jun/2014:06:33:46 -0700] "GET /root/my-project/import HTTP/1.1" 200 5775 "https://172.16.26.169/root/my-project/import" "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_9_3) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/35.0.1916.153 Safari/537.36"
2014-06-26_13:33:46.49866 ubuntu1204-test sidekiq: 2014-06-26T13:33:46Z 18107 TID-7nbj0 Sidekiq::Extensions::DelayedMailer JID-bbfb118dd1db20f6c39f5b50 INFO: start
2014-06-26_13:33:46.52608 ubuntu1204-test sidekiq: 2014-06-26T13:33:46Z 18107 TID-7muoc RepositoryImportWorker JID-57ee926c3655fcfa062338ae INFO: start

사용자 정의 NGINX 로그 형식 사용

기본적으로 NGINX 액세스 로그는 쿼리 문자열에 포함된 잠재적으로 민감한 정보를 숨기도록 설계된 ‘combined’ NGINX 형식의 버전을 사용합니다. 사용자 정의 로그 형식 문자열을 사용하려면 /etc/gitlab/gitlab.rb에서 지정할 수 있습니다. 형식에 대한 자세한 내용은 NGINX 문서를 참조하십시오. 

nginx['log_format'] = '내 형식 문자열 $foo $bar'
mattermost_nginx['log_format'] = '내 형식 문자열 $foo $bar'

JSON 로깅

구조화된 로그는 Elasticsearch, Splunk 또는 다른 로그 관리 시스템에서 구문 분석할 수 있도록 JSON으로 내보낼 수 있습니다. JSON 형식은 지원하는 모든 서비스에 대해 기본적으로 활성화되어 있습니다.

참고: 외부 플러그인 없이 PostgreSQL은 JSON 로깅을 지원하지 않습니다. 그러나 CSV 형식으로 로깅을 지원합니다. 

postgresql['log_destination'] = 'csvlog'
postgresql['logging_collector'] = 'on'

이를 적용하려면 데이터베이스를 다시 시작해야 합니다. 자세한 내용은 PostgreSQL 문서를 참조하십시오.

텍스트 로깅

설정된 로그 인계 시스템이 있는 고객은 JSON 로그 형식을 사용하지 않을 수 있습니다. 텍스트 형식을 구성하려면 /etc/gitlab/gitlab.rb에 다음을 설정한 다음 gitlab-ctl reconfigure를 실행하십시오. 

gitaly['configuration'] = {
   logging: {
    format: ""
   }
}
gitlab_shell['log_format'] = '텍스트'
gitlab_workhorse['log_format'] = '텍스트'
registry['log_formatter'] = '텍스트'
sidekiq['log_format'] = '텍스트'
gitlab_pages['log_format'] = '텍스트'

참고: 서비스에 따라 로그 형식을 나타내는 속성 이름에 약간의 차이가 있습니다(Container Registry는 log_formatter를 사용하고, Gitaly 및 Praefect는 모두 logging_format을 사용합니다). 자세한 내용은 이슈 #4280을 참조하십시오.

rbtrace

GitLab에는 rbtrace가 포함되어 있어 Ruby 코드를 추적하고 모든 실행 중인 스레드를 볼 수 있으며 메모리 덤프를 찍는 등의 작업을 수행할 수 있습니다. 그러나 기본적으로 이 기능은 활성화되어 있지 않습니다. 이를 활성화하려면 환경 변수로 ENABLE_RBTRACE를 정의하십시오. 

gitlab_rails['env'] = {"ENABLE_RBTRACE" => "1"}

그런 다음 시스템을 재구성하고 Puma 및 Sidekiq을 다시 시작하십시오. Linux 패키지 설치에서 이를 실행하려면 root로 다음을 실행하십시오. 

/opt/gitlab/embedded/bin/ruby /opt/gitlab/embedded/bin/rbtrace

로그 레벨/축적도 구성

GitLab Rails, 컨테이너 레지스트리, GitLab Shell 및 Gitaly의 최소 로그 레벨(축적도)을 구성할 수 있습니다:

  1. /etc/gitlab/gitlab.rb 파일을 편집하고 다음과 같이 로그 레벨을 설정합니다: 

    gitlab_rails['env'] = {
  "GITLAB_LOG_LEVEL" => "WARN",
}
registry['log_level'] = 'info'
gitlab_shell['log_level'] = 'INFO'
gitaly['configuration'] = {
  logging: {
    level: "warn"
  }
}

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

    sudo gitlab-ctl reconfigure

참고: 특정 GitLab 로그, 예를 들어 production_json.log, graphql_json.log 등의 log_level을 편집할 수 없습니다. 기본 로그 레벨 재정의도 참조하세요.

사용자 정의 로그 그룹 설정

GitLab은 구성된 로그 디렉터리에 사용자 정의 그룹을 할당하는 것을 지원합니다.

/etc/gitlab/gitlab.rb 파일의 전역 logging['log_group'] 설정과 gitaly['log_group'] 같은 각 서비스의 log_group 설정을 추가할 때 인스턴스를 구성하기 위해 sudo gitlab-ctl reconfigure를 실행해야 합니다.

전역 또는 각 서비스 log_group를 설정하면:

  • 설정된 그룹 멤버가 로그 디렉터리 내용을 읽을 수 있도록 로그 디렉터리(또는 전역 설정을 사용하는 경우 모든 로그 디렉터리)의 권한을 0750으로 변경합니다.

  • 지정된 log_group을 사용하여 runit 로그를 작성하고 회전합니다 : 각 서비스 또는 모든 runit으로 관리되는 서비스에 대해.

사용자 정의 로그 그룹의 제한

(runit으로 관리되지 않는 gitlab-rails 로그와 같이) runit으로 관리되지 않는 서비스의 로그 (/var/log/gitlab/gitlab-rails에서의 gitlab-rails 로그)는 구성된 log_group 설정을 상속받지 않습니다.

그룹은 호스트에 이미 존재해야 합니다. Linux 패키지 설치는 sudo gitlab-ctl reconfigure 실행 시 그룹을 생성하지 않습니다.