ログシステム
- プラン: Free、Premium、Ultimate
- 提供形態: GitLab Self-Managed
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 |
ログローテーション
特定のサービスのログは、次のいずれかによって管理およびローテーションされる場合があります:
logrotatesvlogd(runitのサービスログの生成デーモン)logrotateおよびsvlogd- または、いずれにも管理されない
次の表は、各サービスのログの管理およびローテーションを担当する仕組みに関する情報を示しています。svlogdによって管理されるログは、currentというファイルに書き込まれます。GitLabに組み込まれているlogrotateサービスは、runitによってキャプチャされるログを除く、すべてのログを管理します。
| ログタイプ | logrotateによる管理 | svlogd/runitによる管理 |
|---|---|---|
| Alertmanagerのログ | いいえ | はい |
| crondのログ | いいえ | はい |
| Gitaly | はい | はい |
| LinuxパッケージインストールのGitLab Exporter | いいえ | はい |
| GitLab Pagesのログ | はい | はい |
| GitLab Rails | はい | いいえ |
| GitLab Shellのログ | はい | いいえ |
| Grafanaのログ | いいえ | はい |
| LogRotateのログ | いいえ | はい |
| Mailroom | はい | はい |
| NGINX | はい | はい |
| Patroniのログ | いいえ | はい |
| PgBouncerのログ | いいえ | はい |
| PostgreSQLのログ | いいえ | はい |
| Praefectのログ | はい | はい |
| Prometheusのログ | いいえ | はい |
| Puma | はい | はい |
| Redisのログ | いいえ | はい |
| レジストリのログ | いいえ | はい |
| Sentinelのログ | いいえ | はい |
| Workhorseのログ | はい | はい |
Helmインストールでのログへのアクセス
Helmでインストールした場合では、GitLabコンポーネントはstdoutにログを送信します。これは、kubectl logsを使用してアクセスできます。ログは、ポッドのライフタイムの間、/var/log/gitlabのポッドでも利用できます。
構造化されたログを持つポッド(サブコンポーネントのフィルタリング)
一部のポッドには、特定のログタイプを識別する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>")'以下のログセクションでは、該当する場合に適切なポッドとサブコンポーネントキーを示します。
その他のポッド
サブコンポーネントを含む構造化されたログを使用しない他のGitLabコンポーネントについては、ログに直接アクセスできます。
利用可能なポッドセレクターを見つけるには、次を実行します:
# 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 cheat sheet(Kubernetesのチートシート)を参照してください。
production_json.log
このログは次の場所にあります:
- Linuxパッケージインストールでは、
/var/log/gitlab/gitlab-rails/production_json.logファイルにあります。 - セルフコンパイルインストールでは、
/home/git/gitlab/log/production_json.logファイルにあります。 - Helmインストールでは、Webサービスのポッドの
subcomponent="production_json"キーの下にあります。
このファイルには、GitLabから受信したRailsコントローラーリクエストの構造化ログが含まれています。この構造化にはLogrageが使用されています。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_call_duration_sもログに記録され、それぞれの意味は次のとおりです:
elasticsearch_calls: Elasticsearchへの呼び出しの総数elasticsearch_duration_s: Elasticsearchの呼び出しにかかった総時間elasticsearch_timed_out_count: タイムアウトにより部分的な結果しか返されなかったElasticsearchへの呼び出しの総数
ActionCableの接続イベントとサブスクリプションイベントもこのファイルに記録され、前述の形式に従います。method、path、formatの各フィールドは該当せず、常に空になります。controllerとして、ActionCableの接続またはチャンネルクラスが使用されます。
{
"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
}エラーが発生した場合、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 #<Admin::DashboardController:0x00007ff3c9648588>",
"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からの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インストールでは、Webサービスのポッドの
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: リクエスタのユーザーエージェント
Grape Logging v1.8.4以降、view_duration_sはduration_s - db_duration_sによって算出されます。したがって、view_duration_sは、シリアライズプロセスだけでなく、Redisでの読み書きプロセスや外部HTTPなど、複数の異なる要因の影響を受ける可能性があります。
application.log(非推奨)
このログは次の場所にあります:
- 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 removedapplication_json.log
このログは次の場所にあります:
- Linuxパッケージインストールでは、
/var/log/gitlab/gitlab-rails/application_json.logファイルにあります。 - セルフコンパイルインストールでは、
/home/git/gitlab/log/application_json.logファイルにあります。 - Helmインストールでは、SidekiqとWebサービスのポッドの
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とWebサービスのポッドの
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(非推奨)
このログは次の場所にあります:
- Linuxパッケージインストールでは、
/var/log/gitlab/gitlab-rails/kubernetes.logファイルにあります。 - セルフコンパイルインストールでは、
/home/git/gitlab/log/kubernetes.logファイルにあります。 - Helmインストールでは、Sidekiqのポッドの
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のポッドの
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
- プラン: Free、Premium、Ultimate
- 提供形態: GitLab Self-Managed、GitLab Dedicated
GitLab Freeでは、数種類の監査イベントのみを追跡します。GitLab Premiumでは、さらに多くの監査イベントを追跡します。
このログは次の場所にあります:
- Linuxパッケージインストールでは、
/var/log/gitlab/gitlab-rails/audit_json.logファイルにあります。 - セルフコンパイルインストールでは、
/home/git/gitlab/log/audit_json.logファイルにあります。 - Helmインストールでは、SidekiqとWebサービスのポッドの
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は、時間がかかる可能性のあるタスクを処理するためにバックグラウンドジョブを使用します。このファイルは、これらのジョブの処理に関するすべての情報が記録されます。次に例を示します:
{
"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: textsidekiq_client.log
このログは次の場所にあります:
- Linuxパッケージインストールでは、
/var/log/gitlab/gitlab-rails/sidekiq_client.logファイルにあります。 - セルフコンパイルインストールでは、
/home/git/gitlab/log/sidekiq_client.logファイルにあります。 - Helmインストールでは、Webサービスのポッドの
subcomponent="sidekiq_client"キーの下にあります。
このファイルには、Sidekiqがジョブの処理を開始する前、たとえばキューに投入される前など、ジョブに関するログ情報が含まれています。
このログファイルはsidekiq.logと同じ構造になっており、前述したようにSidekiqに対してJSON形式を使用するよう設定している場合は、JSON形式で構造化されています。
gitlab-shell.log
GitLab Shellは、Gitコマンドの実行やGitリポジトリへのSSHアクセスを提供するためにGitLabが使用します。
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パッケージのドキュメントに記載されています。ログファイルはローテーションされ、UNIXタイムスタンプ形式で名前が変更されたうえでgzip圧縮されます(例: @1584057562.s)。
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インストールでは、Sidekiqのポッドの
subcomponent="importer"キーの下にあります。
このファイルには、プロジェクトのインポートと移行の進捗状況が記録されます。
exporter.log
このログは次の場所にあります:
- Linuxパッケージインストールでは、
/var/log/gitlab/gitlab-rails/exporter.logファイルにあります。 - セルフコンパイルインストールでは、
/home/git/gitlab/log/exporter.logファイルにあります。 - Helmインストールでは、SidekiqとWebサービスのポッドの
subcomponent="exporter"キーの下にあります。
このファイルには、エクスポートプロセスの進捗状況が記録されます。
features_json.log
このログは次の場所にあります:
- Linuxパッケージインストールでは、
/var/log/gitlab/gitlab-rails/features_json.logファイルにあります。 - セルフコンパイルインストールでは、
/home/git/gitlab/log/features_json.logファイルにあります。 - Helmインストールでは、SidekiqとWebサービスのポッドの
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とWebサービスのポッドの
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ファイルにあります。
このログには、以下の内容が記録されます:
auth_json.log
このログは次の場所にあります:
- Linuxパッケージインストールでは、
/var/log/gitlab/gitlab-rails/auth_json.logファイルにあります。 - セルフコンパイルインストールでは、
/home/git/gitlab/log/auth_json.logファイルにあります。 - Helmインストールでは、SidekiqとWebサービスのポッドの
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とWebサービスのポッドの
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ファイルにあります。 - Helmインストールでは、SidekiqとWebサービスのポッドの
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のポッドの
subcomponent="web_hooks"キーの下にあります。
このファイルには、Webhookのバックオフ、無効化、再有効化イベントが記録されます。次に例を示します:
{"severity":"INFO","time":"2020-11-24T02:30:59.860Z","hook_id":12,"action":"backoff","disabled_until":"2020-11-24T04:30:59.860Z","recent_failures":2}
{"severity":"INFO","time":"2020-11-24T02:30:59.860Z","hook_id":12,"action":"disable","disabled_until":null,"recent_failures":100}
{"severity":"INFO","time":"2020-11-24T02:30:59.860Z","hook_id":12,"action":"enable","disabled_until":null,"recent_failures":0}再設定ログ
Linuxパッケージインストールの場合、再設定ログファイルは/var/log/gitlab/reconfigureにあります。自己コンパイルインストールの場合、再設定ログはありません。gitlab-ctl reconfigureを手動で実行した場合、またはアップグレードの一部として実行した場合に、再設定ログが記録されます。
再設定ログファイルの名前は、再設定が開始された時点のUNIXタイムスタンプに基づいて付けられます(例: 1509705644.log)。
sidekiq_exporter.logとweb_exporter.log
PrometheusメトリクスとSidekiq Exporterの両方が有効になっている場合、Sidekiqは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
- プラン: Premium、Ultimate
- 提供形態: GitLab Self-Managed
GitLabのデータベースロードバランシングの詳細が含まれています。
このログは次の場所にあります:
- Linuxパッケージインストールでは、
/var/log/gitlab/gitlab-rails/database_load_balancing.logファイルにあります。 - セルフコンパイルインストールでは、
/home/git/gitlab/log/database_load_balancing.logファイルにあります。 - Helmインストールでは、SidekiqとWebサービスのポッドの
subcomponent="database_load_balancing"キーの下にあります。
zoekt.log
- プラン: Premium、Ultimate
- 提供形態: GitLab Self-Managed
このファイルには、完全一致コードの検索に関連する情報が記録されます。
このログは次の場所にあります:
- Linuxパッケージインストールでは、
/var/log/gitlab/gitlab-rails/zoekt.logファイルにあります。 - セルフコンパイルインストールでは、
/home/git/gitlab/log/zoekt.logファイルにあります。 - Helmインストールでは、SidekiqとWebサービスのポッドの
subcomponent="zoekt"キーの下にあります。
elasticsearch.log
- プラン: Premium、Ultimate
- 提供形態: GitLab Self-Managed
このファイルには、Elasticsearchのインデックス作成や検索中のエラーなど、Elasticsearchインテグレーションに関連する情報が記録されます。
このログは次の場所にあります:
- Linuxパッケージインストールでは、
/var/log/gitlab/gitlab-rails/elasticsearch.logファイルにあります。 - セルフコンパイルインストールでは、
/home/git/gitlab/log/elasticsearch.logファイルにあります。 - Helmインストールでは、SidekiqとWebサービスのポッドの
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が追跡している例外に関する情報が記録されます。これにより、捕捉された例外を標準的かつ一貫した方法で処理できるようになります。
このログは次の場所にあります:
- Linuxパッケージインストールでは、
/var/log/gitlab/gitlab-rails/exceptions_json.logファイルにあります。 - セルフコンパイルインストールでは、
/home/git/gitlab/log/exceptions_json.logファイルにあります。 - Helmインストールでは、SidekiqとWebサービスのポッドの
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 #<Gitlab::ImportExport::RelationFactory:0x00007fb5d917c4b0>",
"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とWebサービスのポッドの
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
- プラン: Premium、Ultimate
- 提供形態: GitLab Self-Managed
このログは次の場所にあります:
- Linuxパッケージインストールでは、
/var/log/gitlab/gitlab-rails/geo.logファイルにあります。 - セルフコンパイルインストールでは、
/home/git/gitlab/log/geo.logファイルにあります。 - Helmインストールでは、SidekiqとWebサービスのポッドの
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のポッドの
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
- プラン: Premium、Ultimate
- 提供形態: GitLab.com、GitLab Self-Managed、GitLab Dedicated
llm.logファイルには、AI機能に関連する情報が記録されます。ログには、AIイベントに関する情報が含まれています。
LLMの入力および出力ログの生成
この機能の利用可否は、機能フラグによって制御されます。詳細については、履歴を参照してください。この機能はテストには利用できますが、本番環境での使用には適していません。
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インストールでは、Webサービスのポッドの
subcomponent="llm"キーの下にあります。
epic_work_item_sync.log
- プラン: Premium、Ultimate
- 提供形態: GitLab.com、GitLab Self-Managed、GitLab Dedicated
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とWebサービスのポッドの
subcomponent="epic_work_item_sync"キーの下にあります。
secret_push_protection.log
- プラン: Ultimate
- 提供形態: GitLab.com、GitLab Dedicated
secret_push_protection.logファイルには、シークレットプッシュ保護機能に関連する情報が記録されます。
このログは次の場所にあります:
- Linuxパッケージインストールでは、
/var/log/gitlab/gitlab-rails/secret_push_protection.logファイルにあります。 - セルフコンパイルインストールでは、
/home/git/gitlab/log/secret_push_protection.logファイルにあります。 - Helmインストールでは、Webサービスのポッドの
subcomponent="secret_push_protection"キーの下にあります。
active_context.log
- プラン: Premium、Ultimate
- 提供形態: GitLab.com、GitLab Self-Managed
active_context.logファイルは、ActiveContextレイヤーを介したパイプラインの埋め込みに関する情報をログに記録します。
GitLabは、ActiveContextコードの埋め込みをサポートしています。このパイプラインは、プロジェクトコードファイルの埋め込み生成を処理します。詳細については、アーキテクチャ設計を参照してください。
このログは次の場所にあります:
- Linuxパッケージインストールでは、
/var/log/gitlab/gitlab-rails/active_context.logファイルにあります。 - セルフコンパイルインストールでは、
/home/git/gitlab/log/active_context.logファイルにあります。 - Helmインストールでは、Sidekiqのポッドの
subcomponent="activecontext"キーの下にあります。
user_experience_slis.log
このログは次の場所にあります:
- Linuxパッケージインストールでは、
/var/log/gitlab/gitlab-rails/user_experience_slis.logファイルにあります。 - セルフコンパイルインストールでは、
/home/git/gitlab/log/user_experience_slis.logファイルにあります。 - Helmインストールでは、Webサービスのポッドの
subcomponent="user_experience_slis"キーの下にあります。
これには、ユーザーエクスペリエンスサービスレベル指標とそのメトリクスに一致するJSON構造化ログが含まれています。
各行には、ElasticsearchやSplunkなどのサービスでインジェストできる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
}利用可能なフィールドは、ユーザーエクスペリエンスサービスレベル指標の設計ドキュメントに記載されています。
レジストリのログ
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
}Product Usage Dataのログ
データ品質が正確であることがまだ証明されていないことから、機能の使用状況の分析にはrawログの使用をおすすめしません。
イベントのリストは、新しい機能や既存の機能の変更に基づいて、各バージョンで変更される可能性があります。認定製品内アドプションレポートは、データが分析できる状態になった後で利用可能になります。
このログは次の場所にあります:
- Linuxパッケージインストールでは、
/var/log/gitlab/gitlab-rails/product_usage_data.logファイルにあります。 - セルフコンパイルインストールでは、
/home/git/gitlab/log/product_usage_data.logファイルにあります。 - Helmインストールでは、Webサービスのポッドの
subcomponent="product_usage_data"キーの下にあります。
これには、Snowplowで追跡される製品使用状況イベントのJSON形式のログが含まれています。ファイル内の各行には個別のJSONエントリが含まれており、ElasticsearchやSplunkなどのサービスがインジェストできます。例では、読みやすくするために改行を追加しています:
{
"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にあります。
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 Chartでインストールした場合、バックアップのログはToolboxポッド内の/var/log/gitlab/backup_json.logに保存されます。
このログは、GitLabのバックアップが作成されたときに記録されます。このログを使用して、バックアッププロセスの実行状況を把握できます。
パフォーマンスバーの統計
このログは次の場所にあります:
- Linuxパッケージインストールでは、
/var/log/gitlab/gitlab-rails/performance_bar_json.logファイルにあります。 - セルフコンパイルインストールでは、
/home/git/gitlab/log/performance_bar_json.logファイルにあります。 - Helmインストールでは、Sidekiqのポッドの
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インスタンスから複数のログや統計を同時に収集すると役立ちます。
GitLabサポートはこれらの情報の提供を要求することが多く、そのために必要なツールを用意しています。
メインログを短時間のみ追跡する
バグやエラーを容易に再現できる場合は、問題を数回再現しながら、GitLabのメインログをファイルに保存します:
sudo gitlab-ctl tail | tee /tmp/<case-ID-and-keywords>.logControl + Cでログ収集を終了します。
SOSログの収集
パフォーマンスの低下や、前述のGitLabコンポーネントのいずれに起因するのか容易に特定できない連鎖的なエラーが発生した場合は、SOSスクリプトを使用してください。
fast-stats
fast-statsは、GitLabログからパフォーマンス統計を作成および比較するためのツールです。詳細および実行手順については、fast-statsのドキュメントを参照してください。
相関IDを使用して関連するログエントリを検索する
ほとんどのリクエストには、関連するログエントリの特定に使用できるログIDがあります。