Linux 패키지 설치 로그

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

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

서버에서 콘솔에 로그 테일링

GitLab 로그의 실시간 업데이트를 보고 싶다면 ‘테일(tail)’하려면 gitlab-ctl 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'를 사용하여 모든 로그를 STDOUT에 테일링하고 동시에 파일에 씁니다
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 관리 서비스는 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 # 로그 메시지의 사용자 정의 접두사

Logrotate

GitLab 내장 logrotate 서비스는 runit이 캡처하지 않는 모든 로그를 관리합니다. 이 서비스는 gitlab-rails/production.log 및 nginx/gitlab_access.log와 같은 로그 데이터를 회전, 압축 및 최종적으로 삭제합니다. 여러분은 공통 logrotate 설정, 서비스 별 logrotate 설정, 그리고 /etc/gitlab/gitlab.rb를 통해 logrotate를 완전히 비활성화할 수 있습니다.

공통 logrotate 설정 구성

모든 logrotate 서비스에 적용되는 설정은 /etc/gitlab/gitlab.rb 파일에 설정할 수 있습니다. 이러한 설정은 각 서비스의 logrotate 구성 파일에 대응됩니다. 자세한 내용은 각 서비스의 logrotate 구성 옵션에 대한 자세한 내용은 logrotate 매뉴얼 페이지 (man logrotate)를 참조하십시오. 

logging['logrotate_frequency'] = "daily" # 로그를 매일 회전
logging['logrotate_maxsize'] = nil # logs will be rotated when they grow bigger than size specified for `maxsize`, even before the specified time interval (daily, weekly, monthly, or yearly)
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 # 기본적으로 postrotate 명령이 없습니다
logging['logrotate_dateformat'] = nil # rotated 파일을 숫자 대신 날짜 확장으로 사용, 예를들면 "-%Y-%m-%d"라는 값은 production.log-2016-03-09.gz와 같은 회전 파일을 생성

각 서비스별 logrotate 설정 구성

각 서비스별로 logrotate 설정을 사용자 정의할 수 있습니다. 예를들어 nginx 서비스의 로그로테이트 빈도와 크기를 사용자 정의하려면 다음과 같이 할 수 있습니다. ruby nginx['logrotate_frequency'] = nil nginx['logrotate_size'] = "200M"

logrotate 비활성화

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

logrotate['enable'] = false

Logrotate notifempty 설정

GitLab 13.6부터 logrotate 서비스는 notifempty의 기본값을 갖고 실행되어 다음과 같은 문제를 해결합니다:

  • 불필요하게 로테이트된 빈 로그와 종종 많은 빈 로그들이 저장되는 문제.
  • 데이터베이스 마이그레이션 로그와 같은 장기간 문제 해결을 위해 유용한 일회성 로그들이 30일 후에 삭제되는 문제.

Logrotate one-off 및 빈 로그 처리

로그는 이제 logrotate에 의해 필요할 때 회전 및 재생성되며, 일회성 로그는 변경될 때만 회전됩니다. 이 설정을 통해 아래와 같이 정리할 수 있습니다:

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

logrotate 매뉴얼 실행

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

logrotate를 사용하여 GitLab 로그 회전을 수동으로 트리거하려면 다음 명령을 사용하십시오. 

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

UDP 로그 전달

Tier: Premium, Ultimate Offering: Self-managed

Linux 패키지 설치는 svlogd에서 UDP 로깅 기능을 활용하고, 비-svlogd 로그를 UDP를 사용하는 syslog 호환 원격 시스템으로 전송할 수 있습니다. 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)
note
udp_log_shipping_host를 설정하면 각 runit-managed 서비스에 대해 지정된 호스트 이름 및 서비스에 대한 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.228.1 - - [26/Jun/2014:06:33:46 -0700] "GET /root/my-project/import HTTP/1.1" 200 5775 "https://172.16.228.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 형식은 지원하는 모든 서비스에 대해 기본적으로 활성화되어 있습니다.

note
외부 플러그인 없이 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'] = 'text'
gitlab_workhorse['log_format'] = 'text'
registry['log_formatter'] = 'text'
sidekiq['log_format'] = 'text'
gitlab_pages['log_format'] = 'text'
note
서비스에 따라 로그 형식에 대한 속성 이름에 약간의 차이가 있습니다. (예: Container Registry는 log_formatter를 사용하고, Gitaly 및 Praefect는 둘 다 logging_format을 사용합니다). 자세한 내용은 Issue #4280을 참조하십시오.

rbtrace

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

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

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

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

로그 레벨/상세 설정

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

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

    registry['log_level'] = 'info'
gitlab_shell['log_level'] = 'INFO'
gitaly['configuration'] = {
  logging: {
    level: "warn"
  }
}

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

    sudo gitlab-ctl reconfigure
note
다른 GitLab 로그(예: production_json.log, sidekiq.log 등)의 log_level은 편집할 수 없습니다.

사용자 정의 로그 그룹 설정

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

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

전역 또는 서비스별 log_group 설정을 하는 경우:

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

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

사용자 정의 로그 그룹 제한

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

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