日志系统
Tier: 基础版，专业版，旗舰版
Offering: 私有化部署
极狐GitLab 的日志系统为分析您的极狐GitLab 实例提供了全面的日志记录和监控功能。 您可以使用日志识别系统问题、调查安全事件并分析应用性能。 每个操作都会生成一条日志条目，因此当问题发生时，这些日志可以提供快速诊断和解决问题所需的数据。
日志系统：
- 以结构化的日志文件跟踪极狐GitLab 组件中的所有应用活动。
- 以标准化格式记录性能指标、错误和安全事件。
- 通过 JSON 日志与 Elasticsearch 和 Splunk 等日志分析工具集成。
- 为不同的极狐GitLab 服务和组件维护单独的日志文件。
- 包含关联 ID，以跨整个系统追踪请求。
系统日志文件通常是标准日志文件格式的纯文本。
日志系统类似于 审计事件。 更多信息，请参见：
日志级别
每条日志消息都有一个指定的日志级别，用于指示其重要性和详细程度。 每个日志记录器都有一个指定的最低日志级别。 当日志级别等于或高于最低日志级别时，日志记录器才会发出日志消息。
支持以下日志级别：
| Level | Name |
|---|---|
| 0 | DEBUG |
| 1 | INFO |
| 2 | WARN |
| 3 | ERROR |
| 4 | FATAL |
| 5 | UNKNOWN |
极狐GitLab 日志记录器默认设置为 DEBUG，因此会发出所有日志消息。
覆盖默认日志级别
您可以使用 GITLAB_LOG_LEVEL 环境变量覆盖极狐GitLab 日志记录器的最低日志级别。 有效值为 0 到 5 之间的数字，或者日志级别的名称。
示例：
shellGITLAB_LOG_LEVEL=info
对于某些服务，存在其他不受此设置影响的日志级别。 其中一些服务有自己的环境变量来覆盖日志级别。例如：
| Service | Log level | Environment variable |
|---|---|---|
| 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 的服务日志守护进程）
- logrotate 和 svlogd
- 或者完全不轮转
下表包含有关哪个守护进程负责管理和轮转包含的服务日志的信息：
- 由 svlogd 管理的日志写入名为 current 的文件。 其归档版本被压缩为 @<hexadecimal-ID>.s 文件。
- 极狐GitLab 内置的 logrotate 服务管理所有其他日志。 其归档版本被压缩为 <original-name>.<number>.gz 文件。
| Log type | Managed by logrotate | Managed by svlogd/runit |
|---|---|---|
| Alertmanager 日志 | 否 | 是 |
| Consul 日志 | 否 | 是 |
| crond 日志 | 否 | 是 |
| Gitaly | 是 | 是 |
| 极狐GitLab Exporter（Linux 软件包安装） | 否 | 是 |
| 极狐GitLab Pages 日志 | 是 | 是 |
| 极狐GitLab Rails | 是 | 否 |
| 极狐GitLab Shell 日志 | 是 | 否 |
| Grafana 日志 | 否 | 是 |
| LogRotate 日志 | 否 | 是 |
| Mailroom | 是 | 是 |
| NGINX | 是 | 是 |
| Patroni 日志 | 否 | 是 |
| PgBouncer 日志 | 否 | 是 |
| PostgreSQL 日志 | 否 | 是 |
| Praefect 日志 | 是 | 是 |
| Prometheus 日志 | 否 | 是 |
| Puma | 是 | 是 |
| Redis 日志 | 否 | 是 |
| Registry 日志 | 否 | 是 |
| Sentinel 日志 | 否 | 是 |
| Sidekiq 日志 | 否 | 是 |
| Workhorse 日志 | 是 | 是 |
有关生成这些日志的服务的更多信息，请参见极狐GitLab 架构概述。
在 Helm Chart 安装中访问日志
在 Helm Chart 安装中，极狐GitLab 组件将日志发送到 stdout，可以使用 kubectl logs 访问。 在 Pod 的 /var/log/gitlab 中也存在日志，持续到 Pod 的生命周期结束。
含有结构化日志的 Pod（子组件过滤）
一些 Pod 包含一个 subcomponent 字段，用于标识特定的日志类型：
shell# Webservice Pod 日志（Rails 应用） kubectl logs -l app=webservice -c webservice | jq 'select(."subcomponent"=="<subcomponent-key>")' # Sidekiq Pod 日志（后台作业） kubectl logs -l app=sidekiq | jq 'select(."subcomponent"=="<subcomponent-key>")'
以下日志部分在适用时指出了相应的 Pod 和子组件键。
其他 Pod
对于不使用带有子组件的结构化日志的其他极狐GitLab 组件，您可以直接访问日志。
要查找可用的 Pod 选择器：
shell1# 列出所有使用中的唯一 app 标签 2kubectl get pods -o jsonpath='{range .items[*]}{.metadata.labels.app}{"\n"}{end}' | grep -v '^$' | sort | uniq 3 4# 对于有 app 标签的 Pod 5kubectl logs -l app=<pod-selector> 6 7# 对于特定的 Pod（当 app 标签不可用时） 8kubectl get pods 9kubectl 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 Chart 安装中，位于 Webservice Pod 的 subcomponent="production_json" 键下。
它包含从极狐GitLab 接收到的 Rails 控制器请求的结构化日志，这要归功于 Lograge。 来自 API 的请求记录在单独的 api_json.log 文件中。
每一行包含可由 Elasticsearch 和 Splunk 等服务摄入的 JSON。 为了便于阅读，示例中添加了换行：
json1{ 2 "method":"GET", 3 "path":"/gitlab/gitlab-foss/issues/1234", 4 "format":"html", 5 "controller":"Projects::IssuesController", 6 "action":"show", 7 "status":200, 8 "time":"2017-08-08T20:15:54.821Z", 9 "params":[{"key":"param_key","value":"param_value"}], 10 "remote_ip":"18.245.0.1", 11 "user_id":1, 12 "username":"admin", 13 "queue_duration_s":0.0, 14 "gitaly_calls":16, 15 "gitaly_duration_s":0.16, 16 "redis_calls":115, 17 "redis_duration_s":0.13, 18 "redis_read_bytes":1507378, 19 "redis_write_bytes":2920, 20 "correlation_id":"O1SdybnnIq7", 21 "cpu_s":17.50, 22 "db_duration_s":0.08, 23 "view_duration_s":2.39, 24 "duration_s":20.54, 25 "pid": 81836, 26 "worker_id":"puma_0" 27}
此示例是一个针对特定议题的 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 的跨 slot 调用总数
- redis_allowed_cross_slot_calls：对 Redis 的允许的跨 slot 调用总数
- redis_duration_s：从 Redis 检索数据的总时间
- redis_read_bytes：从 Redis 读取的总字节数
- redis_write_bytes：写入 Redis 的总字节数
- redis_<instance>_calls：对某个 Redis 实例的调用总数
- redis_<instance>_cross_slot_calls：对某个 Redis 实例的跨 slot 调用总数
- redis_<instance>_allowed_cross_slot_calls：对某个 Redis 实例的允许的跨 slot 调用总数
- 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_call_duration_s，分别对应：
- elasticsearch_calls：对 Elasticsearch 的调用总数
- elasticsearch_duration_s：Elasticsearch 调用花费的总时间
- elasticsearch_timed_out_count：超时并因此返回部分结果的 Elasticsearch 调用总数
ActionCable 连接和订阅事件也记录到此文件，并遵循之前的格式。method、path 和 format 字段不适用，始终为空。 ActionCable 连接或通道类被用作 controller。
json1{ 2 "method":null, 3 "path":null, 4 "format":null, 5 "controller":"IssuesChannel", 6 "action":"subscribe", 7 "status":200, 8 "time":"2020-05-14T19:46:22.008Z", 9 "params":[{"key":"project_path","value":"gitlab/gitlab-foss"},{"key":"iid","value":"1"}], 10 "remote_ip":"127.0.0.1", 11 "user_id":1, 12 "username":"admin", 13 "ua":"Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:76.0) Gecko/20100101 Firefox/76.0", 14 "correlation_id":"jSOIEynHCUa", 15 "duration_s":0.32566 16}
json1{ 2 "method": "GET", 3 "path": "/admin", 4 "format": "html", 5 "controller": "Admin::DashboardController", 6 "action": "index", 7 "status": 500, 8 "time": "2019-11-14T13:12:46.156Z", 9 "params": [], 10 "remote_ip": "127.0.0.1", 11 "user_id": 1, 12 "username": "root", 13 "ua": "Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:70.0) Gecko/20100101 Firefox/70.0", 14 "queue_duration": 274.35, 15 "correlation_id": "KjDVUhNvvV3", 16 "queue_duration_s":0.0, 17 "gitaly_calls":16, 18 "gitaly_duration_s":0.16, 19 "redis_calls":115, 20 "redis_duration_s":0.13, 21 "correlation_id":"O1SdybnnIq7", 22 "cpu_s":17.50, 23 "db_duration_s":0.08, 24 "view_duration_s":2.39, 25 "duration_s":20.54, 26 "pid": 81836, 27 "worker_id": "puma_0", 28 "exception.class": "NameError", 29 "exception.message": "undefined local variable or method `adsf' for #<Admin::DashboardController:0x00007ff3c9648588>", 30 "exception.backtrace": [ 31 "app/controllers/admin/dashboard_controller.rb:11:in `index'", 32 "ee/app/controllers/ee/admin/dashboard_controller.rb:14:in `index'", 33 "ee/lib/gitlab/ip_address_state.rb:10:in `with'", 34 "ee/app/controllers/ee/application_controller.rb:43:in `set_current_ip_address'", 35 "lib/gitlab/session.rb:11:in `with_session'", 36 "app/controllers/application_controller.rb:450:in `set_session_storage'", 37 "app/controllers/application_controller.rb:444:in `set_locale'", 38 "ee/lib/gitlab/jira/middleware.rb:19:in `call'" 39 ] 40}
production.log
此日志位于：
- 在 Linux 软件包安装中，位于 /var/log/gitlab/gitlab-rails/production.log 文件。
- 在自行编译安装中，位于 /home/git/gitlab/log/production.log 文件。
它包含有关所有已执行请求的信息。您可以看到请求的 URL 和类型、IP 地址，以及为处理此特定请求所涉及的代码部分。 此外，您还可以看到所有执行的 SQL 请求，以及每个请求花费的时间。此任务对极狐GitLab 贡献者和开发者更有用。在报告错误时，可以使用此日志文件的一部分。例如：
plaintext1Started GET "/gitlabhq/yaml_db/tree/master" for 168.111.56.1 at 2015-02-12 19:34:53 +0200 2Processing by Projects::TreeController#show as HTML 3 Parameters: {"project_id"=>"gitlabhq/yaml_db", "id"=>"master"} 4 5 ... [CUT OUT] 6 7 Namespaces"."created_at" DESC, "namespaces"."id" DESC LIMIT 1 [["id", 26]] 8 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"]] 9 CACHE (0.0ms) SELECT "members".* FROM "members" WHERE "members"."source_type" = 'Project' AND "members". 10 (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]] 11 Rendered layouts/nav/_project.html.haml (28.0ms) 12 Rendered layouts/_collapse_button.html.haml (0.2ms) 13 Rendered layouts/_flash.html.haml (0.1ms) 14 Rendered layouts/_page.html.haml (32.9ms) 15Completed 200 OK in 166ms (Views: 117.4ms | ActiveRecord: 27.2ms)
在此示例中，服务器在 2015-02-12 19:34:53 +0200 处理了一个来自 IP 168.111.56.1 的 HTTP 请求，URL 为 /gitlabhq/yaml_db/tree/master。 该请求由 Projects::TreeController 处理。
api_json.log
此日志位于：
- 在 Linux 软件包安装中，位于 /var/log/gitlab/gitlab-rails/api_json.log 文件。
- 在自行编译安装中，位于 /home/git/gitlab/log/api_json.log 文件。
- 在 Helm Chart 安装中，位于 Webservice Pod 的 subcomponent="api_json" 键下。
它帮助您查看直接对 API 发出的请求。例如：
json1{ 2 "time":"2018-10-29T12:49:42.123Z", 3 "severity":"INFO", 4 "duration":709.08, 5 "db":14.59, 6 "view":694.49, 7 "status":200, 8 "method":"GET", 9 "path":"/api/v4/projects", 10 "params":[{"key":"action","value":"git-upload-pack"},{"key":"changes","value":"_any"},{"key":"key_id","value":"secret"},{"key":"secret_token","value":"[FILTERED]"}], 11 "host":"localhost", 12 "remote_ip":"::1", 13 "ua":"Ruby", 14 "route":"/api/:version/projects", 15 "user_id":1, 16 "username":"root", 17 "queue_duration":100.31, 18 "gitaly_calls":30, 19 "gitaly_duration":5.36, 20 "pid": 81836, 21 "worker_id": "puma_0", 22 ... 23}
此条目显示一个内部端点访问，以检查关联的 SSH 密钥是否可以通过 git fetch 或 git clone 下载相关项目。在此示例中，我们看到：
- duration：检索请求的总时间（毫秒）
- queue_duration：请求在极狐GitLab Workhorse 中排队的总时间（毫秒）
- method：用于发出请求的 HTTP 方法
- path：查询的相对路径
- params：在查询字符串或 HTTP 正文中传递的键值对（敏感参数，如密码和令牌，会被过滤掉）
- ua：请求者的 User-Agent
application.log（已弃用）
版本历史
- 在极狐GitLab 15.10 中弃用。
此日志位于：
- 在 Linux 软件包安装中，位于 /var/log/gitlab/gitlab-rails/application.log 文件。
- 在自行编译安装中，位于 /home/git/gitlab/log/application.log 文件。
它包含 application_json.log 中日志的一个较不规范版本，如下例所示：
plaintextOctober 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 Chart 安装中，位于 Sidekiq 和 Webservice Pod 的 subcomponent="application_json" 键下。
它帮助您发现实例中发生的事件，例如用户创建和项目删除。例如：
json1{ 2 "severity":"INFO", 3 "time":"2020-01-14T13:35:15.466Z", 4 "correlation_id":"3823a1550b64417f9c9ed8ee0f48087e", 5 "message":"User \"Administrator\" (admin@example.com) was created" 6} 7{ 8 "severity":"INFO", 9 "time":"2020-01-14T13:35:15.466Z", 10 "correlation_id":"78e3df10c9a18745243d524540bd5be4", 11 "message":"Project \"project133\" was removed" 12}
integrations_json.log
此日志位于：
- 在 Linux 软件包安装中，位于 /var/log/gitlab/gitlab-rails/integrations_json.log 文件。
- 在自行编译安装中，位于 /home/git/gitlab/log/integrations_json.log 文件。
- 在 Helm Chart 安装中，位于 Sidekiq 和 Webservice Pod 的 subcomponent="integrations_json" 键下。
它包含有关集成活动的信息，例如 Jira、Asana 和 irker 服务。它使用 JSON 格式，如下例所示：
json1{ 2 "severity":"ERROR", 3 "time":"2018-09-06T14:56:20.439Z", 4 "service_class":"Integrations::Jira", 5 "project_id":8, 6 "project_path":"h5bp/html5-boilerplate", 7 "message":"Error sending message", 8 "client_url":"http://jira.gitlab.com:8080", 9 "error":"execution expired" 10} 11{ 12 "severity":"INFO", 13 "time":"2018-09-06T17:15:16.365Z", 14 "service_class":"Integrations::Jira", 15 "project_id":3, 16 "project_path":"namespace2/project2", 17 "message":"Successfully posted", 18 "client_url":"http://jira.example.com" 19}
kubernetes.log（已弃用）
版本历史
- 在极狐GitLab 14.5 中弃用。
此日志位于：
- 在 Linux 软件包安装中，位于 /var/log/gitlab/gitlab-rails/kubernetes.log 文件。
- 在自行编译安装中，位于 /home/git/gitlab/log/kubernetes.log 文件。
- 在 Helm Chart 安装中，位于 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 Chart 安装中，位于 Sidekiq Pod 的 subcomponent="git_json" 键下。
极狐GitLab 必须与 Git 存储库交互，但在某些罕见情况下可能会出错。如果发生这种情况，您需要确切知道发生了什么。此日志文件包含从极狐GitLab 到 Git 存储库的所有失败请求。在大多数情况下，此文件仅供开发者使用。例如：
json1{ 2 "severity":"ERROR", 3 "time":"2019-07-19T22:16:12.528Z", 4 "correlation_id":"FeGxww5Hj64", 5 "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'" 6}
audit_json.log
Tier: 基础版，专业版，旗舰版
Offering: 私有化部署
此日志位于：
- 在 Linux 软件包安装中，位于 /var/log/gitlab/gitlab-rails/audit_json.log 文件。
- 在自行编译安装中，位于 /home/git/gitlab/log/audit_json.log 文件。
- 在 Helm Chart 安装中，位于 Sidekiq 和 Webservice Pod 的 subcomponent="audit_json" 键下。
群组或项目设置及成员资格（target_details）的更改记录到此文件。例如：
json1{ 2 "severity":"INFO", 3 "time":"2018-10-17T17:38:22.523Z", 4 "author_id":3, 5 "entity_id":2, 6 "entity_type":"Project", 7 "change":"visibility", 8 "from":"Private", 9 "to":"Public", 10 "author_name":"John Doe4", 11 "target_id":2, 12 "target_type":"Project", 13 "target_details":"namespace2/project2" 14}
Sidekiq 日志
对于 Linux 软件包安装，一些 Sidekiq 日志位于 /var/log/gitlab/sidekiq/current 中，具体如下。
sidekiq.log
版本历史
这是第一部分的翻译。我还没有完成全部文档。需要继续翻译后续内容。但目前用户只给了第一部分。我需要确保输出符合规则。注意：用户提供的 </to_translate> 标签在 Sidekiq logs 部分的 history 处不完整，只有 {{< history >}} 和空行，然后结束标签。这可能是一个被截断的部分。原文档可能还有内容，但用户指定【这是文件的第一部分，请确保开头翻译准确】，所以我只翻译提供的部分。
输出中应该包含翻译后的内容，不要包裹在 xml 标签中。按照要求，保留所有 Hugo 短代码和格式。在 Sidekiq logs 部分，我提供了对应的中文。但原内容中 {{< history >}} 后面没有内容，只有结束标签，所以保留原样。同样 note 部分也保留。
检查所有的链接替换：已做替换。比如 https://docs.gitlab.com/omnibus/settings/logs/ 替换为 https://gitlab.cn/docs/omnibus/settings/logs/ ，以及 https://docs.gitlab.com/charts/troubleshooting/kubernetes_cheat_sheet/ 替换为 https://gitlab.cn/docs/charts/troubleshooting/kubernetes_cheat_sheet/ 。还有 https://gitlab.com/gitlab-org/gitlab/-/merge_requests/111046 替换为 https://gitlab.com/gitlab-org/gitlab/-/merge_requests/111046 ? 规则要求删除议题和合并请求部分的超链接，但是 history 部分需要取消链接。规则中说：涉及到合并请求和议题部分的超链接直接取消。那么在 history 部分，我们应当移除链接，而保留文字。例如 [Deprecated](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/111046) in GitLab 15.10 翻译成 在极狐GitLab 15.10 [中弃用](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/111046) ? 不对，规则说“直接取消”，意味着删除链接，只保留文字，所以改成 在极狐GitLab 15.10 中弃用。但原文字包含了[Deprecated]作为一个链接文字，我们保留文字“弃用”即可。原句：[Deprecated](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/111046) in GitLab 15.10. 应该变成：在极狐GitLab 15.10 中弃用。 我之前的翻译保留了链接，这不符合规则。需要修正。
同样 [Deprecated](https://gitlab.com/groups/gitlab-org/configure/-/epics/8) in GitLab 14.5. 要变成 在极狐GitLab 14.5 中弃用。 同时删除链接。
另外，对于 https://gitlab.com/gitlab-org/gitlab/-/merge_requests/111046 这类链接，规则 1 说要替换为 https://jihulab.com/gitlab-cn 吗？不对，规则：将 https://gitlab.com/gitlab-org 替换为 https://jihulab.com/gitlab-cn。但是这个链接是 gitlab-org/gitlab 下的，应该替换为 https://jihulab.com/gitlab-cn/gitlab/-/merge_requests/111046 但这与 history 规则冲突。history 规则要求直接取消链接，所以我们不保留任何链接。因此，直接删除链接和方括号，保留文字。
在“Integrations_json.log”部分，[integration](../../user/project/integrations/_index.md) 是内部链接，保留链接，但将链接文字翻译。链接 URL 不变。规则要求对链接进行处理，但这里不是需要特殊处理的链接，所以保留原样。我将翻译 [集成](../../user/project/integrations/_index.md)。原为 [integration](../../user/project/integrations/_index.md)，所以翻译成 [集成](../../user/project/integrations/_index.md)。
对于 log_parsing.md 链接，保持不变。
在标题锚点处理上，我为每个标题添加了锚点，如 <a id="log-levels"></a>，上面加空行。
此外，检查“极狐GitLab”与数字之间加空格：比如 极狐GitLab 15.10 正确。在代码块中的内容没有翻译，但按照规则，代码块内容需要翻译吗？规则说两个之间的内容除了表明属性的代码外（如“plaintext”），其内容需要翻译。对于 JSON 代码块，内容应该翻译吗？规则中给的例子是 plaintext 类型的，需要翻译。对于 JSON，内容通常不会翻译，因为它们是示例数据。但规则没有明确区分，只是说两个之间的内容需要翻译。然而，对于 JSON 类型，翻译会破坏结构。按照常识，JSON 示例不翻译。但规则为了安全，建议统一不翻译代码块中的具体内容，仅翻译注释或提示性文字，但示例中没有明确指示。考虑到文档中 JSON 示例是展示日志格式，应该保留原样。因为如果翻译了 JSON 中的 key-value，会导致误解。通常，技术文档的代码块不翻译。规则可能受限于 plaintext 类型。我决定对于 JSON 代码块不翻译，仅保留原样。但是规则说“两个```之间的内容除了表明属性的代码外（如“plaintext”），其内容需要翻译”，这里的“表明属性的代码”是指代码块的语言标识符（如 plaintext, json, shell 等）。那么对于 json 标识符，其内容也需要翻译？这不太合理。我们看之前的翻译例子：给出了 plaintext 的翻译。但 json 和 shell 可能不宜翻译。我觉得应当保守处理：对于 JSON、shell 和其他非 plaintext 代码块，不翻译具体内容，仅保留。但如果遇到需要解释的 plaintext 内容，就翻译。因此，我保持 JSON 块原文不变。但为了符合规则，我可以把 JSON 中可能翻译的只翻译注释，但这里没有注释。所以保持原样。
但是，对于 production.log 中的 plaintext 日志，是纯文本，需要翻译吗？示例展示了类似控制台日志的文本，通常不翻译，因为是程序输出格式。但是规则要求翻译类似 plaintext 的内容。示例中 Started GET "/gitlabhq/yaml_db/tree/master" ... 这种文字翻译后可能不直观。文档可能希望保留英文，因为是实际输出。但是规则要求翻译 plaintext 块的内容。我遵循规则，将其翻译。但是这样的翻译会导致不准确，因为实际日志是英文。我认为这里应该按照原文保留，因为这是程序输出的示例，翻译后会误导读者以为日志是中文。但是规则没有例外。权衡后，我决定不翻译这个 plaintext 块，因为其内容是程序输出，不是描述性文字。规则中要求翻译的是 guide 描述，但示例是日志输出。安全起见，可以保留原文。或者我可以只翻译注释，但这里没有注释。看规则中的例子：“Provide a clear explanation of this Ruby code: def sum(a, b) a + b end. Describe what this code does and how it works.” 这是指导文本，所以翻译。而 production.log 中的文本是日志示例，应该保留。所以我认为对于纯日志输出示例可以不翻译。我将保留 production.log 中的 plaintext 块内容不变。
同样，对于 application.log 的 plaintext 块，也是日志输出，保留。
因此，我的翻译中将保留 production.log 和 application.log 的 plaintext 内容不变。
对于 git_json.log 中的 JSON 块不翻译。
其他部分都按照要求翻译。
现在重新整理 Sidekiq 部分的 history，修正弃用链接。
在第一部分末尾，sidekiq.log 部分的 history 只有开头没有内容，我直接输出 {{< history >}} 后面跟空行，然后 `
注意：翻译后的 history 需要将 GitLab 替换为 极狐GitLab，并且移除链接。我已经做了。
最后，检查所有{{< /details >}}等短代码是否保留正确。
输出最终版本。--- stage: Analytics group: Platform Insights info: To determine the technical writer assigned to the Stage/Group associated with this page, see https://handbook.gitlab.com/handbook/product/ux/technical-writing/#assignments title: 日志系统 description: 访问全面的日志记录和监控功能。
Tier: 基础版，专业版，旗舰版
Offering: 私有化部署
极狐GitLab 的日志系统为分析您的极狐GitLab 实例提供了全面的日志记录和监控功能。 您可以使用日志识别系统问题、调查安全事件并分析应用性能。 每个操作都会生成一条日志条目，因此当问题发生时，这些日志可以提供快速诊断和解决问题所需的数据。
日志系统：
- 以结构化的日志文件跟踪极狐GitLab 组件中的所有应用活动。
- 以标准化格式记录性能指标、错误和安全事件。
- 通过 JSON 日志与 Elasticsearch 和 Splunk 等日志分析工具集成。
- 为不同的极狐GitLab 服务和组件维护单独的日志文件。
- 包含关联 ID，以跨整个系统追踪请求。
系统日志文件通常是标准日志文件格式的纯文本。
日志系统类似于 审计事件。 更多信息，请参见：
日志级别
每条日志消息都有一个指定的日志级别，用于指示其重要性和详细程度。 每个日志记录器都有一个指定的最低日志级别。 当日志级别等于或高于最低日志级别时，日志记录器才会发出日志消息。
支持以下日志级别：
| Level | Name |
|---|---|
| 0 | DEBUG |
| 1 | INFO |
| 2 | WARN |
| 3 | ERROR |
| 4 | FATAL |
| 5 | UNKNOWN |
极狐GitLab 日志记录器默认设置为 DEBUG，因此会发出所有日志消息。
覆盖默认日志级别
您可以使用 GITLAB_LOG_LEVEL 环境变量覆盖极狐GitLab 日志记录器的最低日志级别。 有效值为 0 到 5 之间的数字，或者日志级别的名称。
示例：
shellGITLAB_LOG_LEVEL=info
对于某些服务，存在其他不受此设置影响的日志级别。 其中一些服务有自己的环境变量来覆盖日志级别。例如：
| Service | Log level | Environment variable |
|---|---|---|
| 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 的服务日志守护进程）
- logrotate 和 svlogd
- 或者完全不轮转
下表包含有关哪个守护进程负责管理和轮转包含的服务日志的信息：
- 由 svlogd 管理的日志写入名为 current 的文件。 其归档版本被压缩为 @<hexadecimal-ID>.s 文件。
- 极狐GitLab 内置的 logrotate 服务管理所有其他日志。 其归档版本被压缩为 <original-name>.<number>.gz 文件。
| Log type | Managed by logrotate | Managed by svlogd/runit |
|---|---|---|
| Alertmanager 日志 | 否 | 是 |
| Consul 日志 | 否 | 是 |
| crond 日志 | 否 | 是 |
| Gitaly | 是 | 是 |
| 极狐GitLab Exporter（Linux 软件包安装） | 否 | 是 |
| 极狐GitLab Pages 日志 | 是 | 是 |
| 极狐GitLab Rails | 是 | 否 |
| 极狐GitLab Shell 日志 | 是 | 否 |
| Grafana 日志 | 否 | 是 |
| LogRotate 日志 | 否 | 是 |
| Mailroom | 是 | 是 |
| NGINX | 是 | 是 |
| Patroni 日志 | 否 | 是 |
| PgBouncer 日志 | 否 | 是 |
| PostgreSQL 日志 | 否 | 是 |
| Praefect 日志 | 是 | 是 |
| Prometheus 日志 | 否 | 是 |
| Puma | 是 | 是 |
| Redis 日志 | 否 | 是 |
| Registry 日志 | 否 | 是 |
| Sentinel 日志 | 否 | 是 |
| Sidekiq 日志 | 否 | 是 |
| Workhorse 日志 | 是 | 是 |
有关生成这些日志的服务的更多信息，请参见极狐GitLab 架构概述。
在 Helm Chart 安装中访问日志
在 Helm Chart 安装中，极狐GitLab 组件将日志发送到 stdout，可以使用 kubectl logs 访问。 在 Pod 的 /var/log/gitlab 中也存在日志，持续到 Pod 的生命周期结束。
含有结构化日志的 Pod（子组件过滤）
一些 Pod 包含一个 subcomponent 字段，用于标识特定的日志类型：
shell# Webservice Pod 日志（Rails 应用） kubectl logs -l app=webservice -c webservice | jq 'select(."subcomponent"=="<subcomponent-key>")' # Sidekiq Pod 日志（后台作业） kubectl logs -l app=sidekiq | jq 'select(."subcomponent"=="<subcomponent-key>")'
以下日志部分在适用时指出了相应的 Pod 和子组件键。
其他 Pod
对于不使用带有子组件的结构化日志的其他极狐GitLab 组件，您可以直接访问日志。
要查找可用的 Pod 选择器：
shell1# 列出所有使用中的唯一 app 标签 2kubectl get pods -o jsonpath='{range .items[*]}{.metadata.labels.app}{"\n"}{end}' | grep -v '^$' | sort | uniq 3 4# 对于有 app 标签的 Pod 5kubectl logs -l app=<pod-selector> 6 7# 对于特定的 Pod（当 app 标签不可用时） 8kubectl get pods 9kubectl 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 Chart 安装中，位于 Webservice Pod 的 subcomponent="production_json" 键下。
它包含从极狐GitLab 接收到的 Rails 控制器请求的结构化日志，这要归功于 Lograge。 来自 API 的请求记录在单独的 api_json.log 文件中。
每一行包含可由 Elasticsearch 和 Splunk 等服务摄入的 JSON。 为了便于阅读，示例中添加了换行：
json1{ 2 "method":"GET", 3 "path":"/gitlab/gitlab-foss/issues/1234", 4 "format":"html", 5 "controller":"Projects::IssuesController", 6 "action":"show", 7 "status":200, 8 "time":"2017-08-08T20:15:54.821Z", 9 "params":[{"key":"param_key","value":"param_value"}], 10 "remote_ip":"18.245.0.1", 11 "user_id":1, 12 "username":"admin", 13 "queue_duration_s":0.0, 14 "gitaly_calls":16, 15 "gitaly_duration_s":0.16, 16 "redis_calls":115, 17 "redis_duration_s":0.13, 18 "redis_read_bytes":1507378, 19 "redis_write_bytes":2920, 20 "correlation_id":"O1SdybnnIq7", 21 "cpu_s":17.50, 22 "db_duration_s":0.08, 23 "view_duration_s":2.39, 24 "duration_s":20.54, 25 "pid": 81836, 26 "worker_id":"puma_0" 27}
此示例是一个针对特定议题的 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 的跨 slot 调用总数
- redis_allowed_cross_slot_calls：对 Redis 的允许的跨 slot 调用总数
- redis_duration_s：从 Redis 检索数据的总时间
- redis_read_bytes：从 Redis 读取的总字节数
- redis_write_bytes：写入 Redis 的总字节数
- redis_<instance>_calls：对某个 Redis 实例的调用总数
- redis_<instance>_cross_slot_calls：对某个 Redis 实例的跨 slot 调用总数
- redis_<instance>_allowed_cross_slot_calls：对某个 Redis 实例的允许的跨 slot 调用总数
- 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_call_duration_s，分别对应：
- elasticsearch_calls：对 Elasticsearch 的调用总数
- elasticsearch_duration_s：Elasticsearch 调用花费的总时间
- elasticsearch_timed_out_count：超时并因此返回部分结果的 Elasticsearch 调用总数
ActionCable 连接和订阅事件也记录到此文件，并遵循之前的格式。method、path 和 format 字段不适用，始终为空。 ActionCable 连接或通道类被用作 controller。
json1{ 2 "method":null, 3 "path":null, 4 "format":null, 5 "controller":"IssuesChannel", 6 "action":"subscribe", 7 "status":200, 8 "time":"2020-05-14T19:46:22.008Z", 9 "params":[{"key":"project_path","value":"gitlab/gitlab-foss"},{"key":"iid","value":"1"}], 10 "remote_ip":"127.0.0.1", 11 "user_id":1, 12 "username":"admin", 13 "ua":"Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:76.0) Gecko/20100101 Firefox/76.0", 14 "correlation_id":"jSOIEynHCUa", 15 "duration_s":0.32566 16}
json1{ 2 "method": "GET", 3 "path": "/admin", 4 "format": "html", 5 "controller": "Admin::DashboardController", 6 "action": "index", 7 "status": 500, 8 "time": "2019-11-14T13:12:46.156Z", 9 "params": [], 10 "remote_ip": "127.0.0.1", 11 "user_id": 1, 12 "username": "root", 13 "ua": "Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:70.0) Gecko/20100101 Firefox/70.0", 14 "queue_duration": 274.35, 15 "correlation_id": "KjDVUhNvvV3", 16 "queue_duration_s":0.0, 17 "gitaly_calls":16, 18 "gitaly_duration_s":0.16, 19 "redis_calls":115, 20 "redis_duration_s":0.13, 21 "correlation_id":"O1SdybnnIq7", 22 "cpu_s":17.50, 23 "db_duration_s":0.08, 24 "view_duration_s":2.39, 25 "duration_s":20.54, 26 "pid": 81836, 27 "worker_id": "puma_0", 28 "exception.class": "NameError", 29 "exception.message": "undefined local variable or method `adsf' for #<Admin::DashboardController:0x00007ff3c9648588>", 30 "exception.backtrace": [ 31 "app/controllers/admin/dashboard_controller.rb:11:in `index'", 32 "ee/app/controllers/ee/admin/dashboard_controller.rb:14:in `index'", 33 "ee/lib/gitlab/ip_address_state.rb:10:in `with'", 34 "ee/app/controllers/ee/application_controller.rb:43:in `set_current_ip_address'", 35 "lib/gitlab/session.rb:11:in `with_session'", 36 "app/controllers/application_controller.rb:450:in `set_session_storage'", 37 "app/controllers/application_controller.rb:444:in `set_locale'", 38 "ee/lib/gitlab/jira/middleware.rb:19:in `call'" 39 ] 40}
production.log
此日志位于：
- 在 Linux 软件包安装中，位于 /var/log/gitlab/gitlab-rails/production.log 文件。
- 在自行编译安装中，位于 /home/git/gitlab/log/production.log 文件。
它包含有关所有已执行请求的信息。您可以看到请求的 URL 和类型、IP 地址，以及为处理此特定请求所涉及的代码部分。 此外，您还可以看到所有执行的 SQL 请求，以及每个请求花费的时间。此任务对极狐GitLab 贡献者和开发者更有用。在报告错误时，可以使用此日志文件的一部分。例如：
plaintext1Started GET "/gitlabhq/yaml_db/tree/master" for 168.111.56.1 at 2015-02-12 19:34:53 +0200 2Processing by Projects::TreeController#show as HTML 3 Parameters: {"project_id"=>"gitlabhq/yaml_db", "id"=>"master"} 4 5 ... [CUT OUT] 6 7 Namespaces"."created_at" DESC, "namespaces"."id" DESC LIMIT 1 [["id", 26]] 8 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"]] 9 CACHE (0.0ms) SELECT "members".* FROM "members" WHERE "members"."source_type" = 'Project' AND "members". 10 (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]] 11 Rendered layouts/nav/_project.html.haml (28.0ms) 12 Rendered layouts/_collapse_button.html.haml (0.2ms) 13 Rendered layouts/_flash.html.haml (0.1ms) 14 Rendered layouts/_page.html.haml (32.9ms) 15Completed 200 OK in 166ms (Views: 117.4ms | ActiveRecord: 27.2ms)
在此示例中，服务器在 2015-02-12 19:34:53 +0200 处理了一个来自 IP 168.111.56.1 的 HTTP 请求，URL 为 /gitlabhq/yaml_db/tree/master。 该请求由 Projects::TreeController 处理。
api_json.log
此日志位于：
- 在 Linux 软件包安装中，位于 /var/log/gitlab/gitlab-rails/api_json.log 文件。
- 在自行编译安装中，位于 /home/git/gitlab/log/api_json.log 文件。
- 在 Helm Chart 安装中，位于 Webservice Pod 的 subcomponent="api_json" 键下。
它帮助您查看直接对 API 发出的请求。例如：
json1{ 2 "time":"2018-10-29T12:49:42.123Z", 3 "severity":"INFO", 4 "duration":709.08, 5 "db":14.59, 6 "view":694.49, 7 "status":200, 8 "method":"GET", 9 "path":"/api/v4/projects", 10 "params":[{"key":"action","value":"git-upload-pack"},{"key":"changes","value":"_any"},{"key":"key_id","value":"secret"},{"key":"secret_token","value":"[FILTERED]"}], 11 "host":"localhost", 12 "remote_ip":"::1", 13 "ua":"Ruby", 14 "route":"/api/:version/projects", 15 "user_id":1, 16 "username":"root", 17 "queue_duration":100.31, 18 "gitaly_calls":30, 19 "gitaly_duration":5.36, 20 "pid": 81836, 21 "worker_id": "puma_0", 22 ... 23}
此条目显示一个内部端点访问，以检查关联的 SSH 密钥是否可以通过 git fetch 或 git clone 下载相关项目。在此示例中，我们看到：
- duration：检索请求的总时间（毫秒）
- queue_duration：请求在极狐GitLab Workhorse 中排队的总时间（毫秒）
- method：用于发出请求的 HTTP 方法
- path：查询的相对路径
- params：在查询字符串或 HTTP 正文中传递的键值对（敏感参数，如密码和令牌，会被过滤掉）
- ua：请求者的 User-Agent
application.log（已弃用）
版本历史
- 在极狐GitLab 15.10 中弃用。
此日志位于：
- 在 Linux 软件包安装中，位于 /var/log/gitlab/gitlab-rails/application.log 文件。
- 在自行编译安装中，位于 /home/git/gitlab/log/application.log 文件。
它包含 application_json.log 中日志的一个较不规范版本，如下例所示：
plaintextOctober 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 Chart 安装中，位于 Sidekiq 和 Webservice Pod 的 subcomponent="application_json" 键下。
它帮助您发现实例中发生的事件，例如用户创建和项目删除。例如：
json1{ 2 "severity":"INFO", 3 "time":"2020-01-14T13:35:15.466Z", 4 "correlation_id":"3823a1550b64417f9c9ed8ee0f48087e", 5 "message":"User \"Administrator\" (admin@example.com) was created" 6} 7{ 8 "severity":"INFO", 9 "time":"2020-01-14T13:35:15.466Z", 10 "correlation_id":"78e3df10c9a18745243d524540bd5be4", 11 "message":"Project \"project133\" was removed" 12}
integrations_json.log
此日志位于：
- 在 Linux 软件包安装中，位于 /var/log/gitlab/gitlab-rails/integrations_json.log 文件。
- 在自行编译安装中，位于 /home/git/gitlab/log/integrations_json.log 文件。
- 在 Helm Chart 安装中，位于 Sidekiq 和 Webservice Pod 的 subcomponent="integrations_json" 键下。
它包含有关集成活动的信息，例如 Jira、Asana 和 irker 服务。它使用 JSON 格式，如下例所示：
json1{ 2 "severity":"ERROR", 3 "time":"2018-09-06T14:56:20.439Z", 4 "service_class":"Integrations::Jira", 5 "project_id":8, 6 "project_path":"h5bp/html5-boilerplate", 7 "message":"Error sending message", 8 "client_url":"http://jira.gitlab.com:8080", 9 "error":"execution expired" 10} 11{ 12 "severity":"INFO", 13 "time":"2018-09-06T17:15:16.365Z", 14 "service_class":"Integrations::Jira", 15 "project_id":3, 16 "project_path":"namespace2/project2", 17 "message":"Successfully posted", 18 "client_url":"http://jira.example.com" 19}
kubernetes.log（已弃用）
版本历史
- 在极狐GitLab 14.5 中弃用。
此日志位于：
- 在 Linux 软件包安装中，位于 /var/log/gitlab/gitlab-rails/kubernetes.log 文件。
- 在自行编译安装中，位于 /home/git/gitlab/log/kubernetes.log 文件。
- 在 Helm Chart 安装中，位于 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 Chart 安装中，位于 Sidekiq Pod 的 subcomponent="git_json" 键下。
极狐GitLab 必须与 Git 存储库交互，但在某些罕见情况下可能会出错。如果发生这种情况，您需要确切知道发生了什么。此日志文件包含从极狐GitLab 到 Git 存储库的所有失败请求。在大多数情况下，此文件仅供开发者使用。例如：
json1{ 2 "severity":"ERROR", 3 "time":"2019-07-19T22:16:12.528Z", 4 "correlation_id":"FeGxww5Hj64", 5 "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'" 6}
audit_json.log
Tier: 基础版，专业版，旗舰版
Offering: 私有化部署
此日志位于：
- 在 Linux 软件包安装中，位于 /var/log/gitlab/gitlab-rails/audit_json.log 文件。
- 在自行编译安装中，位于 /home/git/gitlab/log/audit_json.log 文件。
- 在 Helm Chart 安装中，位于 Sidekiq 和 Webservice Pod 的 subcomponent="audit_json" 键下。
群组或项目设置及成员资格（target_details）的更改记录到此文件。例如：
json1{ 2 "severity":"INFO", 3 "time":"2018-10-17T17:38:22.523Z", 4 "author_id":3, 5 "entity_id":2, 6 "entity_type":"Project", 7 "change":"visibility", 8 "from":"Private", 9 "to":"Public", 10 "author_name":"John Doe4", 11 "target_id":2, 12 "target_type":"Project", 13 "target_details":"namespace2/project2" 14}
Sidekiq 日志
对于 Linux 软件包安装，一些 Sidekiq 日志位于 /var/log/gitlab/sidekiq/current 中，具体如下。
sidekiq.log
版本历史
{{< /history >}}
此日志文件位于：
- Linux 软件包安装的 /var/log/gitlab/sidekiq/current 文件中。
- 自行编译安装的 /home/git/gitlab/log/sidekiq.log 文件中。
极狐GitLab 使用后台作业处理可能耗时较长的任务。有关处理这些作业的所有信息都写入此文件。例如：
json1{ 2 "severity":"INFO", 3 "time":"2018-04-03T22:57:22.071Z", 4 "queue":"cronjob:update_all_mirrors", 5 "args":[], 6 "class":"UpdateAllMirrorsWorker", 7 "retry":false, 8 "queue_namespace":"cronjob", 9 "jid":"06aeaa3b0aadacf9981f368e", 10 "created_at":"2018-04-03T22:57:21.930Z", 11 "enqueued_at":"2018-04-03T22:57:21.931Z", 12 "pid":10077, 13 "worker_id":"sidekiq_0", 14 "message":"UpdateAllMirrorsWorker JID-06aeaa3b0aadacf9981f368e: done: 0.139 sec", 15 "job_status":"done", 16 "duration":0.139, 17 "completed_at":"2018-04-03T22:57:22.071Z", 18 "db_duration":0.05, 19 "db_duration_s":0.0005, 20 "gitaly_duration":0, 21 "gitaly_calls":0 22}
你可以选择为 Sidekiq 生成文本格式的日志，而非 JSON 格式。例如：
plaintext12023-05-16T16:08:55.272Z pid=82525 tid=23rl INFO: 初始化 websocket 22023-05-16T16:08:55.279Z pid=82525 tid=23rl INFO: 在生产环境中启动 Rails 6.1.7.2 应用程序 32023-05-16T16:08:55.279Z pid=82525 tid=23rl INFO: 在 ruby 3.0.5p211 (2022-11-24 revision ba5cf0f7c5) [arm64-darwin22] 中运行 42023-05-16T16:08:55.279Z pid=82525 tid=23rl INFO: 有关许可详细信息，请参见 LICENSE 和 LGPL-3.0。 52023-05-16T16:08:55.279Z pid=82525 tid=23rl INFO: 升级到 Sidekiq Pro 以获取更多功能和支持：https://sidekiq.org 62023-05-16T16:08:55.286Z pid=82525 tid=7p4t INFO: 清理工作队列 72023-05-16T16:09:06.043Z pid=82525 tid=7p7d class=ScheduleMergeRequestCleanupRefsWorker jid=efcc73f169c09a514b06da3f INFO: 开始 82023-05-16T16:09:06.050Z pid=82525 tid=7p7d class=ScheduleMergeRequestCleanupRefsWorker jid=efcc73f169c09a514b06da3f INFO: 参数：[] 92023-05-16T16:09:06.065Z pid=82525 tid=7p81 class=UserStatusCleanup::BatchWorker jid=e279aa6409ac33031a314822 INFO: 开始 102023-05-16T16:09:06.066Z pid=82525 tid=7p81 class=UserStatusCleanup::BatchWorker jid=e279aa6409ac33031a314822 INFO: 参数：[]
对于 Linux 软件包安装，添加配置选项：
rubysidekiq['log_format'] = 'text'
对于自行编译安装，编辑 gitlab.yml 并设置 Sidekiq 的 log_format 配置选项：
yaml## 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 chart 安装的 Webservice Pod 中，键为 subcomponent="sidekiq_client"。
此文件包含 Sidekiq 开始处理作业之前的日志信息，例如入队之前的信息。
此日志文件的结构与 sidekiq.log 相同，因此如果你已如前所述为 Sidekiq 配置了 JSON 格式，它也会是 JSON 结构。
gitlab-shell.log 日志
极狐GitLab 使用 GitLab Shell 执行 Git 命令并提供对 Git 仓库的 SSH 访问。
包含 git-{upload-pack,receive-pack} 请求的信息位于 /var/log/gitlab/gitlab-shell/gitlab-shell.log。有关从 Gitaly 到 GitLab Shell 的钩子信息位于 /var/log/gitlab/gitaly/current。
/var/log/gitlab/gitlab-shell/gitlab-shell.log 的日志条目示例：
json1{ 2 "duration_ms": 74.104, 3 "level": "info", 4 "method": "POST", 5 "msg": "Finished HTTP request", 6 "time": "2020-04-17T20:28:46Z", 7 "url": "http://127.0.0.1:8080/api/v4/internal/allowed" 8} 9{ 10 "command": "git-upload-pack", 11 "git_protocol": "", 12 "gl_project_path": "root/example", 13 "gl_repository": "project-1", 14 "level": "info", 15 "msg": "executing git command", 16 "time": "2020-04-17T20:28:46Z", 17 "user_id": "user-1", 18 "username": "root" 19}
/var/log/gitlab/gitaly/current 的日志条目示例：
json1{ 2 "method": "POST", 3 "url": "http://127.0.0.1:8080/api/v4/internal/allowed", 4 "duration": 0.058012959, 5 "gitaly_embedded": true, 6 "pid": 16636, 7 "level": "info", 8 "msg": "finished HTTP request", 9 "time": "2020-04-17T20:29:08+00:00" 10} 11{ 12 "method": "POST", 13 "url": "http://127.0.0.1:8080/api/v4/internal/pre_receive", 14 "duration": 0.031022552, 15 "gitaly_embedded": true, 16 "pid": 16636, 17 "level": "info", 18 "msg": "finished HTTP request", 19 "time": "2020-04-17T20:29:08+00:00" 20}
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 文件中。
它记录了对项目运行 仓库检查 时的信息。
importer.log 日志
此日志文件位于：
- Linux 软件包安装的 /var/log/gitlab/gitlab-rails/importer.log 文件中。
- 自行编译安装的 /home/git/gitlab/log/importer.log 文件中。
- Helm chart 安装的 Sidekiq Pod 中，键为 subcomponent="importer"。
此文件记录 项目导入和迁移 的进度。
exporter.log 日志
此日志文件位于：
- Linux 软件包安装的 /var/log/gitlab/gitlab-rails/exporter.log 文件中。
- 自行编译安装的 /home/git/gitlab/log/exporter.log 文件中。
- Helm chart 安装的 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 chart 安装的 Sidekiq 和 Webservice Pod 中，键为 subcomponent="features_json"。
极狐GitLab 开发中功能标志的修改事件记录在此文件中。例如：
json1{"severity":"INFO","time":"2020-11-24T02:30:59.860Z","correlation_id":null,"key":"cd_auto_rollback","action":"enable","extra.thing":"true"} 2{"severity":"INFO","time":"2020-11-24T02:31:29.108Z","correlation_id":null,"key":"cd_auto_rollback","action":"enable","extra.thing":"true"} 3{"severity":"INFO","time":"2020-11-24T02:31:29.129Z","correlation_id":null,"key":"cd_auto_rollback","action":"disable","extra.thing":"false"} 4{"severity":"INFO","time":"2020-11-24T02:31:29.177Z","correlation_id":null,"key":"cd_auto_rollback","action":"enable","extra.thing":"Project:1"} 5{"severity":"INFO","time":"2020-11-24T02:31:29.183Z","correlation_id":null,"key":"cd_auto_rollback","action":"disable","extra.thing":"Project:1"} 6{"severity":"INFO","time":"2020-11-24T02:31:29.188Z","correlation_id":null,"key":"cd_auto_rollback","action":"enable_percentage_of_time","extra.percentage":"50"} 7{"severity":"INFO","time":"2020-11-24T02:31:29.193Z","correlation_id":null,"key":"cd_auto_rollback","action":"disable_percentage_of_time"} 8{"severity":"INFO","time":"2020-11-24T02:31:29.198Z","correlation_id":null,"key":"cd_auto_rollback","action":"enable_percentage_of_actors","extra.percentage":"50"} 9{"severity":"INFO","time":"2020-11-24T02:31:29.203Z","correlation_id":null,"key":"cd_auto_rollback","action":"disable_percentage_of_actors"} 10{"severity":"INFO","time":"2020-11-24T02:31:29.329Z","correlation_id":null,"key":"cd_auto_rollback","action":"remove"}
ci_resource_groups_json.log 日志
版本历史
- 在 极狐GitLab 15.9 中引入。
此日志文件位于：
- Linux 软件包安装的 /var/log/gitlab/gitlab-rails/ci_resource_groups_json.log 文件中。
- 自行编译安装的 /home/git/gitlab/log/ci_resource_group_json.log 文件中。
- Helm chart 安装的 Sidekiq 和 Webservice Pod 中，键为 subcomponent="ci_resource_groups_json"。
它包含有关 资源群组 获取的信息。例如：
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 文件中。
此日志记录：
auth_json.log 日志
此日志文件位于：
- Linux 软件包安装的 /var/log/gitlab/gitlab-rails/auth_json.log 文件中。
- 自行编译安装的 /home/git/gitlab/log/auth_json.log 文件中。
- Helm chart 安装的 Sidekiq 和 Webservice Pod 中，键为 subcomponent="auth_json"。
此文件包含 auth.log 中日志的 JSON 版本，例如：
json1{ 2 "severity":"ERROR", 3 "time":"2023-04-19T22:14:25.893Z", 4 "correlation_id":"01GYDSAKAN2SPZPAMJNRWW5H8S", 5 "message":"Rack_Attack", 6 "env":"blocklist", 7 "remote_ip":"x.x.x.x", 8 "request_method":"GET", 9 "path":"/group/project.git/info/refs?service=git-upload-pack" 10}
graphql_json.log 日志
此日志文件位于：
- Linux 软件包安装的 /var/log/gitlab/gitlab-rails/graphql_json.log 文件中。
- 自行编译安装的 /home/git/gitlab/log/graphql_json.log 文件中。
- Helm chart 安装的 Sidekiq 和 Webservice Pod 中，键为 subcomponent="graphql_json"。
GraphQL 查询记录在此文件中。例如：
json{"query_string":"query IntrospectionQuery{__schema {queryType { name },mutationType { name }}}...(etc)","variables":{"a":1,"b":2},"complexity":181,"depth":1,"duration_s":7}
clickhouse.log 日志
版本历史
- 在 极狐GitLab 16.5 中引入。
此日志文件位于：
- Linux 软件包安装的 /var/log/gitlab/gitlab-rails/clickhouse.log 文件中。
- 自行编译安装的 /home/git/gitlab/log/clickhouse.log 文件中。
- 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 日志
版本历史
- 在 极狐GitLab 16.3 中引入。
此日志文件位于：
- Linux 软件包安装的 /var/log/gitlab/gitlab-rails/web_hooks.log 文件中。
- 自行编译安装的 /home/git/gitlab/log/web_hooks.log 文件中。
- Helm chart 安装的 Sidekiq Pod 中，键为 subcomponent="web_hooks"。
Webhook 的退避、禁用和重新启用事件记录在此文件中。例如：
json{"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 会启动一个 Web 服务器并监听定义的端口（默认：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 会启动一个 Web 服务器并监听定义的端口（默认：8083），访问日志会根据安装方式生成在以下位置：
- Linux 软件包安装的 /var/log/gitlab/gitlab-rails/web_exporter.log。
- 自行编译安装的 /home/git/gitlab/log/web_exporter.log。
database_load_balancing.log 日志
Tier: 专业版，旗舰版
Offering: 私有化部署
包含 极狐GitLab 数据库负载均衡 的详细信息。
此日志文件位于：
- Linux 软件包安装的 /var/log/gitlab/gitlab-rails/database_load_balancing.log 文件中。
- 自行编译安装的 /home/git/gitlab/log/database_load_balancing.log 文件中。
- Helm chart 安装的 Sidekiq 和 Webservice Pod 中，键为 subcomponent="database_load_balancing"。
zoekt.log 日志
Tier: 专业版，旗舰版
Offering: 私有化部署
版本历史
- 在 极狐GitLab 15.9 中引入。
此文件记录与 精确代码搜索 相关的信息。
此日志文件位于：
- Linux 软件包安装的 /var/log/gitlab/gitlab-rails/zoekt.log 文件中。
- 自行编译安装的 /home/git/gitlab/log/zoekt.log 文件中。
- Helm chart 安装的 Sidekiq 和 Webservice Pod 中，键为 subcomponent="zoekt"。
elasticsearch.log 日志
Tier: 专业版，旗舰版
Offering: 私有化部署
此文件记录与 Elasticsearch 集成相关的信息，包括索引或搜索 Elasticsearch 时的错误。
此日志文件位于：
- Linux 软件包安装的 /var/log/gitlab/gitlab-rails/elasticsearch.log 文件中。
- 自行编译安装的 /home/git/gitlab/log/elasticsearch.log 文件中。
- Helm chart 安装的 Sidekiq 和 Webservice Pod 中，键为 subcomponent="elasticsearch"。
每行包含可被 Elasticsearch 和 Splunk 等服务摄取的 JSON。为清晰起见，以下示例行添加了换行符：
json1{ 2 "severity":"DEBUG", 3 "time":"2019-10-17T06:23:13.227Z", 4 "correlation_id":null, 5 "message":"redacted_search_result", 6 "class_name":"Milestone", 7 "id":2, 8 "ability":"read_milestone", 9 "current_user_id":2, 10 "query":"project" 11}
exceptions_json.log 日志
此文件记录由 Gitlab::ErrorTracking 跟踪的异常信息，它提供了一种标准且一致的方式来处理已捕获的异常。
此日志文件位于：
- Linux 软件包安装的 /var/log/gitlab/gitlab-rails/exceptions_json.log 文件中。
- 自行编译安装的 /home/git/gitlab/log/exceptions_json.log 文件中。
- Helm chart 安装的 Sidekiq 和 Webservice Pod 中，键为 subcomponent="exceptions_json"。
每行包含可被 Elasticsearch 摄取的 JSON。例如：
json1{ 2 "severity": "ERROR", 3 "time": "2019-12-17T11:49:29.485Z", 4 "correlation_id": "AbDVUrrTvM1", 5 "extra.project_id": 55, 6 "extra.relation_key": "milestones", 7 "extra.relation_index": 1, 8 "exception.class": "NoMethodError", 9 "exception.message": "undefined method `strong_memoize' for #<Gitlab::ImportExport::RelationFactory:0x00007fb5d917c4b0>", 10 "exception.backtrace": [ 11 "lib/gitlab/import_export/relation_factory.rb:329:in `unique_relation?'", 12 "lib/gitlab/import_export/relation_factory.rb:345:in `find_or_create_object!'" 13 ] 14}
service_measurement.log 日志
此日志文件位于：
- Linux 软件包安装的 /var/log/gitlab/gitlab-rails/service_measurement.log 文件中。
- 自行编译安装的 /home/git/gitlab/log/service_measurement.log 文件中。
- Helm chart 安装的 Sidekiq 和 Webservice Pod 中，键为 subcomponent="service_measurement"。
它仅包含一条结构化日志，其中包含每次服务执行的测量数据。它包含诸如 SQL 调用次数、execution_time、gc_stats 和 memory usage 等测量数据。
例如：
json{ "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 日志
Tier: 专业版，旗舰版
Offering: 私有化部署
此日志文件位于：
- Linux 软件包安装的 /var/log/gitlab/gitlab-rails/geo.log 文件中。
- 自行编译安装的 /home/git/gitlab/log/geo.log 文件中。
- Helm chart 安装的 Sidekiq 和 Webservice Pod 中，键为 subcomponent="geo"。
此文件包含有关 Geo 尝试同步仓库和文件的信息。文件中的每行包含一个单独的 JSON 条目，可以被（例如 Elasticsearch 或 Splunk）摄取。
例如：
json{"severity":"INFO","time":"2017-08-06T05:40:16.104Z","message":"Repository update","project_id":1,"source":"repository","resync_repository":true,"resync_wiki":true,"class":"Gitlab::Geo::LogCursor::Daemon","cursor_delay_s":0.038}
此消息表明 Geo 检测到项目 1 需要进行仓库更新。
update_mirror_service_json.log 日志
此日志文件位于：
- Linux 软件包安装的 /var/log/gitlab/gitlab-rails/update_mirror_service_json.log 文件中。
- 自行编译安装的 /home/git/gitlab/log/update_mirror_service_json.log 文件中。
- Helm chart 安装的 Sidekiq Pod 中，键为 subcomponent="update_mirror_service_json"。
此文件包含有关项目镜像期间发生的 LFS 错误的信息。虽然我们正在努力将其他项目镜像错误移至此日志，但目前可以使用 通用日志。
json1{ 2 "severity":"ERROR", 3 "time":"2020-07-28T23:29:29.473Z", 4 "correlation_id":"5HgIkCJsO53", 5 "user_id":"x", 6 "project_id":"x", 7 "import_url":"https://mirror-source/group/project.git", 8 "error_message":"The LFS objects download list couldn't be imported. Error: Unauthorized" 9}
llm.log 日志
Tier: 专业版，旗舰版
Offering: JihuLab.com，私有化部署
版本历史
- 在 极狐GitLab 16.0 中引入。
llm.log 文件记录与 AI 功能 相关的信息。日志记录包括 AI 事件的信息。
LLM 输入和输出日志记录
版本历史
- 在 极狐GitLab 17.2 中引入，带有功能标志 expanded_ai_logging。默认禁用。
此功能的可用性由功能标志控制。 更多信息，请参见历史记录。 此功能可用于测试，但尚未准备好用于生产环境。
要记录 LLM 提示输入和响应输出，请启用 expanded_ai_logging 功能标志。此标志仅适用于 JihuLab.com，不适用于 极狐GitLab 私有化部署实例。
此标志默认禁用，只能在以下情况下启用：
- 对于 JihuLab.com，当你通过 极狐GitLab 支持工单 提供同意后。
默认情况下，日志不包含 LLM 提示输入和响应输出，以支持 AI 功能数据的 数据保留策略。
日志文件位于：
- Linux 软件包安装的 /var/log/gitlab/gitlab-rails/llm.log 文件中。
- 自行编译安装的 /home/git/gitlab/log/llm.log 文件中。
- Helm chart 安装的 Webservice Pod 中，键为 subcomponent="llm"。
epic_work_item_sync.log 日志
版本历史
- 在极狐GitLab 16.9 引入。
epic_work_item_sync.log 文件记录了与将史诗同步和迁移为工作项相关的信息。
该日志位于：
- 在 Linux 软件包安装中，位于 /var/log/gitlab/gitlab-rails/epic_work_item_sync.log 文件。
- 在自行编译安装中，位于 /home/git/gitlab/log/epic_work_item_sync.log 文件。
- 在 Helm Chart 安装中，位于带有 subcomponent="epic_work_item_sync" 键的 Sidekiq 和 Webservice Pod 中。
secret_push_protection.log
Tier: 旗舰版
Offering: JihuLab.com
版本历史
- 在极狐GitLab 16.7 引入。
secret_push_protection.log 文件记录了与密钥推送保护功能相关的信息。
该日志位于：
- 在 Linux 软件包安装中，位于 /var/log/gitlab/gitlab-rails/secret_push_protection.log 文件。
- 在自行编译安装中，位于 /home/git/gitlab/log/secret_push_protection.log 文件。
- 在 Helm Chart 安装中，位于带有 subcomponent="secret_push_protection" 键的 Webservice Pod 中。
active_context.log
Tier: 专业版，旗舰版
Offering: JihuLab.com，私有化部署
版本历史
- 在极狐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 Chart 安装中，位于带有 subcomponent="activecontext" 键的 Sidekiq Pod 中。
ai_catalog.log
Tier: 专业版，旗舰版
Offering: JihuLab.com，私有化部署
版本历史
- 在极狐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 Chart 安装中，位于带有 subcomponent="ai_catalog" 键的 Sidekiq Pod 中。
user_experience_slis.log
该日志位于：
- 在 Linux 软件包安装中，位于 /var/log/gitlab/gitlab-rails/user_experience_slis.log 文件。
- 在自行编译安装中，位于 /home/git/gitlab/log/user_experience_slis.log 文件。
- 在 Helm Chart 安装中，位于带有 subcomponent="user_experience_slis" 键的 Webservice Pod 中。
它包含了与用户体验 SLI 指标匹配的 JSON 结构化日志。
每一行都包含可以被 Elasticsearch 等服务摄取处理的 JSON。
示例：
json1{ 2 "checkpoint": "start", 3 "component": "gitlab", 4 "correlation_id": "3823a1550b64417f9c9ed8ee0f48087e", 5 "covered_experience": "create_merge_request", 6 "elapsed_time_s": 0, 7 "environment": "gprd", 8 "feature_category": "code_review_workflow", 9 "logtag": "F", 10 "meta": { 11 "caller_id": "Projects::MergeRequests::CreationsController#create", 12 "client_id": "user/123", 13 "feature_category": "code_review_workflow", 14 "gl_user_id": 123, 15 "organization_id": 456, 16 "project": "project/path/here", 17 "remote_ip": "x.x.x.x", 18 "root_namespace": "project", 19 "subscription_plan": "ultimate", 20 "user": "a_username" 21 }, 22 "severity": "INFO", 23 "shard": "default", 24 "stage": "cny", 25 "start_time": "2025-10-31 15:21:40 UTC", 26 "subcomponent": "user_experience_slis", 27 "tag": "web-cny-rails.var.log.containers.gitlab-cny-webservice-web-123-abc_gitlab-cny_webservice-4567890.log", 28 "tier": "sv", 29 "time": "2025-10-31T15:21:40.333Z", 30 "type": "web", 31 "urgency": "async_fast", 32 "urgency_threshold_s": 15 33}
可用字段详见用户体验 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 访问日志格式：
plaintext'$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。
例如：
json1{ 2 "level": "info", 3 "msg": "GitLab Pages Daemon", 4 "revision": "52b2899", 5 "time": "2020-04-22T17:53:12Z", 6 "version": "1.17.0" 7} 8{ 9 "level": "info", 10 "msg": "URL: https://gitlab.com/gitlab-org/gitlab-pages", 11 "time": "2020-04-22T17:53:12Z" 12} 13{ 14 "gid": 998, 15 "in-place": false, 16 "level": "info", 17 "msg": "running the daemon as unprivileged user", 18 "time": "2020-04-22T17:53:12Z", 19 "uid": 998 20}
产品使用数据日志
该日志位于：
- 在 Linux 软件包安装中，位于 /var/log/gitlab/gitlab-rails/product_usage_data.log 文件。
- 在自行编译安装中，位于 /home/git/gitlab/log/product_usage_data.log 文件。
- 在 Helm Chart 安装中，位于带有 subcomponent="product_usage_data" 键的 Webservice Pod 中。
它包含通过 Snowplow 追踪的产品使用事件的 JSON 格式日志。文件中的每一行都包含一个独立的 JSON 条目，可以被 Elasticsearch 或 Splunk 等服务摄取处理。为了可读性，示例中添加了换行：
json1{ 2 "severity":"INFO", 3 "time":"2025-04-09T13:43:40.254Z", 4 "message":"sending event", 5 "payload":"{ 6 \"e\":\"se\", 7 \"se_ca\":\"projects:merge_requests:diffs\", 8 \"se_ac\":\"i_code_review_user_searches_diff\", 9 \"cx\":\"eyJzY2hlbWEiOiJpZ2x1OmNvbS5zbm93cGxvd2FuYWx5dGljcy5zbm93cGxvdy9jb250ZXh0cy9qc29uc2NoZW1hLzEtMC0xIiwiZGF0YSI6W3sic2NoZW1hIjoiaWdsdTpjb20uZ2l0bGFiL2dpdGxhYl9zdGFuZGFyZC9qc29uc2NoZW1hLzEtMS0xIiwiZGF0YSI6eyJlbnZpcm9ubWVudCI6ImRldmVsb3BtZW50Iiwic291cmNlIjoiZ2l0bGFiLXJhaWxzIiwiY29ycmVsYXRpb25faWQiOiJlNDk2NzNjNWI2MGQ5ODc0M2U4YWI0MjZiMTZmMTkxMiIsInBsYW4iOiJkZWZhdWx0IiwiZXh0cmEiOnt9LCJ1c2VyX2lkIjpudWxsLCJnbG9iYWxfdXNlcl9pZCI6bnVsbCwiaXNfZ2l0bGFiX3RlYW1fbWVtYmVyIjpudWxsLCJuYW1lc3BhY2VfaWQiOjMxLCJwcm9qZWN0X2lkIjo2LCJmZWF0dXJlX2VuYWJsZWRfYnlfbmFtZXNwYWNlX2lkcyI6bnVsbCwicmVhbG0iOiJzZWxmLW1hbmFnZWQiLCJpbnN0YW5jZV9pZCI6IjJkMDg1NzBkLWNmZGItNDFmMy1iODllLWM3MTM5YmFjZTI3NSIsImhvc3RfbmFtZSI6ImpsYXJzZW4tLTIwMjIxMjE0LVBWWTY5IiwiaW5zdGFuY2VfdmVyc2lvbiI6IjE3LjExLjAiLCJjb250ZXh0X2dlbmVyYXRlZF9hdCI6IjIwMjUtMDQtMDkgMTM6NDM6NDAgVVRDIn19LHsic2NoZW1hIjoiaWdsdTpjb20uZ2l0bGFiL2dpdGxhYl9zZXJ2aWNlX3BpbmcvanNvbnNjaGVtYS8xLTAtMSIsImRhdGEiOnsiZGF0YV9zb3VyY2UiOiJyZWRpc19obGwiLCJldmVudF9uYW1lIjoiaV9jb2RlX3Jldmlld191c2VyX3NlYXJjaGVzX2RpZmYifX1dfQ==\", 10 \"p\":\"srv\", 11 \"dtm\":\"1744206220253\", 12 \"tna\":\"gl\", 13 \"tv\":\"rb-0.8.0\", 14 \"eid\":\"4f067989-d10d-40b0-9312-ad9d7355be7f\" 15}
要检查这些日志，你可以使用 Rake 任务 product_usage_data:format，它会格式化 JSON 输出并解码 base64 编码的上下文数据以提高可读性：
shellgitlab-rake "product_usage_data:format[log/product_usage_data.log]" # 或者直接管道传输日志 cat log/product_usage_data.log | gitlab-rake product_usage_data:format # 或者实时跟踪日志 tail -f log/product_usage_data.log | gitlab-rake product_usage_data:format
你可以通过将 GITLAB_DISABLE_PRODUCT_USAGE_EVENT_LOGGING 环境变量设置为任意值来禁用此日志。
Let's Encrypt 日志
对于 Linux 软件包安装，Let's Encrypt 自动续订日志位于 /var/log/gitlab/lets-encrypt/。
Mattermost 日志
对于 Linux 软件包安装，Mattermost 日志位于以下位置：
- /var/log/gitlab/mattermost/mattermost.log
- /var/log/gitlab/mattermost/current
Workhorse 日志
对于 Linux 软件包安装，Workhorse 日志位于 /var/log/gitlab/gitlab-workhorse/current。
Patroni 日志
对于 Linux 软件包安装，Patroni 日志位于 /var/log/gitlab/patroni/current。
PgBouncer 日志
对于 Linux 软件包安装，PgBouncer 日志位于 /var/log/gitlab/pgbouncer/current。
PostgreSQL 日志
对于 Linux 软件包安装，PostgreSQL 日志位于 /var/log/gitlab/postgresql/current。
如果使用了 Patroni，PostgreSQL 日志将改为存储在 Patroni 日志中。
Prometheus 日志
对于 Linux 软件包安装，Prometheus 日志位于 /var/log/gitlab/prometheus/current。
Redis 日志
对于 Linux 软件包安装，Redis 日志位于 /var/log/gitlab/redis/current。
Sentinel 日志
对于 Linux 软件包安装，Sentinel 日志位于 /var/log/gitlab/sentinel/current。
Alertmanager 日志
对于 Linux 软件包安装，Alertmanager 日志位于 /var/log/gitlab/alertmanager/current。
Consul 日志
对于 Linux 软件包安装，Consul 日志位于 /var/log/gitlab/consul/current。
crond 日志
对于 Linux 软件包安装，crond 日志位于 /var/log/gitlab/crond/。
Grafana 日志
对于 Linux 软件包安装，Grafana 日志位于 /var/log/gitlab/grafana/current。
LogRotate 日志
对于 Linux 软件包安装，logrotate 日志位于 /var/log/gitlab/logrotate/current。
GitLab Monitor 日志
对于 Linux 软件包安装，GitLab Monitor 日志位于 /var/log/gitlab/gitlab-monitor/。
GitLab Exporter 日志
对于 Linux 软件包安装，GitLab Exporter 日志位于 /var/log/gitlab/gitlab-exporter/current。
极狐GitLab Kubernetes 代理服务器日志
对于 Linux 软件包安装，极狐GitLab Kubernetes 代理服务器日志位于 /var/log/gitlab/gitlab-kas/current。
Praefect 日志
对于 Linux 软件包安装，Praefect 日志位于 /var/log/gitlab/praefect/。
极狐GitLab 还会追踪 Gitaly 集群（Praefect）的 Prometheus 指标。
备份日志
对于 Linux 软件包安装，备份日志位于 /var/log/gitlab/gitlab-rails/backup_json.log。
在 Helm Chart 安装中，备份日志存储在 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 Chart 安装中，位于带有 subcomponent="performance_bar_json" 键的 Sidekiq Pod 中。
性能栏统计信息（目前仅包含 SQL 查询的持续时间）会记录在此文件中。例如：
json{"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"}
这些统计信息仅在极狐GitLab.com 上记录，在私有化部署环境中是禁用的。
收集日志
在故障排除那些无法归因于前面列出的某个组件的问题时，最好同时从极狐GitLab 实例中收集多个日志和统计信息。
简要追踪主日志
如果错误或缺陷容易复现，请在复现问题几次的同时将主要极狐GitLab 日志保存到文件：
shellsudo gitlab-ctl tail | tee /tmp/<case-ID-and-keywords>.log
使用 Control + C 结束日志收集。
收集 SOS 日志
如果出现性能降级或级联错误，且无法轻易归因于前面列出的某个极狐GitLab 组件，请使用我们的 SOS 脚本。
Fast-stats
Fast-stats 是一款用于从极狐GitLab 日志中创建和比较性能统计信息的工具。 有关更多详情和运行说明，请阅读 fast-stats 文档。
使用关联 ID 查找相关日志条目
大多数请求都有一个日志 ID，可用于查找相关日志条目。