로그 시스템

요약

GitLab의 로그 시스템은 GitLab 인스턴스를 분석할 수 있는 포괄적인 로깅 및 모니터링 기능을 제공합니다. 로그 시스템은 다음과 같이 동작합니다. 시스템 로그 파일은 일반적으로 표준 로그 파일 형식의 일반 텍스트입니다.

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

로그 시스템은 다음과 같이 동작합니다.

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

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

로그 시스템은 감사 이벤트와 유사합니다. 자세한 내용은 다음도 참고합니다.

로그 수준#

각 로그 메시지에는 중요도와 상세도를 나타내는 로그 수준이 지정됩니다. 각 로거에는 최소 로그 수준이 지정됩니다. 로거는 로그 메시지의 수준이 최소 로그 수준 이상일 때만 해당 메시지를 출력합니다.

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

수준	이름
0	`DEBUG`
1	`INFO`
2	`WARN`
3	`ERROR`
4	`FATAL`
5	`UNKNOWN`

GitLab 로거는 기본적으로 DEBUG로 설정되어 있으므로 모든 로그 메시지를 출력합니다.

기본 로그 수준 재정의#

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

예시:

GITLAB_LOG_LEVEL=info

일부 서비스에는 이 설정의 영향을 받지 않는 다른 로그 수준이 적용되어 있습니다. 이 서비스 중 일부는 로그 수준을 재정의하는 자체 환경 변수를 제공합니다. 예를 들면 다음과 같습니다.

서비스	로그 수준	환경 변수
GitLab Cleanup	`INFO`	`DEBUG`
GitLab Doctor	`INFO`	`VERBOSE`
GitLab Export	`INFO`	`EXPORT_DEBUG`
GitLab Import	`INFO`	`IMPORT_DEBUG`
GitLab QA Runtime	`INFO`	`QA_LOG_LEVEL`
GitLab Product Usage Data	`INFO`
Google APIs	`INFO`
Rack Timeout	`ERROR`
Snowplow Tracker	`FATAL`
gRPC Client (Gitaly)	`WARN`	`GRPC_LOG_LEVEL`
LLM	`INFO`	`LLM_DEBUG`

로그 순환#

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

logrotate
svlogd (runit's service logging daemon)
logrotate와 svlogd 모두
또는 전혀 관리하지 않음

다음 표는 포함된 서비스의 로그를 관리하고 순환하는 데몬이 무엇인지 보여 줍니다.

svlogd가 관리하는 로그는 current라는 파일에 기록됩니다. 보관된 버전은 @<hexadecimal-ID>.s 파일로 압축됩니다.
GitLab에 내장된 logrotate 서비스가 그 밖의 모든 로그를 관리합니다. 보관된 버전은 <original-name>.<number>.gz 파일로 압축됩니다.

로그 유형	logrotate 관리	svlogd/runit 관리
Alertmanager 로그	❌	✅
Consul 로그	❌	✅
crond 로그	❌	✅
Gitaly	✅	✅
Linux 패키지 설치용 GitLab Exporter	❌	✅
GitLab Pages 로그	✅	✅
GitLab Rails	✅	❌
GitLab Shell 로그	✅	❌
Grafana 로그	❌	✅
LogRotate 로그	❌	✅
Mailroom	✅	✅
NGINX	✅	✅
Patroni 로그	❌	✅
PgBouncer 로그	❌	✅
PostgreSQL 로그	❌	✅
Praefect 로그	✅	✅
Prometheus 로그	❌	✅
Puma	✅	✅
Redis 로그	❌	✅
Registry 로그	❌	✅
Sentinel 로그	❌	✅
Sidekiq 로그	❌	✅
Workhorse 로그	✅	✅

이 로그를 생성하는 서비스에 대한 자세한 내용은 GitLab 아키텍처 개요를 참고합니다.

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

Helm 차트 설치에서 GitLab 구성 요소는 로그를 stdout으로 보내며, kubectl logs로 접근할 수 있습니다. 로그는 Pod가 존재하는 동안 Pod 내부의 /var/log/gitlab에서도 확인할 수 있습니다.

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

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

# Webservice pod logs (Rails application)
kubectl logs -l app=webservice -c webservice | jq 'select(."subcomponent"=="<subcomponent-key>")'

# Sidekiq pod logs (background jobs)
kubectl logs -l app=sidekiq | jq 'select(."subcomponent"=="<subcomponent-key>")'

이후 로그 절에서는 해당하는 경우 적절한 Pod와 서브컴포넌트 키를 함께 안내합니다.

기타 Pod#

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

사용 가능한 Pod 셀렉터를 찾는 방법은 다음과 같습니다.

# List all unique app labels in use
kubectl get pods -o jsonpath='{range .items[*]}{.metadata.labels.app}{"\n"}{end}' | grep -v '^$' | sort | uniq

# For pods with app labels
kubectl logs -l app=<pod-selector>

# For specific pods (when app labels aren't available)
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 차트 설치에서는 Webservice Pod의 subcomponent="production_json" 키 아래에 있습니다.

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 전송을 사용하는 사용자의 클론 및 페치 활동은 로그에 action: git_upload_pack으로 나타납니다.

이와 함께 로그에는 요청을 보낸 IP 주소(remote_ip), 사용자 ID(user_id), 사용자 이름(username)이 포함됩니다.

일부 엔드포인트(예: /search)는 고급 검색을 사용하는 경우 Elasticsearch에 요청을 보낼 수 있습니다. 이러한 엔드포인트는 elasticsearch_calls와 elasticsearch_duration_s도 추가로 기록하며, 각각 다음을 의미합니다.

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

검색 요청은 단일 검색 요청을 식별하는 UUID인 meta.search.request_id도 기록합니다. 같은 값이 perform_search 및 click_search_result 이벤트의 property로 전송되므로, 결과 클릭을 그 결과를 반환한 검색에 대응시킬 수 있습니다. meta.search.request_id를 기록하지 않은 요청은 perform_search 이벤트를 발생시키지 않았습니다.

Feature flag

meta.search.request_id의 가용성은 search_relevancy_join_key 기능 플래그로 제어됩니다. 이 플래그는 기본적으로 비활성화되어 있습니다.

GitLab Secrets Manager로 시크릿을 읽거나 쓰는 요청은 openbao_calls와 openbao_duration_s도 추가로 기록하며, 각각 다음을 의미합니다.

openbao_calls: OpenBao에 대한 총 호출 횟수
openbao_duration_s: OpenBao 호출에 소요된 총 시간

GitLab 19.5 이상에서는 LabKit 속도 제한기가 평가하는 요청도 rate_limit_state를 기록합니다. 이 필드는 production_json.log와 api_json.log를 포함해 요청별 구조화 로그에 추가됩니다. 이 필드는 <limiter>:<rule>:<result> 형식의 문자열 배열입니다. 배열에는 요청을 집계했거나 검사를 종료한 속도 제한 규칙마다 항목이 하나씩 있습니다. 예를 들면 다음과 같습니다.

"rate_limit_state": ["rack_request:unauthenticated_api:log"]

<result>는 다음 중 하나입니다.

allow: 요청이 규칙의 한도를 초과하지 않았습니다.
log: 요청이 로그만 남기는 규칙의 한도를 초과했습니다. 예를 들어 드라이 런 모드의 스로틀이 이에 해당합니다. GitLab은 요청을 차단하지 않습니다.
block: 요청이 요청을 차단할 수 있는 규칙의 한도를 초과했습니다. 이 결과가 GitLab이 요청을 거부했다는 의미는 아닐 수 있습니다.
banned: 요청이 클라이언트를 차단하는 규칙의 한도를 초과했습니다.
skip: 규칙이 요청을 집계하지 않고 속도 제한 검사를 종료했습니다 (예: 요청이 속도 제한기를 우회한 경우).

LabKit 규칙 결과가 없는 요청은 rate_limit_state를 기록하지 않습니다. 필드가 없다는 것은 어떤 규칙도 해당 요청에 대한 결과를 내지 않았다는 뜻이며, 텔레메트리가 실패했다는 뜻이 아닙니다.

기존 Rack::Attack 속도 제한기는 rate_limit_state를 기록하지 않습니다. 해당 이벤트는 auth.log를 참고합니다.

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
}

Note

오류가 발생하면 class, message, backtrace가 포함된 exception 필드가 함께 기록됩니다. 이전 버전에서는 exception.class와 exception.message 대신 error 필드가 포함되었습니다. 예를 들면 다음과 같습니다.

{
  "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)

이 예시에서 서버는 2015-02-12 19:34:53 +0200에 IP 168.111.56.1에서 온 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 차트 설치에서는 Webservice Pod의 subcomponent="api_json" 키 아래에 있습니다.

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

Note

Grape Logging v1.8.4부터 view_duration_s는 duration_s - db_duration_s로 계산됩니다. 따라서 view_duration_s는 직렬화 과정뿐 아니라 Redis의 읽기-쓰기 프로세스나 외부 HTTP 호출 같은 여러 요인의 영향을 받을 수 있습니다.

`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 차트 설치에서는 Sidekiq 및 Webservice Pod의 subcomponent="application_json" 키 아래에 있습니다.

사용자 생성, 프로젝트 삭제처럼 인스턴스에서 발생하는 이벤트를 파악하는 데 도움이 됩니다. 예를 들면 다음과 같습니다.

{
  "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 차트 설치에서는 Sidekiq 및 Webservice Pod의 subcomponent="integrations_json" 키 아래에 있습니다.

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 차트 설치에서는 Sidekiq Pod의 subcomponent="kubernetes" 키 아래에 있습니다.

연결 오류 같은 인증서 기반 클러스터 관련 정보를 기록합니다. 각 줄에는 Elasticsearch, Splunk 같은 서비스에서 수집할 수 있는 JSON이 들어 있습니다.

`git_json.log`#

이 로그는 다음 위치에 있습니다.

Linux 패키지 설치에서는 /var/log/gitlab/gitlab-rails/git_json.log 파일에 있습니다.
자체 컴파일 설치에서는 /home/git/gitlab/log/git_json.log 파일에 있습니다.
Helm 차트 설치에서는 Sidekiq Pod의 subcomponent="git_json" 키 아래에 있습니다.

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`#

Note

GitLab Free는 소수의 감사 이벤트만 추적합니다. GitLab Premium은 훨씬 더 많은 감사 이벤트를 추적합니다.

이 로그는 다음 위치에 있습니다.

Linux 패키지 설치에서는 /var/log/gitlab/gitlab-rails/audit_json.log 파일에 있습니다.
자체 컴파일 설치에서는 /home/git/gitlab/log/audit_json.log 파일에 있습니다.
Helm 차트 설치에서는 Sidekiq 및 Webservice Pod의 subcomponent="audit_json" 키 아래에 있습니다.

그룹 또는 프로젝트 설정과 멤버십(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`#

이 로그는 다음 위치에 있습니다.

Linux 패키지 설치에서는 /var/log/gitlab/sidekiq/current 파일에 있습니다.
자체 컴파일 설치에서는 /home/git/gitlab/log/sidekiq.log 파일에 있습니다.

GitLab Helm 차트 설치의 기본 로그 형식은 json입니다.

GitLab은 오래 걸릴 수 있는 작업을 처리하기 위해 백그라운드 job을 사용합니다. 이러한 job 처리에 관한 모든 정보가 이 파일에 기록됩니다. 예를 들면 다음과 같습니다.

{
  "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 차트 설치에서는 Webservice Pod의 subcomponent="sidekiq_client" 키 아래에 있습니다.

이 파일에는 Sidekiq가 job 처리를 시작하기 전, 예를 들어 대기열에 추가되기 전 job에 대한 로그 정보가 들어 있습니다.

이 로그 파일은 sidekiq.log와 구조가 같으므로, 앞서 설명한 대로 Sidekiq에 JSON을 설정했다면 JSON으로 구조화됩니다.

`gitlab-shell.log`#

GitLab은 Git 명령을 실행하고 Git 리포지터리에 대한 SSH 접근을 제공하기 위해 GitLab Shell을 사용합니다.

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 차트 설치에서는 Sidekiq Pod의 subcomponent="repocheck" 키 아래에 있습니다.

프로젝트에서 리포지터리 검사가 실행될 때마다 정보를 기록합니다.

`importer.log`#

이 로그는 다음 위치에 있습니다.

Linux 패키지 설치에서는 /var/log/gitlab/gitlab-rails/importer.log 파일에 있습니다.
자체 컴파일 설치에서는 /home/git/gitlab/log/importer.log 파일에 있습니다.
Helm 차트 설치에서는 Sidekiq Pod의 subcomponent="importer" 키 아래에 있습니다.

이 파일에는 프로젝트 가져오기 및 마이그레이션의 진행 상황이 기록됩니다.

`exporter.log`#

이 로그는 다음 위치에 있습니다.

Linux 패키지 설치에서는 /var/log/gitlab/gitlab-rails/exporter.log 파일에 있습니다.
자체 컴파일 설치에서는 /home/git/gitlab/log/exporter.log 파일에 있습니다.
Helm 차트 설치에서는 Sidekiq 및 Webservice Pod의 subcomponent="exporter" 키 아래에 있습니다.

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

`features_json.log`#

이 로그는 다음 위치에 있습니다.

Linux 패키지 설치에서는 /var/log/gitlab/gitlab-rails/features_json.log 파일에 있습니다.
자체 컴파일 설치에서는 /home/git/gitlab/log/features_json.log 파일에 있습니다.
Helm 차트 설치에서는 Sidekiq 및 Webservice Pod의 subcomponent="features_json" 키 아래에 있습니다.

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`#

이 로그는 다음 위치에 있습니다.

Linux 패키지 설치에서는 /var/log/gitlab/gitlab-rails/ci_resource_groups_json.log 파일에 있습니다.
자체 컴파일 설치에서는 /home/git/gitlab/log/ci_resource_group_json.log 파일에 있습니다.
Helm 차트 설치에서는 Sidekiq 및 Webservice Pod의 subcomponent="ci_resource_groups_json" 키 아래에 있습니다.

리소스 그룹 획득에 관한 정보가 포함되어 있습니다. 예를 들면 다음과 같습니다.

{"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 파일에 있습니다.

이 로그에는 다음이 기록됩니다.

raw 엔드포인트에서 속도 제한을 초과한 요청
보호된 경로에 대한 남용 요청
사용자 ID와 사용자 이름 (확인 가능한 경우)

`auth_json.log`#

이 로그는 다음 위치에 있습니다.

Linux 패키지 설치에서는 /var/log/gitlab/gitlab-rails/auth_json.log 파일에 있습니다.
자체 컴파일 설치에서는 /home/git/gitlab/log/auth_json.log 파일에 있습니다.
Helm 차트 설치에서는 Sidekiq 및 Webservice Pod의 subcomponent="auth_json" 키 아래에 있습니다.

이 파일에는 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 차트 설치에서는 Sidekiq 및 Webservice Pod의 subcomponent="graphql_json" 키 아래에 있습니다.

이 파일에는 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`#

이 로그는 다음 위치에 있습니다.

Linux 패키지 설치에서는 /var/log/gitlab/gitlab-rails/clickhouse.log 파일에 있습니다.
자체 컴파일 설치에서는 /home/git/gitlab/log/clickhouse.log 파일에 있습니다.
Sidekiq 및 Webservice Pod의 subcomponent="clickhouse" 키 아래에 있습니다.

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`#

이 로그는 다음 위치에 있습니다.

Linux 패키지 설치에서는 /var/log/gitlab/gitlab-rails/web_hooks.log 파일에 있습니다.
자체 컴파일 설치에서는 /home/git/gitlab/log/web_hooks.log 파일에 있습니다.
Helm 차트 설치에서는 Sidekiq Pod의 subcomponent="web_hooks" 키 아래에 있습니다.

웹훅의 백오프, 비활성화, 재활성화 이벤트가 이 파일에 기록됩니다. 예를 들면 다음과 같습니다.

{"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 차트 설치에서는 Sidekiq 및 Webservice Pod의 subcomponent="database_load_balancing" 키 아래에 있습니다.

`zoekt.log`#

이 파일에는 정확한 코드 검색과 관련된 정보가 기록됩니다.

이 로그는 다음 위치에 있습니다.

Linux 패키지 설치에서는 /var/log/gitlab/gitlab-rails/zoekt.log 파일에 있습니다.
자체 컴파일 설치에서는 /home/git/gitlab/log/zoekt.log 파일에 있습니다.
Helm 차트 설치에서는 Sidekiq 및 Webservice Pod의 subcomponent="zoekt" 키 아래에 있습니다.

`zoekt.log` 필드#

주기적인 메트릭 cron job의 항목은 metric 필드(node_metrics, indices_metrics 또는 enabled_namespaces_metrics)로 구분됩니다. 요청별 로그 항목에는 metric 필드가 없으며, 대신 아래에 설명된 Zoekt 필드가 해당 항목이 기록된 Rails 요청 또는 Sidekiq job 로그 줄에 덧붙여집니다.

노드 메트릭 항목 (`metric: node_metrics`)#

이 항목은 주기적인 메트릭 cron job이 온라인 Zoekt 노드마다 한 번씩 출력합니다.

필드	유형	설명
`enabled_namespaces_count`	Integer	이 노드에서 정확한 코드 검색이 활성화된 네임스페이스 수
`indices_count`	Integer	이 노드의 리포지터리 인덱스 수
`task_count_pending`	Integer	`pending` 상태인 인덱싱 작업 수
`task_count_failed`	Integer	`failed` 상태인 인덱싱 작업 수
`task_count_processing_queue`	Integer	처리 준비가 된 인덱싱 작업 수 (상태가 `pending`이거나, `perform_at <= now`인 `processing`)
`task_count_orphaned`	Integer	`orphaned` 상태인 인덱싱 작업 수
`task_count_done`	Integer	`done` 상태인 인덱싱 작업 수
`meta`	Object	노드 ID와 URL을 포함한 노드 메타데이터

인덱스 메트릭 항목 (`metric: indices_metrics`)#

이 항목은 메트릭 수집 주기마다 한 번씩 출력됩니다.

meta.zoekt.with_stale_used_storage_bytes_updated_at 키는 점이 포함된 평면 키 이름 그대로이며, 중첩된 객체 경로가 아닙니다.

필드	유형	설명
`meta.zoekt.with_stale_used_storage_bytes_updated_at`	Integer	`used_storage_bytes` 값이 최근에 갱신되지 않은 Zoekt 인덱스 수

활성화된 네임스페이스 메트릭 항목 (`metric: enabled_namespaces_metrics`)#

이 항목은 메트릭 수집 주기마다 한 번씩 출력됩니다.

meta.zoekt.enabled_namespaces_without_replicas 키는 점이 포함된 평면 키 이름 그대로이며, 중첩된 객체 경로가 아닙니다.

필드	유형	설명
`meta.zoekt.enabled_namespaces_without_replicas`	Integer	정확한 코드 검색이 활성화되어 있지만 Zoekt 복제본이 없어 롤아웃을 기다리는 네임스페이스 수

요청별 필드#

이 필드는 GitLab Rails에서 Zoekt 노드로 보내는 각 HTTP 요청마다 출력되는 로그 항목에 나타납니다.

필드	유형	설명
`zoekt_calls`	Integer	이 Rails 요청 중 발생한 Zoekt HTTP 요청 수
`zoekt_duration_s`	Float	이 Rails 요청 중 Zoekt 응답을 기다리는 데 소요된 총 시간(초)

`elasticsearch.log`#

이 파일에는 Elasticsearch 통합과 관련된 정보가 기록되며, Elasticsearch 인덱싱 또는 검색 중 발생한 오류도 포함됩니다.

이 로그는 다음 위치에 있습니다.

Linux 패키지 설치에서는 /var/log/gitlab/gitlab-rails/elasticsearch.log 파일에 있습니다.
자체 컴파일 설치에서는 /home/git/gitlab/log/elasticsearch.log 파일에 있습니다.
Helm 차트 설치에서는 Sidekiq 및 Webservice Pod의 subcomponent="elasticsearch" 키 아래에 있습니다.

각 줄에는 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이 추적하는 예외에 관한 정보가 기록됩니다. Gitlab::ErrorTracking은 처리된 예외를 표준적이고 일관된 방식으로 처리하는 방법을 제공합니다.

이 로그는 다음 위치에 있습니다.

Linux 패키지 설치에서는 /var/log/gitlab/gitlab-rails/exceptions_json.log 파일에 있습니다.
자체 컴파일 설치에서는 /home/git/gitlab/log/exceptions_json.log 파일에 있습니다.
Helm 차트 설치에서는 Sidekiq 및 Webservice Pod의 subcomponent="exceptions_json" 키 아래에 있습니다.

각 줄에는 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 차트 설치에서는 Sidekiq 및 Webservice Pod의 subcomponent="service_measurement" 키 아래에 있습니다.

서비스 실행마다 측정값이 담긴 구조화된 로그 하나만 포함합니다. 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 차트 설치에서는 Sidekiq 및 Webservice Pod의 subcomponent="geo" 키 아래에 있습니다.

이 파일에는 Geo가 리포지터리와 파일을 동기화하려고 시도한 시점에 관한 정보가 들어 있습니다. 파일의 각 줄에는 별도의 JSON 항목이 있으며, 이를 Elasticsearch나 Splunk 등에 수집할 수 있습니다.

예를 들면 다음과 같습니다.

{"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 차트 설치에서는 Sidekiq Pod의 subcomponent="update_mirror_service_json" 키 아래에 있습니다.

이 파일에는 프로젝트 미러링 중 발생한 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`#

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

LLM 입력 및 출력 로깅#

히스토리

GitLab 17.2에서 expanded_ai_logging이라는 기능 플래그와 함께 도입되었습니다. 기본적으로 비활성화되어 있습니다.

Feature flag

이 기능의 사용 가능 여부는 기능 플래그로 제어됩니다. 자세한 내용은 히스토리를 참고합니다. 이 기능은 테스트용으로 제공되며 프로덕션 환경에서 사용할 준비가 되지 않았습니다.

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 차트 설치에서는 Webservice Pod의 subcomponent="llm" 키 아래에 있습니다.

`mcp.log`#

히스토리

MCP를 통한 GitLab Duo 세션 생성 로깅이 GitLab 19.5에서 도입되었습니다.

mcp.log 파일에는 GitLab MCP 서버와 관련된 정보가 기록됩니다. 로깅에는 요청이 거부된 이유를 설명하는 denial_reason 필드가 포함된 MCP 서버 사용 거부 기록이 포함됩니다.

도구 호출은 호출이 어떻게 끝났는지 기록하는 tool_status 필드와 함께 기록됩니다:

`tool_status`	필드 설명
`ok`	도구가 성공적으로 실행되었습니다.
`bad_request`	에이전트가 누락되거나, 형식이 잘못되었거나, 유효하지 않은 인수를 보냈습니다.
`unauthorized`	사용자에게 리소스에 대한 액세스 권한이 없습니다. 에이전트에 반환되는 메시지는 리소스를 찾을 수 없다고 표시할 수 있습니다.
`not_found`	리소스가 존재하지 않거나, 사용자가 볼 수 없는 리소스와 구별할 수 없었습니다.
`error`	백엔드 또는 다운스트림 실패이거나 도구가 분류할 수 없는 실패입니다.

도구가 예상하지 못한 예외를 발생시키면 오류 추적 서비스에 보고됩니다. error_type은 알 수 없는 도구 이름에 대해서만 not_found와 함께 기록됩니다.

도구 호출은 도구 호출이 대상으로 하는 프로젝트 또는 그룹의 최상위 네임스페이스 ID를 담은 gl_root_namespace_id 필드도 기록합니다. 도구가 프로젝트나 그룹을 대상으로 하지 않으면 이 필드는 비어 있습니다. 도구 호출이 지정한 프로젝트나 그룹을 GitLab이 찾을 수 없는 경우(예: 존재하지 않거나 조회에 실패한 경우)에도 이 필드는 비어 있습니다.

initialize 및 tool_call 줄에는 MCP 클라이언트가 자신을 식별하는 경우 mcp_client_name과 mcp_client_version 필드가 포함됩니다. 값은 요청 _meta의 clientInfo에서 가져오거나, Cursor/1.0.0처럼 User-Agent 헤더의 첫 번째 제품 토큰에서 가져옵니다. initialize 줄에는 요청의 clientInfo에서 가져온 declared_client_name과 declared_client_version 필드도 있습니다. 이 값은 클라이언트가 보고한 것이며 검증되지 않습니다. 각 값은 64자로 잘립니다.

MCP 서버를 통해 GitLab Duo 세션이 생성되면 event_name이 duo_session_created로 설정된 줄이 기록됩니다. 이 줄은 source_type이 mcp로 설정됩니다. duo_workflow_id 필드에는 세션 ID가 들어 있습니다. 이 줄에는 세션이 실행하는 플로 또는 에이전트도 item_type, flow_name, component_name, custom_item_id, item_version, item_schema_version 필드로 표시됩니다. 해당하지 않는 필드는 생략됩니다.

로그 파일은 다음 위치에 있습니다.

Linux 패키지 설치에서는 /var/log/gitlab/gitlab-rails/mcp.log 파일에 있습니다.
자체 컴파일 설치에서는 /home/git/gitlab/log/mcp.log 파일에 있습니다.
Helm 차트 설치에서는 Webservice Pod의 subcomponent="mcp" 키 아래에 있습니다.

`epic_work_item_sync.log`#

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 차트 설치에서는 Sidekiq 및 Webservice Pod의 subcomponent="epic_work_item_sync" 키 아래에 있습니다.

`secret_push_protection.log`#

secret_push_protection.log 파일에는 시크릿 푸시 보호 기능과 관련된 정보가 기록됩니다.

이 로그는 다음 위치에 있습니다.

Linux 패키지 설치에서는 /var/log/gitlab/gitlab-rails/secret_push_protection.log 파일에 있습니다.
자체 컴파일 설치에서는 /home/git/gitlab/log/secret_push_protection.log 파일에 있습니다.
Helm 차트 설치에서는 Webservice Pod의 subcomponent="secret_push_protection" 키 아래에 있습니다.

`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 차트 설치에서는 Sidekiq Pod의 subcomponent="activecontext" 키 아래에 있습니다.

`ai_catalog.log`#

히스토리

GitLab 18.8에서 도입되었습니다.

ai_catalog.log 파일에는 AI Catalog와 관련된 정보가 기록되며, AI Catalog 플로와 에이전트가 실행된 시점도 포함됩니다.

이 로그는 다음 위치에 있습니다.

Linux 패키지 설치에서는 /var/log/gitlab/gitlab-rails/ai_catalog.log 파일에 있습니다.
자체 컴파일 설치에서는 /home/git/gitlab/log/ai_catalog.log 파일에 있습니다.
Helm 차트 설치에서는 Sidekiq Pod의 subcomponent="ai_catalog" 키 아래에 있습니다.

`user_experience_slis.log`#

이 로그는 다음 위치에 있습니다.

Linux 패키지 설치에서는 /var/log/gitlab/gitlab-rails/user_experience_slis.log 파일에 있습니다.
자체 컴파일 설치에서는 /home/git/gitlab/log/user_experience_slis.log 파일에 있습니다.
Helm 차트 설치에서는 Webservice Pod의 subcomponent="user_experience_slis" 키 아래에 있습니다.

메트릭과 대응하는 사용자 경험 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
}

제품 사용 데이터 로그#

Note

데이터 품질의 정확성이 아직 인증되지 않았으므로, 기능 사용량 분석에 원시 로그를 사용하지 않기를 권장합니다.

이벤트 목록은 새 기능이나 기존 기능의 변경에 따라 버전마다 달라질 수 있습니다. 인증된 제품 내 도입 현황 보고서는 데이터가 분석할 준비가 된 후에 제공될 예정입니다.

이 로그는 다음 위치에 있습니다.

Linux 패키지 설치에서는 /var/log/gitlab/gitlab-rails/product_usage_data.log 파일에 있습니다.
자체 컴파일 설치에서는 /home/git/gitlab/log/product_usage_data.log 파일에 있습니다.
Helm 차트 설치에서는 Webservice Pod의 subcomponent="product_usage_data" 키 아래에 있습니다.

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\"
}

이 로그를 확인하려면 Rake 태스크 product_usage_data:format을 사용할 수 있습니다. 이 태스크는 JSON 출력을 정리하고 base64로 인코딩된 컨텍스트 데이터를 디코딩하여 가독성을 높입니다.

gitlab-rake "product_usage_data:format[log/product_usage_data.log]"
# or pipe the logs directly
cat log/product_usage_data.log | gitlab-rake product_usage_data:format
# or tail the logs in real-time
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 Pod의 /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 차트 설치에서는 Sidekiq Pod의 subcomponent="performance_bar_json" 키 아래에 있습니다.

성능 바 통계(현재는 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 인스턴스에서 여러 로그와 통계를 동시에 수집하면 도움이 됩니다.

Note

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가 있습니다.

로그 시스템

GitLab v19.5

Tier: Premium, Ultimate
Offering: GitLab.com, GitLab Self-Managed, GitLab Dedicated

원문 보기

번역일: 2026-10-15

요약

로그 시스템은 다음과 같이 동작합니다.

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

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

로그 시스템은 감사 이벤트와 유사합니다. 자세한 내용은 다음도 참고합니다.

로그 수준#

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

수준	이름
0	`DEBUG`
1	`INFO`
2	`WARN`
3	`ERROR`
4	`FATAL`
5	`UNKNOWN`

GitLab 로거는 기본적으로 DEBUG로 설정되어 있으므로 모든 로그 메시지를 출력합니다.

기본 로그 수준 재정의#

예시:

GITLAB_LOG_LEVEL=info

서비스	로그 수준	환경 변수
GitLab Cleanup	`INFO`	`DEBUG`
GitLab Doctor	`INFO`	`VERBOSE`
GitLab Export	`INFO`	`EXPORT_DEBUG`
GitLab Import	`INFO`	`IMPORT_DEBUG`
GitLab QA Runtime	`INFO`	`QA_LOG_LEVEL`
GitLab Product Usage Data	`INFO`
Google APIs	`INFO`
Rack Timeout	`ERROR`
Snowplow Tracker	`FATAL`
gRPC Client (Gitaly)	`WARN`	`GRPC_LOG_LEVEL`
LLM	`INFO`	`LLM_DEBUG`

로그 순환#

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

logrotate
svlogd (runit's service logging daemon)
logrotate와 svlogd 모두
또는 전혀 관리하지 않음

다음 표는 포함된 서비스의 로그를 관리하고 순환하는 데몬이 무엇인지 보여 줍니다.

svlogd가 관리하는 로그는 current라는 파일에 기록됩니다. 보관된 버전은 @<hexadecimal-ID>.s 파일로 압축됩니다.
GitLab에 내장된 logrotate 서비스가 그 밖의 모든 로그를 관리합니다. 보관된 버전은 <original-name>.<number>.gz 파일로 압축됩니다.

로그 유형	logrotate 관리	svlogd/runit 관리
Alertmanager 로그	❌	✅
Consul 로그	❌	✅
crond 로그	❌	✅
Gitaly	✅	✅
Linux 패키지 설치용 GitLab Exporter	❌	✅
GitLab Pages 로그	✅	✅
GitLab Rails	✅	❌
GitLab Shell 로그	✅	❌
Grafana 로그	❌	✅
LogRotate 로그	❌	✅
Mailroom	✅	✅
NGINX	✅	✅
Patroni 로그	❌	✅
PgBouncer 로그	❌	✅
PostgreSQL 로그	❌	✅
Praefect 로그	✅	✅
Prometheus 로그	❌	✅
Puma	✅	✅
Redis 로그	❌	✅
Registry 로그	❌	✅
Sentinel 로그	❌	✅
Sidekiq 로그	❌	✅
Workhorse 로그	✅	✅

이 로그를 생성하는 서비스에 대한 자세한 내용은 GitLab 아키텍처 개요를 참고합니다.

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

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

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

# Webservice pod logs (Rails application)
kubectl logs -l app=webservice -c webservice | jq 'select(."subcomponent"=="<subcomponent-key>")'

# Sidekiq pod logs (background jobs)
kubectl logs -l app=sidekiq | jq 'select(."subcomponent"=="<subcomponent-key>")'

이후 로그 절에서는 해당하는 경우 적절한 Pod와 서브컴포넌트 키를 함께 안내합니다.

기타 Pod#

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

사용 가능한 Pod 셀렉터를 찾는 방법은 다음과 같습니다.

# List all unique app labels in use
kubectl get pods -o jsonpath='{range .items[*]}{.metadata.labels.app}{"\n"}{end}' | grep -v '^$' | sort | uniq

# For pods with app labels
kubectl logs -l app=<pod-selector>

# For specific pods (when app labels aren't available)
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 차트 설치에서는 Webservice Pod의 subcomponent="production_json" 키 아래에 있습니다.

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 전송을 사용하는 사용자의 클론 및 페치 활동은 로그에 action: git_upload_pack으로 나타납니다.

이와 함께 로그에는 요청을 보낸 IP 주소(remote_ip), 사용자 ID(user_id), 사용자 이름(username)이 포함됩니다.

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

Feature flag

meta.search.request_id의 가용성은 search_relevancy_join_key 기능 플래그로 제어됩니다. 이 플래그는 기본적으로 비활성화되어 있습니다.

GitLab Secrets Manager로 시크릿을 읽거나 쓰는 요청은 openbao_calls와 openbao_duration_s도 추가로 기록하며, 각각 다음을 의미합니다.

openbao_calls: OpenBao에 대한 총 호출 횟수
openbao_duration_s: OpenBao 호출에 소요된 총 시간

"rate_limit_state": ["rack_request:unauthenticated_api:log"]

<result>는 다음 중 하나입니다.

allow: 요청이 규칙의 한도를 초과하지 않았습니다.
log: 요청이 로그만 남기는 규칙의 한도를 초과했습니다. 예를 들어 드라이 런 모드의 스로틀이 이에 해당합니다. GitLab은 요청을 차단하지 않습니다.
block: 요청이 요청을 차단할 수 있는 규칙의 한도를 초과했습니다. 이 결과가 GitLab이 요청을 거부했다는 의미는 아닐 수 있습니다.
banned: 요청이 클라이언트를 차단하는 규칙의 한도를 초과했습니다.
skip: 규칙이 요청을 집계하지 않고 속도 제한 검사를 종료했습니다 (예: 요청이 속도 제한기를 우회한 경우).

기존 Rack::Attack 속도 제한기는 rate_limit_state를 기록하지 않습니다. 해당 이벤트는 auth.log를 참고합니다.

{
  "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
}

Note

{
  "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 파일에 있습니다.

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)

`api_json.log`#

이 로그는 다음 위치에 있습니다.

Linux 패키지 설치에서는 /var/log/gitlab/gitlab-rails/api_json.log 파일에 있습니다.
자체 컴파일 설치에서는 /home/git/gitlab/log/api_json.log 파일에 있습니다.
Helm 차트 설치에서는 Webservice Pod의 subcomponent="api_json" 키 아래에 있습니다.

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",
  ...
}

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

Note

`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 차트 설치에서는 Sidekiq 및 Webservice Pod의 subcomponent="application_json" 키 아래에 있습니다.

사용자 생성, 프로젝트 삭제처럼 인스턴스에서 발생하는 이벤트를 파악하는 데 도움이 됩니다. 예를 들면 다음과 같습니다.

{
  "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 차트 설치에서는 Sidekiq 및 Webservice Pod의 subcomponent="integrations_json" 키 아래에 있습니다.

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 차트 설치에서는 Sidekiq Pod의 subcomponent="kubernetes" 키 아래에 있습니다.

연결 오류 같은 인증서 기반 클러스터 관련 정보를 기록합니다. 각 줄에는 Elasticsearch, Splunk 같은 서비스에서 수집할 수 있는 JSON이 들어 있습니다.

`git_json.log`#

이 로그는 다음 위치에 있습니다.

Linux 패키지 설치에서는 /var/log/gitlab/gitlab-rails/git_json.log 파일에 있습니다.
자체 컴파일 설치에서는 /home/git/gitlab/log/git_json.log 파일에 있습니다.
Helm 차트 설치에서는 Sidekiq Pod의 subcomponent="git_json" 키 아래에 있습니다.

{
   "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`#

Note

GitLab Free는 소수의 감사 이벤트만 추적합니다. GitLab Premium은 훨씬 더 많은 감사 이벤트를 추적합니다.

이 로그는 다음 위치에 있습니다.

Linux 패키지 설치에서는 /var/log/gitlab/gitlab-rails/audit_json.log 파일에 있습니다.
자체 컴파일 설치에서는 /home/git/gitlab/log/audit_json.log 파일에 있습니다.
Helm 차트 설치에서는 Sidekiq 및 Webservice Pod의 subcomponent="audit_json" 키 아래에 있습니다.

그룹 또는 프로젝트 설정과 멤버십(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`#

이 로그는 다음 위치에 있습니다.

Linux 패키지 설치에서는 /var/log/gitlab/sidekiq/current 파일에 있습니다.
자체 컴파일 설치에서는 /home/git/gitlab/log/sidekiq.log 파일에 있습니다.

GitLab Helm 차트 설치의 기본 로그 형식은 json입니다.

{
  "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 차트 설치에서는 Webservice Pod의 subcomponent="sidekiq_client" 키 아래에 있습니다.

이 파일에는 Sidekiq가 job 처리를 시작하기 전, 예를 들어 대기열에 추가되기 전 job에 대한 로그 정보가 들어 있습니다.

이 로그 파일은 sidekiq.log와 구조가 같으므로, 앞서 설명한 대로 Sidekiq에 JSON을 설정했다면 JSON으로 구조화됩니다.

`gitlab-shell.log`#

GitLab은 Git 명령을 실행하고 Git 리포지터리에 대한 SSH 접근을 제공하기 위해 GitLab Shell을 사용합니다.

/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 로그#

`grpc.log`#

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

`gitaly_hooks.log`#

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 차트 설치에서는 Sidekiq Pod의 subcomponent="repocheck" 키 아래에 있습니다.

프로젝트에서 리포지터리 검사가 실행될 때마다 정보를 기록합니다.

`importer.log`#

이 로그는 다음 위치에 있습니다.

Linux 패키지 설치에서는 /var/log/gitlab/gitlab-rails/importer.log 파일에 있습니다.
자체 컴파일 설치에서는 /home/git/gitlab/log/importer.log 파일에 있습니다.
Helm 차트 설치에서는 Sidekiq Pod의 subcomponent="importer" 키 아래에 있습니다.

이 파일에는 프로젝트 가져오기 및 마이그레이션의 진행 상황이 기록됩니다.

`exporter.log`#

이 로그는 다음 위치에 있습니다.

Linux 패키지 설치에서는 /var/log/gitlab/gitlab-rails/exporter.log 파일에 있습니다.
자체 컴파일 설치에서는 /home/git/gitlab/log/exporter.log 파일에 있습니다.
Helm 차트 설치에서는 Sidekiq 및 Webservice Pod의 subcomponent="exporter" 키 아래에 있습니다.

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

`features_json.log`#

이 로그는 다음 위치에 있습니다.

Linux 패키지 설치에서는 /var/log/gitlab/gitlab-rails/features_json.log 파일에 있습니다.
자체 컴파일 설치에서는 /home/git/gitlab/log/features_json.log 파일에 있습니다.
Helm 차트 설치에서는 Sidekiq 및 Webservice Pod의 subcomponent="features_json" 키 아래에 있습니다.

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`#

이 로그는 다음 위치에 있습니다.

Linux 패키지 설치에서는 /var/log/gitlab/gitlab-rails/ci_resource_groups_json.log 파일에 있습니다.
자체 컴파일 설치에서는 /home/git/gitlab/log/ci_resource_group_json.log 파일에 있습니다.
Helm 차트 설치에서는 Sidekiq 및 Webservice Pod의 subcomponent="ci_resource_groups_json" 키 아래에 있습니다.

리소스 그룹 획득에 관한 정보가 포함되어 있습니다. 예를 들면 다음과 같습니다.

{"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 파일에 있습니다.

이 로그에는 다음이 기록됩니다.

raw 엔드포인트에서 속도 제한을 초과한 요청
보호된 경로에 대한 남용 요청
사용자 ID와 사용자 이름 (확인 가능한 경우)

`auth_json.log`#

이 로그는 다음 위치에 있습니다.

Linux 패키지 설치에서는 /var/log/gitlab/gitlab-rails/auth_json.log 파일에 있습니다.
자체 컴파일 설치에서는 /home/git/gitlab/log/auth_json.log 파일에 있습니다.
Helm 차트 설치에서는 Sidekiq 및 Webservice Pod의 subcomponent="auth_json" 키 아래에 있습니다.

이 파일에는 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 차트 설치에서는 Sidekiq 및 Webservice Pod의 subcomponent="graphql_json" 키 아래에 있습니다.

이 파일에는 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`#

이 로그는 다음 위치에 있습니다.

Linux 패키지 설치에서는 /var/log/gitlab/gitlab-rails/clickhouse.log 파일에 있습니다.
자체 컴파일 설치에서는 /home/git/gitlab/log/clickhouse.log 파일에 있습니다.
Sidekiq 및 Webservice Pod의 subcomponent="clickhouse" 키 아래에 있습니다.

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 파일에 있습니다.

`web_hooks.log`#

이 로그는 다음 위치에 있습니다.

Linux 패키지 설치에서는 /var/log/gitlab/gitlab-rails/web_hooks.log 파일에 있습니다.
자체 컴파일 설치에서는 /home/git/gitlab/log/web_hooks.log 파일에 있습니다.
Helm 차트 설치에서는 Sidekiq Pod의 subcomponent="web_hooks" 키 아래에 있습니다.

웹훅의 백오프, 비활성화, 재활성화 이벤트가 이 파일에 기록됩니다. 예를 들면 다음과 같습니다.

{"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}

재구성 로그#

재구성 로그 파일의 이름은 재구성이 시작된 시점의 UNIX 타임스탬프를 따르며, 예를 들면 1509705644.log입니다.

`sidekiq_exporter.log` 및 `web_exporter.log`#

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

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 차트 설치에서는 Sidekiq 및 Webservice Pod의 subcomponent="database_load_balancing" 키 아래에 있습니다.

`zoekt.log`#

이 파일에는 정확한 코드 검색과 관련된 정보가 기록됩니다.

이 로그는 다음 위치에 있습니다.

Linux 패키지 설치에서는 /var/log/gitlab/gitlab-rails/zoekt.log 파일에 있습니다.
자체 컴파일 설치에서는 /home/git/gitlab/log/zoekt.log 파일에 있습니다.
Helm 차트 설치에서는 Sidekiq 및 Webservice Pod의 subcomponent="zoekt" 키 아래에 있습니다.

`zoekt.log` 필드#

노드 메트릭 항목 (`metric: node_metrics`)#

이 항목은 주기적인 메트릭 cron job이 온라인 Zoekt 노드마다 한 번씩 출력합니다.

필드	유형	설명
`enabled_namespaces_count`	Integer	이 노드에서 정확한 코드 검색이 활성화된 네임스페이스 수
`indices_count`	Integer	이 노드의 리포지터리 인덱스 수
`task_count_pending`	Integer	`pending` 상태인 인덱싱 작업 수
`task_count_failed`	Integer	`failed` 상태인 인덱싱 작업 수
`task_count_processing_queue`	Integer	처리 준비가 된 인덱싱 작업 수 (상태가 `pending`이거나, `perform_at <= now`인 `processing`)
`task_count_orphaned`	Integer	`orphaned` 상태인 인덱싱 작업 수
`task_count_done`	Integer	`done` 상태인 인덱싱 작업 수
`meta`	Object	노드 ID와 URL을 포함한 노드 메타데이터

인덱스 메트릭 항목 (`metric: indices_metrics`)#

이 항목은 메트릭 수집 주기마다 한 번씩 출력됩니다.

meta.zoekt.with_stale_used_storage_bytes_updated_at 키는 점이 포함된 평면 키 이름 그대로이며, 중첩된 객체 경로가 아닙니다.

필드	유형	설명
`meta.zoekt.with_stale_used_storage_bytes_updated_at`	Integer	`used_storage_bytes` 값이 최근에 갱신되지 않은 Zoekt 인덱스 수

활성화된 네임스페이스 메트릭 항목 (`metric: enabled_namespaces_metrics`)#

이 항목은 메트릭 수집 주기마다 한 번씩 출력됩니다.

meta.zoekt.enabled_namespaces_without_replicas 키는 점이 포함된 평면 키 이름 그대로이며, 중첩된 객체 경로가 아닙니다.

필드	유형	설명
`meta.zoekt.enabled_namespaces_without_replicas`	Integer	정확한 코드 검색이 활성화되어 있지만 Zoekt 복제본이 없어 롤아웃을 기다리는 네임스페이스 수

요청별 필드#

이 필드는 GitLab Rails에서 Zoekt 노드로 보내는 각 HTTP 요청마다 출력되는 로그 항목에 나타납니다.

필드	유형	설명
`zoekt_calls`	Integer	이 Rails 요청 중 발생한 Zoekt HTTP 요청 수
`zoekt_duration_s`	Float	이 Rails 요청 중 Zoekt 응답을 기다리는 데 소요된 총 시간(초)

`elasticsearch.log`#

이 파일에는 Elasticsearch 통합과 관련된 정보가 기록되며, Elasticsearch 인덱싱 또는 검색 중 발생한 오류도 포함됩니다.

이 로그는 다음 위치에 있습니다.

Linux 패키지 설치에서는 /var/log/gitlab/gitlab-rails/elasticsearch.log 파일에 있습니다.
자체 컴파일 설치에서는 /home/git/gitlab/log/elasticsearch.log 파일에 있습니다.
Helm 차트 설치에서는 Sidekiq 및 Webservice Pod의 subcomponent="elasticsearch" 키 아래에 있습니다.

각 줄에는 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`#

이 로그는 다음 위치에 있습니다.

Linux 패키지 설치에서는 /var/log/gitlab/gitlab-rails/exceptions_json.log 파일에 있습니다.
자체 컴파일 설치에서는 /home/git/gitlab/log/exceptions_json.log 파일에 있습니다.
Helm 차트 설치에서는 Sidekiq 및 Webservice Pod의 subcomponent="exceptions_json" 키 아래에 있습니다.

각 줄에는 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 차트 설치에서는 Sidekiq 및 Webservice Pod의 subcomponent="service_measurement" 키 아래에 있습니다.

서비스 실행마다 측정값이 담긴 구조화된 로그 하나만 포함합니다. 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 차트 설치에서는 Sidekiq 및 Webservice Pod의 subcomponent="geo" 키 아래에 있습니다.

예를 들면 다음과 같습니다.

{"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 차트 설치에서는 Sidekiq Pod의 subcomponent="update_mirror_service_json" 키 아래에 있습니다.

{
   "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`#

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

LLM 입력 및 출력 로깅#

히스토리

GitLab 17.2에서 expanded_ai_logging이라는 기능 플래그와 함께 도입되었습니다. 기본적으로 비활성화되어 있습니다.

Feature flag

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

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

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

로그 파일은 다음 위치에 있습니다.

Linux 패키지 설치에서는 /var/log/gitlab/gitlab-rails/llm.log 파일에 있습니다.
자체 컴파일 설치에서는 /home/git/gitlab/log/llm.log 파일에 있습니다.
Helm 차트 설치에서는 Webservice Pod의 subcomponent="llm" 키 아래에 있습니다.

`mcp.log`#

히스토리

MCP를 통한 GitLab Duo 세션 생성 로깅이 GitLab 19.5에서 도입되었습니다.

도구 호출은 호출이 어떻게 끝났는지 기록하는 tool_status 필드와 함께 기록됩니다:

`tool_status`	필드 설명
`ok`	도구가 성공적으로 실행되었습니다.
`bad_request`	에이전트가 누락되거나, 형식이 잘못되었거나, 유효하지 않은 인수를 보냈습니다.
`unauthorized`	사용자에게 리소스에 대한 액세스 권한이 없습니다. 에이전트에 반환되는 메시지는 리소스를 찾을 수 없다고 표시할 수 있습니다.
`not_found`	리소스가 존재하지 않거나, 사용자가 볼 수 없는 리소스와 구별할 수 없었습니다.
`error`	백엔드 또는 다운스트림 실패이거나 도구가 분류할 수 없는 실패입니다.

도구가 예상하지 못한 예외를 발생시키면 오류 추적 서비스에 보고됩니다. error_type은 알 수 없는 도구 이름에 대해서만 not_found와 함께 기록됩니다.

로그 파일은 다음 위치에 있습니다.

Linux 패키지 설치에서는 /var/log/gitlab/gitlab-rails/mcp.log 파일에 있습니다.
자체 컴파일 설치에서는 /home/git/gitlab/log/mcp.log 파일에 있습니다.
Helm 차트 설치에서는 Webservice Pod의 subcomponent="mcp" 키 아래에 있습니다.

`epic_work_item_sync.log`#

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 차트 설치에서는 Sidekiq 및 Webservice Pod의 subcomponent="epic_work_item_sync" 키 아래에 있습니다.

`secret_push_protection.log`#

secret_push_protection.log 파일에는 시크릿 푸시 보호 기능과 관련된 정보가 기록됩니다.

이 로그는 다음 위치에 있습니다.

Linux 패키지 설치에서는 /var/log/gitlab/gitlab-rails/secret_push_protection.log 파일에 있습니다.
자체 컴파일 설치에서는 /home/git/gitlab/log/secret_push_protection.log 파일에 있습니다.
Helm 차트 설치에서는 Webservice Pod의 subcomponent="secret_push_protection" 키 아래에 있습니다.

`active_context.log`#

히스토리

GitLab 18.3에서 도입되었습니다.

active_context.log 파일에는 ActiveContext 계층을 통한 임베딩 파이프라인과 관련된 정보가 기록됩니다.

이 로그는 다음 위치에 있습니다.

Linux 패키지 설치에서는 /var/log/gitlab/gitlab-rails/active_context.log 파일에 있습니다.
자체 컴파일 설치에서는 /home/git/gitlab/log/active_context.log 파일에 있습니다.
Helm 차트 설치에서는 Sidekiq Pod의 subcomponent="activecontext" 키 아래에 있습니다.

`ai_catalog.log`#

히스토리

GitLab 18.8에서 도입되었습니다.

ai_catalog.log 파일에는 AI Catalog와 관련된 정보가 기록되며, AI Catalog 플로와 에이전트가 실행된 시점도 포함됩니다.

이 로그는 다음 위치에 있습니다.

Linux 패키지 설치에서는 /var/log/gitlab/gitlab-rails/ai_catalog.log 파일에 있습니다.
자체 컴파일 설치에서는 /home/git/gitlab/log/ai_catalog.log 파일에 있습니다.
Helm 차트 설치에서는 Sidekiq Pod의 subcomponent="ai_catalog" 키 아래에 있습니다.

`user_experience_slis.log`#

이 로그는 다음 위치에 있습니다.

Linux 패키지 설치에서는 /var/log/gitlab/gitlab-rails/user_experience_slis.log 파일에 있습니다.
자체 컴파일 설치에서는 /home/git/gitlab/log/user_experience_slis.log 파일에 있습니다.
Helm 차트 설치에서는 Webservice Pod의 subcomponent="user_experience_slis" 키 아래에 있습니다.

메트릭과 대응하는 사용자 경험 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
}

제품 사용 데이터 로그#

Note

데이터 품질의 정확성이 아직 인증되지 않았으므로, 기능 사용량 분석에 원시 로그를 사용하지 않기를 권장합니다.

이 로그는 다음 위치에 있습니다.

Linux 패키지 설치에서는 /var/log/gitlab/gitlab-rails/product_usage_data.log 파일에 있습니다.
자체 컴파일 설치에서는 /home/git/gitlab/log/product_usage_data.log 파일에 있습니다.
Helm 차트 설치에서는 Webservice Pod의 subcomponent="product_usage_data" 키 아래에 있습니다.

{
  "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\"
}

gitlab-rake "product_usage_data:format[log/product_usage_data.log]"
# or pipe the logs directly
cat log/product_usage_data.log | gitlab-rake product_usage_data:format
# or tail the logs in real-time
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 Pod의 /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 차트 설치에서는 Sidekiq Pod의 subcomponent="performance_bar_json" 키 아래에 있습니다.

성능 바 통계(현재는 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 인스턴스에서 여러 로그와 통계를 동시에 수집하면 도움이 됩니다.

Note

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가 있습니다.

로그 시스템

로그 수준#

기본 로그 수준 재정의#

로그 순환#

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

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

기타 Pod#

production_json.log#

production.log#

api_json.log#

application.log (지원 중단됨)#

application_json.log#

integrations_json.log#

kubernetes.log (지원 중단됨)#

git_json.log#

audit_json.log#

Sidekiq 로그#

sidekiq.log#

sidekiq_client.log#

gitlab-shell.log#

Gitaly 로그#

grpc.log#

gitaly_hooks.log#

Puma 로그#

puma_stdout.log#

puma_stderr.log#

repocheck.log#

importer.log#

exporter.log#

features_json.log#

ci_resource_groups_json.log#

auth.log#

auth_json.log#

graphql_json.log#

clickhouse.log#

migrations.log#

mail_room_json.log (기본값)#

web_hooks.log#

재구성 로그#

sidekiq_exporter.log 및 web_exporter.log#

database_load_balancing.log#

zoekt.log#

zoekt.log 필드#

노드 메트릭 항목 (metric: node_metrics)#

인덱스 메트릭 항목 (metric: indices_metrics)#

활성화된 네임스페이스 메트릭 항목 (metric: enabled_namespaces_metrics)#

요청별 필드#

elasticsearch.log#

exceptions_json.log#

service_measurement.log#

geo.log#

update_mirror_service_json.log#

llm.log#

LLM 입력 및 출력 로깅#

mcp.log#

epic_work_item_sync.log#

secret_push_protection.log#

active_context.log#

ai_catalog.log#

user_experience_slis.log#

Registry 로그#

NGINX 로그#

Pages 로그#

제품 사용 데이터 로그#

Let's Encrypt 로그#

Mattermost 로그#

Workhorse 로그#

Patroni 로그#

PgBouncer 로그#

PostgreSQL 로그#

Prometheus 로그#

Redis 로그#

Sentinel 로그#

Alertmanager 로그#

Consul 로그#

crond 로그#

Grafana 로그#

LogRotate 로그#

GitLab Monitor 로그#

GitLab Exporter 로그#

`production_json.log`#

`production.log`#

`api_json.log`#

`application.log` (지원 중단됨)#

`application_json.log`#

`integrations_json.log`#

`kubernetes.log` (지원 중단됨)#

`git_json.log`#

`audit_json.log`#

`sidekiq.log`#

`sidekiq_client.log`#

`gitlab-shell.log`#

`grpc.log`#

`gitaly_hooks.log`#

`puma_stdout.log`#

`puma_stderr.log`#

`repocheck.log`#

`importer.log`#

`exporter.log`#

`features_json.log`#

`ci_resource_groups_json.log`#

`auth.log`#

`auth_json.log`#

`graphql_json.log`#

`clickhouse.log`#

`migrations.log`#

`mail_room_json.log` (기본값)#

`web_hooks.log`#

`sidekiq_exporter.log` 및 `web_exporter.log`#

`database_load_balancing.log`#

`zoekt.log`#

`zoekt.log` 필드#

노드 메트릭 항목 (`metric: node_metrics`)#

인덱스 메트릭 항목 (`metric: indices_metrics`)#

활성화된 네임스페이스 메트릭 항목 (`metric: enabled_namespaces_metrics`)#

`elasticsearch.log`#

`exceptions_json.log`#

`service_measurement.log`#

`geo.log`#

`update_mirror_service_json.log`#

`llm.log`#

`mcp.log`#

`epic_work_item_sync.log`#

`secret_push_protection.log`#

`active_context.log`#

`ai_catalog.log`#

`user_experience_slis.log`#

`production_json.log`#

`production.log`#

`api_json.log`#

`application.log` (지원 중단됨)#

`application_json.log`#

`integrations_json.log`#

`kubernetes.log` (지원 중단됨)#

`git_json.log`#

`audit_json.log`#

`sidekiq.log`#

`sidekiq_client.log`#

`gitlab-shell.log`#

`grpc.log`#

`gitaly_hooks.log`#

`puma_stdout.log`#

`puma_stderr.log`#

`repocheck.log`#

`importer.log`#

`exporter.log`#

`features_json.log`#

`ci_resource_groups_json.log`#

`auth.log`#

`auth_json.log`#

`graphql_json.log`#

`clickhouse.log`#

`migrations.log`#

`mail_room_json.log` (기본값)#

`web_hooks.log`#

`sidekiq_exporter.log` 및 `web_exporter.log`#

`database_load_balancing.log`#

`zoekt.log`#

`zoekt.log` 필드#

노드 메트릭 항목 (`metric: node_metrics`)#