Red Hat Training

A Red Hat training course is available for Red Hat Enterprise Linux

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 セッションで処理されたものであっても、ジャーナルのすべてのメッセージが処理されます。
注記

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

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

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