Linux のシステムログ

rsyslogd と journald の連携

• Unix/Linux のシステムログは、伝統的に syslog デーモンが管理
• Linux 上で動くサービスやアプリケーションは、一般に syslog 関数（syslog ライブラリコール）を用いてログを出力

CentOS の最新バージョン CentOS 7 では、journald, rsyslogd が連携してログを管理する。

journald

• プロセスと rsyslogd の間に入り、ログデータベースにメッセージ（ログ）を保存する。
• ログメッセージと合わせてサービスの種類やその他独自の追加情報を記録するため、システム管理者が journalctl コマンドを使って特定サービスのログを検索できる。
• journald が受け取るメッセージは以下の2つ。
  • syslog メッセージ
  • 標準出力/標準エラー出力 (stdout/stderr)
• syslog メッセージについては、rsyslogd にも転送される。
• ログデータベースには stdout/stderr も保存されるため、これらも journalctl で検索できる。

rsyslogd

• journald から転送されたメッセージを /etc/rsyslog.conf に従って各種ログファイルに記録する。
• 以前はコイツが直接ログを受け取っていた。

journald のログ活用

# less コマンド実行時と同じようにデータベース内のログを表示
$ journalctl
# データベース内のログをすべて表示
$ journalctl --no-pager
# 特定プロセスのログのみを表示
$ journalctl -u sshd.service
# less -f のようにリアルタイムに更新の様子を見る
$ journalctl -f -u sshd.service
# journald が追加したメタデータも含めて JSON 形式で表示
$ journalctl -u sshd.service -o json-pretty

ログデータベースの永続保存

デフォルトでは、ログデータベースの内容は /var/run/log/journal 以下（一時ファイルを保存する RAM ディスク領域）にある。

→ OS の再起動で消える

ログを永続保存するためには、前準備として /var/log/journal ディレクトリを作成して OS を再起動しておく。このディレクトリが存在する場合、journald はこちらにログデータベースを作成して永続保存を行う。 ただし、

1. データベースのサイズがファイルシステムの10%以上になる
2. ファイルシステムの空き容量が15%を下回る

これらの閾値は /etc/systemd/journald.conf で変更可能。

rsyslogd の仕組み

以下は Linux の主なシステムログファイル。

ログファイル	内容
/var/log/message	システム関連ログのデフォルトの出力ファイル
/var/log/secure	ユーザのログイン認証など、セキュリティ関連情報
/var/log/cron	cron ジョブの実行履歴
/var/log/dmesg	システム起動直後のカーネルログバッファの内容を記録
/var/log/wtmp	ユーザのログイン履歴を記録するバイナリファイル。last コマンドで参照
/var/log/lastlog	ユーザの最終ログイン履歴を保管するバイナリファイル。lastlog コマンドで参照
/var/log/utmp	ログイン中のユーザ情報を保管するバイナリファイル。uptime コマンドや w コマンドで参照

rsyslogd が出力するログファイルは最初の3つで、メッセージの Facility（種類）と Priority（緊急度）に応じて出力先が決まる。これらは、syslog 関数のオプションで指定される。

以下は rsyslog.conf の書式。

...

#### RULES ####

# Log all kernel messages to the console.
# Logging much else clutters up the screen.
#kern.*                                                 /dev/console

# Log anything (except mail) of level info or higher.
# Don't log private authentication messages!
*.info;mail.none;authpriv.none;cron.none                /var/log/messages

# The authpriv file has restricted access.
authpriv.*                                              /var/log/secure

# Log all the mail messages in one place.
mail.*                                                  -/var/log/maillog


# Log cron stuff
cron.*                                                  /var/log/cron

# Everybody gets emergency messages
*.emerg                                                 *

# Save news errors of level crit and higher in a special file.
uucp,news.crit                                          /var/log/spooler

# Save boot messages also to boot.log
local7.*                                                /var/log/boot.log

...

Web サーバのログ設定

はじめに

Web サーバが出力するログは主に2種類

• アクセスログ
  • クライアントから HTTP リクエストを受け取った時
• エラーログ
  • リクエスト処理中にエラーが発生した時

Apache HTTPD のログ

Apache は柔軟なロギング機能を備え、syslog を経由せず独自機構でログを出力する。

→ フォーマットや出力方法を自由に設定可能（httpd.conf）

（以下略）

マーケティングにも使えるログ設計とは

例として、ウェブアプリケーションを想定する。

どのようなログを残すべきか

基本は “5W1H”

• When
• Where
  • Web サービスの場合、URL がベース。エラーログを出す場合は発生位置（スタックトレース）が出ていると良い。
• Who
  • ユーザ ID, IP アドレス, セッション ID など。
• What
  • どんな情報が処理（送信）されたか。
• Why
  • エラーログにおいては、エラーの発生原因を。
• How
  • どういった内容の操作をされたか（どのボタンを押したか、どのリンクをクリックしたか、など）

ログに残してはいけない情報

• 個人情報
• 企業秘密

そのほか決めておいて方が良いこと

• 日付・時刻の形式
  • 使用言語やソフトウェアによってフォーマットが違うので、見やすいようにできるだけ統一を
• 文字コード
  • 他システムと連携する際に問題になることも…
• ログ保管場所
  • できるだけ同じディレクトリ下で管理できるように。
• ログファイルの種類
  • ログの用途によって出力ファイルを分ける。アクセスログ・バッチログ・スローログ・エラーログなど。
• ローテート間隔
  • ログの量に応じて適切な間隔でローテート。ローテート後は圧縮を忘れない（ただし、ファイルが大きすぎると圧縮処理が重くなってパフォーマンスに影響するので注意）。
• 保存期間
  • ディスク圧迫の危険を回避
• ログフォーマット
  • 自由記述となるメッセージフィールドの仕様はあらかじめ決めておいたほうが良い。
• サーバ配置によるログ出力制限
  • 外部に繋がっている（サービス提供用の）サーバは、ファイアウォール内部のサーバに比べてリスクが高い。サーバがいる環境に応じて出力するログレベルを制限。
• 運用担当者との認識合わせ
  • 「このタイミングでこんなログを出して欲しい」という運用側の要望を知っておく。