• サーバ上のコンソールでログを出力
  • コンソールでログをテールしてファイルに保存
• デフォルトのログディレクトリの設定
• runit ログ
• Logrotate
  • 一般的なlogrotate設定の構成
  • 個々のサービスの logrotate 設定
  • logrotate の無効化
  • Logrotatenotifempty 設定
  • Logrotate の単発ログと空ログの処理
  • logrotate を手動で実行します。
• UDPログ転送
• カスタムNGINXログフォーマットの使用
• JSON ロギング
• テキストロギング
• rbtrace
• ログレベル/厳しさの設定
• カスタムロググループの設定
  • カスタムロググループの制限

Linux パッケージインストールに関するログ

GitLabには先進的なログシステムがあり、GitLab内の全てのサービスとコンポーネントがシステムログを出力します。Linuxパッケージインストールでこれらのログを管理するための設定とツールを紹介します。

サーバ上のコンソールでログを出力

GitLabのログを’tail’、つまりライブで表示したい場合は、gitlab-ctl tail.

# Tail all logs; press Ctrl-C to exit
sudo gitlab-ctl tail

# Drill down to a sub-directory of /var/log/gitlab
sudo gitlab-ctl tail gitlab-rails

# Drill down to an individual file
sudo gitlab-ctl tail nginx/gitlab_error.log

コンソールでログをテールしてファイルに保存

ログをコンソールに表示し、後でデバッグや分析をするためにファイルに保存しておくと便利なことがよくあります。このためにはtee ユーティリティを使います。

# Use 'tee' to tail all the logs to STDOUT and write to a file at the same time
sudo gitlab-ctl tail | tee --append /tmp/gitlab_tail.log

デフォルトのログディレクトリの設定

/etc/gitlab/gitlab.rb ファイルには、様々なタイプのログ用のlog_directory キーがたくさんあります。他の場所に置きたいすべてのログの値をアンコメントして更新してください：

# For example:
gitlab_rails['log_directory'] = "/var/log/gitlab/gitlab-rails"
puma['log_directory'] = "/var/log/gitlab/puma"
registry['log_directory'] = "/var/log/gitlab/registry"
...

Gitaly と Mattermost ではログディレクトリの設定が異なります：

gitaly['configuration']['logging']['dir'] = "/var/log/gitlab/registry"
mattermost['log_file_directory'] = "/var/log/gitlab/registry"

sudo gitlab-ctl reconfigure を実行して、これらの設定でインスタンスを構成してください。

runit ログ

Linux のパッケージインストールでrunit が管理するサービスはsvlogd を使ってログデータを生成します。

• ログはcurrent というファイルに書き込まれます。
• このログは定期的に圧縮され、TAI64Nフォーマットでリネームされます（例：@400000005f8eaf6f1a80ef5c.s ）。
• 圧縮されたログのファイルシステムの日付スタンプは、GitLabがそのファイルに最後に書き込んだ時刻と一致します。
• zmore とzgrep 、圧縮・非圧縮両方のログを閲覧・検索することができます。

svlogdが生成するファイルの詳細については、svlogd のドキュメントを読んでください。

svlogdの設定は、/etc/gitlab/gitlab.rb 、以下の設定で変更できます：

# Below are the default values
logging['svlogd_size'] = 200 * 1024 * 1024 # rotate after 200 MB of log data
logging['svlogd_num'] = 30 # keep 30 rotated log files
logging['svlogd_timeout'] = 24 * 60 * 60 # rotate after 24 hours
logging['svlogd_filter'] = "gzip" # compress logs with gzip
logging['svlogd_udp'] = nil # transmit log messages via UDP
logging['svlogd_prefix'] = nil # custom prefix for log messages

# Optionally, you can override the prefix for e.g. Nginx
nginx['svlogd_prefix'] = "nginx"

Logrotate

GitLabに組み込まれているlogrotateサービスは、runitによってキャプチャされたログ以外のすべてのログを管理します。このサービスはgitlab-rails/production.log やnginx/gitlab_access.logのようなログデータを回転、圧縮、そして最終的には削除します。共通の logrotate 設定、サービスごとの logrotate 設定、そして/etc/gitlab/gitlab.rbを使って logrotate を完全に無効にすることができます。

一般的なlogrotate設定の構成

全てのlogrotateサービスに共通する設定は、/etc/gitlab/gitlab.rb 。これらの設定は、各サービスのlogrotate設定ファイルの設定オプションに対応しています。詳細はlogrotateのマニュアルページ(man logrotate)を参照してください。

logging['logrotate_frequency'] = "daily" # rotate logs daily
logging['logrotate_maxsize'] = nil # logs will be rotated when they grow bigger than size specified for `maxsize`, even before the specified time interval (daily, weekly, monthly, or yearly)
logging['logrotate_size'] = nil # do not rotate by size by default
logging['logrotate_rotate'] = 30 # keep 30 rotated logs
logging['logrotate_compress'] = "compress" # see 'man logrotate'
logging['logrotate_method'] = "copytruncate" # see 'man logrotate'
logging['logrotate_postrotate'] = nil # no postrotate command by default
logging['logrotate_dateformat'] = nil # use date extensions for rotated files rather than numbers e.g. a value of "-%Y-%m-%d" would give rotated files like production.log-2016-03-09.gz

個々のサービスの logrotate 設定

/etc/gitlab/gitlab.rb を使用して、個々のサービスの logrotate 設定をカスタマイズできます。例えば、nginx サービスの logrotate の頻度とサイズをカスタマイズするには、次のようにします：

nginx['logrotate_frequency'] = nil
nginx['logrotate_size'] = "200M"

logrotate の無効化

/etc/gitlab/gitlab.rb の以下の設定で、内蔵のlogrotateサービスを無効にすることもできます：

logrotate['enable'] = false

Logrotatenotifempty 設定

GitLab 13.6以降、logrotateサービスは設定不可能なデフォルトnotifempty、以下のイシューを解決して実行されます：

• 空のログが不必要にローテーションされ、多くの空のログが保存されます。
• データベースのマイグレーションログなど、長期的なトラブルシューティングに役立つ単発のログが30日後に削除されること。

Logrotate の単発ログと空ログの処理

ログは必要に応じてlogrotateによってローテート、再作成され、単発のログは変更時のみローテートされるようになりました。この設定により、いくつかの整理ができます：

• gitlab-rails/gitlab-rails-db-migrate*.log のような空の単発ログは削除できます。
• 古いバージョンのGitLabでローテーションされ圧縮された空のログ。これらの空のログのサイズは通常20バイトです。

logrotate を手動で実行します。

Logrotateはスケジュールされたジョブですが、オンデマンドで実行することもできます。

手動でGitLabのログローテーションをlogrotate 、次のコマンドを使います：

/opt/gitlab/embedded/sbin/logrotate -fv -s /var/opt/gitlab/logrotate/logrotate.status /var/opt/gitlab/logrotate/logrotate.conf

UDPログ転送

Linux パッケージインストールは、svlogd の UDP ログ機能を利用し、svlogd 以外のログを UDP を使用して syslog 互換のリモートシステムに送信することができます。syslog プロトコルメッセージを UDP 経由で送信するように Linux パッケージインストールを設定するには、以下の設定を使用します：

logging['udp_log_shipping_host'] = '1.2.3.4' # Your syslog server
# logging['udp_log_shipping_hostname'] = nil # Optional, defaults the system hostname
logging['udp_log_shipping_port'] = 1514 # Optional, defaults to 514 (syslog)

ログメッセージの例

Jun 26 06:33:46 ubuntu1204-test production.log: Started GET "/root/my-project/import" for 127.0.0.1 at 2014-06-26 06:33:46 -0700
Jun 26 06:33:46 ubuntu1204-test production.log: Processing by ProjectsController#import as HTML
Jun 26 06:33:46 ubuntu1204-test production.log: Parameters: {"id"=>"root/my-project"}
Jun 26 06:33:46 ubuntu1204-test production.log: Completed 200 OK in 122ms (Views: 71.9ms | ActiveRecord: 12.2ms)
Jun 26 06:33:46 ubuntu1204-test gitlab_access.log: 172.16.228.1 - - [26/Jun/2014:06:33:46 -0700] "GET /root/my-project/import HTTP/1.1" 200 5775 "https://172.16.228.169/root/my-project/import" "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_9_3) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/35.0.1916.153 Safari/537.36"
2014-06-26_13:33:46.49866 ubuntu1204-test sidekiq: 2014-06-26T13:33:46Z 18107 TID-7nbj0 Sidekiq::Extensions::DelayedMailer JID-bbfb118dd1db20f6c39f5b50 INFO: start
2014-06-26_13:33:46.52608 ubuntu1204-test sidekiq: 2014-06-26T13:33:46Z 18107 TID-7muoc RepositoryImportWorker JID-57ee926c3655fcfa062338ae INFO: start

カスタムNGINXログフォーマットの使用

デフォルトでは、NGINXアクセスログは、クエリ文字列に埋め込まれた潜在的に機密性の高い情報を隠すように設計された「結合」NGINXフォーマットのバージョンを使用します。カスタムのログ書式文字列を使用したい場合は、/etc/gitlab/gitlab.rb で指定することができます。書式の詳細についてはNGINX のドキュメントを参照してください。

nginx['log_format'] = 'my format string $foo $bar'
mattermost_nginx['log_format'] = 'my format string $foo $bar'

JSON ロギング

構造化されたログを JSON でエクスポートし、Elasticsearch や Splunk、その他のログ管理システムで解析することができます。JSON フォーマットは、それをサポートするすべてのサービスでデフォルトで有効になっています。

postgresql['log_destination'] = 'csvlog'
postgresql['logging_collector'] = 'on'

これを有効にするにはデータベースの再起動が必要です。詳細についてはPostgreSQLのドキュメントを参照してください。

テキストロギング

確立されたログ取り込みシステムを持つお客様は、JSONログフォーマットを使用したくないかもしれません。テキストフォーマットは、/etc/gitlab/gitlab.rb で以下を設定し、gitlab-ctl reconfigure を実行することで設定できます：

gitaly['logging_format'] = ''
gitlab_shell['log_format'] = 'text'
gitlab_workhorse['log_format'] = 'text'
registry['log_formatter'] = 'text'
sidekiq['log_format'] = 'text'
gitlab_pages['log_format'] = 'text'

rbtrace

GitLab にはrbtrace が同梱されており、Ruby コードのトレースや実行中のスレッドの表示、メモリダンプなどができます。しかし、これはデフォルトでは有効になっていません。有効にするには、ENABLE_RBTRACE 環境変数を定義します：

gitlab_rails['env'] = {"ENABLE_RBTRACE" => "1"}

その後、システムを再設定し、PumaとSidekiqを再起動します。Linuxパッケージインストールでこれを実行するには、rootとして実行します：

/opt/gitlab/embedded/bin/ruby /opt/gitlab/embedded/bin/rbtrace

ログレベル/厳しさの設定

コンテナレジストリ、GitLab Shell、Gitalyの最小ログレベル(verbosity)を設定することができます：

1. /etc/gitlab/gitlab.rb を編集し、ログレベルを設定します：

   registry['log_level'] = 'info'
   gitlab_shell['log_level'] = 'INFO'
   gitaly['logging_level'] = 'warn'
   

2. GitLab を再設定します：

   sudo gitlab-ctl reconfigure
   

カスタムロググループの設定

GitLabは設定されたログディレクトリにカスタムグループを割り当てることをサポートしています。

/etc/gitlab/gitlab.rb ファイル内のグローバルなlogging['log_group'] 設定と、gitaly['log_group']のようなサービスごとのlog_group 設定を設定することができます。log_group 設定を追加する際には、インスタンスを設定するためにsudo gitlab-ctl reconfigure を実行する必要があります。

グローバルまたはサービスごとのlog_group ：

• サービスごとのログディレクトリ（またはグローバル設定を使用する場合はすべてのログディレクトリ）の権限を0750 に変更し、設定されたグループメンバーがログディレクトリの内容を読み取れるようにします。

• 指定されたlog_group ：サービスごとまたはすべてのrunit管理サービスのログを書き込み、ローテーションするようにrunitを設定します。

カスタムロググループの制限

runitによって管理されていないサービスのログ（例えば、/var/log/gitlab/gitlab-rails のgitlab-rails ログ）は、設定されたlog_group の設定を継承しません。

グループはホスト上にすでに存在している必要があります。Linux パッケージのインストールでは、sudo gitlab-ctl reconfigure を実行してもグループは作成されません。