GitLab의 로그 시스템은 GitLab 인스턴스를 분석하기 위한 포괄적인 로깅 및 모니터링 기능을 제공합니다. 로그를 사용하여 시스템 문제를 파악하고, 보안 이벤트를 조사하고, 애플리케이션 성능을 분석할 수 있습니다. 모든 작업에 대해 로그 항목이 존재하므로, 문제가 발생할 때 이러한 로그를 통해 신속하게 진단하고 해결하는 데 필요한 데이터를 얻을 수 있습니다.

로그 시스템은:

• 구조화된 로그 파일에서 GitLab 구성 요소 전체의 모든 애플리케이션 활동을 추적합니다.
• 표준화된 형식으로 성능 메트릭, 오류 및 보안 이벤트를 기록합니다.
• JSON 로깅을 통해 Elasticsearch, Splunk와 같은 로그 분석 도구와 통합됩니다.
• 다양한 GitLab 서비스 및 구성 요소별로 별도의 로그 파일을 유지 관리합니다.
• 전체 시스템에서 요청을 추적하기 위한 상관관계 ID를 포함합니다.

시스템 로그 파일은 일반적으로 표준 로그 파일 형식의 일반 텍스트입니다.

로그 시스템은 감사 이벤트와 유사합니다. 자세한 정보는 다음을 참조하세요:

• Linux 패키지 설치에서 로깅 커스터마이징
• JSON 형식의 GitLab 로그 파싱 및 분석

로그 수준#

각 로그 메시지에는 중요도와 상세도를 나타내는 로그 수준이 할당되어 있습니다. 각 로거에는 할당된 최소 로그 수준이 있습니다. 로거는 로그 수준이 최소 로그 수준 이상인 경우에만 로그 메시지를 내보냅니다.

지원되는 로그 수준은 다음과 같습니다:

GitLab 로거는 기본적으로 DEBUG로 설정되어 있어 모든 로그 메시지를 내보냅니다.

기본 로그 수준 재정의#

GITLAB_LOG_LEVEL 환경 변수를 사용하여 GitLab 로거의 최소 로그 수준을 재정의할 수 있습니다. 유효한 값은 0에서 5 사이의 값 또는 로그 수준 이름입니다.

예시:

GITLAB_LOG_LEVEL=info

일부 서비스의 경우 이 설정의 영향을 받지 않는 다른 로그 수준이 적용됩니다. 일부 서비스에는 로그 수준을 재정의하는 자체 환경 변수가 있습니다. 예를 들면:

로그 순환#

특정 서비스의 로그는 다음 방법으로 관리하고 순환할 수 있습니다:

• logrotate
• svlogd (runit의 서비스 로깅 데몬)
• logrotate와 svlogd 모두
• 또는 전혀 관리하지 않음

다음 표에는 포함된 서비스의 로그를 관리하고 순환하는 데 책임이 있는 데몬에 대한 정보가 포함되어 있습니다:

• svlogd로 관리되는 로그는 current라는 파일에 기록됩니다. 아카이브 버전은 @<hexadecimal-ID>.s 파일로 압축됩니다.
• GitLab에 내장된 logrotate 서비스는 다른 모든 로그를 관리합니다. 아카이브 버전은 <original-name>.<number>.gz 파일로 압축됩니다.

이러한 로그를 생성하는 서비스에 대한 자세한 정보는 GitLab 아키텍처 개요를 참조하세요.

Helm 차트 설치에서 로그 접근#

Helm 차트 설치에서 GitLab 구성 요소는 kubectl logs를 사용하여 접근할 수 있는 stdout으로 로그를 전송합니다. 로그는 파드 수명 동안 /var/log/gitlab의 파드에서도 사용할 수 있습니다.

구조화된 로그가 있는 파드 (서브컴포넌트 필터링)#

일부 파드에는 특정 로그 유형을 식별하는 subcomponent 필드가 포함되어 있습니다:

# Webservice 파드 로그 (Rails 애플리케이션)
kubectl logs -l app=webservice -c webservice | jq 'select(."subcomponent"=="<subcomponent-key>")'

# Sidekiq 파드 로그 (백그라운드 작업)
kubectl logs -l app=sidekiq | jq 'select(."subcomponent"=="<subcomponent-key>")'

다음 로그 섹션에는 해당되는 경우 적절한 파드 및 서브컴포넌트 키가 표시되어 있습니다.

기타 파드#

서브컴포넌트로 구조화된 로그를 사용하지 않는 다른 GitLab 구성 요소의 경우, 로그에 직접 접근할 수 있습니다.

사용 가능한 파드 선택기를 찾으려면:

# 사용 중인 모든 고유 app 레이블 목록
kubectl get pods -o jsonpath='{range .items[*]}{.metadata.labels.app}{"\n"}{end}' | grep -v '^$' | sort | uniq

# app 레이블이 있는 파드의 경우
kubectl logs -l app=<pod-selector>

# 특정 파드의 경우 (app 레이블을 사용할 수 없는 경우)
kubectl get pods
kubectl logs <pod-name>

Kubernetes 트러블슈팅 명령어에 대한 자세한 정보는 Kubernetes 치트 시트를 참조하세요.

production_json.log#

이 로그의 위치:

• Linux 패키지 설치에서 /var/log/gitlab/gitlab-rails/production_json.log 파일.
• 소스 컴파일 설치에서 /home/git/gitlab/log/production_json.log 파일.
• Helm 차트 설치에서 subcomponent="production_json" 키 아래 Webservice 파드.

Lograge 덕분에 GitLab으로부터 수신된 Rails 컨트롤러 요청에 대한 구조화된 로그를 포함합니다. API 요청은 api_json.log의 별도 파일에 기록됩니다.

각 행에는 Elasticsearch, Splunk와 같은 서비스에서 수집할 수 있는 JSON이 포함되어 있습니다. 가독성을 위해 예시에 줄바꿈이 추가되었습니다:

{
  "method":"GET",
  "path":"/gitlab/gitlab-foss/issues/1234",
  "format":"html",
  "controller":"Projects::IssuesController",
  "action":"show",
  "status":200,
  "time":"2017-08-08T20:15:54.821Z",
  "params":[{"key":"param_key","value":"param_value"}],
  "remote_ip":"18.245.0.1",
  "user_id":1,
  "username":"admin",
  "queue_duration_s":0.0,
  "gitaly_calls":16,
  "gitaly_duration_s":0.16,
  "redis_calls":115,
  "redis_duration_s":0.13,
  "redis_read_bytes":1507378,
  "redis_write_bytes":2920,
  "correlation_id":"O1SdybnnIq7",
  "cpu_s":17.50,
  "db_duration_s":0.08,
  "view_duration_s":2.39,
  "duration_s":20.54,
  "pid": 81836,
  "worker_id":"puma_0"
}

이 예시는 특정 이슈에 대한 GET 요청이었습니다. 각 행에는 성능 데이터도 포함되어 있으며, 시간은 초 단위입니다:

• duration_s: 요청을 검색하는 데 걸린 총 시간
• queue_duration_s: GitLab Workhorse 내부에서 요청이 대기한 총 시간
• view_duration_s: Rails 뷰 내부에서 보낸 총 시간
• db_duration_s: PostgreSQL에서 데이터를 검색하는 데 걸린 총 시간
• cpu_s: CPU에서 소비한 총 시간
• gitaly_duration_s: Gitaly 호출로 인한 총 시간
• gitaly_calls: Gitaly에 대한 총 호출 수
• redis_calls: Redis에 대한 총 호출 수
• redis_cross_slot_calls: Redis에 대한 크로스 슬롯 호출 총 수
• redis_allowed_cross_slot_calls: Redis에 허용된 크로스 슬롯 호출 총 수
• redis_duration_s: Redis에서 데이터를 검색하는 데 걸린 총 시간
• redis_read_bytes: Redis에서 읽은 총 바이트 수
• redis_write_bytes: Redis에 쓴 총 바이트 수
• redis_<instance>_calls: Redis 인스턴스에 대한 총 호출 수
• redis_<instance>_cross_slot_calls: Redis 인스턴스에 대한 크로스 슬롯 호출 총 수
• redis_<instance>_allowed_cross_slot_calls: Redis 인스턴스에 허용된 크로스 슬롯 호출 총 수
• redis_<instance>_duration_s: Redis 인스턴스에서 데이터를 검색하는 데 걸린 총 시간
• redis_<instance>_read_bytes: Redis 인스턴스에서 읽은 총 바이트 수
• redis_<instance>_write_bytes: Redis 인스턴스에 쓴 총 바이트 수
• pid: 워커의 Linux 프로세스 ID (워커가 재시작될 때 변경됨)
• worker_id: 워커의 논리적 ID (워커가 재시작될 때 변경되지 않음)

HTTP 전송을 사용한 사용자 클론 및 fetch 활동은 로그에 action: git_upload_pack으로 표시됩니다.

또한, 로그에는 발신 IP 주소(remote_ip), 사용자 ID(user_id), 사용자 이름(username)이 포함됩니다.

고급 검색을 사용하는 경우 일부 엔드포인트(예: /search)는 Elasticsearch에 요청할 수 있습니다. 이 경우 추가로 elasticsearch_calls와 elasticsearch_call_duration_s가 기록되며, 다음에 해당합니다:

• elasticsearch_calls: Elasticsearch에 대한 총 호출 수
• elasticsearch_duration_s: Elasticsearch 호출에 소요된 총 시간
• elasticsearch_timed_out_count: 시간 초과되어 부분 결과를 반환한 Elasticsearch 호출 총 수

ActionCable 연결 및 구독 이벤트도 이 파일에 기록되며, 앞의 형식을 따릅니다. method, path, format 필드는 적용되지 않으며 항상 비어 있습니다. ActionCable 연결 또는 채널 클래스가 controller로 사용됩니다.

{
  "method":null,
  "path":null,
  "format":null,
  "controller":"IssuesChannel",
  "action":"subscribe",
  "status":200,
  "time":"2020-05-14T19:46:22.008Z",
  "params":[{"key":"project_path","value":"gitlab/gitlab-foss"},{"key":"iid","value":"1"}],
  "remote_ip":"127.0.0.1",
  "user_id":1,
  "username":"admin",
  "ua":"Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:76.0) Gecko/20100101 Firefox/76.0",
  "correlation_id":"jSOIEynHCUa",
  "duration_s":0.32566
}

{
  "method": "GET",
  "path": "/admin",
  "format": "html",
  "controller": "Admin::DashboardController",
  "action": "index",
  "status": 500,
  "time": "2019-11-14T13:12:46.156Z",
  "params": [],
  "remote_ip": "127.0.0.1",
  "user_id": 1,
  "username": "root",
  "ua": "Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:70.0) Gecko/20100101 Firefox/70.0",
  "queue_duration": 274.35,
  "correlation_id": "KjDVUhNvvV3",
  "queue_duration_s":0.0,
  "gitaly_calls":16,
  "gitaly_duration_s":0.16,
  "redis_calls":115,
  "redis_duration_s":0.13,
  "correlation_id":"O1SdybnnIq7",
  "cpu_s":17.50,
  "db_duration_s":0.08,
  "view_duration_s":2.39,
  "duration_s":20.54,
  "pid": 81836,
  "worker_id": "puma_0",
  "exception.class": "NameError",
  "exception.message": "undefined local variable or method `adsf' for #",
  "exception.backtrace": [
    "app/controllers/admin/dashboard_controller.rb:11:in `index'",
    "ee/app/controllers/ee/admin/dashboard_controller.rb:14:in `index'",
    "ee/lib/gitlab/ip_address_state.rb:10:in `with'",
    "ee/app/controllers/ee/application_controller.rb:43:in `set_current_ip_address'",
    "lib/gitlab/session.rb:11:in `with_session'",
    "app/controllers/application_controller.rb:450:in `set_session_storage'",
    "app/controllers/application_controller.rb:444:in `set_locale'",
    "ee/lib/gitlab/jira/middleware.rb:19:in `call'"
  ]
}

production.log#

이 로그의 위치:

• Linux 패키지 설치에서 /var/log/gitlab/gitlab-rails/production.log 파일.
• 소스 컴파일 설치에서 /home/git/gitlab/log/production.log 파일.

수행된 모든 요청에 대한 정보가 포함됩니다. URL과 요청 유형, IP 주소, 이 특정 요청을 처리하는 데 관련된 코드 부분을 확인할 수 있습니다. 또한 수행된 모든 SQL 요청과 각 요청에 소요된 시간을 확인할 수 있습니다. 이 작업은 GitLab 기여자와 개발자에게 더 유용합니다. 버그를 보고할 때 이 로그 파일의 일부를 사용하세요. 예를 들면:

Started GET "/gitlabhq/yaml_db/tree/master" for 168.111.56.1 at 2015-02-12 19:34:53 +0200
Processing by Projects::TreeController#show as HTML
  Parameters: {"project_id"=>"gitlabhq/yaml_db", "id"=>"master"}

  ... [CUT OUT]

  Namespaces"."created_at" DESC, "namespaces"."id" DESC LIMIT 1 [["id", 26]]
  CACHE (0.0ms) SELECT  "members".* FROM "members"  WHERE "members"."source_type" = 'Project' AND "members"."type" IN ('ProjectMember') AND "members"."source_id" = $1 AND "members"."source_type" = $2 AND "members"."user_id" = 1  ORDER BY "members"."created_at" DESC, "members"."id" DESC LIMIT 1  [["source_id", 18], ["source_type", "Project"]]
  CACHE (0.0ms) SELECT  "members".* FROM "members"  WHERE "members"."source_type" = 'Project' AND "members".
  (1.4ms) SELECT COUNT(*) FROM "merge_requests"  WHERE "merge_requests"."target_project_id" = $1 AND ("merge_requests"."state" IN ('opened','reopened')) [["target_project_id", 18]]
  Rendered layouts/nav/_project.html.haml (28.0ms)
  Rendered layouts/_collapse_button.html.haml (0.2ms)
  Rendered layouts/_flash.html.haml (0.1ms)
  Rendered layouts/_page.html.haml (32.9ms)
Completed 200 OK in 166ms (Views: 117.4ms | ActiveRecord: 27.2ms)

이 예시에서 서버는 IP 168.111.56.1에서 2015-02-12 19:34:53 +0200에 URL /gitlabhq/yaml_db/tree/master의 HTTP 요청을 처리했습니다. 요청은 Projects::TreeController에 의해 처리되었습니다.

api_json.log#

이 로그의 위치:

• Linux 패키지 설치에서 /var/log/gitlab/gitlab-rails/api_json.log 파일.
• 소스 컴파일 설치에서 /home/git/gitlab/log/api_json.log 파일.
• Helm 차트 설치에서 subcomponent="api_json" 키 아래 Webservice 파드.

API에 직접 요청을 확인하는 데 도움이 됩니다. 예를 들면:

{
  "time":"2018-10-29T12:49:42.123Z",
  "severity":"INFO",
  "duration":709.08,
  "db":14.59,
  "view":694.49,
  "status":200,
  "method":"GET",
  "path":"/api/v4/projects",
  "params":[{"key":"action","value":"git-upload-pack"},{"key":"changes","value":"_any"},{"key":"key_id","value":"secret"},{"key":"secret_token","value":"[FILTERED]"}],
  "host":"localhost",
  "remote_ip":"::1",
  "ua":"Ruby",
  "route":"/api/:version/projects",
  "user_id":1,
  "username":"root",
  "queue_duration":100.31,
  "gitaly_calls":30,
  "gitaly_duration":5.36,
  "pid": 81836,
  "worker_id": "puma_0",
  ...
}

이 항목은 연결된 SSH 키가 git fetch 또는 git clone을 사용하여 해당 프로젝트를 다운로드할 수 있는지 확인하기 위해 접근된 내부 엔드포인트를 보여줍니다. 이 예시에서 볼 수 있는 것:

• duration: 요청을 검색하는 데 걸린 총 시간 (밀리초)
• queue_duration: GitLab Workhorse 내부에서 요청이 대기한 총 시간 (밀리초)
• method: 요청에 사용된 HTTP 메서드
• path: 쿼리의 상대 경로
• params: 쿼리 문자열 또는 HTTP 본문에 전달된 키-값 쌍 (비밀번호 및 토큰과 같은 민감한 매개변수는 필터링됨)
• ua: 요청자의 User-Agent

application.log (지원 중단됨)#

히스토리

• GitLab 15.10에서 지원 중단됨.

이 로그의 위치:

• Linux 패키지 설치에서 /var/log/gitlab/gitlab-rails/application.log 파일.
• 소스 컴파일 설치에서 /home/git/gitlab/log/application.log 파일.

다음 예시와 같이 application_json.log의 로그보다 구조화가 덜 된 버전을 포함합니다:

October 06, 2014 11:56: User "Administrator" (admin@example.com) was created
October 06, 2014 11:56: Documentcloud created a new project "Documentcloud / Underscore"
October 06, 2014 11:56: Gitlab Org created a new project "Gitlab Org / Gitlab Ce"
October 07, 2014 11:25: User "Claudie Hodkiewicz" (nasir_stehr@olson.co.uk)  was removed
October 07, 2014 11:25: Project "project133" was removed

application_json.log#

이 로그의 위치:

• Linux 패키지 설치에서 /var/log/gitlab/gitlab-rails/application_json.log 파일.
• 소스 컴파일 설치에서 /home/git/gitlab/log/application_json.log 파일.
• Helm 차트 설치에서 subcomponent="application_json" 키 아래 Sidekiq 및 Webservice 파드.

사용자 생성 및 프로젝트 삭제와 같은 인스턴스에서 발생하는 이벤트를 발견하는 데 도움이 됩니다. 예를 들면:

{
  "severity":"INFO",
  "time":"2020-01-14T13:35:15.466Z",
  "correlation_id":"3823a1550b64417f9c9ed8ee0f48087e",
  "message":"User \"Administrator\" (admin@example.com) was created"
}
{
  "severity":"INFO",
  "time":"2020-01-14T13:35:15.466Z",
  "correlation_id":"78e3df10c9a18745243d524540bd5be4",
  "message":"Project \"project133\" was removed"
}

integrations_json.log#

이 로그의 위치:

• Linux 패키지 설치에서 /var/log/gitlab/gitlab-rails/integrations_json.log 파일.
• 소스 컴파일 설치에서 /home/git/gitlab/log/integrations_json.log 파일.
• Helm 차트 설치에서 subcomponent="integrations_json" 키 아래 Sidekiq 및 Webservice 파드.

Jira, Asana, irker 서비스와 같은 통합 활동에 대한 정보를 포함합니다. 다음 예시와 같이 JSON 형식을 사용합니다:

{
  "severity":"ERROR",
  "time":"2018-09-06T14:56:20.439Z",
  "service_class":"Integrations::Jira",
  "project_id":8,
  "project_path":"h5bp/html5-boilerplate",
  "message":"Error sending message",
  "client_url":"http://jira.gitlab.com:8080",
  "error":"execution expired"
}
{
  "severity":"INFO",
  "time":"2018-09-06T17:15:16.365Z",
  "service_class":"Integrations::Jira",
  "project_id":3,
  "project_path":"namespace2/project2",
  "message":"Successfully posted",
  "client_url":"http://jira.example.com"
}

kubernetes.log (지원 중단됨)#

히스토리

• GitLab 14.5에서 지원 중단됨.

이 로그의 위치:

• Linux 패키지 설치에서 /var/log/gitlab/gitlab-rails/kubernetes.log 파일.
• 소스 컴파일 설치에서 /home/git/gitlab/log/kubernetes.log 파일.
• Helm 차트 설치에서 subcomponent="kubernetes" 키 아래 Sidekiq 파드.

연결 오류와 같이 인증서 기반 클러스터와 관련된 정보를 기록합니다. 각 행에는 Elasticsearch, Splunk와 같은 서비스에서 수집할 수 있는 JSON이 포함됩니다.

git_json.log#

이 로그의 위치:

• Linux 패키지 설치에서 /var/log/gitlab/gitlab-rails/git_json.log 파일.
• 소스 컴파일 설치에서 /home/git/gitlab/log/git_json.log 파일.
• Helm 차트 설치에서 subcomponent="git_json" 키 아래 Sidekiq 파드.

GitLab은 Git 저장소와 상호 작용해야 하지만, 드물게 문제가 발생할 수 있습니다. 이 경우 정확히 무슨 일이 일어났는지 알아야 합니다. 이 로그 파일에는 GitLab에서 Git 저장소로의 실패한 모든 요청이 포함됩니다. 대부분의 경우 이 파일은 개발자에게만 유용합니다. 예를 들면:

{
   "severity":"ERROR",
   "time":"2019-07-19T22:16:12.528Z",
   "correlation_id":"FeGxww5Hj64",
   "message":"Command failed [1]: /usr/bin/git --git-dir=/Users/vsizov/gitlab-development-kit/gitlab/tmp/tests/gitlab-satellites/group184/gitlabhq/.git --work-tree=/Users/vsizov/gitlab-development-kit/gitlab/tmp/tests/gitlab-satellites/group184/gitlabhq merge --no-ff -mMerge branch 'feature_conflict' into 'feature' source/feature_conflict\n\nerror: failed to push some refs to '/Users/vsizov/gitlab-development-kit/repositories/gitlabhq/gitlab_git.git'"
}

audit_json.log#

이 로그의 위치:

• Linux 패키지 설치에서 /var/log/gitlab/gitlab-rails/audit_json.log 파일.
• 소스 컴파일 설치에서 /home/git/gitlab/log/audit_json.log 파일.
• Helm 차트 설치에서 subcomponent="audit_json" 키 아래 Sidekiq 및 Webservice 파드.

그룹 또는 프로젝트 설정 및 멤버십(target_details)에 대한 변경 사항이 이 파일에 기록됩니다. 예를 들면:

{
  "severity":"INFO",
  "time":"2018-10-17T17:38:22.523Z",
  "author_id":3,
  "entity_id":2,
  "entity_type":"Project",
  "change":"visibility",
  "from":"Private",
  "to":"Public",
  "author_name":"John Doe4",
  "target_id":2,
  "target_type":"Project",
  "target_details":"namespace2/project2"
}

Sidekiq 로그#

Linux 패키지 설치에서 일부 Sidekiq 로그는 /var/log/gitlab/sidekiq/current 및 다음 위치에 있습니다.

sidekiq.log#

히스토리

• Helm 차트 설치의 기본 로그 형식이 GitLab 16.0 이상에서 text에서 json으로 변경됨.

이 로그의 위치:

• Linux 패키지 설치에서 /var/log/gitlab/sidekiq/current 파일.
• 소스 컴파일 설치에서 /home/git/gitlab/log/sidekiq.log 파일.

GitLab은 오랜 시간이 걸릴 수 있는 작업 처리를 위해 백그라운드 작업을 사용합니다. 이러한 작업 처리에 대한 모든 정보는 이 파일에 기록됩니다. 예를 들면:

{
  "severity":"INFO",
  "time":"2018-04-03T22:57:22.071Z",
  "queue":"cronjob:update_all_mirrors",
  "args":[],
  "class":"UpdateAllMirrorsWorker",
  "retry":false,
  "queue_namespace":"cronjob",
  "jid":"06aeaa3b0aadacf9981f368e",
  "created_at":"2018-04-03T22:57:21.930Z",
  "enqueued_at":"2018-04-03T22:57:21.931Z",
  "pid":10077,
  "worker_id":"sidekiq_0",
  "message":"UpdateAllMirrorsWorker JID-06aeaa3b0aadacf9981f368e: done: 0.139 sec",
  "job_status":"done",
  "duration":0.139,
  "completed_at":"2018-04-03T22:57:22.071Z",
  "db_duration":0.05,
  "db_duration_s":0.0005,
  "gitaly_duration":0,
  "gitaly_calls":0
}

JSON 로그 대신 Sidekiq의 텍스트 로그를 생성할 수도 있습니다. 예를 들면:

2023-05-16T16:08:55.272Z pid=82525 tid=23rl INFO: Initializing websocket
2023-05-16T16:08:55.279Z pid=82525 tid=23rl INFO: Booted Rails 6.1.7.2 application in production environment
2023-05-16T16:08:55.279Z pid=82525 tid=23rl INFO: Running in ruby 3.0.5p211 (2022-11-24 revision ba5cf0f7c5) [arm64-darwin22]
2023-05-16T16:08:55.279Z pid=82525 tid=23rl INFO: See LICENSE and the LGPL-3.0 for licensing details.
2023-05-16T16:08:55.279Z pid=82525 tid=23rl INFO: Upgrade to Sidekiq Pro for more features and support: https://sidekiq.org
2023-05-16T16:08:55.286Z pid=82525 tid=7p4t INFO: Cleaning working queues
2023-05-16T16:09:06.043Z pid=82525 tid=7p7d class=ScheduleMergeRequestCleanupRefsWorker jid=efcc73f169c09a514b06da3f INFO: start
2023-05-16T16:09:06.050Z pid=82525 tid=7p7d class=ScheduleMergeRequestCleanupRefsWorker jid=efcc73f169c09a514b06da3f INFO: arguments: []
2023-05-16T16:09:06.065Z pid=82525 tid=7p81 class=UserStatusCleanup::BatchWorker jid=e279aa6409ac33031a314822 INFO: start
2023-05-16T16:09:06.066Z pid=82525 tid=7p81 class=UserStatusCleanup::BatchWorker jid=e279aa6409ac33031a314822 INFO: arguments: []

Linux 패키지 설치의 경우 다음 구성 옵션을 추가하세요:

sidekiq['log_format'] = 'text'

소스 컴파일 설치의 경우 gitlab.yml을 편집하고 Sidekiq log_format 구성 옵션을 설정하세요:

  ## Sidekiq
  sidekiq:
    log_format: text

sidekiq_client.log#

이 로그의 위치:

• Linux 패키지 설치에서 /var/log/gitlab/gitlab-rails/sidekiq_client.log 파일.
• 소스 컴파일 설치에서 /home/git/gitlab/log/sidekiq_client.log 파일.
• Helm 차트 설치에서 subcomponent="sidekiq_client" 키 아래 Webservice 파드.

이 파일은 Sidekiq이 처리를 시작하기 전(예: 큐에 넣기 전)의 작업에 대한 로깅 정보를 포함합니다.

이 로그 파일은 앞서 언급한 대로 Sidekiq에 대해 구성한 경우 JSON으로 구조화되는 sidekiq.log와 동일한 구조를 따릅니다.

gitlab-shell.log#

GitLab Shell은 GitLab에서 Git 명령을 실행하고 Git 저장소에 대한 SSH 접근을 제공하는 데 사용됩니다.

git-{upload-pack,receive-pack} 요청을 포함하는 정보는 /var/log/gitlab/gitlab-shell/gitlab-shell.log에 있습니다. Gitaly에서 GitLab Shell로의 훅에 대한 정보는 /var/log/gitlab/gitaly/current에 있습니다.

/var/log/gitlab/gitlab-shell/gitlab-shell.log의 예시 로그 항목:

{
  "duration_ms": 74.104,
  "level": "info",
  "method": "POST",
  "msg": "Finished HTTP request",
  "time": "2020-04-17T20:28:46Z",
  "url": "http://127.0.0.1:8080/api/v4/internal/allowed"
}
{
  "command": "git-upload-pack",
  "git_protocol": "",
  "gl_project_path": "root/example",
  "gl_repository": "project-1",
  "level": "info",
  "msg": "executing git command",
  "time": "2020-04-17T20:28:46Z",
  "user_id": "user-1",
  "username": "root"
}

/var/log/gitlab/gitaly/current의 예시 로그 항목:

{
  "method": "POST",
  "url": "http://127.0.0.1:8080/api/v4/internal/allowed",
  "duration": 0.058012959,
  "gitaly_embedded": true,
  "pid": 16636,
  "level": "info",
  "msg": "finished HTTP request",
  "time": "2020-04-17T20:29:08+00:00"
}
{
  "method": "POST",
  "url": "http://127.0.0.1:8080/api/v4/internal/pre_receive",
  "duration": 0.031022552,
  "gitaly_embedded": true,
  "pid": 16636,
  "level": "info",
  "msg": "finished HTTP request",
  "time": "2020-04-17T20:29:08+00:00"
}

Gitaly 로그#

이 파일은 /var/log/gitlab/gitaly/current에 있으며 runit에 의해 생성됩니다. runit은 Linux 패키지와 함께 패키지되어 있으며 Linux 패키지 문서에서 목적에 대한 간략한 설명을 확인할 수 있습니다.

grpc.log#

이 파일은 Linux 패키지 설치에서 /var/log/gitlab/gitlab-rails/grpc.log에 있습니다. Gitaly에서 사용되는 네이티브 gRPC 로깅입니다.

gitaly_hooks.log#

이 파일은 /var/log/gitlab/gitaly/gitaly_hooks.log에 있으며 gitaly-hooks 명령에 의해 생성됩니다. GitLab API로부터의 응답 처리 중 수신된 실패에 대한 레코드도 포함됩니다.

Puma 로그#

puma_stdout.log#

이 로그의 위치:

• Linux 패키지 설치에서 /var/log/gitlab/puma/puma_stdout.log 파일.
• 소스 컴파일 설치에서 /home/git/gitlab/log/puma_stdout.log 파일.

puma_stderr.log#

이 로그의 위치:

• Linux 패키지 설치에서 /var/log/gitlab/puma/puma_stderr.log 파일.
• 소스 컴파일 설치에서 /home/git/gitlab/log/puma_stderr.log 파일.

repocheck.log#

이 로그의 위치:

• Linux 패키지 설치에서 /var/log/gitlab/gitlab-rails/repocheck.log 파일.
• 소스 컴파일 설치에서 /home/git/gitlab/log/repocheck.log 파일.
• Helm 차트 설치에서 subcomponent="repocheck" 키 아래 Sidekiq 파드.

프로젝트에서 저장소 검사가 실행될 때마다 정보를 기록합니다.

importer.log#

이 로그의 위치:

• Linux 패키지 설치에서 /var/log/gitlab/gitlab-rails/importer.log 파일.
• 소스 컴파일 설치에서 /home/git/gitlab/log/importer.log 파일.
• Helm 차트 설치에서 subcomponent="importer" 키 아래 Sidekiq 파드.

이 파일은 프로젝트 가져오기 및 마이그레이션 진행 상황을 기록합니다.

exporter.log#

이 로그의 위치:

• Linux 패키지 설치에서 /var/log/gitlab/gitlab-rails/exporter.log 파일.
• 소스 컴파일 설치에서 /home/git/gitlab/log/exporter.log 파일.
• Helm 차트 설치에서 subcomponent="exporter" 키 아래 Sidekiq 및 Webservice 파드.

내보내기 프로세스의 진행 상황을 기록합니다.

features_json.log#

이 로그의 위치:

• Linux 패키지 설치에서 /var/log/gitlab/gitlab-rails/features_json.log 파일.
• 소스 컴파일 설치에서 /home/git/gitlab/log/features_json.log 파일.
• Helm 차트 설치에서 subcomponent="features_json" 키 아래 Sidekiq 및 Webservice 파드.

GitLab 개발에서 피처 플래그의 수정 이벤트가 이 파일에 기록됩니다. 예를 들면:

{"severity":"INFO","time":"2020-11-24T02:30:59.860Z","correlation_id":null,"key":"cd_auto_rollback","action":"enable","extra.thing":"true"}
{"severity":"INFO","time":"2020-11-24T02:31:29.108Z","correlation_id":null,"key":"cd_auto_rollback","action":"enable","extra.thing":"true"}
{"severity":"INFO","time":"2020-11-24T02:31:29.129Z","correlation_id":null,"key":"cd_auto_rollback","action":"disable","extra.thing":"false"}
{"severity":"INFO","time":"2020-11-24T02:31:29.177Z","correlation_id":null,"key":"cd_auto_rollback","action":"enable","extra.thing":"Project:1"}
{"severity":"INFO","time":"2020-11-24T02:31:29.183Z","correlation_id":null,"key":"cd_auto_rollback","action":"disable","extra.thing":"Project:1"}
{"severity":"INFO","time":"2020-11-24T02:31:29.188Z","correlation_id":null,"key":"cd_auto_rollback","action":"enable_percentage_of_time","extra.percentage":"50"}
{"severity":"INFO","time":"2020-11-24T02:31:29.193Z","correlation_id":null,"key":"cd_auto_rollback","action":"disable_percentage_of_time"}
{"severity":"INFO","time":"2020-11-24T02:31:29.198Z","correlation_id":null,"key":"cd_auto_rollback","action":"enable_percentage_of_actors","extra.percentage":"50"}
{"severity":"INFO","time":"2020-11-24T02:31:29.203Z","correlation_id":null,"key":"cd_auto_rollback","action":"disable_percentage_of_actors"}
{"severity":"INFO","time":"2020-11-24T02:31:29.329Z","correlation_id":null,"key":"cd_auto_rollback","action":"remove"}

ci_resource_groups_json.log#

히스토리

• GitLab 15.9에서 도입됨.

이 로그의 위치:

• Linux 패키지 설치에서 /var/log/gitlab/gitlab-rails/ci_resource_groups_json.log 파일.
• 소스 컴파일 설치에서 /home/git/gitlab/log/ci_resource_group_json.log 파일.
• Helm 차트 설치에서 subcomponent="ci_resource_groups_json" 키 아래 Sidekiq 및 Webservice 파드.

리소스 그룹 획득에 대한 정보를 포함합니다. 예를 들면:

{"severity":"INFO","time":"2023-02-10T23:02:06.095Z","correlation_id":"01GRYS10C2DZQ9J1G12ZVAD4YD","resource_group_id":1,"processable_id":288,"message":"attempted to assign resource to processable","success":true}
{"severity":"INFO","time":"2023-02-10T23:02:08.945Z","correlation_id":"01GRYS138MYEG32C0QEWMC4BDM","resource_group_id":1,"processable_id":288,"message":"attempted to release resource from processable","success":true}

예시는 각 항목에 대한 resource_group_id, processable_id, message, success 필드를 보여줍니다.

auth.log#

이 로그의 위치:

• Linux 패키지 설치에서 /var/log/gitlab/gitlab-rails/auth.log 파일.
• 소스 컴파일 설치에서 /home/git/gitlab/log/auth.log 파일.

이 로그는 다음을 기록합니다:

• 원시 엔드포인트의 속도 제한을 초과한 요청.
• 보호된 경로 남용 요청.
• 사용 가능한 경우 사용자 ID 및 사용자 이름.

auth_json.log#

이 로그의 위치:

• Linux 패키지 설치에서 /var/log/gitlab/gitlab-rails/auth_json.log 파일.
• 소스 컴파일 설치에서 /home/git/gitlab/log/auth_json.log 파일.
• Helm 차트 설치에서 subcomponent="auth_json" 키 아래 Sidekiq 및 Webservice 파드.

이 파일은 auth.log의 JSON 버전 로그를 포함합니다. 예를 들면:

{
    "severity":"ERROR",
    "time":"2023-04-19T22:14:25.893Z",
    "correlation_id":"01GYDSAKAN2SPZPAMJNRWW5H8S",
    "message":"Rack_Attack",
    "env":"blocklist",
    "remote_ip":"x.x.x.x",
    "request_method":"GET",
    "path":"/group/project.git/info/refs?service=git-upload-pack"
}

graphql_json.log#

이 로그의 위치:

• Linux 패키지 설치에서 /var/log/gitlab/gitlab-rails/graphql_json.log 파일.
• 소스 컴파일 설치에서 /home/git/gitlab/log/graphql_json.log 파일.
• Helm 차트 설치에서 subcomponent="graphql_json" 키 아래 Sidekiq 및 Webservice 파드.

GraphQL 쿼리가 파일에 기록됩니다. 예를 들면:

{"query_string":"query IntrospectionQuery{__schema {queryType { name },mutationType { name }}}...(etc)","variables":{"a":1,"b":2},"complexity":181,"depth":1,"duration_s":7}

clickhouse.log#

히스토리

• GitLab 16.5에서 도입됨.

이 로그의 위치:

• Linux 패키지 설치에서 /var/log/gitlab/gitlab-rails/clickhouse.log 파일.
• 소스 컴파일 설치에서 /home/git/gitlab/log/clickhouse.log 파일.
• Helm 차트 설치에서 subcomponent="clickhouse" 키 아래 Sidekiq 및 Webservice 파드.

clickhouse.log 파일은 GitLab의 ClickHouse 데이터베이스 클라이언트와 관련된 정보를 기록합니다.

migrations.log#

이 로그의 위치:

• Linux 패키지 설치에서 /var/log/gitlab/gitlab-rails/migrations.log 파일.
• 소스 컴파일 설치에서 /home/git/gitlab/log/migrations.log 파일.

이 파일은 데이터베이스 마이그레이션 진행 상황을 기록합니다.

mail_room_json.log (기본값)#

이 로그의 위치:

• Linux 패키지 설치에서 /var/log/gitlab/mailroom/current 파일.
• 소스 컴파일 설치에서 /home/git/gitlab/log/mail_room_json.log 파일.

이 구조화된 로그 파일은 mail_room gem의 내부 활동을 기록합니다. 이름과 경로는 구성 가능하므로 이름과 경로가 앞서 문서화된 것과 일치하지 않을 수 있습니다.

web_hooks.log#

히스토리

• GitLab 16.3에서 도입됨.

이 로그의 위치:

• Linux 패키지 설치에서 /var/log/gitlab/gitlab-rails/web_hooks.log 파일.
• 소스 컴파일 설치에서 /home/git/gitlab/log/web_hooks.log 파일.
• Helm 차트 설치에서 subcomponent="web_hooks" 키 아래 Sidekiq 파드.

Webhook의 백오프, 비활성화 및 재활성화 이벤트가 이 파일에 기록됩니다. 예를 들면:

{"severity":"INFO","time":"2020-11-24T02:30:59.860Z","hook_id":12,"action":"backoff","disabled_until":"2020-11-24T04:30:59.860Z","recent_failures":2}
{"severity":"INFO","time":"2020-11-24T02:30:59.860Z","hook_id":12,"action":"disable","disabled_until":null,"recent_failures":100}
{"severity":"INFO","time":"2020-11-24T02:30:59.860Z","hook_id":12,"action":"enable","disabled_until":null,"recent_failures":0}

재구성 로그#

재구성 로그 파일은 Linux 패키지 설치에서 /var/log/gitlab/reconfigure에 있습니다. 소스 컴파일 설치에는 재구성 로그가 없습니다. 재구성 로그는 gitlab-ctl reconfigure를 수동으로 실행하거나 업그레이드의 일부로 실행할 때마다 채워집니다.

재구성 로그 파일은 재구성이 시작된 UNIX 타임스탬프에 따라 이름이 지정됩니다. 예: 1509705644.log

sidekiq_exporter.log 및 web_exporter.log#

Prometheus 메트릭과 Sidekiq Exporter가 모두 활성화된 경우, Sidekiq은 웹 서버를 시작하고 정의된 포트(기본값: 8082)에서 수신합니다. 기본적으로 Sidekiq Exporter 접근 로그는 비활성화되어 있지만 활성화할 수 있습니다:

• Linux 패키지 설치에서 /etc/gitlab/gitlab.rb의 sidekiq['exporter_log_enabled'] = true 옵션 사용.
• 소스 컴파일 설치에서 gitlab.yml의 sidekiq_exporter.log_enabled 옵션 사용.

활성화되면 설치 방법에 따라 이 파일의 위치는 다음과 같습니다:

• Linux 패키지 설치에서 /var/log/gitlab/gitlab-rails/sidekiq_exporter.log.
• 소스 컴파일 설치에서 /home/git/gitlab/log/sidekiq_exporter.log.

Prometheus 메트릭과 Web Exporter가 모두 활성화된 경우, Puma는 웹 서버를 시작하고 정의된 포트(기본값: 8083)에서 수신하며, 접근 로그는 설치 방법에 따라 위치가 달라집니다:

• Linux 패키지 설치에서 /var/log/gitlab/gitlab-rails/web_exporter.log.
• 소스 컴파일 설치에서 /home/git/gitlab/log/web_exporter.log.

database_load_balancing.log#

GitLab 데이터베이스 로드 밸런싱의 세부 정보를 포함합니다.

이 로그의 위치:

• Linux 패키지 설치에서 /var/log/gitlab/gitlab-rails/database_load_balancing.log 파일.
• 소스 컴파일 설치에서 /home/git/gitlab/log/database_load_balancing.log 파일.
• Helm 차트 설치에서 subcomponent="database_load_balancing" 키 아래 Sidekiq 및 Webservice 파드.

zoekt.log#

히스토리

• GitLab 15.9에서 도입됨.

이 파일은 정확한 코드 검색과 관련된 정보를 기록합니다.

이 로그의 위치:

• Linux 패키지 설치에서 /var/log/gitlab/gitlab-rails/zoekt.log 파일.
• 소스 컴파일 설치에서 /home/git/gitlab/log/zoekt.log 파일.
• Helm 차트 설치에서 subcomponent="zoekt" 키 아래 Sidekiq 및 Webservice 파드.

elasticsearch.log#

이 파일은 Elasticsearch 통합과 관련된 정보를 기록하며, Elasticsearch 인덱싱 또는 검색 중 오류를 포함합니다.

이 로그의 위치:

• Linux 패키지 설치에서 /var/log/gitlab/gitlab-rails/elasticsearch.log 파일.
• 소스 컴파일 설치에서 /home/git/gitlab/log/elasticsearch.log 파일.
• Helm 차트 설치에서 subcomponent="elasticsearch" 키 아래 Sidekiq 및 Webservice 파드.

각 행에는 Elasticsearch, Splunk와 같은 서비스에서 수집할 수 있는 JSON이 포함됩니다. 명확성을 위해 다음 예시 행에 줄바꿈이 추가되었습니다:

{
  "severity":"DEBUG",
  "time":"2019-10-17T06:23:13.227Z",
  "correlation_id":null,
  "message":"redacted_search_result",
  "class_name":"Milestone",
  "id":2,
  "ability":"read_milestone",
  "current_user_id":2,
  "query":"project"
}

exceptions_json.log#

이 파일은 표준적이고 일관된 방식으로 복구된 예외를 처리하는 Gitlab::ErrorTracking에 의해 추적되는 예외에 대한 정보를 기록합니다.

이 로그의 위치:

• Linux 패키지 설치에서 /var/log/gitlab/gitlab-rails/exceptions_json.log 파일.
• 소스 컴파일 설치에서 /home/git/gitlab/log/exceptions_json.log 파일.
• Helm 차트 설치에서 subcomponent="exceptions_json" 키 아래 Sidekiq 및 Webservice 파드.

각 행에는 Elasticsearch에서 수집할 수 있는 JSON이 포함됩니다. 예를 들면:

{
  "severity": "ERROR",
  "time": "2019-12-17T11:49:29.485Z",
  "correlation_id": "AbDVUrrTvM1",
  "extra.project_id": 55,
  "extra.relation_key": "milestones",
  "extra.relation_index": 1,
  "exception.class": "NoMethodError",
  "exception.message": "undefined method `strong_memoize' for #",
  "exception.backtrace": [
    "lib/gitlab/import_export/relation_factory.rb:329:in `unique_relation?'",
    "lib/gitlab/import_export/relation_factory.rb:345:in `find_or_create_object!'"
  ]
}

service_measurement.log#

이 로그의 위치:

• Linux 패키지 설치에서 /var/log/gitlab/gitlab-rails/service_measurement.log 파일.
• 소스 컴파일 설치에서 /home/git/gitlab/log/service_measurement.log 파일.
• Helm 차트 설치에서 subcomponent="service_measurement" 키 아래 Sidekiq 및 Webservice 파드.

각 서비스 실행에 대한 측정값이 있는 단일 구조화 로그만 포함합니다. SQL 호출 수, execution_time, gc_stats, memory usage와 같은 측정값을 포함합니다.

예를 들면:

{ "severity":"INFO", "time":"2020-04-22T16:04:50.691Z","correlation_id":"04f1366e-57a1-45b8-88c1-b00b23dc3616","class":"Projects::ImportExport::ExportService","current_user":"John Doe","project_full_path":"group1/test-export","file_path":"/path/to/archive","gc_stats":{"count":{"before":127,"after":127,"diff":0},"heap_allocated_pages":{"before":10369,"after":10369,"diff":0},"heap_sorted_length":{"before":10369,"after":10369,"diff":0},"heap_allocatable_pages":{"before":0,"after":0,"diff":0},"heap_available_slots":{"before":4226409,"after":4226409,"diff":0},"heap_live_slots":{"before":2542709,"after":2641420,"diff":98711},"heap_free_slots":{"before":1683700,"after":1584989,"diff":-98711},"heap_final_slots":{"before":0,"after":0,"diff":0},"heap_marked_slots":{"before":2542704,"after":2542704,"diff":0},"heap_eden_pages":{"before":10369,"after":10369,"diff":0},"heap_tomb_pages":{"before":0,"after":0,"diff":0},"total_allocated_pages":{"before":10369,"after":10369,"diff":0},"total_freed_pages":{"before":0,"after":0,"diff":0},"total_allocated_objects":{"before":24896308,"after":24995019,"diff":98711},"total_freed_objects":{"before":22353599,"after":22353599,"diff":0},"malloc_increase_bytes":{"before":140032,"after":6650240,"diff":6510208},"malloc_increase_bytes_limit":{"before":25804104,"after":25804104,"diff":0},"minor_gc_count":{"before":94,"after":94,"diff":0},"major_gc_count":{"before":33,"after":33,"diff":0},"remembered_wb_unprotected_objects":{"before":34284,"after":34284,"diff":0},"remembered_wb_unprotected_objects_limit":{"before":68568,"after":68568,"diff":0},"old_objects":{"before":2404725,"after":2404725,"diff":0},"old_objects_limit":{"before":4809450,"after":4809450,"diff":0},"oldmalloc_increase_bytes":{"before":140032,"after":6650240,"diff":6510208},"oldmalloc_increase_bytes_limit":{"before":68537556,"after":68537556,"diff":0}},"time_to_finish":0.12298400001600385,"number_of_sql_calls":70,"memory_usage":"0.0 MiB","label":"process_48616"}

geo.log#

이 로그의 위치:

• Linux 패키지 설치에서 /var/log/gitlab/gitlab-rails/geo.log 파일.
• 소스 컴파일 설치에서 /home/git/gitlab/log/geo.log 파일.
• Helm 차트 설치에서 subcomponent="geo" 키 아래 Sidekiq 및 Webservice 파드.

이 파일에는 Geo가 저장소와 파일을 동기화하려고 할 때의 정보가 포함됩니다. 파일의 각 행에는 Elasticsearch 또는 Splunk와 같은 서비스에 수집할 수 있는 별도의 JSON 항목이 포함됩니다.

예를 들면:

{"severity":"INFO","time":"2017-08-06T05:40:16.104Z","message":"Repository update","project_id":1,"source":"repository","resync_repository":true,"resync_wiki":true,"class":"Gitlab::Geo::LogCursor::Daemon","cursor_delay_s":0.038}

이 메시지는 Geo가 프로젝트 1에 대한 저장소 업데이트가 필요하다고 감지했음을 보여줍니다.

update_mirror_service_json.log#

이 로그의 위치:

• Linux 패키지 설치에서 /var/log/gitlab/gitlab-rails/update_mirror_service_json.log 파일.
• 소스 컴파일 설치에서 /home/git/gitlab/log/update_mirror_service_json.log 파일.
• Helm 차트 설치에서 subcomponent="update_mirror_service_json" 키 아래 Sidekiq 파드.

이 파일에는 프로젝트 미러링 중 발생한 LFS 오류에 대한 정보가 포함됩니다. 다른 프로젝트 미러링 오류를 이 로그로 이동하는 작업을 진행 중이므로, 일반 로그를 사용할 수 있습니다.

{
   "severity":"ERROR",
   "time":"2020-07-28T23:29:29.473Z",
   "correlation_id":"5HgIkCJsO53",
   "user_id":"x",
   "project_id":"x",
   "import_url":"https://mirror-source/group/project.git",
   "error_message":"The LFS objects download list couldn't be imported. Error: Unauthorized"
}

llm.log#

히스토리

• GitLab 16.0에서 도입됨.

llm.log 파일은 AI 기능과 관련된 정보를 기록합니다. 로깅에는 AI 이벤트에 대한 정보가 포함됩니다.

LLM 입력 및 출력 로깅#

히스토리

• GitLab 17.2에서 expanded_ai_logging이라는 플래그와 함께 도입됨. 기본적으로 비활성화됨.

LLM 프롬프트 입력 및 응답 출력을 기록하려면 expanded_ai_logging 피처 플래그를 활성화하세요. 이 플래그는 GitLab.com에서만 사용하도록 의도되었으며, GitLab Self-Managed 인스턴스에서는 사용할 수 없습니다.

이 플래그는 기본적으로 비활성화되어 있으며 다음 경우에만 활성화할 수 있습니다:

• GitLab.com의 경우, GitLab 지원 티켓을 통해 동의를 제공할 때.

기본적으로, AI 기능 데이터의 데이터 보존 정책을 지원하기 위해 로그에는 LLM 프롬프트 입력 및 응답 출력이 포함되지 않습니다.

로그 파일의 위치:

• Linux 패키지 설치에서 /var/log/gitlab/gitlab-rails/llm.log 파일.
• 소스 컴파일 설치에서 /home/git/gitlab/log/llm.log 파일.
• Helm 차트 설치에서 subcomponent="llm" 키 아래 Webservice 파드.

epic_work_item_sync.log#

히스토리

• GitLab 16.9에서 도입됨.

epic_work_item_sync.log 파일은 에픽을 작업 항목으로 동기화 및 마이그레이션하는 것과 관련된 정보를 기록합니다.

이 로그의 위치:

• Linux 패키지 설치에서 /var/log/gitlab/gitlab-rails/epic_work_item_sync.log 파일.
• 소스 컴파일 설치에서 /home/git/gitlab/log/epic_work_item_sync.log 파일.
• Helm 차트 설치에서 subcomponent="epic_work_item_sync" 키 아래 Sidekiq 및 Webservice 파드.

secret_push_protection.log#

히스토리

• GitLab 16.7에서 도입됨.

secret_push_protection.log 파일은 시크릿 푸시 보호 기능과 관련된 정보를 기록합니다.

이 로그의 위치:

• Linux 패키지 설치에서 /var/log/gitlab/gitlab-rails/secret_push_protection.log 파일.
• 소스 컴파일 설치에서 /home/git/gitlab/log/secret_push_protection.log 파일.
• Helm 차트 설치에서 subcomponent="secret_push_protection" 키 아래 Webservice 파드.

active_context.log#

히스토리

• GitLab 18.3에서 도입됨.

active_context.log 파일은 ActiveContext 레이어를 통한 임베딩 파이프라인과 관련된 정보를 기록합니다.

GitLab은 ActiveContext 코드 임베딩을 지원합니다. 이 파이프라인은 프로젝트 코드 파일에 대한 임베딩 생성을 처리합니다. 자세한 정보는 아키텍처 설계를 참조하세요.

이 로그의 위치:

• Linux 패키지 설치에서 /var/log/gitlab/gitlab-rails/active_context.log 파일.
• 소스 컴파일 설치에서 /home/git/gitlab/log/active_context.log 파일.
• Helm 차트 설치에서 subcomponent="activecontext" 키 아래 Sidekiq 파드.

ai_catalog.log#

히스토리

• GitLab 18.8에서 도입됨.

ai_catalog.log 파일은 AI 카탈로그와 관련된 정보를 기록하며, AI 카탈로그 플로우 및 에이전트가 실행될 때의 정보를 포함합니다.

이 로그의 위치:

• Linux 패키지 설치에서 /var/log/gitlab/gitlab-rails/ai_catalog.log 파일.
• 소스 컴파일 설치에서 /home/git/gitlab/log/ai_catalog.log 파일.
• Helm 차트 설치에서 subcomponent="ai_catalog" 키 아래 Sidekiq 파드.

user_experience_slis.log#

이 로그의 위치:

• Linux 패키지 설치에서 /var/log/gitlab/gitlab-rails/user_experience_slis.log 파일.
• 소스 컴파일 설치에서 /home/git/gitlab/log/user_experience_slis.log 파일.
• Helm 차트 설치에서 subcomponent="user_experience_slis" 키 아래 Webservice 파드.

메트릭과 일치하는 사용자 경험 SLI에 대한 JSON 구조화 로그를 포함합니다.

각 행에는 Elasticsearch와 같은 서비스에서 수집할 수 있는 JSON이 포함됩니다.

예시:

{
  "checkpoint": "start",
  "component": "gitlab",
  "correlation_id": "3823a1550b64417f9c9ed8ee0f48087e",
  "covered_experience": "create_merge_request",
  "elapsed_time_s": 0,
  "environment": "gprd",
  "feature_category": "code_review_workflow",
  "logtag": "F",
  "meta": {
    "caller_id": "Projects::MergeRequests::CreationsController#create",
    "client_id": "user/123",
    "feature_category": "code_review_workflow",
    "gl_user_id": 123,
    "organization_id": 456,
    "project": "project/path/here",
    "remote_ip": "x.x.x.x",
    "root_namespace": "project",
    "subscription_plan": "ultimate",
    "user": "a_username"
  },
  "severity": "INFO",
  "shard": "default",
  "stage": "cny",
  "start_time": "2025-10-31 15:21:40 UTC",
  "subcomponent": "user_experience_slis",
  "tag": "web-cny-rails.var.log.containers.gitlab-cny-webservice-web-123-abc_gitlab-cny_webservice-4567890.log",
  "tier": "sv",
  "time": "2025-10-31T15:21:40.333Z",
  "type": "web",
  "urgency": "async_fast",
  "urgency_threshold_s": 15
}

사용 가능한 필드는 사용자 경험 SLI 설계 문서에 문서화되어 있습니다.

Registry 로그#

Linux 패키지 설치에서 컨테이너 레지스트리 로그는 /var/log/gitlab/registry/current에 있습니다.

NGINX 로그#

Linux 패키지 설치에서 NGINX 로그는 다음 위치에 있습니다:

• /var/log/gitlab/nginx/gitlab_access.log: GitLab에 대한 요청 로그
• /var/log/gitlab/nginx/gitlab_error.log: GitLab에 대한 NGINX 오류 로그
• /var/log/gitlab/nginx/gitlab_pages_access.log: Pages 정적 사이트에 대한 요청 로그
• /var/log/gitlab/nginx/gitlab_pages_error.log: Pages 정적 사이트에 대한 NGINX 오류 로그
• /var/log/gitlab/nginx/gitlab_registry_access.log: 컨테이너 레지스트리에 대한 요청 로그
• /var/log/gitlab/nginx/gitlab_registry_error.log: 컨테이너 레지스트리에 대한 NGINX 오류 로그
• /var/log/gitlab/nginx/gitlab_mattermost_access.log: Mattermost에 대한 요청 로그
• /var/log/gitlab/nginx/gitlab_mattermost_error.log: Mattermost에 대한 NGINX 오류 로그

기본 GitLab NGINX 접근 로그 형식은 다음과 같습니다:

'$remote_addr - $remote_user [$time_local] "$request" $status $body_bytes_sent "$http_referer" "$http_user_agent"'

$request와 $http_referer는 시크릿 토큰과 같은 민감한 쿼리 문자열 매개변수에 대해 필터링됩니다.

Pages 로그#

Linux 패키지 설치에서 Pages 로그는 /var/log/gitlab/gitlab-pages/current에 있습니다.

예를 들면:

{
  "level": "info",
  "msg": "GitLab Pages Daemon",
  "revision": "52b2899",
  "time": "2020-04-22T17:53:12Z",
  "version": "1.17.0"
}
{
  "level": "info",
  "msg": "URL: https://gitlab.com/gitlab-org/gitlab-pages",
  "time": "2020-04-22T17:53:12Z"
}
{
  "gid": 998,
  "in-place": false,
  "level": "info",
  "msg": "running the daemon as unprivileged user",
  "time": "2020-04-22T17:53:12Z",
  "uid": 998
}

제품 사용 데이터 로그#

이 로그의 위치:

• Linux 패키지 설치에서 /var/log/gitlab/gitlab-rails/product_usage_data.log 파일.
• 소스 컴파일 설치에서 /home/git/gitlab/log/product_usage_data.log 파일.
• Helm 차트 설치에서 subcomponent="product_usage_data" 키 아래 Webservice 파드.

Snowplow를 통해 추적된 제품 사용 이벤트의 JSON 형식 로그를 포함합니다. 파일의 각 행에는 Elasticsearch 또는 Splunk와 같은 서비스에서 수집할 수 있는 별도의 JSON 항목이 포함됩니다. 가독성을 위해 예시에 줄바꿈이 추가되었습니다:

{
  "severity":"INFO",
  "time":"2025-04-09T13:43:40.254Z",
  "message":"sending event",
  "payload":"{
  \"e\":\"se\",
  \"se_ca\":\"projects:merge_requests:diffs\",
  \"se_ac\":\"i_code_review_user_searches_diff\",
  \"cx\":\"eyJzY2hlbWEiOiJpZ2x1OmNvbS5zbm93cGxvd2FuYWx5dGljcy5zbm93cGxvdy9jb250ZXh0cy9qc29uc2NoZW1hLzEtMC0xIiwiZGF0YSI6W3sic2NoZW1hIjoiaWdsdTpjb20uZ2l0bGFiL2dpdGxhYl9zdGFuZGFyZC9qc29uc2NoZW1hLzEtMS0xIiwiZGF0YSI6eyJlbnZpcm9ubWVudCI6ImRldmVsb3BtZW50Iiwic291cmNlIjoiZ2l0bGFiLXJhaWxzIiwiY29ycmVsYXRpb25faWQiOiJlNDk2NzNjNWI2MGQ5ODc0M2U4YWI0MjZiMTZmMTkxMiIsInBsYW4iOiJkZWZhdWx0IiwiZXh0cmEiOnt9LCJ1c2VyX2lkIjpudWxsLCJnbG9iYWxfdXNlcl9pZCI6bnVsbCwiaXNfZ2l0bGFiX3RlYW1fbWVtYmVyIjpudWxsLCJuYW1lc3BhY2VfaWQiOjMxLCJwcm9qZWN0X2lkIjo2LCJmZWF0dXJlX2VuYWJsZWRfYnlfbmFtZXNwYWNlX2lkcyI6bnVsbCwicmVhbG0iOiJzZWxmLW1hbmFnZWQiLCJpbnN0YW5jZV9pZCI6IjJkMDg1NzBkLWNmZGItNDFmMy1iODllLWM3MTM5YmFjZTI3NSIsImhvc3RfbmFtZSI6ImpsYXJzZW4tLTIwMjIxMjE0LVBWWTY5IiwiaW5zdGFuY2VfdmVyc2lvbiI6IjE3LjExLjAiLCJjb250ZXh0X2dlbmVyYXRlZF9hdCI6IjIwMjUtMDQtMDkgMTM6NDM6NDAgVVRDIn19LHsic2NoZW1hIjoiaWdsdTpjb20uZ2l0bGFiL2dpdGxhYl9zZXJ2aWNlX3BpbmcvanNvbnNjaGVtYS8xLTAtMSIsImRhdGEiOnsiZGF0YV9zb3VyY2UiOiJyZWRpc19obGwiLCJldmVudF9uYW1lIjoiaV9jb2RlX3Jldmlld191c2VyX3NlYXJjaGVzX2RpZmYifX1dfQ==\",
  \"p\":\"srv\",
  \"dtm\":\"1744206220253\",
  \"tna\":\"gl\",
  \"tv\":\"rb-0.8.0\",
  \"eid\":\"4f067989-d10d-40b0-9312-ad9d7355be7f\"
}

이러한 로그를 검사하려면 JSON 출력을 형식화하고 가독성을 위해 base64 인코딩된 컨텍스트 데이터를 디코딩하는 Rake 작업 product_usage_data:format을 사용할 수 있습니다:

gitlab-rake "product_usage_data:format[log/product_usage_data.log]"
# 또는 로그를 직접 파이프
cat log/product_usage_data.log | gitlab-rake product_usage_data:format
# 또는 실시간으로 로그 추적
tail -f log/product_usage_data.log | gitlab-rake product_usage_data:format

GITLAB_DISABLE_PRODUCT_USAGE_EVENT_LOGGING 환경 변수를 임의의 값으로 설정하여 이 로그를 비활성화할 수 있습니다.

Let's Encrypt 로그#

Linux 패키지 설치에서 Let's Encrypt 자동 갱신 로그는 /var/log/gitlab/lets-encrypt/에 있습니다.

Mattermost 로그#

Linux 패키지 설치에서 Mattermost 로그는 다음 위치에 있습니다:

• /var/log/gitlab/mattermost/mattermost.log
• /var/log/gitlab/mattermost/current

Workhorse 로그#

Linux 패키지 설치에서 Workhorse 로그는 /var/log/gitlab/gitlab-workhorse/current에 있습니다.

Patroni 로그#

Linux 패키지 설치에서 Patroni 로그는 /var/log/gitlab/patroni/current에 있습니다.

PgBouncer 로그#

Linux 패키지 설치에서 PgBouncer 로그는 /var/log/gitlab/pgbouncer/current에 있습니다.

PostgreSQL 로그#

Linux 패키지 설치에서 PostgreSQL 로그는 /var/log/gitlab/postgresql/current에 있습니다.

Patroni를 사용하는 경우, PostgreSQL 로그는 대신 Patroni 로그에 저장됩니다.

Prometheus 로그#

Linux 패키지 설치에서 Prometheus 로그는 /var/log/gitlab/prometheus/current에 있습니다.

Redis 로그#

Linux 패키지 설치에서 Redis 로그는 /var/log/gitlab/redis/current에 있습니다.

Sentinel 로그#

Linux 패키지 설치에서 Sentinel 로그는 /var/log/gitlab/sentinel/current에 있습니다.

Alertmanager 로그#

Linux 패키지 설치에서 Alertmanager 로그는 /var/log/gitlab/alertmanager/current에 있습니다.

Consul 로그#

Linux 패키지 설치에서 Consul 로그는 /var/log/gitlab/consul/current에 있습니다.

crond 로그#

Linux 패키지 설치에서 crond 로그는 /var/log/gitlab/crond/에 있습니다.

Grafana 로그#

Linux 패키지 설치에서 Grafana 로그는 /var/log/gitlab/grafana/current에 있습니다.

LogRotate 로그#

Linux 패키지 설치에서 logrotate 로그는 /var/log/gitlab/logrotate/current에 있습니다.

GitLab Monitor 로그#

Linux 패키지 설치에서 GitLab Monitor 로그는 /var/log/gitlab/gitlab-monitor/에 있습니다.

GitLab Exporter 로그#

Linux 패키지 설치에서 GitLab Exporter 로그는 /var/log/gitlab/gitlab-exporter/current에 있습니다.

Kubernetes용 GitLab 에이전트 서버 로그#

Linux 패키지 설치에서 Kubernetes용 GitLab 에이전트 서버 로그는 /var/log/gitlab/gitlab-kas/current에 있습니다.

Praefect 로그#

Linux 패키지 설치에서 Praefect 로그는 /var/log/gitlab/praefect/에 있습니다.

GitLab은 Gitaly Cluster (Praefect)에 대한 Prometheus 메트릭도 추적합니다.

백업 로그#

Linux 패키지 설치에서 백업 로그는 /var/log/gitlab/gitlab-rails/backup_json.log에 있습니다.

Helm 차트 설치에서 백업 로그는 Toolbox 파드의 /var/log/gitlab/backup_json.log에 저장됩니다.

이 로그는 GitLab 백업이 생성될 때 채워집니다. 이 로그를 사용하여 백업 프로세스가 어떻게 수행되었는지 이해할 수 있습니다.

성능 바 통계#

이 로그의 위치:

• Linux 패키지 설치에서 /var/log/gitlab/gitlab-rails/performance_bar_json.log 파일.
• 소스 컴파일 설치에서 /home/git/gitlab/log/performance_bar_json.log 파일.
• Helm 차트 설치에서 subcomponent="performance_bar_json" 키 아래 Sidekiq 파드.

성능 바 통계 (현재 SQL 쿼리 지속 시간만)가 해당 파일에 기록됩니다. 예를 들면:

{"severity":"INFO","time":"2020-12-04T09:29:44.592Z","correlation_id":"33680b1490ccd35981b03639c406a697","filename":"app/models/ci/pipeline.rb","method_path":"app/models/ci/pipeline.rb:each_with_object","request_id":"rYHomD0VJS4","duration_ms":26.889,"count":2,"query_type": "active-record"}

이 통계는 .com에서만 기록되며, 자체 배포에서는 비활성화됩니다.

로그 수집#

특정 구성 요소에 국한되지 않은 문제 해결 시 GitLab 인스턴스에서 여러 로그와 통계를 동시에 수집하는 것이 도움이 됩니다.

주요 로그를 간략하게 추적#

버그 또는 오류가 쉽게 재현 가능한 경우, 문제를 몇 번 재현하면서 주요 GitLab 로그를 파일로 저장하세요:

sudo gitlab-ctl tail | tee /tmp/<case-ID-and-keywords>.log

Control + C로 로그 수집을 종료합니다.

SOS 로그 수집#

나열된 GitLab 구성 요소 중 하나에 쉽게 귀인할 수 없는 성능 저하 또는 연쇄 오류가 발생하는 경우 SOS 스크립트를 사용하세요.

Fast-stats#

Fast-stats는 GitLab 로그에서 성능 통계를 생성하고 비교하는 도구입니다. 자세한 내용 및 실행 지침은 fast-stats 문서를 참조하세요.

상관관계 ID로 관련 로그 항목 찾기#

대부분의 요청에는 관련 로그 항목을 찾는 데 사용할 수 있는 로그 ID가 있습니다.