第23章 ログファイルの表示と管理

ログファイルは、システム (カーネル、サービス、および実行中のアプリケーションなど) に関するメッセージが含まれるファイルです。各情報にはそれぞれ異なるログファイルがあります。例えば、デフォルトのシステムログファイル、セキュリティメッセージ専用のログファイル、cron タスク用のログファイルなどです。

ログファイルは、カーネルドライバーのロードを試行するなどシステムの問題を解決する場合や、システムへの無許可のログイン試行を探す場合に役立ちます。本章では、ログファイルの場所、ログファイルの閲覧方法、ログファイルの注意すべき項目を説明します。

一部のログファイルは、rsyslogd という名前のデーモンによって制御されます。rsyslogd デーモンは、sysklogd の拡張版であり、拡張されたフィルタリング、暗号化で保護されたメッセージリレー、様々な設定オプション、入出力モジュール、TCP または UDP プロコトルを介した伝送のサポートを提供します。rsyslogsysklogd は互換性があることに注意してください。

ログファイルは、journald デーモン (systemd のコンポーネント) で管理できます。journald デーモンは全サービスの標準出力および標準エラー出力に書き込まれたメッセージに加えて、Syslog メッセージ、カーネルログメッセージ、初期 RAM ディスクおよび初期起動メッセージを取り込みます。構造化およびインデックス化されたバイナリーファイルであるネイティブジャーナルファイル形式は、検索を改善します。また、より高速に操作を提供するため、タイムスタンプやユーザー ID などのメタデータ情報も格納します。journald が生成するログファイルはデフォルトで永続的ではなく、ログファイルは /run/log/journal/ ディレクトリー内のメモリーまたはリングバッファーにのみ保存されます。ログに記録されるデータの量は、容量制限に達すると、最も古いエントリーが削除されます。ただし、この設定は変更できます。「永続的ストレージの有効化」を参照してください。ジャーナルの詳細情報は、「Journal の使用」 を参照してください。

デフォルトでは、これら 2 つのロギングツールはシステム上で共存しています。journald デーモンは、トラブルシューティング用の主要ツールです。また、構造化ログメッセージの作成に必要な追加データも提供します。journald で取得したデータは /run/systemd/journal/syslog ソケットに転送され、データをさらに処理するために rsyslogd で使用できます。ただし、rsyslogimjournal 入力モジュールを介して実際の統合を行うため、上記のソケットを回避します。omjournal モジュールを使用して、逆方向で rsyslogd から journald にデータを転送することもできます。詳細は「Rsyslog と Journal の相互作用」を参照してください。統合によりテキストベースのログを一貫性のある形式で保持できることになり、rsyslogd に依存するアプリケーションや設定との互換性を確保できます。また、構造化形式で rsyslog メッセージを保持することもできます (「Rsyslog での構造化ロギング」 を参照)。

23.1. ログファイルの場所の特定

rsyslogd で保持されるログファイルの一覧は、/etc/rsyslog.conf 設定ファイルにあります。ほとんどのログファイルは /var/log/ ディレクトリーにあります。httpdsamba などの一部のアプリケーションには、ログファイル用に /var/log/ 内にディレクトリーがあります。

/var/log/ ディレクトリー内には末尾に番号が付いた複数のファイル (例: cron-20100906) があることに気付くかもしれません。これらの番号はローテーションを行ったログファイルに追加されたタイムスタンプを表します。ログファイルは、ファイルサイズが大きくなり過ぎないようにローテーションが行われます。logrotate パッケージには cron タスクが含まれており、設定ファイルと /etc/logrotate.d/ ディレクトリー内の /etc/logrotate.conf 設定ファイルに従って自動的にログファイルをローテーションします。

23.2. Rsyslog の基本設定

rsyslog の主な設定ファイルは /etc/rsyslog.conf です。このファイルでは、グローバルディレクティブモジュール、および フィルターアクション の部分で構成される ルール を指定できます。また、ハッシュ記号 (#) の後にテキスト形式でコメントを追加することもできます。

23.2.1. フィルター

ルールは、syslog メッセージのサブセットを選択する フィルターの部分と、選択したメッセージで何をするかを指定する アクションの部分で指定されます。/etc/rsyslog.conf 設定ファイル内でルールを定義するには、フィルターとアクションの両方を同じ行に、1 つ以上の空白かタブで区切って定義します。

rsyslog は、選択されたプロパティーに従って syslog メッセージをフィルターする様々な方法を提供します。利用可能なフィルタリングの方法は、Facility/Priority ベースProperty ベースExpression ベース の 3 種類のフィルターに分けられます。

Facility (ファシリティー) /Priority (優先度) ベースのフィルター

syslog メッセージをフィルターする最もよく知られた方法は、syslog メッセージをフィルターするファシリティー/priority ベースのフィルターを使用して、2 つの条件 (ファシリティー および 優先度をドットで区切る) を使用することです。セレクターを作成するには以下の構文を使用します。

FACILITY.PRIORITY

詳細は以下のようになります。

  • FACILITY は、特定の syslog メッセージを作成するサブシステムを指定します。たとえば、mail サブシステムはメール関連のすべての syslog メッセージを処理します。FACILY は、以下のキーワード (または数字コード) のいずれかで表すことができます。kern (0)、user (1)、mail (2)、daemon (3) auth (4)、syslog (5)、lpr (6)、news (7)、cron (8) authpriv (9)、ftp (10)、および local0 から local7 (16 - 23) まで。
  • PRIORITY は、syslog メッセージの優先度を指定します。priority は、以下のキーワード (または数字) のいずれかで表示できます。debug (7)、info (6)、notice (5)、warning (4)、 err (3)、crit (2)、alert (1)、および emerg (0)。

    上記の構文は、定義された優先度もしくは より高い 優先度で syslog メッセージを選択します。いずれかの優先度のキーワード前に等号 (=) を付けると、指定された優先度の syslog メッセージのみ選択されることが指定されます。他のすべての優先度は無視されます。反対に、感嘆符 (!) を優先度のキーワードの前に付けると、この優先度以外のすべての syslog メッセージが選択されます。

    上記で指定されているキーワード以外に、アスタリスク (*) を使用してすべてのファシリティーもしくは優先度を定義することもできます (アスタリスクをコンマの前か後に配置するかによる)。優先度キーワード none を指定すると、優先度のないファシリティーを指定することになります。ファシリティーおよび優先度の条件は、どちらも大文字と小文字を区別しません。

    定義するファシリティーや優先度が複数になる場合は、コンマ (,) を使用して区切ります。同じ行に複数のセレクターを定義するには、セミコロン (;) を使用して区切ります。セレクターフィールド内の各セレクターは、以前のものを上書きすることに注意してください。これにより、パターンから優先度が除外される可能性があります。

    例23.1 ファシリティー/優先度ベースのフィルター

    以下は、/etc/rsyslog.conf で指定できる単純な facility/priority ベースのフィルターの例です。優先度ですべてのカーネル syslog メッセージを選択するには、設定ファイルに以下のテキストを追加します。

    kern.*

    優先度が crit 以上になるメール syslog メッセージすべてを選択するには、以下の形式を使用します。

    mail.crit

    info または debug 優先度以外のすべての cron syslog メッセージを選択するには、設定ファイルで以下の形式を設定します。

    cron.!info,!debug
プロパティーベースのフィルター

プロパティベースのフィルターでは、timegeneratedsyslogtag などのプロパティーで syslog メッセージのフィルター処理ができます。プロパティーに関する詳細情報は、「プロパティー」 を参照してください。指定された各プロパティーは、表23.1「プロパティベースの比較処理」 で一覧表示されている比較処理のいずれかを使用して特定の値に対して比較できます。プロパティー名と比較処理はどちらも大文字と小文字を区別します。

プロパティーベースのフィルターは、コロン (:) で開始する必要があります。フィルターの定義には、以下の構文を使用します。

:PROPERTY, [!]COMPARE_OPERATION, "STRING"

詳細は以下のようになります。

  • PROPERTY 属性は希望するプロパティーを指定します。
  • オプションの感嘆符 (!) は比較処理の出力を無効にします。他のブール値演算子は現在、プロパティーベースのフィルターではサポートされていません。
  • COMPARE_OPERATION 属性は、表23.1「プロパティベースの比較処理」 に一覧表示してある比較処理のいずれかを指定します。
  • STRING 属性は、プロパティーが提供するテキストの比較対象となる値を指定します。この値は、引用符で囲む必要があります。この文字列内の特定の文字をエスケープさせるには (たとえば、引用符 ("))、バックスラッシュ (\) を使用します。

    表23.1 プロパティベースの比較処理

    比較処理詳細

    contains

    提供された文字列が、プロパティーで提供されたテキストのいずれかの部分に適合するかどうかをチェックします。大文字と小文字を区別しない比較を実行するには、contains_i を使用します。

    isequal

    用意された文字列をプロパティーで提供されたすべてのテキストと比較します。これら 2 つの値が適合するには、完全に等しいものである必要があります。

    startswith

    提供された文字列が、プロパティーで提供されたテキストのちょうど最初にあるかどうかをチェックします。大文字と小文字を区別しない比較を実行するには、startswith_i を使用します。

    regex

    指定された POSIX BRE (Basic Regular Expression) をプロパティーが提供したテキストと比較します。

    ereregex

    指定された POSIX ERE (Extended Regular Expression) 正規表現をプロパティーが提供したテキストと比較します。

    isempty

    プロパティーが空かどうかをチェックします。値は破棄されます。これは、いくつかのフィールドが正規化の結果に基づいて設定される正規化データでの作業時に特に有用です。

    例23.2 プロパティーベースのフィルター

    以下は、/etc/rsyslog.conf で指定できるプロパティーベースのフィルターの例です。syslog メッセージのテキストに文字列 error が含まれているものを選択するには、以下を使用します。

    :msg, contains, "error"

    以下のフィルターは、ホスト名 host1 から受信した syslog メッセージを選択します。

    :hostname, isequal, "host1"

    単語 fatalerror のメンションが含まれておらず、その単語間でテキストなし (例: fatal lib error) が含まれる syslog メッセージを選択するには、以下を入力します。

    :msg, !regex, "fatal .* error"
式ベースのフィルター

式ベースのフィルターは、定義されている算術演算、ブール演算、または文字列演算に従って syslog メッセージを選択します。複雑なフィルターを構築するために、式ベースのフィルターは、RainerScript と呼ばれる rsyslog の独自のスクリプト言語を使用します。

式ベースのフィルターの基本的な構文は、以下のようになります。

if EXPRESSION then ACTION else ACTION

詳細は以下のようになります。

  • EXPRESSION 属性は、$msg startswith 'DEVNAME' または $syslogfacility-text == 'local0' などの評価される式を表します。and および or 演算子を使用することで、単一フィルター内に複数の式を指定できます。
  • ACTION 属性は、式が true の値を返す場合に実行される動作を表します。これは単一のアクションの場合と、波括弧で囲まれた任意の複雑なスクリプトになる場合があります。
  • 式ベースのフィルターは、行の最初の if キーワードで示されます。then キーワードは、EXPRESSIONACTION から離します。オプションで、else キーワードを使用して条件が満たされない場合に実行されるアクションを指定することもできます。

    式ベースのフィルターでは、例23.3「式ベースのフィルター」 にあるように、波括弧に囲まれた式を使うことで条件をネスト化することができます。このスクリプトでは、式内で facility/priority-based フィルターを使用することができます。ただし、ここで property-based フィルターを使用することは推奨されません。RainerScript は、特殊関数 re_match() および re_extract() を含む正規表現をサポートします。

    例23.3 式ベースのフィルター

    以下の式には、ネスト化された条件が 2 つ含まれています。prog1 と呼ばれるプログラムが生成したログファイルが、メッセージ内の文字列 "test" の有無に基づいて 2 つのファイルに分割されます。

    if $programname == 'prog1' then {
      action(type="omfile" file="/var/log/prog1.log")
      if $msg contains 'test' then
       action(type="omfile" file="/var/log/prog1test.log")
      else
       action(type="omfile" file="/var/log/prog1notest.log")
    }

様々な式ベースのフィルターの他の例は、「オンラインドキュメント」 を参照してください。RainerScript は rsyslog の新しい設定形式の基礎となります。「新規設定フォーマットの使用」 を参照してください。

23.2.2. アクション

アクションは、定義済みのセレクターでフィルターされたメッセージで実行すべきことを指定します。以下にルール内で定義できるアクションをいくつか示します。

ログファイルへの syslog メッセージの保存

アクションの大半は、どのログファイルに syslog メッセージを保存するかを指定します。これは定義済みセレクターの後にファイルパスを指定することで行います。

FILTER PATH

ここでの FILTER はユーザーが指定したセレクターを表し、PATH はターゲットファイルのパスを表します。

たとえば、以下のルールは、すべての cron syslog メッセージを選択するセレクターと、それらのメッセージを /var/log/cron.log ログファイルに保存するアクションで構成されています。

cron.* /var/log/cron.log

デフォルトでは、syslog メッセージの生成時に毎回ログファイルは同期されます。同期を省略する場合は、ダッシュ記号 (-) を該当するファイルパスの接頭辞として使います。

FILTER -PATH

書き込みの直後にシステムが終了すると、情報が失われる場合があることに注意してください。ただし、この設定では、特に非常に詳細なログメッセージを生成するプログラムを実行する場合には、パフォーマンスも改善されます。

指定したファイルパスは、static または dynamic のいずれかになります。静的ファイルは、上記の例で示されているように固定ファイルパスで示されます。動的ファイルパスは、受け取ったメッセージによって異なります。動的ファイルパスは、テンプレートと疑問符 (?) の接頭辞で示されます。

FILTER ?DynamicFile

ここでは、DynamicFile は出力パスを修正する定義済みテンプレート名になります。ダッシュ記号 (-) の接頭辞を使うと同期を無効にでき、またコロン (;) 区切りで複数のテンプレートを使用できます。テンプレートに関する詳細は 「動的なファイル名の生成」 を参照してください。

指定したファイルが既存の terminal または /dev/console デバイスである場合、syslog メッセージは標準出力 (特別な terminal 処理を使用) へ送信されるか、X Window システムの使用時には使用中のコンソール (特別な /dev/console 処理を使用) へそれぞれ送信されます。

ネットワークを使った syslog メッセージの送信

rsyslog を使用すると、ネットワークを使用して syslog メッセージを送受信できます。この機能により、1 台のマシンで複数ホストの syslog メッセージを管理できます。syslog メッセージをリモートマシンに転送するには、以下の構文を使用します。

@(zNUMBER)HOST:PORT

詳細は以下のようになります。

  • アットマーク (@) は、syslog メッセージが UDP プロトコルを使用してホストへ転送されることを示します。TCP プロトコルを使用するには、2 つのアットマークを空白なしで (@@) 使用します。
  • オプションの zNUMBER 設定を使用すると、syslog メッセージの zlib 圧縮が可能になります。NUMBER 属性は、圧縮レベルを指定します (最低の 1 から最高の 9 まで)。圧縮が得られたことは rsyslogd が自動的にチェックします。メッセージが圧縮されるのは圧縮が可能になった場合のみで、60 バイト未満のメッセージは圧縮されません。
  • HOST 属性は、選択した syslog メッセージを受信するホストを指定します。
  • PORT 属性は、ホストマシンのポートを指定します。

    IPv6 アドレスをホストとして指定する場合は、アドレスを角括弧 ([, ]) で囲みます。

    例23.4 ネットワークを使用した syslog メッセージの送信

    以下の例は、ネットワーク上で syslog メッセージを転送するアクションです (注記: すべてのアクションの前には、いずれかの優先度を持つすべてのメッセージを選択するセレクターが付いています)。UDP プロトコルから 192.168.0.1 にメッセージを転送するには、以下を入力します。

    . @192.168.0.1

    ポート 6514 と TCP プロトコルを使用してメッセージを "example.com" に転送するには、以下を使用します。

    . @@example.com:6514

    以下ではメッセージを zlib (レベル 9 圧縮) で圧縮し、UDP プロトコルを使用して 2001:db8::1 に転送します。

    . @(z9)[2001:db8::1]
出力チャンネル

出力チャンネルは主にログファイルの最大サイズを指定するために使用されます。これは、ログファイルのローテーションに非常に便利です (詳細はを参照してください 「ログローテーション」)。出力チャンネルは基本的に出力アクションに関する情報を集めたものです。出力チャンネルは $outchannel ディレクティブで定義されます。/etc/rsyslog.conf で出力チャンネルを定義するには、以下の構文を使用します。

$outchannel NAME, FILE_NAME, MAX_SIZE, ACTION

詳細は以下のようになります。

  • NAME 属性は、出力チャンネル名を指定します。
  • FILE_NAME 属性は、出力ファイル名を指定します。出力チャンネルはファイルにのみ書き込み可能で、パイプやターミナル、その他の出力には書き込みできません。
  • MAX_SIZE 属性は、(FILE_NAME 内にある) 指定されたファイルが拡張可能な最大サイズを表します。この値は バイト 単位で指定します。
  • ACTION 属性は、MAX_SIZE で定義された最大サイズに到達した際に取るべきアクションを指定します。

    定義済みの出力チャンネルをルール内のアクションとして使用するには、以下を入力します。

    FILTER :omfile:$NAME

    例23.5 出力チャンネルのログローテーション

    以下の出力は、出力チャンネルを使用した簡単なログローテーションを示しています。まず、出力チャンネルは $outchannel ディレクティブにより定義されます。

     $outchannel log_rotation, /var/log/test_log.log, 104857600, /home/joe/log_rotation_script

    その後に、優先度を持つすべての syslog メッセージを選択し、取得した syslog メッセージ上の事前定義された出力チャンネルを実行するルール内で使用されます。

    . :omfile:$log_rotation

    制限 (この例では 100 MB) に達すると、/home/joe/log_rotation_script が実行されます。このスクリプトには、ファイルを異なるフォルダーに移動することやその中の特別なコンテンツを編集すること、単にそれを削除することなど、様々なタスクを含めることができます。

特定ユーザーへの syslog メッセージの送信
メッセージの送信先となるユーザー名を指定することで、rsyslog は syslog メッセージを送信することができます (例23.7「複数アクションの指定」 で表示)。複数のユーザーを指定するには、各ユーザー名をコンマ (,) で区切ります。現在ログオンしている全ユーザーにメッセージを送るには、アスタリスク (*) を使用します。
プログラムの実行

rsyslog を使用すると、選択した syslog メッセージに対してプログラムを実行でき、system() 呼び出しを使用してシェルでプログラムを実行できます。実行するプログラムを指定するには、そのプログラムの前に キャレット文字 (^) を付けます。その後に、受信したメッセージをフォーマットしてそれを 1 行のパラメーターとして指定した実行ファイルに渡すテンプレートを指定します (テンプレートに関する詳細は 「テンプレート」 を参照)。

FILTER ^EXECUTABLE; TEMPLATE

ここでは、FILTER 条件の出力は EXECUTABLE で表されるプログラムで処理されます。このプログラムは、有効な実行ファイルであればどれでも構いません。TEMPLATE をフォーマットするテンプレートに置き換えます。

例23.6 プログラムの実行

以下の例では、すべての優先度の syslog メッセージが選択され、template テンプレートでフォーマットされた後にパラメーターとして test-program プログラムに渡されます。その後は、提供されているパラメーターで実行されます。

. ^test-program;template
警告

ホストからメッセージを受信して、シェル実行アクションを使用する際には、コマンドインジェクションに対する脆弱性があります。ユーザーが自身のアクションで実行されるように指定しているプログラム内で、攻撃者が別のコマンドの挿入と実行を試みる可能性があります。セキュリティー脅威の可能性を回避するには、シェル実行アクションの使用をよく検討してください。

syslog メッセージのデータベースでの保存

選択された syslog メッセージは、データベースライター の動作を使用して、直接データベーステーブルに書き込むことができます。データベースライターは、以下の構文を使用します。

:PLUGIN:DB_HOST,DB_NAME,DB_USER,DB_PASSWORD;TEMPLATE

詳細は以下のようになります。

  • PLUGIN はデータベースの書き込みを処理する指定プラグインを呼び出します (例えば、ommysql プラグイン)。
  • DB_HOST 属性は、データベースのホスト名を指定します。
  • DB_NAME 属性はデータベースの名前を指定します。
  • DB_USER 属性はデータベースのユーザーを指定します。
  • DB_PASSWORD 属性は上述のデータベースユーザーが使用するパスワードを指定します。
  • TEMPLATE 属性は syslog メッセージを修正するテンプレートのオプション使用を指定します。テンプレートに関する詳細は 「テンプレート」 を参照してください。

    重要

    現在、rsyslog は、MySQL および PostgreSQL データベースにのみ対応しています。MySQL および PostgreSQL のデータベースライター機能を使用するには、rsyslog-mysql および rsyslog-pgsql パッケージをそれぞれインストールします。また、/etc/rsyslog.conf 設定ファイルに適切なモジュールを読み込んでください。

    module(load=”ommysql”)  # Output module for MySQL support
    module(load=”ompgsql”)  # Output module for PostgreSQL support

    rsyslog モジュールの詳細は「Rsyslog モジュールの使用」 を参照してください。

    もしくは、omlibdb モジュールが提供する汎用のデータベースインターフェースを使用することもできます (サポート対象: Firebird/Interbase、MS SQL、Sybase、SQLLite、Ingres、Oracle、mSQL)。

syslog メッセージの破棄

選択したメッセージを破棄する場合は、stop を使用します。

破棄するアクションは、ほとんどの場合、さらに処理をする前にメッセージをフィルタリングするために使用されます。繰り返されるメッセージを省略しなければログファイルがいっぱいになってしまう場合に、これは効果的です。破棄アクションの結果は、指定された設定ファイル内の場所によって異なります。最善の結果を得るためにも、これらのアクションは、アクションリストの上に配置します。一旦破棄したメッセージを、設定ファイルの後の行で回復することはできないことに注意してください。

たとえば、以下のルールを使用すると、local5.* フィルターに一致するメッセージをすべて破棄します。

local5.* stop

以下の例では、cron syslog メッセージがすべて破棄されます。

cron.* stop
注記

rsyslog 7 より前のバージョンでは、syslog メッセージを破棄する際に、~ の代わりにチルダ文字 (stop) が使用されていました。

複数アクションの指定

各セレクターで、複数のアクションを指定できます。1 つのセレクターに複数アクションを指定するには、各アクションを別々の行に書き込んでそれらの先頭にアンパサンド文字 (&) を付けます。

FILTER ACTION
& ACTION
& ACTION

指定されたセレクターが評価されるのは 1 回のみであるため、複数の動作を指定すると、希望する結果の全体的なパフォーマンスが向上します。

例23.7 複数アクションの指定

以下の例では、重要な優先度 (crit) を持つすべてのカーネル syslog メッセージはユーザー user1 に送信され、テンプレート temp によって処理され、test-program 実行可能ファイルに渡され、UDP プロトコルで 192.168.0.1 に転送されます。

kern.=crit user1
& ^test-program;temp
& @192.168.0.1

すべてのアクションで、メッセージをフォーマットするテンプレートが後に続きます。テンプレートを指定するには、アクションの末尾にセミコロン (;) を付け、続けてテンプレートの名前を指定します。テンプレートに関する詳細は 「テンプレート」 を参照してください。

警告

テンプレートはアクションで使用される前に定義する必要があり、アクションの後に定義しても無視されます。つまり、/etc/rsyslog.conf では、テンプレート定義が常にルール定義の前にくるようにする必要があります。

23.2.3. テンプレート

rsyslog で生成された出力はすべて、テンプレート を使用して、ユーザーのニーズに応じて修正とフォーマット設定ができます。テンプレートを作成するには、/etc/rsyslog.conf で以下の構文を使用します。

template(name=”TEMPLATE_NAME” type=”string” string="text %PROPERTY% more text" [option.OPTION="on"])

詳細は以下のようになります。

  • template() はテンプレートを定義するディレクティブ導入ブロックです。
  • TEMPLATE_NAME の必須引数はテンプレートの参照に使用します。TEMPLATE_NAME は一意であるべきことに注意してください。
  • type の必須引数は「list」、「subtree」、「string」、「plugin」のいずれかの値を取得します。
  • string 引数は実際のテンプレートテキストです。このテキスト内では、改行文字の \n、キャリッジリターンの \r などの特殊文字を使用できます。% または " などのその他の文字を使用する場合は、それらの文字を文字どおりエスケープする必要があります。このテキスト内では、改行文字の \n、キャリッジリターンの \r などの特殊文字を使用できます。% または " などのその他の文字を使用する場合は、それらの文字を文字どおりエスケープする必要があります。
  • 2 つのパーセントマーク (%) の間にあるテキストは、syslog メッセージの特定のコンテンツにアクセスできるようにする プロパティー を指定します。プロパティーに関する詳細情報は、「プロパティー」 を参照してください。
  • OPTION 属性は、テンプレート機能を修正するオプションを指定します。現在サポートされているテンプレートオプションは、テキストを SQL クエリーとしてフォーマット作成する sqlstdsql、または JSON 処理に適した形にテキストをフォーマットする JSON です。casesensitive はプロパティー名の大文字小文字の区別を設定します。

    注記

    データベースライターは、sql オプションまたは stdsql オプションがテンプレート内で指定されているかどうかをチェックします。指定されていないと、データベースライターはアクションを実行しません。これは SQL インジェクションなどのセキュリティーの脅威を回避するためです。

    詳細は、「アクション」 の「syslog メッセージのデータベースでの保存」を参照してください。

動的なファイル名の生成

テンプレートを使用して、動的なファイル名を生成できます。プロパティーをファイルパスの一部として指定すると、それぞれ一意のプロパティーに対して新しいファイルが作成されます。これは、syslog メッセージを分類する便利な方法です。

たとえば、メッセージからタイムスタンプを抽出する timegenerated プロパティーを使用すると、各 syslog メッセージに一意のファイル名を生成できます。

  template(name=”DynamicFile” type=”list”) {
  constant(value=”/var/log/test_logs/”)
  property(name=”timegenerated”)
  constant(value”-test.log”)
}

$template ディレクティブは単にテンプレートを指定するだけです。効果を反映するためには、それをルール内で使用しなければなりません。/etc/rsyslog.conf 内のアクション定義でクエスチョンマーク (?) を使用して、動的ファイル名テンプレートをマークします。

. ?DynamicFile
プロパティー

テンプレート内 (2 つのパーセントマーク (%) の内側) で定義されたプロパティーにより、プロパティー置換関数 を使用して syslog メッセージの各種コンテンツにアクセスできるようになります。テンプレート内 (2 つの引用符 (“…”) の間) でプロパティーを定義するには、以下の構文を使用します。

%PROPERTY_NAME:FROM_CHAR:TO_CHAR:OPTION%

詳細は以下のようになります。

  • PROPERTY_NAME 属性は、プロパティー名を指定します。利用可能なすべてのプロパティーとその詳細な説明は、rsyslog.conf(5) の man ページの「Available Properties」セクションでご覧になれます。
  • FROM_CHAR 属性と TO_CHAR 属性は、指定したプロパティーが動作する文字の範囲を表します。他の方法では、正規表現を使用して文字の範囲を指定することもできます。これを行うには、文字 RFROM_CHAR 属性として指定し、希望する正規表現を TO_CHAR 属性として指定します。
  • OPTION 属性は、入力を小文字に変換する lowercase オプションなど、プロパティーオプションを指定します。利用可能なすべてのプロパティーオプションとその詳細な説明は、rsyslog.conf(5) の man ページの Property Options セクションでご覧になれます。

簡単なプロパティーの例を以下に示します。

  • 以下のプロパティーは、syslog メッセージのメッセージテキスト全体を取得します。

    %msg%
  • 以下のプロパティは、syslog メッセージにあるメッセージテキストの最初の 2 文字を取得します。

    %msg:1:2%
  • 以下のプロパティは、syslog メッセージの全メッセージテキストを取得して、最後のラインフィード文字を省きます。

    %msg:::drop-last-lf%
  • 以下のプロパティは、syslog メッセージを受信し、RFC 3999 日付基準に従ってそれをフォーマットした時に生成されるタイムスタンプの最初の 10 文字を取得します。

    %timegenerated:1:10:date-rfc3339%
テンプレートの例

このセクションでは、rsyslog テンプレートの例をいくつか示しています。

例23.8「詳細な syslog メッセージのテンプレート」 は、syslog メッセージのフォーマットを作成するテンプレートを示しています。これにより、メッセージの重要性、機能、メッセージ受信時のタイムスタンプ、ホスト名、メッセージのタグ、メッセージテキストが出力され、改行後に終了します。

例23.8 詳細な syslog メッセージのテンプレート

  template(name=”verbose” type=”list”) {
  property(name="syslogseverity”)
  property(name="syslogfacility”)
  property(name="timegenerated”)
  property(name="HOSTNAME”)
  property(name="syslogtag”)
  property(name="msg”)
  constant(value=”\n")
}

例23.9「ウォールメッセージのテンプレート」 は、従来のウォールメッセージ (ログインしていてその mesg(1) パーミッションが yes に設定されている全ユーザーに送信されるメッセージ) に似ているテンプレートを示しています。このテンプレートは改行後 (\r\n を使用) にメッセージテキストと共にホスト名、メッセージタグ、およびタイムスタンプを出力してベル (\7 を使用) を鳴らします。

例23.9 ウォールメッセージのテンプレート

  template(name=”wallmsg” type=”list”) {
  constant(value="\r\n\7Message from syslogd@”)
  property(name="HOSTNAME”)
  constant(value=” at ")
  property(name="timegenerated”)
  constant(value=" ...\r\n ”)
  property(name="syslogtag”)
  constant(value=” “)
  property(name="msg”)
  constant(value=”\r\n”)
}

例23.10「データベースフォーマットが設定されたメッセージのテンプレート」 は、syslog メッセージのフォーマットを作成してデータベースクエリーとして使用できるようにするテンプレートを示しています。テンプレートの末尾でテンプレートオプションとして指定されている sql オプションに注目してください。これにより、データベースライターが、メッセージを MySQL SQL クエリーのフォーマットに指定します。

例23.10 データベースフォーマットが設定されたメッセージのテンプレート

template(name="dbFormat" type="list" option.sql="on") {
constant(value="insert into SystemEvents (Message, Facility, FromHost, Priority, DeviceReportedTime, ReceivedAt, InfoUnitID, SysLogTag)")
constant(value=" values ('")
property(name="msg")
constant(value="', ")
property(name="syslogfacility")
constant(value=", '")
property(name="hostname")
constant(value="', ")
property(name="syslogpriority")
constant(value=", '")
property(name="timereported" dateFormat="mysql")
constant(value="', '")
property(name="timegenerated" dateFormat="mysql")
constant(value="', ")
property(name="iut")
constant(value=", '")
property(name="syslogtag")
constant(value="')")
}

rsyslog には、RSYSLOG_ 接頭辞で識別される事前定義のテンプレートのセットも含まれています。これらは syslog の使用に確保されており、競合を防止するためにこの接頭辞を使用したテンプレートを作成しないことが推奨されます。以下の一覧では、これらの事前定義のテンプレートとその定義を示しています。

RSYSLOG_DebugFormat

プロパティー問題のトラブルシューティングに使われる特別なフォーマット。

template(name=”RSYSLOG_DebugFormat” type=”string” string="Debug line with all properties:\nFROMHOST: '%FROMHOST%', fromhost-ip: '%fromhost-ip%', HOSTNAME: '%HOSTNAME%', PRI: %PRI%,\nsyslogtag '%syslogtag%', programname: '%programname%', APP-NAME: '%APP-NAME%', PROCID: '%PROCID%', MSGID: '%MSGID%',\nTIMESTAMP: '%TIMESTAMP%', STRUCTURED-DATA: '%STRUCTURED-DATA%',\nmsg: '%msg%'\nescaped msg: '%msg:::drop-cc%'\nrawmsg: '%rawmsg%'\n\n")
RSYSLOG_SyslogProtocol23Format

IETF のインターネットドラフト ietf-syslog-protocol-23 で指定されるフォーマット。これは新たな syslog 標準 RFC になると想定されています。

template(name=”RSYSLOG_SyslogProtocol23Format” type=”string” string="%PRI%1 %TIMESTAMP:::date-rfc3339% %HOSTNAME% %APP-NAME% %PROCID% %MSGID% %STRUCTURED-DATA% %msg%\n ")
RSYSLOG_FileFormat

TraditionalFileFormat に類似した新しいスタイルのログファイルフォーマットですが、タイムスタンプとタイムゾーン情報の精度がより高くなります。

template(name="RSYSLOG_FileFormat" type="list") {
property(name="timestamp" dateFormat="rfc3339")
constant(value=" ")
property(name="hostname")
constant(value=" ")
property(name="syslogtag")
property(name="msg" spifno1stsp="on" )
property(name="msg" droplastlf="on" )
constant(value="\n")
}
RSYSLOG_TraditionalFileFormat

タイムスタンプの精度の低い古いスタイルのデフォルトのログファイルフォーマット。

template(name="RSYSLOG_TraditionalFileFormat" type="list") {
property(name="timestamp")
constant(value=" ")
property(name="hostname")
constant(value=" ")
property(name="syslogtag")
property(name="msg" spifno1stsp="on" )
property(name="msg" droplastlf="on" )
constant(value="\n")
}
RSYSLOG_ForwardFormat

高精度のタイムスタンプとタイムゾーン情報が含まれる転送フォーマット。

template(name="ForwardFormat" type="list") {
constant(value="<")
property(name="pri")
constant(value=">")
property(name="timestamp" dateFormat="rfc3339")
constant(value=" ")
property(name="hostname")
constant(value=" ")
property(name="syslogtag" position.from="1" position.to="32")
property(name="msg" spifno1stsp="on" )
property(name="msg")
}
RSYSLOG_TraditionalForwardFormat

精度の低いタイムスタンプを使用する従来の転送フォーマット。

template(name="TraditionalForwardFormat" type="list") {
constant(value="<")
property(name="pri")
constant(value=">")
property(name="timestamp")
constant(value=" ")
property(name="hostname")
constant(value=" ")
property(name="syslogtag" position.from="1" position.to="32")
property(name="msg" spifno1stsp="on" )
property(name="msg")
}

23.2.4. グローバルディレクティブ

グローバルディレクティブは、rsyslogd デーモンに適用される設定オプションです。通常、これらは rsyslogd デーモンの動作に影響を与える事前定義された特定の変数の値、または生じるルールを指定します。グローバルディレクティブはすべて、global 設定ブロックに含まれています。以下は、上書きするログメッセージのローカルホスト名を指定するグローバルディレクティブのサンプルです。

global(localHostname=”machineXY”)

このディレクティブ用に定義されたデフォルトのサイズ (10,000 メッセージ) は、別の値を指定することで上書きされます (上記の例を参照)。

/etc/rsyslog.conf 設定ファイルで複数のディレクティブを定義できます。1 つのディレクティブは、同じディレクティブの発生が再度検出されるまですべての設定オプションの動作に影響します。グローバルディレクティブは、アクション、キュー、デバッグの設定に使用できます。利用可能なすべての設定ディレクティブの一覧は、「オンラインドキュメント」 でご覧になれます。現在、$ ベースの構文 (「新規設定フォーマットの使用」 を参照) に代わる新たな設定フォーマットが開発されています。ただし、従来のグローバルディレクティブはレガシーフォーマットとして引き続きサポートされます。

23.2.5. ログローテーション

以下は、サンプルの /etc/logrotate.conf 設定ファイルです。

# rotate log files weekly
weekly
# keep 4 weeks worth of backlogs
rotate 4
# uncomment this if you want your log files compressed
compress

上記の設定ファイル内のすべての行は、すべてのログファイルに適用されるグローバルオプションを定義しています。この例では、ログファイルが週ごとにローテーションされ、ローテーションされたログファイルは 4 週間保持され、ローテーションされるログファイルはすべて gzip により .gz 形式に圧縮されます。ハッシュマーク (#) で始まる行はすべてコメントで、これは処理されません。

特定のログファイル用に設定オプションを定義して、それをグローバルオプションの下に置くこともできます。ただし、/etc/logrotate.d/ ディレクトリーに、特定ログファイル用の個別の設定ファイルを作成し、そこに設定オプションを定義することが推奨されます。

/etc/logrotate.d/ ディレクトリーに、設定ファイルが保存されている例を以下に示します。

/var/log/messages {
  rotate 5
  weekly
  postrotate
  /usr/bin/killall -HUP syslogd
  endscript
}

このファイル内の設定オプションは、/var/log/messages ログファイル専用の特有なものです。ここで指定された設定は、可能な場合はグローバルオプションを上書きします。そのため、ローテートされた /var/log/messages ログファイルは、グローバルオプションで定義された 4 週間ではなく、5 週間保管されます。

以下は、logrotate 設定ファイル内で指定できるディレクティブの一覧です。

  • weekly: ログファイルの週ごとのローテーションを指定します。同様なディレクティブには以下のものがあります。

    • daily
    • monthly
    • yearly
  • compress: ローテートしたログファイルの圧縮を有効にします。同様なディレクティブには以下のものがあります。

    • nocompress
    • compresscmd: 圧縮に使用するコマンドを指定します。
    • uncompresscmd
    • compressext: 圧縮に使用する拡張子を指定します。
    • compressoptions: 使用される圧縮プログラムに渡すオプションを指定します。
    • delaycompress: ログファイルの圧縮を次回のログファイルのローテーションまで延期します。
  • rotate INTEGER: ログファイルが削除される、または特定のアドレスに送信されるまでにログファイルがローテーションされる回数を指定します。値 0 が指定されると、古いログファイルはローテーションではなく削除されます。
  • mail ADDRESS: このオプションは、rotate ディレクティブで定義された数だけローテーションされたログファイルを特定のアドレスへメール送信できるようにします。同様なディレクティブには以下のものがあります。

    • nomail
    • mailfirst: 交代されたばかりのログファイルではなく、間もなく期限切れになるログファイルがメール送信されるよう指定します。
    • maillast: 交代されたばかりのログファイルではなく、間もなく期限切れになるログファイルがメール送信されるよう指定します。mail が有効の場合は、これがデフォルトのオプションです。

ディレクティブおよび設定オプションの一覧は、man ページ logrotate(5) を参照してください。

23.2.6. オープンファイルの制限の増加

特定の状況では、rsyslog がオープンファイルの最大数の制限を超えています。したがって、rsyslog は新しいファイルを開くことができません。

rsyslog でオープンファイルの制限を増やすには、以下を行います。

以下の内容で /etc/systemd/system/rsylog.service.d/increase_nofile_limit.conf ファイルを作成します。

[Service]
LimitNOFILE=16384

23.3. 新規設定フォーマットの使用

rsyslog バージョン 7 では、rsyslog パッケージの Red Hat Enterprise Linux 7 のデフォルトでインストールされる新しい設定構文が導入されています。この新しい設定形式の目的は、より強力かつ直感的なものにすることと、特定の無効なコンストラクトを許可しないことによりよくあるミスを防ぐことです。この構文の拡張は、RainerScript に依存する新たな設定プロセッサーによって可能になります。以前の形式は引き続き完全にサポートされ、/etc/rsyslog.conf 設定ファイルでデフォルトで使用されます。

RainerScript は、ネットワークイベントの処理と rsyslog などのイベントプロセッサーの設定用に設計されたスクリプト言語です。RainerScript は最初に、式ベースのフィルターを定義するために使用されました (例23.3「式ベースのフィルター」 を参照)。rsyslogバージョン 7 の RainerScript のバージョンは、input() ステートメントおよび ruleset() ステートメントを実装し、/etc/rsyslog.conf 設定ファイルは新しい構文で記述できます。新しい構文は主に構成される点で異なります。パラメーターは input、action、template、module load などのステートメントへの引数として渡されます。オプションの範囲はブロックによって制限されます。オプションのスコープはブロックにより制限されます。これにより、可読性が増し、設定の間違えによって発生するバグの数が減ります。一部の機能は両方の構文で公開され、他の機能は新しい構文でのみ公開されます。

以前のスタイルのパラメーターで記述された設定を比較します。

$InputFileName /tmp/inputfile
$InputFileTag tag1:
$InputFileStateFile inputfile-state
$InputRunFileMonitor

同じ設定を新たなフォーマットステートメントを使用すると、以下のようになります。

input(type="imfile" file="/tmp/inputfile" tag="tag1:" statefile="inputfile-state")

これにより、設定で使用されるパラメーター数が大幅に削減され、読みやすさが向上するとともに、実行速度も速まります。RainerScript ステートメントおよびパラメーターに関する詳細な情報は、「オンラインドキュメント」 を参照してください。

23.3.1. Rulesets

特定なディレクティブを除いて、rsyslog は、フィルター条件と、条件が当てはまる場合に実行されるアクションで構成される rules で定義したようにメッセージを処理します。従来の /etc/rsyslog.conf ファイルでは、すべてのルールは、どの入力メッセージにおいても表示順に評価されます。このプロセスは最初のルールで開始し、すべてのルールが処理されるか、ルールのいずれかがメッセージを破棄するまで続きます。

ただし、ルールは ルールセット と呼ばれるシーケンスにグループ化できます。このルールセットでは、特定のルールの効果を選択された入力のみに制限したり、特定の入力にバインドした明確なアクションセットを定義することで rsyslog のパフォーマンスを強化したりできます。つまり、特定の種類のメッセージでは必然的に false と評価されるフィルター条件をスキップできます。/etc/rsyslog.conf のレガシールールセット定義は、以下のようになります。

$RuleSet rulesetname
rule
rule2

ルールは、別のルールが定義されたとき、または以下のようにデフォルトのルールセットが呼び出されたときに終了します。

$RuleSet RSYSLOG_DefaultRuleset

rsyslog 7 の新しい設定形式では、この操作のために input() ステートメントおよび ruleset() ステートメントが予約されます。/etc/rsyslog.conf の新たな形式のルールセット定義は以下のようになります。

ruleset(name="rulesetname") {
   rule
   rule2
   call rulesetname2
   &hellip;
}

rulesetname を、使用する ruleset の識別子で置き換えます。この名前空間は rsyslog によって使用されるように予約されているため、ルールセット名は RSYSLOG_ で始めることはできません。RSYSLOG_DefaultRuleset は、メッセージが他のルールセットを割り当てていない場合に実行するデフォルトのルールセットを定義します。rule および rule2 では、上記の filter-action 形式でルールを定義できます。call パラメーターでは、他の ruleset ブロック内から ruleset を呼び出すことでこれらをネスト化できます。

ruleset の作成後は、これが適用される入力を指定する必要があります。

input(type="input_type" port="port_num" ruleset="rulesetname");

ここでは、メッセージを収集する入力モジュールである input_type か、ポート番号である port_num で入力メッセージを特定できます。filetag といった他のパラメーターは、input() 用に指定できます。rulesetname を、メッセージに対して評価されるルールセットの名前に置き換えます。入力メッセージが明示的に ruleset にバインドされていない場合は、デフォルトの ruleset が適用されます。

レガシーフォーマットを使用して ruleset を定義することもできます。詳細は 「オンラインドキュメント」 を参照してください。

例23.11 ルールセットの使用

以下の ruleset は、異なるポートからのリモートメッセージが確実に異なる方法で処理されるようにします。以下を /etc/rsyslog.conf に追加します。

ruleset(name="remote-6514") {
  action(type="omfile" file="/var/log/remote-6514")
}

ruleset(name="remote-601") {
  cron.* action(type="omfile" file="/var/log/remote-601-cron")
  mail.* action(type="omfile" file="/var/log/remote-601-mail")
}

input(type="imtcp" port="6514" ruleset="remote-6514");
input(type="imtcp" port="601" ruleset="remote-601");

上記の例に示されるルールセットは、2 つのポートからのログ宛先を定義します。ポート 601 の場合、メッセージはファシリティーに従ってソートされます。次に、TCP 入力が有効になり、ルールセットにバインドされます。この設定が機能するには、必須モジュール (imtcp) の読み込みが必要なことに注意してください。

23.3.2. sysklogd との互換性

-c オプションで指定される互換性モードは rsyslog バージョン 5 にありますが、バージョン 7 には含まれません。また、sysklogd-style コマンドラインオプションが非推奨となり、これらのコマンドラインオプションを指定した rsyslog の設定は回避する必要があります。ただし、複数のテンプレートおよびディレクティブを使用して、rsyslogd が sysklogd のような動作をエミュレートするように設定できます。

各種 rsyslogd オプションの詳細は、rsyslogd(8) の man ページを参照してください。

23.4. Rsyslog でのキュー (Queue) を使った操作

キューは、rsyslog のコンポーネント間でコンテンツ (主にsyslog メッセージ) を渡すために使用されます。キューを使うと、rsyslog は複数のメッセージを同時に処理することができ、複数のアクションを単一メッセージに一度に適用できます。rsyslog 内のデータフローは、以下のようになります。

図23.1 Rsyslog 内のメッセージフロー

Rsyslog 内のメッセージフロー

rsyslog がメッセージを受信するたびに、このメッセージをプリプロセッサーに渡して、メインのメッセージキュー に配置します。メッセージはそこでキューから取り出され、rule processor に渡されるのを待ちます。

rule processor は、分析およびフィルタリングのエンジンです。ここでは、/etc/rsyslog.conf で定義されるルールが適用されます。これらのルールに基づいて、rule processor はどのアクションが実行されるかを評価します。アクションにはそれぞれ、独自のアクションキューがあります。メッセージはこのキューにより各アクションプロセッサーに渡され、これが最終的な出力を作成します。この時点では、1 つのメッセージに関して複数のアクションが同時に実行可能であることに注意してください。このためにメッセージは複製され、複数のアクションプロセッサーに渡されます。

1 アクションにつき、1 つのキューのみが可能です。設定により、メッセージはアクションキューなしですぐにアクションプロセッサーに送信されることもあります。これはダイレクトキュー (direct queues) (下記参照) と呼ばれる動作です。出力アクションが失敗すると、アクションプロセッサーがアクションキューに通知を行い、それにより未処理要素が戻され、しばらくのインターバルの後、アクションが再度試されます。

まとめると、rsyslog では 2 か所のキュー (ルールプロセッサーの前にある単一の メインメッセージキュー と、さまざまなタイプの出力アクションの前にある アクションキュー) に並びます。キューは、メッセージ処理のパフォーマンス向上につながる以下の 2 つの利点を提供します。

  • rsyslog 構造内での decouple のプロデューサーとコンシューマーのバッファーとして機能します。
  • メッセージで実行されるアクションの 並列化 を可能にします。

それ以外では、キューを複数のディレクティブで設定して、システムに最適なパフォーマンスを提供することができます。これらの設定オプションは、以下の項で説明されています。

警告

出力プラグインがメッセージを提供できない場合、メッセージは、先行のメッセージキューに保存されます。キューがいっぱいになると、空きができるまで入力がブロックされます。これにより、ブロックされたキューを使用して新しいメッセーがログに記録されることが回避されます。個別のアクションキューが存在しないため、SSH ロギングが阻止され、SSH アクセスが阻止されるなどの重大な問題が発生することがあります。したがって、ネットワークを介して転送される、またはデータベースに転送される出力専用アクションキューを使用することが推奨されます。

23.4.1. キューの定義

メッセージが格納されている場所に基づいて、最も一般的に使用される ダイレクトインメモリーディスクディスクアシストメモリー キューの複数のタイプのキューがあります。最もよく使用されるのは、direct、in-memory、disk、および disk-assisted in-memory のキューです。以下を /etc/rsyslog.conf に追加します。

object(queue.type=”queue_type”)

これを追加することで、設定を適用できます。

  • メインメッセージキュー: objectmain_queue に置き換える
  • アクションキュー: objectaction に置き換える
  • ルールセット: objectruleset に置き換えます

queue_typedirectlinkedlist、または fixedarray (インメモリーキュー) または disk のいずれかに置き換えます。

メインメッセージキューのデフォルト設定は、FixedArray queue で 10,000 メッセージの制限があります。アクションキューはデフォルトで、Direct queue に設定されます。

ダイレクトキュー (Direct Queue)

出力をローカルファイルに書き出すなど、多くの単純な操作では、アクションの前にキューを構築することは不要です。キューの使用を回避するには、以下を使用します。

object(queue.type=”Direct”)

objectmain_queueaction、または ruleset に置き換えて、このオプションをメインメッセージキューまたはアクションキューにそれぞれ使用します。ダイレクトキューを使用すると、メッセージはプロデューサーからコンシューマーに直ちに直接渡されます。

ディスクキュー

ディスクキューはメッセージを厳密にハードドライブに保存します。これにより、信頼性が高くなりますが、すべてのキューモードが最も遅くなります。こうすることで信頼性は非常に高くなりますが、queuing モードのなかでは一番遅くなります。ただし、ほとんどのユースケースでは、ディスクキューは推奨されません。ディスクキューを設定するには、/etc/rsyslog.conf に以下のコマンドを入力します。

object(queue.type=”Disk”)

objectmain_queueaction、または ruleset に置き換えて、このオプションをメインメッセージキューまたはアクションキューにそれぞれ使用します。キューのデフォルトサイズは、以下の設定ディレクティブで変更できます。

object(queue.size=”size”)

ここでは、size はディスクキューの一部の指定サイズを表します。定義されたサイズ制限は限定的なものではなく、rsyslog はキューエントリーがサイズ制限を超えていても、常に 1 つの完全なキューエントリーを書き込みます。ディスクキューの各部分は、個別ファイルに適合します。これらファイルの命名ディレクティブは、以下のとおりです。

object(queue.filename=”name”)

これでファイルに name 接頭辞が設定され、1 で始まる 7 桁の数字が続き、ファイルごとにこれが増加します。

object(queue.maxfilesize=”size”)

ディスクキューは、デフォルトサイズの 1 MB でそれぞれに書き込まれています。別の値を使用する場合は size を使用します。

メモリー内キュー

インメモリーキューでは、キューに格納されたメッセージをメモリーに保持し、プロセスを高速化します。コンピュータの電源を切ってすぐに入れ直すか、シャットダウンが行われると、キューのデータは失われます。ただし、action (queue.saveonshutdown=”on”) の設定を使用して、シャットダウン前にデータを保存することができます。インメモリーキューには 2 種類あります。

  • FixedArray キュー: メインメッセージキューのデフォルトモードで、10,000 要素の制限があります。このタイプのキューは、キュー要素へのポインターを保有する固定かつ事前割り当てのアレイを使用します。これらのポインターのために、キューが空であってもある程度のメモリーが消費されます。しかし、FixedArray は、最善のランタイムパフォーマンスを提供し、比較的少ないキューに登録済みのメッセージと高パフォーマンスを期待する場合に最適なものです。
  • LinkedList キュー: ここではすべての構造物はリンクされたリストに動的に割り当てられるので、メモリーは必要な場合にのみ割り当てられます。LinkedList キューは時折発生するメッセージバーストにもうまく対応します。

一般的に、疑いが残る場合は LinkedList キューを使用してみてください。FixedArray と比べてメモリー消費量が少なく、プロセスオーバヘッドが低くて済みます。

以下の構文を使用して、インメモリーキューを設定します。

object(queue.type=”LinkedList”)
object(queue.type=”FixedArray”)

objectmain_queueaction、または ruleset に置き換えて、このオプションをメインメッセージキューまたはアクションキューにそれぞれ使用します。

ディスク補助のインメモリーキュー (Disk-Assisted In-memory Queues)

ディスクとインメモリーキューにはそれぞれ利点があり、rsyslog によって ディスク補助のインメモリーキュー でそれらを統合できます。これを行うには、通常のインメモリーキューを設定し、queue.filename=”file_name” ディレクティブをブロックに追加して、ディスクのファイル名を定義します。このキューは disk-assisted となり、インメモリーキューとディスクキューが連携します。

インメモリーキューがいっぱい、もしくはシャットダウン後にも継続する必要がある場合に、ディスクキューがアクティブ化されます。ディスク補助のキューでは、ディスク固有およびインメモリー固有の設定パラメーターの両方を設定できます。このタイプのキューはおそらく最も広く使われているもので、潜在的に長期間実行され、信頼性が低いアクションで特に便利です。

ディスク補助インメモリーキューの機能を指定するには、いわゆるウォーターマークを使用します。

object(queue.highwatermark=”number”)
object(queue.lowwatermark=”number”)

objectmain_queueaction、または ruleset に置き換えて、このオプションをメインメッセージキューまたはアクションキューにそれぞれ使用します。number をキューに格納されたメッセージの数に置き換えます。インメモリーキューがハイウォーターマークで定義された数字に到達すると、ディスクへのメッセージの書き込みが開始し、インメモリーキューのサイズがローウォーターマークで定義された数字になるまで続きます。watermarks を正しく設定すると、ディスクファイルへの書き込みが長くなるため、不要なディスク書き込みが最小限に抑えられます。そのため、高い基準は queue.size で設定されたキュー容量全体よりも低い値である必要があります。そのために、ハイウォーターマークは queue.size で設定されているキューのキャパシティ全体より低い必要があります。一方で、ハイウォーターマークを低く設定しすぎると、不必要なディスク補助が頻繁に発生してしまいます。

例23.12 サーバーへのログメッセージの確実な転送

多くの場合、Rsyslog は、ログメッセージがネットワークを介してサーバーに転送される中央ロギングシステムを保持するために使用されます。サーバーが利用できない場合にメッセージが失われないように、転送アクションに対するアクションキューを設定することが推奨されます。これにより、送信に失敗したメッセージは、サーバーが再度到達可能になるまでローカルに保存されます。このようなキューは UDP プロトコルを使用している接続には設定できないことに注意してください。

単一サーバーへの転送

ログメッセージをシステムからホスト名が example.com のサーバーに転送し、サーバー停止時にメッセージをバッファーするようアクションキューを設定するタスクを考えてみます。このタスクを実行するには、以下の手順を実行します。

  1. /etc/rsyslog.conf で以下の設定を使用するか、/etc/rsyslog.d/ ディレクトリーに以下の内容が含まれるファイルを作成します。

    . action(type=”omfwd”
    queue.type=”LinkedList”
    queue.filename=”example_fwd”
    action.resumeRetryCount="-1"
    queue.saveonshutdown="on"
    Target="example.com" Port="6514" Protocol="tcp")

    詳細は以下のようになります。

    • queue.type は LinkedList インメモリーキューを有効にします。
    • queue.filename はディスクストレージを定義します。この場合、バックアップファイルが example_fwd 接頭辞を持つ /var/lib/rsyslog/ ディレクトリーで作成され、
    • action.resumeRetryCount= “-1” 設定は、サーバーが応答しない場合に接続を再試行するときに rsyslog がメッセージを破棄しないようにします。
    • rsyslog がシャットダウンした場合、有効化した queue.saveonshutdown がメモリー内データを保存します。
    • 最後の行は信頼できる TCP デリバリーを使用して受信したすべてのメッセージをロギングサーバーに送ります。ポート指定はオプションです。

      上記の設定では、rsyslog は、リモートサーバーに到達できない場合にメッセージをメモリーに保持します。ディスク上にあるファイルは、設定されたメモリーキュー領域が rsyslog で不足するか、シャットダウンする必要がある場合にのみ作成されます。これにより、システムパフォーマンスが向上します。

複数のサーバーへの転送

複数のサーバーにログメッセージを転送するプロセスは前の手順に似ています。

  1. 各送信先サーバーでは、個別の転送ルール、アクションキュー指定、ディスク上のバックアップファイルが必要です。たとえば、/etc/rsyslog.conf で以下の設定を使用するか、/etc/rsyslog.d/ ディレクトリーに以下の内容が含まれるファイルを作成します。

    . action(type=”omfwd”
        queue.type=”LinkedList”
        queue.filename=”example_fwd1”
        action.resumeRetryCount="-1"
        queue.saveonshutdown="on"
        Target="example1.com" Protocol="tcp")
    . action(type=”omfwd”
        queue.type=”LinkedList”
        queue.filename=”example_fwd2”
        action.resumeRetryCount="-1"
        queue.saveonshutdown="on"
        Target="example2.com" Protocol="tcp")

23.4.2. rsyslog ログファイルの新しいディレクトリーの作成

rsyslog は、syslogd デーモンとして実行され、SELinux により管理されます。したがって、rsyslog が書き込む必要があるすべてのファイルでは適切な SELinux ファイルコンテキストが設定されている必要があります。

新規作業用ディレクトリーの作成

  1. 作業用ファイルを格納する別のディレクトリーを使用する必要がある場合は、以下のようにディレクトリーを作成します。

    ~]# mkdir /rsyslog
  2. SELinux ポリシーを管理するためにユーティリティーをインストールします。

    ~]# yum install policycoreutils-python
  3. SELinux ディレクトリーコンテキストタイプを /var/lib/rsyslog/ ディレクトリーと同じものに設定します。

    ~]# semanage fcontext -a -t syslogd_var_lib_t /rsyslog
  4. SELinux コンテキストを適用します。

    ~]# restorecon -R -v /rsyslog
    restorecon reset /rsyslog context unconfined_u:object_r:default_t:s0->unconfined_u:object_r:syslogd_var_lib_t:s0
  5. 必要な場合は、以下のように SELinux コンテキストを確認します。

    ~]# ls -Zd /rsyslog
    drwxr-xr-x. root root system_u:object_r:syslogd_var_lib_t:s0  /rsyslog
  6. 必要に応じてサブディレクトリーを作成します。以下に例を示します。

    ~]# mkdir /rsyslog/work/

    サブディレクトリーが親ディレクトリーと同じ SELinux コンテキストで作成されます。

  7. /etc/rsyslog.conf を有効にする直前にそのファイルに次の行を追加します。

    global(workDirectory=”/rsyslog/work”)

    この設定は、設定ファイルを解析するときに次の WorkDirectory ディレクティブが検出されるまで有効になります。

23.4.3. キューの管理

キューはすべてのタイプで、使用中の要件に合致するようにさらなる設定が可能です。複数のディレクティブを使用してアクションキューとメインメッセージキューの両方を修正できます。現時点では、20 以上のキューパラメーターが利用可能です。「オンラインドキュメント」 を参照してください。これらの設定の一部は一般的に使用されます。ワーカースレッド管理などでは、キューの動作をより詳細に制御でき、上級ユーザー用に予約されています。高度な設定では、rsyslog のパフォーマンスやスケジュールキューイングを最適化したり、システムシャットダウン時のキュー動作を修正したりできます。

キューのサイズ制限

キューが保有できるメッセージ数は、以下の設定で制限できます。

object(queue.highwatermark=”number”)

objectmain_queueaction、または ruleset に置き換えて、このオプションをメインメッセージキューまたはアクションキューにそれぞれ使用します。number をキューに格納されたメッセージの数に置き換えます。キューサイズを実際のメモリーサイズではなくメッセージの数として設定します。デフォルトのキューサイズは、メインメッセージキューとルールセットキューの場合は 10,000 メッセージ、アクションキューの場合は 1,000 となります。

ディスク補助キューはデフォルトでは無制限で、このディレクティブでは制限できませんが、以下の設定で物理的なディスク領域をバイト単位で確保することは可能です。

object(queue.maxdiskspace=”number”)

objectmain_queueactionruleset に置き換えます。数によって指定されるサイズ上限に達している場合、キューから取り出されたメッセージによって十分なスペースが解放されるまでメッセージは破棄されます。

メッセージの破棄

キューのメッセージがある数に達すると、重要でないメッセージを破棄して、より優先度が高いエントリーのためにキューのスペースを節約できます。破棄プロセスを開始するしきい値は、discard mark と呼ばれるもので設定できます。

object(queue.discardmark=”number”)

objectMainMsg または Action に置き換えて、このオプションをメインメッセージキューまたはアクションキューにそれぞれ使用します。ここでは、number は、破棄プロセスを開始するためにキューにある必要がある多くのメッセージを表します。破棄するメッセージを定義するには、以下を使用します。

object(queue.discardseverity=”number”)

number を、関連の優先度の以下の数値のいずれかに置き換えます。7 (debug)、6 (info)、5 (notice)、4 (warning)、3 (err)、2 (crit)、1 (alert)、または 0 (emerg)。この設定により、定義されたプライオリティーを下回る、新しく受信したメッセージおよびすでにキューに格納されたメッセージは、破棄マークに到達すると直ちにキューから消去されます。

タイムフレームの使用

特定の時間帯にキューを処理するように rsyslog を設定できます。このオプションを使用すると、たとえば処理をオフピーク時に移すことができます。時間帯を定義するには、以下の構文を使用します。

object(queue.dequeuetimebegin=”hour”)
object(queue.dequeuetimeend=”hour”)

hour では、時間帯を区切る時間を指定します。分は指定せず、24 時間形式を用います。

ワーカースレッドの設定

ワーカースレッドは キューに入っているメッセージに指定されたアクションを実行します。たとえば、メインメッセージキューでは、ワーカーのタスクは、入ってくるメッセージにフィルター論理を適用し、関連のアクションキューに入れることです。メッセージが届くと、ワーカースレッドは自動的に開始します。メッセージ数がある数に達すると、別のワーカースレッドがオンになります。この数字を指定するには、以下を使用します。

object(queue.workerthreadminimummessages=”number”)

number を、補助のワーカースレッドを起動するメッセージ数に置き換えます。たとえば number を 100 に設定すると、100 を超えるメッセージが届いた際に新たなワーカースレッドが起動します。200を超えるメッセージが到着すると、3番目のワーカースレッドが開始されます。ただし、並行して実行している作業スレッド数が多すぎるため、以下を使用してそれらの最大スレッド数を制限できます。

object(queue.workerthreads=”number”)

ここでの number は、並列で実行可能なワーカースレッドの最大数になります。メインメッセージキューのデフォルトは、1 スレッドです。ワーカースレッドが一旦起動すると、非アクティブタイムアウトが現れるまで、実行し続けます。タイムアウトを設定するには、以下を入力します。

object(queue.timeoutworkerthreadshutdown=”time”)

time をミリ秒単位の期間設定に置き換えます。新しいメッセージなしの時間を指定すると、ワーカースレッドが閉じます。デフォルトの設定は 1 分です。

バッチのデキュー

複数のメッセージを同時にデキューするように rsyslog を設定して、パフォーマンスを高めることができます。このデキューの最大値を設定するには、以下を使用します。

$object(queue.DequeueBatchSize= ”number”)

number を同時にデキュー可能な最大数に置き換えます。この数字を高く設定して、許可されるワーカースレッドの結果を大きくすると、メモリー消費量が大きくなることに注意してください。

キューの終了

メッセージを含んでいるキューを終了する際には、ワーカースレッドがキューの処理を完了する間隔を指定することで、データ損失を最小限に抑えることができます。

object(queue.timeoutshutdown=”time”)

time をミリ秒で指定します。この期間の後にまだキューに入っているメッセージがある場合、ワーカーは現在のデータ要素を完了してから終了します。このため、未処理のメッセージは失われます。ワーカーが最終要素を完了する間隔も設定できます。

object(queue.timeoutactioncompletion=”time”)

このタイムアウトが切れると、残りのワーカーはシャットダウンします。シャットダウン時にデータを保存するには、以下を使用します。

object(queue.saveonshutdown=”on”)

これが設定されていると、rsyslog の終了前にすべてのキュー要素がディスクに保存されます。

23.4.4. rsyslog キューの新規構文の使用

rsyslog 7 で利用可能な新規構文では、キューは /etc/rsyslog.conf で個別に使用、またはルールセット内部で使用できる action() オブジェクト内で定義されます。アクションキューの形式は以下のようになります。

action(type="action_type "queue.size="queue_size" queue.type="queue_type" queue.filename="file_name"

action_type を、アクションを実行するモジュールの名前に置き換え、queue_size を、キューに含めることができるメッセージの最大数に置き換えます。queue_type には、disk を選択するか、インメモリーキュー (directlinkedlist または fixedarray) のいずれかを選択します。file_name には、パスではなくファイル名のみを指定します。ログファイルを保持する新規ディレクトリーを作成する場合は、SELinux コンテキストを設定する必要があることに注意してください。例は、「rsyslog ログファイルの新しいディレクトリーの作成」 を参照してください。

例23.13 アクションキューの定義

出力アクションで、最大 10,000 件のメッセージを保持できる非同期リンクリストベースのアクションキューを設定するには、以下のようにコマンドを入力します。

action(type="omfile" queue.size="10000" queue.type="linkedlist" queue.filename="logfile")

直接アクションキューの rsyslog 7 構文は以下のとおりです。

. action(type="omfile" file="/var/lib/rsyslog/log_file
   )

複数のパラメーターがアクションキュー用 rsyslog 7 構文は以下のように記述できます。

. action(type="omfile"
       queue.filename="log_file"
       queue.type="linkedlist"
       queue.size="10000"
   )

デフォルトの作業ディレクトリー、または最後に設定した作業ディレクトリーが使用されます。別の作業ディレクトリを使用する必要がある場合は、アクションキューの前に次の行を追加します。

global(workDirectory="/directory")

例23.14 新規構文を使用した単一サーバーへの転送

以下の例は 単一サーバーへの転送 の手順に基づき、従来の構文と rsyslog 7 の構文の違いを示しています。この omfwd プラグインは、UDP または TCP を介した転送を提供するために使用されます。デフォルトは UDP です。プラグインは組み込まれているため、ロードする必要がありません。

/etc/rsyslog.conf で以下の設定を使用するか、/etc/rsyslog.d/ ディレクトリーに以下の内容が含まれるファイルを作成します。

. action(type="omfwd"
   queue.type="linkedlist"
   queue.filename="example_fwd"
   action.resumeRetryCount="-1"
   queue.saveOnShutdown="on"
   target="example.com" port="6514" protocol="tcp"
   )

詳細は以下のようになります。

  • queue.type="linkedlist" は LinkedList インメモリーキューを有効にします。
  • queue.filename はディスクストレージを定義します。バックアップファイルは、前のグローバルの workDirectory ディレクティブで指定された作業ディレクトリーに workDirectory 接頭辞を付けて作成されます。
  • action.resumeRetryCount -1 設定は、サーバーが応答しない場合に接続を再試行するときに rsyslog がメッセージを破棄しないようにします。
  • 有効化した queue.saveOnShutdown="on" は、rsyslog がシャットダウンしている場合にメモリー内データを保存します。
  • 最後の行は受信メッセージをすべてロギングサーバーに転送します。ポートの指定は任意です。

23.5. ロギングサーバーでの rsyslog の設定

rsyslog サービスは、ロギングサーバーを実行する機能と、個別のシステムがログファイルをロギングサーバーに送信するように設定する機能の両方を提供します。クライアントの rsyslog 設定の詳細は 例23.12「サーバーへのログメッセージの確実な転送」 を参照してください。

rsyslog サービスは、ロギングサーバーとして使用するシステムと、そのシステムにログを送信するように設定する全システムにインストールする必要があります。Rsyslog は Red Hat Enterprise Linux 7 にデフォルトでインストールされます。必要な場合は、確実にインストールするために root で以下のコマンドを入力します。

~]# yum install rsyslog

syslog トラフィックのデフォルトのプロトコルおよびポートは、/etc/services ファイルに一覧されているように UDP および 514 です。ただし、rsyslog は、デフォルトではポート 514 での TCP の使用に設定されます。設定ファイル /etc/rsyslog.conf では、TCP@@ によって示されます。

例では他のポートが使用されることがありますが、SELinux には、デフォルトで以下のポートでの送受信のみを許可するように設定されています。

~]# semanage port -l | grep syslog
syslog_tls_port_t       tcp   6514, 10514
syslog_tls_port_t       udp   6514, 10514
syslogd_port_t         tcp   601, 20514
syslogd_port_t         udp   514, 601, 20514

semanage ユーティリティーは、policycoreutils-python パッケージの一部として提供されます。必要な場合は、以下のようにパッケージをインストールします。

~]# yum install policycoreutils-python

また、デフォルトで rsyslog の SELinux タイプである rsyslogd_t は、SELinux タイプが rsh のリモートシェル (rsh_port_t) ポートでの送受信を許可するよう設定されます (デフォルトでポート TCP514 に設定されます)。したがって、semanage を使用してポート 514TCP を明示的に許可する必要はありません。たとえば、SELinux がポート 514 でそのTCPを許可するよう設定されているかを確認するには、以下のコマンドを入力します。

~]# semanage port -l | grep 514
output omitted
rsh_port_t           tcp   514
syslogd_port_t         tcp   6514, 601
syslogd_port_t         udp   514, 6514, 601

SELinux の詳細は、Red Hat Enterprise Linux 7 SELinux ユーザーおよび管理者のガイドを参照してください。

ロギングサーバーとして使用するシステムで以下の手順を実行します。これらの手順はすべて root ユーザーで実行する必要があります。

ポートで rsyslog トラフィックを許可する SELinux の設定

rsyslog トラフィックに新しいポートを使用する必要がある場合は、ロギングサーバーとクライアントでこの手順を実行します。たとえば、ポート 10514TCP トラフィックを送受信するには、以下のコマンドシーケンスに進みます。

  1. 以下のパラメーターを指定して、semanage port コマンドを実行します。

    ~]# semanage port -a -t syslogd_port_t -p tcp 10514
  2. 以下のコマンドを入力して SELinux ポートを確認します。

    ~]# semanage port -l | grep syslog
  3. 新しいポートがすでに /etc/rsyslog.conf に設定されている場合は、rsyslog を再起動して変更を反映します。

    ~]# service rsyslog restart
  4. 現在リッスンしているポート rsyslog を確認します。

    ~]# netstat -tnlp | grep rsyslog
    tcp    0   0 0.0.0.0:10514      0.0.0.0:*  LISTEN   2528/rsyslogd
    tcp    0   0 :::10514        :::*    LISTEN   2528/rsyslogd

semanage port コマンドの詳細は semanage-port(8) の man ページを参照してください。

firewalld の設定

受信 rsyslog トラフィックを許可するように firewalld を設定します。たとえば、ポート 10514TCP トラフィックを許可するには、以下の手順を実行します。

~]# firewall-cmd --zone=zone --add-port=10514/tcp
success

ここで、zone は使用するインターフェースのゾーンです。ここで変更する内容は、システムの再起動後は維持されないことに注意してください。ファイアウォールを永続的に変更するには、コマンドに --permanent オプションを繰り返し追加してください。firewalld でのポートのオープンおよびクローズの詳細については、Red Hat Enterprise Linux 7 Security Guide を参照してください。

  1. 上記の設定を確認するには、以下のコマンドを使用します。

    ~]# firewall-cmd --list-all
    public (default, active)
     interfaces: eth0
     sources:
     services: dhcpv6-client ssh
     ports: 10514/tcp
     masquerade: no
     forward-ports:
     icmp-blocks:
     rich rules:

rsyslog で、リモートログメッセージを受信してソートするように設定

  1. テキストエディターで /etc/rsyslog.conf ファイルを開き、以下の手順を実行します。

    1. モジュールセクションと Provides UDP syslog reception セクションの間に以下の行を追加します。

      # Define templates before the rules that use them
      
      # Per-Host Templates for Remote Systems #
      $template TmplAuthpriv, "/var/log/remote/auth/%HOSTNAME%/%PROGRAMNAME:::secpath-replace%.log"
      $template TmplMsg, "/var/log/remote/msg/%HOSTNAME%/%PROGRAMNAME:::secpath-replace%.log"
    2. デフォルトの Provides TCP syslog reception セクションを以下に置き換えます。

      # Provides TCP syslog reception
      $ModLoad imtcp
      # Adding this ruleset to process remote messages
      $RuleSet remote1
      authpriv.*  ?TmplAuthpriv
      *.info;mail.none;authpriv.none;cron.none  ?TmplMsg
      $RuleSet RSYSLOG_DefaultRuleset  #End the rule set by switching back to the default rule set
      $InputTCPServerBindRuleset remote1 #Define a new input and bind it to the "remote1" rule set
      $InputTCPServerRun 10514

      変更を /etc/rsyslog.conf ファイルに保存します。

  2. rsyslog サービスは、ログサーバーと、そのサーバーにログ記録を試みるシステムの両方で実行する必要があります。

    1. systemctl コマンドを使用して rsyslog サービスを起動します。

      ~]# systemctl start rsyslog
    2. rsyslog サービスを今後自動的に起動するために、root で以下のコマンドを入力します。

      ~]# systemctl enable rsyslog

環境内の他のシステムからログファイルを受け取り、保存するように、ログサーバーが設定されています。

23.5.1. ロギングサーバーでの新規テンプレート構文の使用

rsyslog 7 にはテンプレートスタイルが多数あります。文字列テンプレートは従来の形式に最もよく似ています。文字列形式を使用して上記の例からテンプレートを生成する場合は、以下のようになります。

template(name="TmplAuthpriv" type="string"
     string="/var/log/remote/auth/%HOSTNAME%/%PROGRAMNAME:::secpath-replace%.log"
    )

template(name="TmplMsg" type="string"
     string="/var/log/remote/msg/%HOSTNAME%/%PROGRAMNAME:::secpath-replace%.log"
    )

また、これらのテンプレートは、以下のようにリスト形式で記述することもできます。

template(name="TmplAuthpriv" type="list") {
  constant(value="/var/log/remote/auth/")
  property(name="hostname")
  constant(value="/")
  property(name="programname" SecurePath="replace")
  constant(value=".log")
  }

template(name="TmplMsg" type="list") {
  constant(value="/var/log/remote/msg/")
  property(name="hostname")
  constant(value="/")
  property(name="programname" SecurePath="replace")
  constant(value=".log")
  }

このテンプレートテキスト形式は、rsyslog の初心者にとって理解しやすいかもしれません。したがって、要件が変更したら簡単に変更できます。

新規構文への変更を完了するには、モジュールロードコマンドを再作成し、ルールセットを追加して、プロトコル、ポート、およびルールセットにルールセットをバインドする必要があります。

module(load="imtcp")

ruleset(name="remote1"){
   authpriv.*  action(type="omfile" DynaFile="TmplAuthpriv")
   *.info;mail.none;authpriv.none;cron.none action(type="omfile" DynaFile="TmplMsg")
}

input(type="imtcp" port="10514" ruleset="remote1")

23.6. Rsyslog モジュールの使用

モジューラーの設計上、rsyslog は、追加の機能が含まれる各種 モジュール を提供します。モジュールはサードパーティーによる書き込みが可能であることに注意してください。ほとんどのモジュールは、追加入力 (以下の Input Modules 参照) または出力 (以下の Output Modules 参照) を提供します。その他のモジュールは、各モジュールに固有の機能を提供します。モジュールは、モジュールの読み込み後に利用可能になる追加の設定ディレクティブを提供する場合があります。モジュールを読み込むには、以下の構文を使用します。

module(load=”MODULE”)

MODULE は希望のモジュールを表します。たとえば、rsyslog を有効にして標準テキストファイルを syslog メッセージに変換する Text File Input Module (imfile) を読み込む場合は、/etc/rsyslog.conf 設定ファイルの以下の行を指定します。

module(load=”imfile”)

rsyslog は多くのモジュールを提供し、これらは以下の主なカテゴリーに分けられます。

  • 入力モジュール: 入力モジュールは、さまざまなソースからメッセージを収集します。入力モジュールの名前は、常に imfile および imjournal のように接頭辞 im で始まります。
  • 出力モジュール: 出力モジュールはメッセージをネットワーク上に送信したり、データベース内に保存したり、暗号化するなど、様々なターゲットにメッセージを発行するための機能を提供します。入力モジュールの名前は、常に omsnmpomrelp のように接頭辞 om で始まります。
  • パーサーモジュール: これらのモジュールは、カスタムの解析ルールの作成や不正な形式のメッセージ解析に使用されます。C プログラミング言語についてある程度の知識があれば、独自のメッセージパーサーが作成できます。パーサーモジュールの名前は、常に pmrfc5424pmrfc3164 のように接頭辞 pm で始まります。
  • メッセージ修正モジュール: メッセージ修正モジュールは、syslog メッセージの内容を変更します。このモジュールの名前は、mm 接頭辞で始まります。mmanonmmnormalize、または mmjsonparse といったメッセージ修正モジュールは、メッセージの匿名化や正常化に使用されます。
  • 文字列生成モジュール - 文字列生成モジュールは、メッセージ内容を基にして文字列を生成し、rsyslog で用意されているテンプレート機能と密接に機能します。テンプレートに関する詳細は 「テンプレート」 を参照してください。文字列生成モジュールの名前は、smfile または smtradfile のように常に接頭辞 sm で始まります。
  • ライブラリーモジュール - ライブラリーモジュールは、他の読み込み可能なモジュール用の機能を提供します。これらのモジュールは、必要であるのにユーザーが設定できない場合に rsyslog が自動的に読み込みます。

利用可能なモジュールの一覧と、そのモジュールの詳しい説明は、http://www.rsyslog.com/doc/rsyslog_conf_modules.html を参照してください。

警告

rsyslog はモジュールを読み込む際に、モジュールに対して一部の機能とデータへのアクセスを提供します。これはセキュリティー上の脅威となる可能性があります。セキュリティーリスクを最小限にするために、信頼できるモジュールのみを使用するようにしてください。

23.6.1. テキストファイルのインポート

テキストファイル入力モジュールは imfile と省略され、rsyslog がテキストファイルを syslog メッセージのストリームに変換できるようにします。imfile を使用して、独自のテキストファイルログを作成するアプリケーションからログメッセージをインポートできます。imfile を読み込むには、以下を /etc/rsyslog.conf に追加します。

    module(load=”imfile”
    				PollingInterval=”int”)

複数のファイルをインポートする場合でも、imfile を一度読み込むだけで十分です。PollingInterval モジュール引数は、接続済みテキストファイルの変更に対して rsyslog チェックをどのくらいの頻度で行うか指定します。デフォルトの間隔は 10 秒で、変更するには int を秒で指定した時間間隔に置き換えます。

インポートするテキストファイルを特定するには、/etc/rsyslog.conf で以下の構文を使用します。

# File 1
input(type="imfile"
   File="path_to_file"
   Tag="tag:"
   Severity="severity"
   Facility="facility")

# File 2
input(type="imfile"
   File="path_to_file2")
...

入力テキストファイルを指定するために必要な設定:

  • path_to_file をテキストファイルへのパスに置き換えます。
  • tag: をこのメッセージのタグ名に置き換えます。

必要なディレクティブ以外に、テキスト入力に適用可能な設定がいくつかあります。severity を適切なキーワードで置き換えて、インポートされたメッセージの重要度を設定します。facility を、メッセージを作成したサブシステムを定義するキーワードに置き換えます。重要度と機能のキーワードは、機能または優先度ベースのフィルターで使用されたものと同じものです (「フィルター」 を参照)。

例23.15 テキストファイルのインポート

Apache HTTP サーバーはログファイルをテキスト形式で作成します。rsyslog の処理機能を apache エラーメッセージに適用するには、まず imfile モジュールを使用してメッセージをインポートします。以下を /etc/rsyslog.conf に追加します。

module(load=”imfile”)
input(type="imfile"
   File="/var/log/httpd/error_log"
   Tag="apache-error:")

23.6.2. データベースへのメッセージのエクスポート

ログデータの処理は、テキストファイルではなくデータベース内で実行するとより速く、より便利なものになります。使用される DBMS のタイプに基づいて、ommysqlompgsqlomoracleommongodb などの出力モジュールを選択します。別の方法としては、libdbi ライブラリーに依存する一般的な omlibdbi 出力モジュールを使用します。omlibdbi モジュールは、Firebird/Interbase、MS SQL、Sybase、SQLite、Ingres、Oracle、mSQL、MySQL、および PostgreSQL のデータベースシステムをサポートします。

例23.16 データベースへの rsyslog メッセージのエクスポート

rsyslog メッセージを MySQL データベースに保存するには、/etc/rsyslog.conf に以下を追加します。

module(load=”ommysql”)

. action(type”ommysql”
server=”database-server”
db=”database-name”
uid=”database-userid”
pwd=”database-password”
serverport=”1234”)

最初に出力モジュールが読み込まれ、その後に通信ポートが指定されます。上記の例では、サーバー名、データベース名、認証データなどの追加情報は、最後の行で指定されています。

23.6.3. 暗号化トランスポートの有効化

ネットワーク転送の機密性と統合性は、TLS または GSSAPI 暗号化プロトコルのいずれかによって提供されます。

Transport Layer Security (TLS) は、ネットワーク上の通信セキュリティーを提供するために設計された暗号プロトコルです。TLS を使用すると、rsyslog メッセージは送信前に暗号化され、送信者と受信者間で相互認証が行われます。TLS の設定は 「TLS を使用した暗号化メッセージ転送の設定」 を参照してください。

Generic Security Service API (GSSAPI) は、プログラムがセキュリティサービスにアクセスするためのアプリケーションプログラミングインターフェースです。rsyslog と接続して使用するには、機能している Kerberos 環境が必要です。GSSAPI の設定は、を参照してください 「GSSAPI を使用した暗号化メッセージ転送の設定」

TLS を使用した暗号化メッセージ転送の設定

TLS を経由して暗号化トランスポートを使用するには、サーバーとクライアント両方を設定する必要があります。

  1. 公開鍵、秘密鍵、証明書ファイルを作成し、「新しい鍵と証明書の生成」 を参照します。
  2. サーバー側 で、/etc/rsyslog.conf 設定ファイルで以下を設定します。

    1. gtls netstream ドライバーをデフォルトドライバーに設定します。

      global(defaultnetstreamdriver="gtls")
    2. 証明書ファイルへのパスを指定します。

      global(defaultnetstreamdrivercafile="path_ca.pem"
      defaultnetstreamdrivercertfile="path_cert.pem"
      defaultnetstreamdriverkeyfile="path_key.pem")

      簡潔な設定ファイルを好む場合は、グローバルディレクティブをすべて 1 つのブロックに統合できます。

      以下を置き換えます。

      • path_ca.pem を、公開鍵へのパスに置き換え
      • path_cert.pem を、証明書ファイルへのパスに置き換え
      • path_key.pem を、秘密鍵へのパスに置き換え
    3. imtcp モジュールを読み込み、ドライバーオプションを設定します。

      module(load=”imtcp”
      StreamDriver.Mode=“number”
      StreamDriver.AuthMode=”anon”)
    4. サーバーを起動します。

      input(type="imtcp" port="port″)

      以下を置き換えます。

      • number はドライバーモードを指定します。TCP オンリーモードを有効にするには、1 を使用します。
      • port を、リスナーを起動するポート番号に置き換えます。たとえば 10514 にします。

        anon 設定は、クライアントが認証されていないことを意味します。

  3. クライアント 側で、/etc/rsyslog.conf 設定ファイルで以下を設定します。

    1. 公開鍵を読み込みます。

      global(defaultnetstreamdrivercafile="path_ca.pem")

      path_ca.pem を公開鍵へのパスで置き換えます。

    2. gtls netstream ドライバーをデフォルトドライバーに設定します。

       global(defaultnetstreamdriver="gtls")
    3. ドライバーを設定し、実行するアクションを指定します。

      module(load=”imtcp”
        streamdrivermode=”number”
        streamdriverauthmode=”anon”)
      input(type=”imtcp”
        address=”server.net”
        port=”port”)

      numberanonport を、サーバーと同じ値に置き換えます。

      上記一覧の最後の行で、例のアクションがサーバーから指定の TCP ポートにメッセージを転送します。

GSSAPI を使用した暗号化メッセージ転送の設定

rsyslog では、GSSAPI とのやり取りは imgssapi モジュールによって提供されます。GSSAPI 転送モードをオンにするには、以下を実行します。

  1. 以下の設定を /etc/rsyslog.conf に配置します。

    $ModLoad imgssapi

    このディレクティブは、imgssapi モジュールを読み込みます。

  2. 以下のように入力を指定します。

    $InputGSSServerServiceName name
    $InputGSSServerPermitPlainTCP on
    $InputGSSServerMaxSessions number
    $InputGSSServerRun port
    • name を、GSS サーバーの名前に置き換えます。
    • number を置き換え、サポートされる最大セッション数を設定します。デフォルトで、この数字は制限されていません。
    • port を、GSS サーバーを起動したい選択ポートに置き換えます。

      $InputGSSServerPermitPlainTCP on 設定により、サーバーは同じポートでプレーン TCP メッセージを受信できます。デフォルトでオフになっています。

注記

設定ファイルリーダーが imgssapi 設定ファイルで $InputGSSServerRun ディレクティブに遭遇すると、/etc/rsyslog.conf モジュールはすぐに初期化されます。このため、$InputGSSServerRun より後に設定されている補助オプションは無視されます。設定を有効にするには、すべての imgssapi 設定オプションを、$InputGSSServerRun の前に配置する必要があります。

例23.17 GSSAPI の使用

以下の設定では、ポート 1514 上の GSS サーバーが有効になります。この設定では、同一ポート上でプレーンの tcp syslog メッセージの受信も許可されます。

$ModLoad imgssapi
$InputGSSServerPermitPlainTCP on
$InputGSSServerRun 1514

23.6.4. RELP の使用

Reliable Event Logging Protocol (RELP) は、コンピューターネットワークにおけるデータロギング用のネットワーキングプロトコルです。信頼性のあるイベントメッセージの配信を提供するように設計されています。これは、メッセージ損失が許されない環境で便利なものです。

RELP の設定

RELP を設定するには、/etc/rsyslog.conf ファイルを使用してサーバーとクライアントの両方を設定します。

  1. クライアントを設定するには、以下を実行します。

    1. 必須モジュールを読み込みます。

      module(load="imuxsock")
      module(load="omrelp")
      module(load="imtcp")
    2. 以下のように TCP 入力を設定します。

      input(type="imtcp" port="port″)

      port を、必要なポートに置き換えてリスナーを開始します。

    3. トランスポート設定を構成します。

      action(type="omrelp" target="target_IP″ port="target_port″)

      target_IPtarget_port をターゲットサーバーを識別する IP アドレスとポートに置き換えます。

  2. サーバーを設定するには、以下を実行します。

    1. モジュールの読み込みを設定します。

      module(load="imuxsock")
      module(load="imrelp" ruleset="relp")
    2. クライアント設定と同様の TCP 入力を設定します。

      input(type="imrelp" port="target_port″)

      target_port をクライアントと同じ値に置き換えます。

    3. ルールを設定し、実行するアクションを選択します。次の例では、log_path はメッセージを保存するためのパスを指定しています。

      ruleset (name="relp") {
      action(type="omfile" file="log_path")
      }
TLS を使用した RELP の設定

TLS を使用して RELP を設定するには、認証を設定する必要があります。続いて、/etc/rsyslog.conf ファイルを使用してサーバーとクライアントの両方を設定する必要があります。

  1. 公開鍵、秘密鍵、証明書ファイルを作成します。手順は「新しい鍵と証明書の生成」を参照してください。
  2. クライアントを設定するには、以下を実行します。

    1. 必須モジュールを読み込みます。

      module(load="imuxsock")
      module(load="omrelp")
      module(load="imtcp")
    2. 以下のように TCP 入力を設定します。

      input(type="imtcp" port="port″)

      port を、必要なポートに置き換えてリスナーを開始します。

    3. トランスポート設定を構成します。

      action(type="omrelp" target="target_IP″ port="target_port″ tls="on"
      tls.caCert="path_ca.pem"
      tls.myCert="path_cert.pem"
      tls.myPrivKey="path_key.pem"
      tls.authmode="mode"
      tls.permittedpeer=["peer_name"]
      )

      以下を置き換えます。

      • target_IPtarget_port を、ターゲットサーバーを識別する IP アドレスとポートにそれぞれ置き換えます。
      • path_ca.pempath_cert.pem、および path_key.pem を、証明書ファイルのパスに置き換えます。
      • mode を、トランザクションの認証モードに置き換えます。"name" または "fingerprint" のいずれかを使用します。
      • peer_name を、許可されたピアの証明書フィンガープリントに置き換えます。これを指定した場合、tls.permittedpeer は、選択したピアグループへの接続を制限します。

        tls="on" の設定は、TLS プロトコルを有効にします。

  3. サーバーを設定するには、以下を実行します。

    1. モジュールの読み込みを設定します。

      module(load="imuxsock")
      module(load="imrelp" ruleset="relp")
    2. クライアント設定と同様の TCP 入力を設定します。

      input(type="imrelp" port="target_port″ tls="on"
      tls.caCert="path_ca.pem"
      tls.myCert="path_cert.pem"
      tls.myPrivKey="path_key.pem"
      tls.authmode="name"
      tls.permittedpeer=["peer_name","peer_name1","peer_name2"]
      )

      強調した値をクライアントと同じものに置き換えます。

    3. ルールを設定し、実行するアクションを選択します。次の例では、log_path はメッセージを保存するためのパスを指定しています。

      ruleset (name="relp") {
      action(type="omfile" file="log_path")
      }

23.7. Rsyslog と Journal の相互作用

ここまで説明してきたように、使用中のシステムに存在する RsyslogJournal の 2 つのロギングアプリケーションには、特別のユースケースに適したいくつかの特徴的な機能があります。多くの状況では、これらの機能を組み合わせると便利になります。たとえば、構造化メッセージを作成して、ファイルデータベースに格納する場合が考えられます (「Rsyslog での構造化ロギング」 を参照)。ここで必要となる通信インターフェースは、Rsyslog 側の出入力モジュールと Journal の通信ソケットが提供します。

デフォルトでは、rsyslogd はジャーナルファイルのデフォルト入力モードとして imjournal モジュールを使用します。このモジュールを使用すると、メッセージだけでなく、journald が提供する構造化データもインポートできます。古いデータも、journald からインポートできます (IgnorePreviousMessages オプションで禁止されていない場合)。imjournal の基本設定は 「Journal からのデータのインポート」 を参照してください。

別の方法では、syslog ベースのアプリケーション用の出力に、rsyslogd が提供するソケットから読み取るように journal を設定することもできます。ソケットへのパスは /run/systemd/journal/syslog です。プレーンな rsyslog メッセージを維持したい場合は、このオプションを使用します。imjournal と比較すると、ソケット入力は現在、ruleset バインディングやフィルタリングなど、より多くの機能を提供しています。ソケットを使用して Journal データをインポートするには、/etc/rsyslog.conf で以下の設定を使用します。

module(load="imuxsock"
    SysSock.Use="on"
    SysSock.Name="/run/systemd/journal/syslog")

また、omjournal モジュールで Rsyslog から Journal にメッセージを出力することもできます。/etc/rsyslog.conf で出力を設定します。

module(load="omjournal")
action(type="omjournal")

たとえば、以下の設定では、tcp ポート 10514 で受信したメッセージをすべて Journal に転送します。

module(load="imtcp")
module(load="omjournal")

ruleset(name="remote") {
	action(type="omjournal")
}

input(type="imtcp" port="10514" ruleset="remote")

23.8. Rsyslog での構造化ロギング

大量のログデータを生成するシステムでは、ログメッセージを 構造化されたフォーマット で維持すると便利です。構造化メッセージは、特定情報の検索や統計情報の作成、メッセージ構造の変更およびその不整合への対応が容易になります。RsyslogJSON (JavaScript Object Notation) フォーマットを使ってログメッセージに構造を提供します。

以下の非構造化ログメッセージを

Oct 25 10:20:37 localhost anacron[1395]: Jobs will be executed sequentially

次の構造化メッセージと比較してください。

{"timestamp":"2013-10-25T10:20:37", "host":"localhost", "program":"anacron", "pid":"1395", "msg":"Jobs will be executed sequentially"}

鍵と値のペアを使用した構造化データの検索は、正規表現によるテキストファイルの検索よりも速く、より正確です。構造化データでは、異なるアプリケーションで作成されたメッセージで同一エントリーを検索することもできます。また、JSON ファイルは、追加のパフォーマンスおよび分析機能を提供する MongoDB のようなドキュメントデータベースで保存することもできます。一方で、構造化メッセージは、非構造化メッセージよりも多くのディスクスペースを必要とします。

rsyslog では、メタデータを伴うログメッセージは、imjournal モジュールを使用して Journal からプルされます。mmjsonparse モジュールでは、Journal やその他のソースからインポートしたデータを解析し、たとえばデータベース出力としてさらに処理できます。解析が成功するには、mmjsonparse では、Lumberjack プロジェクトで定義された方法で入力メッセージが構築されている必要があります。

Lumberjack プロジェクトは、後方互換性がある方法で構造化ロギングを rsyslog に追加することを目指しています。構造化メッセージを特定するために、Lumberjack は実際の JSON 構造の前に付く @cee: 文字列を指定します。また、Lumberjack は、JSON 文字列内のエントリーに使用する標準フィールド名の一覧も定義します。Lumberjack の詳細情報は 「オンラインドキュメント」 を参照してください。

以下は、lumberjack 形式のメッセージの例です。

      @cee: {"pid":17055, "uid":1000, "gid":1000, "appname":"logger", "msg":"Message text."}

この構造を Rsyslog 内に構築するには、テンプレートを使用します。「構造化メッセージのフィルタリング」 を参照してください。アプリケーションおよびサーバーは、libumberlog ライブラリーを使用して、lumberjack 準拠の形式でメッセージを生成することができます。libumberlog の詳細は 「オンラインドキュメント」 を参照してください。

23.8.1. Journal からのデータのインポート

imjournal モジュールは Rsyslog の入力モジュールで、ネイティブに journal ファイルを読み取ります (「Rsyslog と Journal の相互作用」 を参照)。その後、Journal メッセージは、他の rsyslog メッセージのようにテキスト形式でログ記録されます。しかし、さらに処理することで、Journal が提供するメタデータを構造化メッセージに変換できます。

Journal から Rsyslog にデータをインポートするには、/etc/rsyslog.conf で以下の設定を使用します。

module(load=”imjournal”
  PersistStateInterval=”number_of_messages”
  StateFile=”path”
  ratelimit.interval=”seconds”
  ratelimit.burst=”burst_number”
  IgnorePreviousMessages=”off/on”)
  • number_of_messages では、journal データの保存頻度を指定できます。メッセージの数が指定された数値に達するとデータが保存されます。
  • path は、state ファイルのパスに置き換えます。このファイルは、最後に処理された journal エントリーを追跡します。
  • seconds では、レート制限の間隔を設定します。この間隔内に処理されるメッセージ数は、burst_number で指定した値を超えることはできません。デフォルト設定は、600 秒あたり 20,000 メッセージです。Rsyslog は、この指定された時間枠内で最大バースト後に届いたメッセージを破棄します。
  • IgnorePreviousMessages を使用すると、現在 Journal にあるメッセージを無視し、新しいメッセージのみをインポートできます。このメッセージは、状態ファイルが指定されていない場合に使用されます。デフォルト設定は off になります。この設定がオフで state ファイルが存在しない場合、前回の rsyslog セッションで処理されたものであっても、ジャーナルのすべてのメッセージが処理されます。
注記

従来のシステムログ入力である imuxsock モジュールと imjournal 同時に使用することができます。ただし、メッセージの重複を避けるために、imuxsock がジャーナルのシステムソケットを読まないようにする必要があります。そのためには、SysSock.Use ディレクティブを使用します。

module(load”imjournal”)
module(load”imuxsock”
  SysSock.Use=”off”
  Socket="/run/systemd/journal/syslog")

Journal が保存したデータおよびメタデータはすべて、構造化メッセージに変換することができます。これらのメタデータエントリーの一部は、例23.19「詳細な journalctl 出力」 に一覧表示されています。ジャーナルフィールドの完全なリストは、systemd.journal-fields(7) の man ページを参照してください。たとえば、kernel を元とするメッセージが使用する kernel journal fields にフォーカスできます。これは、カーネルのメッセージで使用されています。

23.8.2. 構造化メッセージのフィルタリング

rsyslog の解析モジュールで必要となる lumberjack 形式のメッセージを作成するには、以下のテンプレートを使用します。

template(name="CEETemplate" type="string" string="%TIMESTAMP% %HOSTNAME% %syslogtag% @cee: %$!all-json%\n")

このテンプレートは、JSON 文字列の前に @cee: 文字列を付加し、たとえば、omfile モジュールで出力ファイルを作成する際に適用できます。JSON フィールド名にアクセスするには、$! 接頭辞を使用します。たとえば、以下のフィルター条件では、特定の hostnameUID のメッセージが検索されます。

($!hostname == "hostname" && $!UID== "UID")

23.8.3. JSON の解析

構造化メッセージの解析には、mmjsonparse モジュールが使用されます。

これらのメッセージは Journal から来る場合もあれば、他の入力ソースから来る場合もあり、Lumberjack プロジェクトで定義された方法でフォーマットされている必要があります。これらのメッセージは @cee: 文字列の存在により識別されます。そして、JSON 構造が有効かどうかを mmjsonparse がチェックした後、メッセージが解析されます。

lumberjack 形式の JSON メッセージを mmjsonparseで解析するには、/etc/rsyslog.conf で以下の設定を使用します。

module(load”mmjsonparse”)

. :mmjsonparse:

この例では、mmjsonparse モジュールが最初の行で読み込まれ、その後にすべてのメッセージがそこに転送されます。現在は、mmjsonparse で使用可能な設定パラメーターはありません。

23.8.4. MongoDB でのメッセージの保存

Rsyslog は、ommongodb 出力モジュールで、MongoDB ドキュメントデータベースでの JSON ログの保存をサポートします。

MongoDB にログメッセージを転送するには、/etc/rsyslog.conf で以下の構文を使用します (ommongodb 用の設定パラメーターは、新たな設定フォーマットでのみ利用可能です。「新規設定フォーマットの使用」 を参照してください)。

module(load”ommongodb”)

. action(type="ommongodb" server="DB_server" serverport="port" db="DB_name" collection="collection_name" uid="UID" pwd="password")
  • DB_server は MongoDB サーバーの名前またはアドレスに置き換えます。port を指定して、MongoDB サーバーから非標準ポートを選択します。port のデフォルト値は 0 で、通常はこのパラメーターを変更する必要はありません。
  • DB_name では、出力先となる MongoDB サーバー上のデータベースを特定します。collection_name を、このデータベース内のコレクション名に置き換えます。MongoDB では、コレクションはドキュメントのグループで、RDBMS テーブルと同等のものです。
  • UIDpassword を、ログイン情報に置き換えて設定します。

テンプレートを使用すると、最終的なデータベースの出力形式を作成できます。デフォルトでは、rsyslog は標準 lumberjack フィールド名をベースにしたテンプレートを使用します。

23.9. Rsyslog のデバッグ

rsyslogd をデバッグモードで実行するには、以下のコマンドを使用します。

rsyslogd -dn

このコマンドでは、rsyslogd がデバッグ情報を作成し、標準出力に印刷します。-n は「no fork」を意味します。たとえば、デバッグ出力をログファイルに保存して、環境変数を使用してデバッグを変更できます。rsyslogd を起動する前に、コマンドラインで次のコマンドを実行します。

export RSYSLOG_DEBUGLOG="path"
export RSYSLOG_DEBUG="Debug"

path を、デバッグ情報をログ記録するファイルの場所に置き換えます。RSYSLOG_DEBUG 変数に利用可能なオプションの一覧は、man ページ rsyslogd(8) の関連セクションを参照してください。

/etc/rsyslog.conf ファイルで使用している構文が有効かどうかをチェックするには、以下を使用します。

rsyslogd -N 1

1 は、出力メッセージの長さのレベルを表します。現在提供されているのは 1 つのレベルのみなので、これは前方互換性オプションになります。ただし、検証を実行するには、この引数を追加する必要があります。

23.10. Journal の使用

Journal は systemd のコンポーネントで、ログファイルの表示および管理を担います。rsyslogd などの従来の syslog デーモンとの並列もしくはその代わりとして使用できます。Journal は、従来のロギングに関連する問題を処理するために開発されました。システムの他の部分と緊密に統合されており、さまざまなロギング技術およびログファイルのアクセス管理をサポートします。

ロギングデータは、Journal の journald サービスが収集、保存、処理を行います。カーネルやユーザー処理、標準出力、システムサービスの標準エラー出力、またはネイティブ API 経由から受信したロギング情報に基づいて、journals と呼ばれるバイナリーファイルを作成、維持します。これらの journals は構造化およびインデックス化され、これによりシーク時間が比較的速くなります。Journal エントリーは、一意の識別子を持つことが可能です。journald サービスは、各ログメッセージについて多数のメタデータを収集します。実際の journal ファイルはセキュリティー保護され、手動での編集はできません。

23.10.1. ログファイルの表示

journal ログにアクセスするには、journalctl ツールを使用します。ログタイプの基本的なビューを見るには、root で以下を入力します。

journalctl

このコマンドの出力は、システム上で生成されたすべてのログファイル一覧で、これにはシステムコンポーネントやユーザーが生成したメッセージも含まれます。この出力の構造は、/var/log/messages/ で使用されているものに似ていますが、以下の改善点があります。

  • エントリーの優先度が視覚的にマークされています。エラー優先度およびそれ以上の行は赤色のハイライト表示がされており、注意および警告の優先度の行には太字フォントが使われています。
  • タイムスタンプが使用中のシステムのローカルタイムゾーンに変換されます。
  • ローテーションされたログを含めて、すべてのログ記録済みデータが表示されます。
  • ブートの最初が特別行にタグ付けされます。

例23.18 journalctl の出力例

以下は、journalctl ツールが提供する出力例です。パラメーターなしで呼び出されると、エントリー一覧がタイムスタンプで始まり、その後にホスト名、操作を実行したアプリケーションが示され、実際のメッセージが続きます。この例では、journal ログの初めの 3 つのエントリーを表示しています。

# journalctl
-- Logs begin at Thu 2013-08-01 15:42:12 CEST, end at Thu 2013-08-01 15:48:48 CEST. --
Aug 01 15:42:12 localhost systemd-journal[54]: Allowing runtime journal files to grow to 49.7M.
Aug 01 15:42:12 localhost kernel: Initializing cgroup subsys cpuset
Aug 01 15:42:12 localhost kernel: Initializing cgroup subsys cpu

[...]

多くのケースでは、journal ログの最新のエントリーにのみ関連します。journalctl 出力を減らす最も簡単な方法は、-n オプションを指定して、指定された数の最新のログエントリーのみを一覧表示することです。

journalctl -n Number

Number を、表示する行数に置き換えます。数字を指定しないと、journalctl では最新の 10 エントリーが表示されます。

journalctl コマンドを使用すると、以下の構文で出力形式をできます。

journalctl -o form

form を、出力形式を指定するキーワードに置き換えます。複数のオプションがあります。すべてのフィールドを含む完全な構造化エントリーアイテムを返す verbose。バックアップおよびネットワーク転送に適したバイナリーストリームを作成する export。JSON データ構造としてエントリーをフォーマットする json。キーワードの完全なリストは、journalctl(1) の man ページを参照してください。

例23.19 詳細な journalctl 出力

すべてのエントリーに関する完全なメタデータを表示するには、以下を入力します。

# journalctl -o verbose
[...]

Fri 2013-08-02 14:41:22 CEST [s=e1021ca1b81e4fc688fad6a3ea21d35b;i=55c;b=78c81449c920439da57da7bd5c56a770;m=27cc
    _BOOT_ID=78c81449c920439da57da7bd5c56a770
    PRIORITY=5
    SYSLOG_FACILITY=3
    _TRANSPORT=syslog
    _MACHINE_ID=69d27b356a94476da859461d3a3bc6fd
    _HOSTNAME=localhost.localdomain
    _PID=562
    _COMM=dbus-daemon
    _EXE=/usr/bin/dbus-daemon
    _CMDLINE=/bin/dbus-daemon --system --address=systemd: --nofork --nopidfile --systemd-activation
    _SYSTEMD_CGROUP=/system/dbus.service
    _SYSTEMD_UNIT=dbus.service
    SYSLOG_IDENTIFIER=dbus
    SYSLOG_PID=562
    _UID=81
    _GID=81
    _SELINUX_CONTEXT=system_u:system_r:system_dbusd_t:s0-s0:c0.c1023
    MESSAGE=[system] Successfully activated service 'net.reactivated.Fprint'
    _SOURCE_REALTIME_TIMESTAMP=1375447282839181

[...]

この例では、単一ログエントリーを識別するフィールドを一覧表示しています。「高度なフィルタリング」 の説明にあるように、これらのメタデータはメッセージのフィルタリングに使用できます。可能なフィールドすべての説明は、systemd.journal-fields(7) の man ページを参照してください。

23.10.2. アクセス制御

デフォルトでは、root 権限のない Journal ユーザーは、自身の生成したログファイルしか見れません。システム管理者が特定のユーザーを adm グループに追加すると、これらユーザーはすべてのログファイルにアクセスできるようになります。これには、root で入力します。

usermod -a -G adm username

ここで、adm グループに追加されるように、username をユーザーの名前に置き換えます。次に、このユーザーは、rootユーザーと同じ journalctl コマンドの出力を受け取ります。アクセス制御は、永続ストレージが Journal に対して有効な場合にのみ機能することに注意してください。

23.10.3. ライブビューの使用

パラメーターを付けずに journalctl を呼び出すと、収集されたエントリーのうち最も古いものから一覧表示します。ライブビューでは、新たなエントリーが現れると継続的に印刷されるので、リアルタイムでログメッセージを監視できます。journalctl をライブビューモードで開始するには、以下を入力します。

journalctl -f

このコマンドは、最新のログ 10 行を返します。その後は journalctl ユーティリティーの実行が継続され、新たな変化があるとそれを直ちに表示します。

23.10.4. メッセージのフィルタリング

パラメーターを付けずに実行した journalctl コマンドの出力は大規模なものになることが多いため、様々なフィルタリング方法を使うとユーザーのニーズに合った情報を抽出できます。

優先度によるフィルタリング

ログメッセージは、システム上の間違った動作を追跡するために使用されることがよくあります。特定のエントリーまたはより高い優先度のエントリーのみを表示するには、以下の構文を使用します。

journalctl -p priority

priority を、以下のキーワード (または数字) に置き換えます。debug (7)、info (6)、notice (5)、warning (4)、err (3)、crit (2)、alert (1)、emerg (0)

例23.20 優先度によるフィルタリング

error もしくはそれ以上の優先度のエントリーのみを表示するには、以下を使用します。

journalctl -p err
時間によるフィルタリング

現在のブートのログエントリーのみを表示するには、以下を入力します。

journalctl -b

時折システムを再起動した場合は、-b を指定していも journalctl の出力が大幅に減りません。この場合は、時間ベースのフィルタリングの方が役に立ちます。

journalctl --since=value --until=value

--since および --until を使用すると、指定した時間範囲内に作成されたログメッセージのみを表示できます。以下の例のように、日付や時刻の形式で、これらのオプションに を渡すことができます。

例23.21 時間および優先度によるフィルタリング

フィルタリングオプションは組み合わせることで、特定のリクエストに沿って結果を絞り込むことができます。たとえば、warning またはそれ以上の優先度で、特定の時刻以降のメッセージのみを表示するには、以下を使用します。

journalctl -p warning --since="2013-3-16 23:59:59"
高度なフィルタリング

例23.19「詳細な journalctl 出力」 では、ログエントリーを特定し、フィルタリングに使用できるフィールドを一覧表示しています。systemd が保存できるメタデータの完全な説明は、systemd.journal-fields(7) の man ページを参照してください。各ログメッセーに対するこのメタデータは、ユーザーが介入することなく収集されます。値は通常テキストベースですが、バイナリーの大きな値になることもあります。フィールドには複数の値がある場合もありますが、一般的ではありません。

指定されたフィールドで発生する一意の値を一覧表示するには、以下の構文を使用します。

journalctl -F fieldname

fieldname を関心のあるフィールド名に置き換えます。

特定条件のみに合致するログエントリーのみを表示するには、以下の構文を使用します。

journalctl fieldname=value

fieldname をフィールド名に、value をそのフィールドに含まれる特定の値に置き換えます。そうすると、この条件に合致する行のみが返されます。

注記

systemd に保存されているメタデータフィールドはかなりの数になるので、関心のあるフィールド名そのものを忘れることがよくあります。名前が不確かな場合は、以下を入力します。

journalctl

そして、Tab キーを 2 回押します。これで、利用可能なフィールド名が一覧表示されます。コンテキストベースの Tab 補完入力はフィールド名で機能するので、フィールド名の明確な文字を入力して Tab を押すと、名前が自動的に完了します。同様に、フィールドから一意の値を一覧表示することもできます。タイプ:

journalctl fieldname=

そして Tab を 2 回押します。これは、journalctl -F fieldname の代替として機能します。

1 つのフィールドに複数の値を指定できます。

journalctl fieldname=value1 fieldname=value2 ...

同一フィールドで 2 つの値を指定すると、2 つの値の論理 OR 演算が行われます。value1 または value2 に一致するエントリーが表示されます。

複数のフィールドと値の組み合わせを指定して、出力をさらにしぼり込むこともできます。

journalctl fieldname1=value fieldname2=value ...

異なるフィールド名に対して 2 つの値を指定すると、値は論理 AND で合算されます。エントリーが表示されるには、両方の条件を満たす必要があります。

+ 記号を使うと、複数のフィールドに対して複数の値の論理 OR 演算を行えます。

journalctl fieldname1=value + fieldname2=value ...

このコマンドは、両方の条件に合致するエントリーだけでなく、少なくとも条件の 1 つに合致するエントリーを返します。

例23.22 高度なフィルタリング

UID 70 のユーザーが avahi-daemon.service または crond.service で作成したエントリーを表示するには、以下のコマンドを使用します。

journalctl _UID=70 _SYSTEMD_UNIT=avahi-daemon.service _SYSTEMD_UNIT=crond.service

_SYSTEMD_UNIT フィールドに 2 つの値があるため、両方の結果が表示されますが、これは _UID=70 の条件に合致する場合のみです。これは単に (UID=70 and (avahi or cron)) と表すこともできます。

上記のフィルタリングをライブビューモードで適用して、特定のログエントリーグループにおける最新の変更を追跡することもできます。

journalctl -f fieldname=value ...

23.10.5. 永続的ストレージの有効化

Journal はデフォルトでは、ログファイルをメモリーか /run/log/journal/ ディレクトリー内の小さいリングバッファーにのみ保存します。これは、journalctl の最近のログ履歴を表示するには十分なものです。このディレクトリーは揮発性なので、ログデータは永続的には保存されません。デフォルト設定では、syslog は journal ログを読み取り、/var/log/ ディレクトリーに保存します。永続的なロギングが有効になると、journal ファイル /var/log/journal に保存され、再起動後も維持されます。これにより、一部のユーザーにとっては、Journal が rsyslog の代わりとなることも可能です (ただし、本章の序論を参照のこと)。

永続的ストレージを有効にすると、以下の利点があります。

  • 長期的なトラブルシュートに使用できる、より豊富なデータが記録されます。
  • 直ちにトラブルシュートを行う場合には、再起動後により多くのデータが利用可能になります。
  • サーバーコンソールがログファイルからではなく、journal からデータを読み取ります。

永続的なストレージには、不利な点もあります。

  • 永続的なストレージを使用しても、保存されるデータ量はメモリーの空き容量に依存するため、全期間を保存できる保証はありません。
  • ログにより、多くのディスクスペースが必要になります。

Journal 用に永続的なストレージを有効にするには、以下の例のように手動で journal ディレクトリーを作成します。root タイプは以下のようになります。

mkdir -p /var/log/journal/

次に、journald を再起動して変更を適用します。

systemctl restart systemd-journald

23.11. グラフィカル環境でのログファイルの管理

上記のコマンドラインユーティリティー以外に、Red Hat Enterprise Linux 7 はログメッセージ管理用の使いやすい GUI を提供します。

23.11.1. ログファイルの表示

ほとんどのログファイルはプレーンなテキスト形式で保存されるため、Vi や Emacs などのテキストエディターで表示できます。ViEmacs などのテキストエディタで表示できます。一部のログファイルは、システム上のすべてのユーザーが読み取り可能ですが、ほとんどのログファイルを読み取るには root 権限が必要になります。

インタラクティブなリアルタイムアプリケーションでシステムのログファイルを表示するには、System Log を使用します。

注記

System Log を使用するには、まず root で以下のコマンドを実行して gnome-system-log パッケージがインストールされていることを確認します。

~]# yum install gnome-system-log

yum を使用したパッケージのインストールは 「パッケージのインストール」 を参照してください。

gnome-system-log パッケージをインストールしたら、ApplicationsSystem ToolsSystem Log の順にクリックするか、シェルプロンプトで以下のコマンドを入力して、System Log を開きます。

~]$ gnome-system-log

このアプリケーションは、存在するログファイルのみを表示します。そのため、図23.2「システムログ」 で表示されている一覧とは異なる場合があります。

図23.2 システムログ

システムログ

システムログ アプリケーションを使用すると、既存のログファイルをフィルタリングできます。ギアの記号で示されたボタンをクリックしてメニューを表示し、メニュー:[Filters > > Manage Filters] を選択して必要なフィルターを定義または編集します。

図23.3 システムログ - フィルター

システムログ - フィルター

フィルターを追加または編集することで、図23.4「システムログ - フィルターの定義」 のようにパラメーターを定義できます。

図23.4 システムログ - フィルターの定義

システムログ - フィルターの定義

フィルターを定義する際には、以下のパラメーターを編集できます。

  • Name: フィルターの名前を指定します。
  • Regular Expression: ログファイルに適用され、その中の実行可能なテキストの文字列に一致するよう試行する正規表現を指定します。
  • Effect

    • Highlight: これが有効な場合、検索結果は選択した色で強調されます。テキストのバックグラウンドまたはフォアグラウンドを強調するかどうかを選択できます。
    • Hide: これが有効な場合は、検索結果は閲覧中のログファイルからは非表示になります。

少なくとも 1 つのフィルターが定義されていれば、Filters メニューからそれを選択することができ、そのフィルターが定義済みの文字列を自動的に検索して、現在表示しているログファイル内でのマッチを強調表示または非表示にします。

図23.5 システムログ - フィルターの有効化

システムログ - フィルターの有効化

Show matches only オプションを選択すると、現在表示されているログファイル内でマッチした文字列のみが表示されます。

23.11.2. ログファイルの追加

一覧に表示するログファイルを追加するには、FileOpen の順に選択します。これにより、表示するログファイルのディレクトリーおよびファイル名を選択できる Open Log ウィンドウが表示されます。図23.6「システムログ - ログファイルの追加」 では、Open Log ウィンドウを示しています。

図23.6 システムログ - ログファイルの追加

システムログ - ログファイルの追加

ファイルを開くには、開く ボタンをクリックします。ファイルは表示中の一覧に直ちに追加されるため、そのファイルを選択してコンテンツを表示できます。

注記

System Log を使用すると、.gz 形式のログファイルを開くことができます。

23.11.3. ログファイルのモニタリング

システムログ はデフォルトで、開いているすべてのログを監視します。監視されているログファイルに新しい行が追加されると、そのログ名はログの一覧に太字で表示されます。ログファイルが選択または表示されると、ログファイルの下部に新しい行が太字で表示されます。図23.7「システムログ - 新しいログ通知」 は、cron ログファイルと messages ログファイル内の新しいアラートを示しています。messages ログファイルをクリックすると、ファイル内のログが表示されます (新しい行は太字で表示されます)。

図23.7 システムログ - 新しいログ通知

システムログ - 新しいログ通知

23.12. 関連資料

rsyslog デーモンの設定方法、およびログファイルの場所の特定、表示、モニタリング方法に関する詳細情報は、以下のリソースを参照してください。

インストールされているドキュメント

  • rsyslogd(8): rsyslogd デーモンの man ページは、その使用方法を説明しています。
  • rsyslog.conf(5): rsyslog.conf という名前の man ページでは、利用可能な設定オプションが説明されています。
  • logrotate(8): logrotate ユーティリティーの man ページは、その設定方法と使用方法を詳細に説明しています。
  • journalctl(1): journalctl デーモンの man ページは、その使用方法を説明しています。
  • journald.conf(5): この man ページは、利用可能な設定オプションを説明しています。
  • systemd.journal-fields(7): この man ページでは、特別な Journal フィールドを一覧表示しています。

インストール可能なドキュメント

/usr/share/doc/rsyslogversion/html/index.html: このファイルはオプションチャンネルの rsyslog-doc パッケージで提供され、rsyslog に関する情報を含みます。Red Hat 追加チャンネルの詳細については、「Optional および Supplementary リポジトリーの追加」 を参照してください。ドキュメンテーションにアクセスする前に、root で以下のコマンドを実行する必要があります。

~]# yum install rsyslog-doc

オンラインドキュメント

rsyslog ホームページは、追加のドキュメンテーション、設定例、および動画チュートリアルを提供します。使用しているバージョンに関連するドキュメントを参照してください。

関連項目

  • 6章権限の取得 では、su および sudo コマンドを使って管理者権限を取得する方法を説明しています。
  • 10章systemd によるサービス管理 では、systemd の詳細情報と、systemctl コマンドを使用してシステムサービスを管理する方法が説明されています。

このページには機械翻訳が使用されている場合があります (詳細はこちら)。