- 서버의 콘솔에서 로그 미리보기
- 기본 로그 디렉토리 구성
- runit 로그
- Logrotate
- UDP 로그 전달
- 사용자 정의 NGINX 로그 형식 사용
- JSON 로깅
- 텍스트 로깅
- rbtrace
- 로그 수준/상세도 구성
- 사용자 정의 로그 그룹 설정
리눅스 패키지 설치의 로그
GitLab은 모든 서비스 및 구성 요소가 시스템 로그를 출력하는 고급 로그 시스템을 포함하고 있습니다.
여기에는 리눅스 패키지 설치에서 이러한 로그를 관리하기 위한 구성 설정과 도구가 있습니다.
서버의 콘솔에서 로그 미리보기
‘미리보기’(tail) 원하는 경우, 즉 GitLab 로그의 실시간 로그 업데이트를 보려면
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-managed 서비스는 svlogd
를 사용하여 로그 데이터를 생성합니다.
- 로그는
current
라는 파일에 기록됩니다. - 주기적으로 이 로그는 압축되어 TAI64N 형식으로 이름이 변경됩니다. 예:
@400000005f8eaf6f1a80ef5c.s
. - 압축된 로그의 파일 시스템 날짜 타임스탬프는 GitLab이 마지막으로 해당 파일에 기록한 시간과 일치합니다.
-
zmore
및zgrep
는 압축되거나 압축되지 않은 로그를 조회하고 검색할 수 있습니다.
생성된 파일에 대한 자세한 내용은 svlogd 문서를 읽어보세요.
다음 설정을 통해 /etc/gitlab/gitlab.rb
에서 svlogd 설정을 수정할 수 있습니다:
# 아래는 기본값입니다
logging['svlogd_size'] = 200 * 1024 * 1024 # 로그 데이터가 200 MB가 된 후 회전
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"
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 매뉴얼 페이지(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 # 숫자 대신 회전된 파일에 날짜 확장을 사용하며, 예를 들어 "-%Y-%m-%d" 값을 사용하면 production.log-2016-03-09.gz와 같은 파일이 생성됩니다.
개별 서비스 logrotate 설정 구성
/etc/gitlab/gitlab.rb
를 사용하여 각 개별 서비스의 logrotate 설정을 사용자 정의할 수 있습니다. 예를 들어, nginx
서비스의 logrotate 주기와 크기를 사용자 정의하려면 다음과 같이 사용하십시오:
nginx['logrotate_frequency'] = nil
nginx['logrotate_size'] = "200M"
logrotate 비활성화
다음 설정을 사용하여 /etc/gitlab/gitlab.rb
에서 내장 logrotate 서비스를 비활성화할 수도 있습니다:
logrotate['enable'] = false
Logrotate notifempty
설정
logrotate 서비스는 비구성 가능한 기본값인 notifempty
로 실행되며, 다음과 같은 문제를 해결합니다:
- 불필요하게 회전되는 빈 로그 및 종종 많은 빈 로그가 저장됩니다.
- 장기적인 문제 해결에 유용한 일회성 로그가 30일 후에 삭제되며, 예를 들어 데이터베이스 마이그레이션 로그입니다.
Logrotate 일회성 및 빈 로그 처리
이제 로그는 필요에 따라 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
logrotate가 트리거되는 빈도 증가
logrotate 스크립트는 50분마다 트리거되며, 로그를 회전하기 전에 10분 동안 대기합니다.
이 값을 수정하려면:
-
/etc/gitlab/gitlab.rb
를 편집합니다:logrotate['pre_sleep'] = 600 # 시작 후 회전하기 전에 10분 대기 logrotate['post_sleep'] = 3000 # 회전 후 50분 대기
-
GitLab을 재구성합니다:
sudo gitlab-ctl reconfigure
UDP 로그 전달
Linux 패키지 설치는 svlogd의 UDP 로깅 기능을 활용할 수 있으며, UDP를 사용하여 syslog 호환 원격 시스템에 비-svlogd 로그를 전송할 수 있습니다.
Linux 패키지 설치에서 syslog 프로토콜 메시지를 UDP를 통해 전송하도록 구성하려면 다음 설정을 사용하세요:
logging['udp_log_shipping_host'] = '1.2.3.4' # 귀하의 syslog 서버
# logging['udp_log_shipping_hostname'] = nil # 선택 사항, 기본값은 시스템 호스트name
logging['udp_log_shipping_port'] = 1514 # 선택 사항, 기본값은 514 (syslog)
예제 로그 메시지:
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 액세스 로그는 쿼리 문자열에 포함된 잠재적으로 민감한 정보를 숨기기 위해 설계된 ‘결합된’ NGINX 형식의 버전을 사용합니다.
사용자 정의 로그 형식 문자열을 사용하려면 /etc/gitlab/gitlab.rb
에 지정할 수 있습니다 - 형식 세부정보는 NGINX 문서를 참조하세요.
nginx['log_format'] = 'my format string $foo $bar'
mattermost_nginx['log_format'] = 'my format string $foo $bar'
JSON 로깅
구조화된 로그는 Elasticsearch, Splunk 또는 다른 로그 관리 시스템에 구문 분석을 위해 JSON을 통해 내보낼 수 있습니다.
JSON 형식은 이를 지원하는 모든 서비스에 대해 기본적으로 활성화되어 있습니다.
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'
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, Container Registry, GitLab Shell 및 Gitaly의 최소 로그 수준(상세도)을 구성할 수 있습니다:
-
/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" } }
-
GitLab을 재구성합니다:
sudo gitlab-ctl reconfigure
production_json.log
, graphql_json.log
등의
log_level
은 편집할 수 없습니다.
또한 기본 로그 수준 재정의를 참조하세요.사용자 정의 로그 그룹 설정
GitLab은 구성된 로그 디렉토리에 사용자 정의 그룹을 할당하는 것을 지원합니다.
/etc/gitlab/gitlab.rb
파일에서
전역 logging['log_group']
설정과
서비스별 log_group
설정(예: gitaly['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
를 실행할 때 그룹을 생성하지 않습니다.