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
    • どういった内容の操作をされたか(どのボタンを押したか、どのリンクをクリックしたか、など)

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

  • 個人情報
  • 企業秘密

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

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