Hitachi

JP1 Version 13 JP1/Integrated Management 3 - Manager 導入・設計ガイド


9.5.4 ログ監視機能

ログ監視機能は,アドオンプログラムとして,ユーザー環境のログを監視して通知する機能を提供します。

ログ監視機能は,監視対象のログファイルに出力される情報,および,Windowsのイベントログに出力される情報を,OSSのFluentdを使用してJP1イベントに変換します。変換したJP1イベントは,統合マネージャーホストのJP1/Baseに登録され,JP1/IM - Viewや統合オペレーション・ビューアーで表示できます。

〈この項の構成〉

(1) 機能概要

ログ監視機能は,JP1/IM - Agentのアドオンプログラムの1つとして,テキスト形式のログファイルに出力されたログメッセージ,および,WindowsイベントログのイベントをJP1イベントに変換する機能を提供します。ログ監視機能は,OSSのFluentdを使用しています。

ログ監視機能で提供する機能の一覧を,次に示します。詳細については,「(2)インプットプラグイン機能(Input Plugins)」,「(3)テキスト形式のログファイルの監視機能(tailプラグイン)」,および「(4)Windowsイベントログの監視機能(windows_eventlog2プラグイン)」を参照してください。小括弧内に記載している文字列は,FluentdがOSSとして提供している機能の名称です。

表9‒26 機能一覧

機能

説明

インプットプラグイン機能

(Input Plugins)

テキスト形式のログファイルに出力されたログメッセージおよびWindowsイベントログのイベントを読み込み,解析します。

テキスト形式のログファイルの監視機能(tail)

ログメッセージを読み込み,解析します。

Windowsイベントログの監視機能(windows_eventlog2)

Windowsイベントログのイベントを読み込み,解析します。

イベント変換機能

(Filter Plugins)

監視するログの条件と,JP1イベントに変換したときの属性を指定します。

ログデータの編集機能(record_transformer)

ログの監視結果をJP1イベントに変換したときに設定する,属性と値を指定します。

ログデータの抽出機能(grep)

監視するログの条件を指定します。

アウトプットプラグイン機能

(Output Plugins)

ログの監視結果を出力します。出力方法としてJP1イベントへの変換と,Fluentd自身のログファイルへの出力があります。

HTTP POSTリクエスト機能(http)

JP1/IM - Managerに通知し,ログの監視結果をJP1イベントに変換します。

複数アウトプット機能(copy)

ログの監視結果を,複数のアウトプットプラグイン機能で出力します。

標準出力機能(stdout)

ログの監視結果をFluentdの標準出力に出力します。標準出力に出力された情報は,Fluentdのログファイルに出力されます。

ログ出力機能

Fluentdの動作に関する情報を,Fluentdのログファイルに出力します。

メトリック送信機能

ログが監視されていることを表すメトリックを,JP1/IM - Managerに送信します。

インプットプラグイン機能でログを検知すると,その後イベント変換機能,アウトプットプラグイン機能が順番に動作し,ユーザーの監視したいログ情報がJP1イベントに変換されます。それぞれの機能の設定は,定義ファイルで行います。

インプットプラグイン機能の設定は,監視定義ファイルの[Input Settings]セクションで行います。監視定義ファイルには,テキスト形式のログファイルを監視する「テキスト形式のログファイルの監視定義ファイル」とイベントログを監視する「Windowsイベントログの監視定義ファイル」があります。各定義ファイルの仕様については,マニュアル「JP1/Integrated Management 3 - Manager コマンド・定義ファイル・APIリファレンス」(2. 定義ファイル)の該当するファイルを参照してください。「テキスト形式のログファイルの監視定義ファイル」は,ラップアラウンドするログファイル群ごと(ラップアラウンドしないログファイルの場合はログファイルごと)に作成します。

イベント変換機能の設定も,監視定義ファイルで行います。ログデータの編集機能の設定は[Attributes Settings]セクションで行い,JP1イベントに変換したときに出力する属性と値を指定できます。ログデータの抽出機能の設定は[Inclusion Settings]セクションと[Exclusion Settings]セクションで行い,監視するログの条件を指定します。

アウトプットプラグイン機能の設定は,ログ監視共通定義ファイルで行います。HTTP POSTリクエスト機能の設定は[Output Settings]セクションで行い,JP1イベント化するときの通知先やリトライ間隔などを指定します。ログ監視共通定義ファイルについては,マニュアル「JP1/Integrated Management 3 - Manager コマンド・定義ファイル・APIリファレンス」の「ログ監視共通定義ファイル(jpc_fluentd_common.conf)」(2. 定義ファイル)を参照してください。

(2) インプットプラグイン機能(Input Plugins)

インプットプラグイン機能は,ログメッセージおよびイベントログを読み込みます。

インプットプラグインで使用できるログの読み込みは,次のとおりです。

(3) テキスト形式のログファイルの監視機能(tailプラグイン)

tailは,テキスト形式のログファイルの監視機能を持つインプットプラグインです。

デフォルトの設定では,tailによる監視は,初回の起動では起動後に追加されたログから読み込みを開始します。ログがローテートすると,先頭から新しいファイルの読み込みを再開します。confファイルでtailのpathに監視対象ログファイルのパスを指定すると,ログファイルが更新されてすぐにtailプラグインが更新されたログを読み込みます。

(a) ログファイルのパス設定

tailプラグインは,ファイルの内容によらず絶対パスで指定したファイルをすべて読み込みます。テキスト形式のログファイルのログメッセージを読み込むには,定義ファイルにログファイルの絶対パスを指定する必要があります。Windowsの場合,ネットワークドライブ上のディレクトリおよびファイルは指定できません。

パスの文字列にはワイルドカードを指定できます。使用できるワイルドカードは「*(任意の0文字以上の文字列)」です。また,複数のパスを指定できます。複数のパスを指定する場合は,「,」で区切って指定します。

ワイルドカードを使用して指定したファイルのパスに,バイナリ形式などの意図しないファイルが含まれている場合は,ファイル内の文字列が読み込まれます。その結果,意図しないFluentdのログや,意図しないメッセージのJP1イベントが発行されます。この問題を回避するために,ワイルドカードは文字列と併用して,監視対象のログファイル名に正しく合致するように設定する必要があります。

設定例を次に示します。

  • /path/to/aディレクトリと,/path/to/a2ディレクトリ以下に格納されたログファイルをすべて監視する場合

    path /path/to/a/*, /path/to/a2/*
  • /path/to1/aディレクトリ以下,/path/to2/a2ディレクトリ以下のような,pathからみて3階層目にあるログファイルをすべて監視する場合(この場合,/path/to1ディレクトリ,/path/to2ディレクトリ以下に格納されているログファイルは監視されません)

    path /path/*/*
  • /path/to/bディレクトリ以下に格納される,ラップアラウンドするログファイル群(funcAlog1.logfuncAlog2.logfuncAlog3.log,…)を監視する場合

    path /path/to/b/funcAlog*.log
  • 複数のログファイル群が同一のディレクトリ(/path/to/c)に出力される場合

    • fluentd_upB_tail.conf

    path /path/to/c/funcBlog*
    • fluentd_upC_tail.conf

    path /path/to/c/funcClog*

(b) 監視できるログファイル

一つのログファイルに追加書き込みし続けるファイル,または,ログファイルが一定の容量に達すると,別のファイル名で新たにログファイルを作成して書き込むファイルを監視できます。

監視できるログファイルの形式を次に示します。

  • シーケンシャルファイル(SEQ)

    一つのログファイルに追加書き込みし続けるファイル,または,ログファイルが一定の容量に達すると,別のファイル名で新たにログファイルを作成して書き込むファイルです。

  • シーケンシャルファイル(SEQ2)

    • Windowsの場合

      同一ボリューム内でファイル名を変更したあと,変更前のファイル名と同じ名称のファイルを作成して新たにログを書き込むファイルです。

    • Linuxの場合

      ファイル名を変更,またはファイルをいったん削除したあと,変更または削除前のファイル名と同じ名称のファイルを作成して新たにログを書き込むファイルです。

  • シーケンシャルファイル(SEQ3)

    • Windows限定

      ファイルをいったん削除したあと,削除前のファイル名と同じ名称のファイルを作成して新たにログを書き込むファイルです。

  • ラップアラウンドファイル(WRAP2)

    ログファイルが一定の容量に達してラップアラウンドするとき,データを削除して再び先頭からデータを書き込む形式のファイルです。

  • UPD タイプのログファイル(UPD)

    ファイル名に日付など不定な文字列が設定されるログファイルを監視するときに使用します。不定な文字列部分は,ワイルドカードで指定します。

(c) 監視できないログファイル

ログファイルが一定の容量に達すると,ラップアラウンドして,再び先頭からデータを上書きする形式のファイルは監視できません。

(d) 監視できるログファイルの文字コード

監視できるログファイルの文字コードを次に示します。

  • UTF-8(初期値)(日本語,英語)

  • UTF-16LE(日本語,英語)

  • UTF-16BE(日本語,英語)

  • Shift_JIS(日本語)

  • Windows-31J(日本語)

  • C(英語)

  • GB18030(中国語)

UTF-8,Cのログファイルを監視する場合は,from_encodingとencodingを指定しません。UTF-8,C以外のログファイルを監視する場合は,from_encodingとencodingを指定する必要があります。encodingにはUTF-8,from_encodingには監視するログファイルの文字コードを指定します。誤った文字コードを指定した場合,意図した文字列を抽出できなかったり,意図した文字コードで変換できずに文字化けした内容をJP1イベントとして通知したりします。

(e) ファイルの最新読み込み位置の記録

tailでは,監視対象のファイルから最後に読み込んだ位置をpos_fileに記録します。pos_fileは監視定義ごとに作成する必要があります。pos_fileはtailの初回起動時に作成されます。JP1/IM - Agentのデフォルトの設定では,初回ログ読み込みではtailはログファイルの起動後に追加されたログから読み込みを開始し,pos_fileを作成して最新読み込み位置を記録します。起動中は更新されたログを読み込んで,最新読み込み位置をpos_fileに記録します。

2回目以降の起動では,tailはpos_fileに記録した最新読み込み位置から更新された部分を読み込みます。

Fluentd停止中にpos_fileの中身が破壊されている場合や,pos_fileが消去されている場合は,次回起動時に,初回起動時と同様にログファイルの末尾から読み込み,pos_fileを更新(作成)して最新読み込み位置を記録します。この場合,停止中に監視対象ログファイルに追加されたログを監視しません。

(f) 初回起動時の既存ログの読み込み

JP1/IM - Agentのデフォルトの設定では,初回ログ読み込みではtailはログファイルの末尾から読み込みを開始します。初回起動時にすでに追加されていたログを読み込むには,監視定義ファイルのパラメータread_from_headをtrue(デフォルトはfalse)に変更する必要があります。

(g) ログのパース機能(parseプラグイン)

パースプラグインは,読み込んだログを解析して,指定したフォーマットで切り出します。

parseプラグインで指定できるログのフォーマット(type)は,次のとおりです。

type

説明

none(デフォルト)

解析,構造化をせずに1行のログをそのまま読み込みます。

regexp

正規表現で指定したパターンに合致した1行のログを読み込みます。

multiline

正規表現で指定したパターンに合致した複数行のログを読み込みます。

syslog

syslogが出力したログを読み込みます。

csv

CSV形式(コンマ区切り)のログを読み込みます。

tsv

TSV形式(タブ区切り)のログを読み込みます。

ltsv

LTSV形式(ラベル付きタブ区切り)のログを読み込みます。

  • none

    初期設定では,新たに追加されたログ1行をすべて読み込みます。

  • regexp

    typeにregexpを指定することで,正規表現で指定したフォーマットに従ってログの解析,切り出しが可能です。正規表現で指定したパターンに合致しなかったログの行は読み込まず,Fluentdのログに警告メッセージを出力します。出力される警告メッセージについては,マニュアル「JP1/Integrated Management 3 - Manager コマンド・定義ファイル・APIリファレンス」の「テキスト形式のログファイルの監視定義ファイル(fluentd_@@trapname@@_tail.conf.template)」(2. 定義ファイル)を参照してください。

    ログを「time」の名前で切り出すとき,timezoneを使用して,ログが出力されたときのタイムゾーンを指定できます。詳細については,マニュアル「JP1/Integrated Management 3 - Manager コマンド・定義ファイル・APIリファレンス」の「テキスト形式のログファイルの監視定義ファイル(fluentd_@@trapname@@_tail.conf.template)」(2. 定義ファイル)を参照してください。

  • multiline

    multilineパースプラグインは,複数行のログを読み込んでログを解析します。テキスト形式のログファイルの監視定義ファイル内の[Input Settings]で,パラメーター「format_firstline」と「formatN」を正規表現で設定すると,正規表現の名前付きキャプチャ機能を使用して,複数行のログを構造化できます。設定するパラメーターの詳細については,マニュアル「JP1/Integrated Management 3 - Manager コマンド・定義ファイル・APIリファレンス」の「テキスト形式のログファイルの監視定義ファイル(fluentd_@@trapname@@_tail.conf.template)」(2. 定義ファイル)を参照してください。

    Javaのスタックトレースログを読み込む場合の設定例を,次に示します。

    • 定義ファイル

    <parse>
      @type multiline
      format_firstline /\d{4}-\d{1,2}-\d{1,2}/
      format1 /^(?<time>\d{4}-\d{1,2}-\d{1,2} \d{1,2}:\d{1,2}:\d{1,2}) \[(?<thread>.*)\] (?<level>[^\s]+)(?<message>.*)/
    </parse>
    • 監視対象のログファイルに追加されるログ

    2013-3-03 14:27:33 [main] INFO  Main - Start
    2013-3-03 14:27:33 [main] ERROR Main - Exception
    javax.management.RuntimeErrorException: null
        at Main.main(Main.java:16) ~[bin/:na]
    2013-3-03 14:27:33 [main] INFO  Main - End
    • ログをパースした結果

    time:
    2013-03-03 14:27:33 +0900
    record:
    {
      "thread" :"main",
      "level"  :"INFO",
      "message":"  Main - Start"
    }
     
    time:
    2013-03-03 14:27:33 +0900
    record:
    {
      "thread" :"main",
      "level"  :"ERROR",
      "message":" Main - Exception\njavax.management.RuntimeErrorException: null\n    at Main.main(Main.java:16) ~[bin/:na]"
    }
     
    time:
    2013-03-03 14:27:33 +0900
    record:
    {
      "thread" :"main",
      "level"  :"INFO",
      "message":"  Main - End"
    }

    Railsのログを読み込む場合の設定例を,次に示します。

    • 定義ファイル

    <parse>
      @type multiline
      format_firstline /^Started/
      format1 /Started (?<method>[^ ]+) "(?<path>[^"]+)" for (?<host>[^ ]+) at (?<time>[^ ]+ [^ ]+ [^ ]+)\n/
      format2 /Processing by (?<controller>[^\u0023]+)\u0023(?<controller_method>[^ ]+) as (?<format>[^ ]+?)\n/
      format3 /(  Parameters: (?<parameters>[^ ]+)\n)?/
      format4 /  Rendered (?<template>[^ ]+) within (?<layout>.+) \([\d\.]+ms\)\n/
      format5 /Completed (?<code>[^ ]+) [^ ]+ in (?<runtime>[\d\.]+)ms \(Views: (?<view_runtime>[\d\.]+)ms \| ActiveRecord: (?<ar_runtime>[\d\.]+)ms\)/
    </parse>
    • 監視対象のログファイルに追加されるログ

    Started GET "/users/123/" for 127.0.0.1 at 2013-06-14 12:00:11 +0900
    Processing by UsersController#show as HTML
      Parameters: {"user_id"=>"123"}
      Rendered users/show.html.erb within layouts/application (0.3ms)
    Completed 200 OK in 4ms (Views: 3.2ms | ActiveRecord: 0.0ms
    • ログをパースした結果

    time:
    1371178811 (2013-06-14 12:00:11 +0900)
     
    record:
    {
      "method"           :"GET",
      "path"             :"/users/123/",
      "host"             :"127.0.0.1",
      "controller"       :"UsersController",
      "controller_method":"show",
      "format"           :"HTML",
      "parameters"       :"{ \"user_id\":\"123\"}",
      ...
    }
  • syslog

    syslogパースプラグインは,syslogが出力したログを解析します。設定するパラメーターの詳細については,マニュアル「JP1/Integrated Management 3 - Manager コマンド・定義ファイル・APIリファレンス」の「テキスト形式のログファイルの監視定義ファイル(fluentd_@@trapname@@_tail.conf.template)」(2. 定義ファイル)を参照してください。

    RFC-3164フォーマットのログを読み込む場合の設定例を,次に示します。

    • 定義ファイル

    <parse>
      @type syslog
      time_format %b %d %H:%M:%S
      message_format rfc3164
      with_priority false
      parser_type string
      support_colonless_ident true
    </parse>
    • 監視対象のログファイルに追加されるログ

    <6>Feb 28 12:00:00 192.168.0.1 fluentd[11111]: [error] Syslog test
    • ログをパースした結果

    time:
    1362020400 (Feb 28 12:00:00)
     
    record:
    {
      "pri"    : 6,
      "host"   : "192.168.0.1",
      "ident"  : "fluentd",
      "pid"    : "11111",
      "message": "[error] Syslog test"
    }

    RFC-5424フォーマットのログを読み込む場合の設定例を,次に示します。

    • 定義ファイル

    <parse>
      @type syslog
      time_format %b %d %H:%M:%S
      rfc5424_time_format %Y-%m-%dT%H:%M:%S.%L%z
      message_format rfc5424
      with_priority false
      parser_type string
      support_colonless_ident true
    </parse>
    • 監視対象のログファイルに追加されるログ

    <16>1 2013-02-28T12:00:00.003Z 192.168.0.1 fluentd 11111 ID24224 [exampleSDID@20224 iut="3" eventSource="Application" eventID="11211"] Hi, from Fluentd!
    • ログをパースした結果

    time:
    1362052800 (2013-02-28T12:00:00.003Z)
     
    record:
    {
      "pri"      : 16,
      "host"     : "192.168.0.1",
      "ident"    : "fluentd",
      "pid"      : "11111",
      "msgid"    : "ID24224",
      "extradata": "[exampleSDID@20224 iut=\"3\" eventSource=\"Application\" eventID=\"11211\"]",
      "message"  : "Hi, from Fluentd!"
    }
  • csv

    csvパースプラグインは,csv形式のログを解析します。設定するパラメーターの詳細については,マニュアル「JP1/Integrated Management 3 - Manager コマンド・定義ファイル・APIリファレンス」の「テキスト形式のログファイルの監視定義ファイル(fluentd_@@trapname@@_tail.conf.template)」(2. 定義ファイル)を参照してください。

    csv形式のログを読み込む場合の設定例を,次に示します。

    • 定義ファイル

    <parse>
      @type csv
      keys time,host,req_id,user
      time_key time
    </parse>
    • 監視対象のログファイルに追加されるログ

    2013/02/28 12:00:00,192.168.0.1,111,-
    • ログをパースした結果

    time:
    1362020400 (2013/02/28/ 12:00:00)
     
    record:
    {
      "host"   : "192.168.0.1",
      "req_id" : "111",
      "user"   : "-"
    }
  • tsv

    tsvパースプラグインは,tsv形式のログを解析します。設定するパラメーターの詳細については,マニュアル「JP1/Integrated Management 3 - Manager コマンド・定義ファイル・APIリファレンス」の「テキスト形式のログファイルの監視定義ファイル(fluentd_@@trapname@@_tail.conf.template)」(2. 定義ファイル)を参照してください。

    tsv形式のログを読み込む場合の設定例を,次に示します。

    • 定義ファイル

    <parse>
      @type tsv
      keys time,host,req_id,user
      time_key time
    </parse>
    • 監視対象のログファイルに追加されるログ

    2013/02/28 12:00:00\t192.168.0.1\t111\t-
    • ログをパースした結果

    time:
    1362020400 (2013/02/28/ 12:00:00)
     
    record:
    {
      "host"   : "192.168.0.1",
      "req_id" : "111",
      "user"   : "-"
    }
  • ltsv

    ltsvパースプラグインは,ltsv形式のログを解析します。設定するパラメーターの詳細については,マニュアル「JP1/Integrated Management 3 - Manager コマンド・定義ファイル・APIリファレンス」の「テキスト形式のログファイルの監視定義ファイル(fluentd_@@trapname@@_tail.conf.template)」(2. 定義ファイル)を参照してください。

    ltsv形式のログを読み込む場合の設定例を,次に示します。

    • 定義ファイル

    <parse>
      @type ltsv
      keys time,host,req_id,user
      time_key time
    </parse>
    • 監視対象のログファイルに追加されるログ

    time:2013/02/28 12:00:00\thost:192.168.0.1\treq_id:111\tuser:-
    • ログをパースした結果

    time:
    1362020400 (2013/02/28/ 12:00:00)
     
    record:
    {
      "host"   : "192.168.0.1",
      "req_id" : "111",
      "user"   : "-"
    }

    delimiter_patternを使用する場合の設定例を,次に示します。

    • 定義ファイル

    <parse>
      @type ltsv
      delimiter_pattern /\s+/
      label_delimiter =
    </parse>
    • 監視対象のログファイルに追加されるログ

    timestamp=1362020400 host=192.168.0.1  req_id=111 user=-
    • ログをパースした結果

    record:
    {
      "timestamp": "1362020400",
      "host"   : "192.168.0.1",
      "req_id" : "111",
      "user"   : "-"
    }

(4) Windowsイベントログの監視機能(windows_eventlog2プラグイン)

windows_eventlog2は,Windowsイベントログからイベントを読み込むインプットプラグインです。

(a) 監視できるログの種別

ログの種別とは,Windows の[イベント ビューアー]に表示される各ログの名前のことです。confファイルのchannelパラメーターにログの種別を指定すると,その種別のログを監視できます。 windows_eventlog2 はデバッグログと分析ログを除くすべてのチャンネルを読むことが可能です。

指定できるログの種別の例を,次に示します。

  • Windowsのイベントログ

    • application

    • system

    • setup

    • security

  • アプリケーションとサービスのログ

    HardwareEventsなど

監視できるログの種別は,次の手順で確認します。

  1. コマンドプロンプト上でwevtutilコマンドを実行し,システムに登録されている「ログの種別」の一覧を確認します。

    コマンドの入力例を次に示します。

    >wevtutil el
  2. 手順1で確認した「ログの種別」の有効・無効の設定および種別を「ログの種別」ごとに確認します。

    コマンドの入力例を次に示します。

    >wevtutil gl Application
    name: Application
    enabled: true
    type: Admin
     :

    次の条件をすべて満たす場合だけ,channelパラメーターに指定できます。

    • enabledが「true」である

    • typeが「Admin」または「Operational」である

(b) 監視できるログファイル

サポートしている言語環境のWindowsイベントログを監視できます。サポートする言語環境については,「9.3.2 言語設定」を参照してください。

(c) イベントログの最新読み込み位置の記録(storageプラグイン)

windows_eventlog2では,storageプラグインを使ってログの最新読み込み位置をローカルストレージにJSON形式で記録することができます。

(d) 注意事項

Fluentdの初回起動から,停止するまでの間に,監視対象のWindowsイベントログにイベントが追加されなかった場合,次に起動するまでの停止中に追加されたWindowsイベントログは監視できません。また,この場合次回起動時に警告メッセージが出力されます。出力される警告メッセージの例は以下の通りです。

[warn]: #0 This stored bookmark is incomplete for using. Referring `read_existing_events` parameter to subscribe: <BookmarkList>
</BookmarkList>, channel:  (チャネル名)

イベントログが一件も追加されず再びFluentdを停止した場合,停止中に追加されたイベントログは監視できず,次回起動時に同様の警告メッセージが出力されます。

Fluentdに新たにWindowsイベントログの監視定義を追加,または監視定義ファイルの内容を変更して,最新読み込み位置が保存されていないチャネルの監視を開始した場合も同様に,停止までの間に監視対象のWindowsイベントログにイベントログが追加されなかった場合は,次に起動するまでの停止中に追加されたWindowsイベントログが監視されず,同様の警告メッセージが出力されます。

次回起動中にイベントログが新たに追加された場合,イベントログが監視され,その後のイベント監視は問題なく動作します。

(5) イベント変換機能(Filter Plugins)

イベント変換機能は,読み込んだログを編集したり,特定のフィールドを抽出したりできます。イベント変換の機能は,次のとおりです。

(6) ログデータの編集機能(record transformerプラグイン)

record_transformerは,ログファイルから読み込んだログデータを編集します。

ログファイルから読み込んだログデータの編集と,リモートライトするメトリックのラベルの編集を行います。メトリックのラベルは[Metric Settings]セクションで,JP1イベントの属性は[Attributes Settings]セクションで指定できます。初期値については,マニュアル「JP1/Integrated Management 3 - Manager コマンド・定義ファイル・APIリファレンス」の「テキスト形式のログファイルの監視定義ファイル(fluentd_@@trapname@@_tail.conf.template)」(2. 定義ファイル)を参照してください。

ユーザーは,定義ファイルの[Metric Settings]セクションと[Attributes Settings]セクションのrecord_transformerが持つパラメーターを編集できます。

[Metric Settings]セクションでは,メトリックのラベルを指定します。ユーザーは次のパラメーターを指定できます。

[Attributes Settings]セクションでは,ログデータをJP1/IM - Managerに送信してJP1イベントに変換するために,ログのフィールドをJP1/IM - ManagerのAPIのリクエスト形式に沿った形に編集できます。

ユーザーは次のパラメーターを指定できます。

(7) ログデータの抽出機能(grepプラグイン)

grepは,読み込んだログの中から指定したパターンに合致するログデータを抽出します。JP1/IM - Managerに送信してJP1イベントに変換するログを選定できます。

(a) 抽出条件の指定

抽出条件は,正規表現で指定します。<regexp>ディレクティブ内に,次の2つのパラメーターを指定することで,正規表現の条件を設定できます。

  • key

    抽出する正規表現のパターンを識別する名称

  • pattern

    抽出する正規表現

抽出条件を複数作成し,次に示す論理和と論理積によってデータを抽出できます。

  • 論理積(AND)条件の指定

    複数の正規表現パターンのすべてを満たすログを抽出する場合は,<and>ディレクティブの内側に<regexp>ディレクティブを配置します。<and>ディレクティブの内側に配置する<regexp>ディレクティブのkeyは,それぞれ異なる必要があります。keyが重複していた場合,Fluentd起動時にエラーが発行されて起動しません。

  • 論理和(OR)条件の指定

    複数の正規表現パターンのいずれかを満たすログを抽出する場合は,<or>ディレクティブの内側に<regexp>ディレクティブを配置します。<or>ディレクティブの内側に配置する<regexp>ディレクティブのkeyは,それぞれ異なる必要があります。keyが重複していた場合,Fluentd起動時にエラーが発行されて起動しません。

(b) 除外条件の指定

除外する条件正規表現で指定できます。<exclude>ディレクティブ内に次の2つのパラメーターを指定することで,正規表現の条件を設定できます。

  • key

    除外する正規表現のパターンを識別する名称

  • pattern

    除外する正規表現

除外条件を複数作成し,次に示す論理和と論理積によってデータを除外できます。

  • 論理積(AND)条件の指定

    複数の正規表現パターンのすべてを満たすログを除外する場合は,<and>ディレクティブの内側に<exclude>ディレクティブを配置します。<and>ディレクティブの内側に配置する< exclude >ディレクティブのkeyは,それぞれ異なる必要があります。keyが重複していた場合,Fluentd起動時にエラーが発行されて起動しません。

  • 論理和(OR)条件の指定

    複数の正規表現パターンのいずれかを満たすログを除外する場合は,<or>ディレクティブの内側に<exclude>ディレクティブを配置します。<or>ディレクティブの内側に配置する< exclude >ディレクティブのkeyは,それぞれ異なる必要があります。keyが重複していた場合,Fluentd起動時にエラーが発行されて起動しません。

(c) 設定例

ログの抽出条件,あるいは除外条件は<>で囲まれたディレクティブ(次の設定規則におけるDIRECTIVE)を使用して設定します。

::=」は,左辺にあるものを右辺にあるもので定義することを示します。「|」は,この記号の前後にあるもののどれかを示します。

CR ::= 改行
KEY ::= key 文字列
PATTERN ::= pattern /正規表現/ 
 
DIRECTIVE ::= REGEXP | EXCLUDE | AND | OR
REGEXP ::= <regexp> KEY CR PATTERN</regexp>
EXCLUDE ::= <exclude> KEY CR PATTERN </exclude>
EXPRESSION ::= REGEXP | EXCLUDE 
EXPRESSIONS ::= EXPRESSION EXPRESSION  |  EXPRESSIONS EXPRESSION 
AND ::= <and> EXPRESSIONS </and>
OR ::= <or> EXPRESSIONS </or> |

一つのログ監視定義にて,AND,ORで指定できる<regexp>ディレクティブ,または<exclude>ディレクティブの合計数は256です。

設定例を次に示します。

  • MESSAGEフィールドに文字列”Error”を含むログを抽出する場合

@type△grep
  <regexp>
    key MESSAGE
    pattern /Error /
  </regexp>
  • MESSAGEフィールドに文字列”Info” を含むログを除外する場合

@type△grep
  <exclude>
    key MESSAGE
    pattern /Info/
  </exclude>
  • VALUEフィールドが数値で,かつRECORD_NAMEがcpu_から始まるログを抽出する場合

@type△grep
  <and>
    <regexp>
      key VALUE
      pattern /[1-9]\d*/
    </regexp>
  
    <regexp>
      key RECORD_NAME
      pattern /^cpu_/
    </regexp>
  </and>
  • STATUS_CODEフィールドが5から始まる3桁の数値である,またはURLの末尾が.cssであるログを除外する場合

@type△grep
  <or>
    <exclude>
      key STATUS_CODE
      pattern /^5\d\d$/
    </exclude>
  
    <exclude>
      key URL
      pattern /\.css$/
    </exclude>
  </or>

(8) アウトプットプラグイン機能(Output Plugins)

アウトプットプラグインは,ログの監視結果を出力します。アウトプットプラグインの機能は,次のとおりです。

(9) HTTP POSTリクエスト機能(httpプラグイン)

httpプラグインは,POSTメソッドを使用してメトリックとログデータをJSON方式で転送します。

(a) メトリックの送信

endpointでトレンドデータ書き込みAPIのURLを指定すると,メトリックをPOSTできます。POSTしたメトリックは,トレンドデータとして統合オペレーション・ビューアーから確認できます。また,メトリックをPOSTすることでIM管理ノードの作成ができます。

ユーザーは,トレンドデータ書き込みAPIを指定する必要があります。

初期値は次のとおりです。

endpoint http://統合エージェントホスト名:ポート/ima/api/v1/proxy/promscale/write

(b) ログデータの送信

endpointでJP1イベント変換APIのURLを指定すると,ログデータをPOSTできます。POSTしたログデータは,JP1イベントとして統合オペレーション・ビューアーから確認できます。

ユーザーは,JP1イベント変換APIを指定する必要があります。

初期値は次のとおりです。

endpoint http://統合エージェントホスト名:ポート/ima/api/v1/proxy/imdd/im/api/v1/events/transform

(c) 送信するログデータのバッファ機能(buffer)

Fluentdはアウトプットプラグインを使用する際に,バッファ機能を使用します。バッファは,取得したログデータを蓄積しておく場所のことです。バッファ機能を使用することで,データを送信する頻度の調整や,送信に失敗したデータの一時保管ができます。httpプラグインは受け取ったログデータをバッファに蓄積します。蓄積したログデータは一定の間隔で統合エージェント管理基盤にPOSTされます。

  • バッファファイルのパス設定

    ユーザーは,バッファを格納するディレクトリの絶対パスを指定する必要があります。定義ファイルの<buffer>ディレクティブ内のpathパラメーターを指定すると,バッファをキャッシュするファイルを指定できます。

  • 蓄積したログデータの転送間隔の設定

    flush_intervalを設定すると,蓄積したログデータの転送間隔を指定することができます。

  • bufferキューがいっぱいになった時のoutputプラグインの動作の設定

    overflow_actionを設定すると,バッファの合計サイズがtotal_limit_sizeで指定したサイズに達した際の動作をthrow_exception,block,drop_oldest_chunkの3つから指定できます。それぞれの動作の詳細については,マニュアル「JP1/Integrated Management 3 - Manager コマンド・定義ファイル・APIリファレンス」の「テキスト形式のログファイルの監視定義ファイル(fluentd_@@trapname@@_tail.conf.template)」(2. 定義ファイル)を参照してください。

  • リトライ間隔の設定

    FluentdはJP1/IM - Managerに接続するために,統合エージェント制御基盤と統合エージェント管理基盤にアクセスします。統合エージェント制御基盤か統合エージェント管理基盤,またはJP1/IM - Managerが停止していた場合,JP1/IM - Managerに接続できないことがあります。

    retry_waitを指定すると,一時的な通信障害で,接続に失敗した場合に行うリトライの間隔を指定できます。

(10) 標準出力機能(stdoutプラグイン)

stdoutプラグインは,イベント変換機能で編集・抽出した後のログデータおよびメトリックを標準出力に出力します。

(a) ログのフォーマット機能(format)

ログをフォーマットしてログファイルに出力できます。

出力される内容は,次のとおりです。

time区切り文字tag区切り文字record改行
  • 区切り文字

    区切り文字は,\t(タブ)です。

  • 改行

    改行は,LF(Windows以外の場合)またはCRLF(Windowsの場合)です。

  • time

    日時の形式は,次の形式で出力します。

    %Y-%m-%d %H:%M:%S %z

    例えば,2022年12月31日 12時34分0秒(日本時間)の場合,「2022-12-31 12:34:00 +0900」と出力されます。

    (3)テキスト形式のログファイルの監視機能(tailプラグイン)」の「(g)ログのパース機能(parseプラグイン)」を使用して,「time」という名前でログメッセージ中の日時を切り出した場合,その日時が出力されます。「time」を切り出さない場合,Fluentdがそのログメッセージを監視したときのホストOSの時刻が設定されます。

    ホストOSの時刻を変更した場合,timeの時刻が変更後の時刻に合わせて出力されます。また,Fluentd停止中にタイムゾーンを変更した場合,変更後のタイムゾーンに合わせて出力されます。

  • tag

    <source>ディレクティブ内で指定した,tagを出力します。

    JP1イベントを発行したログの場合「指定したtagの値.jp1event」,JP1イベントを発行しないログの場合「tagの値.outputlog」と出力します。JP1イベントを発行するか,JP1イベントを発行しないでログデータをログファイルに出力するかは,「(12)イベント転送機能(rewrite_tag_filterプラグイン)」で指定できます。

  • record

    [Input Settings]セクションで解析し,[Attributes Settings]セクションで編集したログのデータを,次のJSON形式で出力します。

    {
      "eventide" :  "イベントID" ,
      "message" :  "メッセージ", 
      "xsystem" : true,  
      "attrs" : {"拡張属性名" : "値", …}
    }

    実際は改行せずに出力します。

(11) 複数アウトプット機能(copyプラグイン)

copyプラグインは,ログデータを複数のプラグインで出力できるようにします。

ログの監視結果を出力するアウトプットプラグインは,[Output Settings]で設定します。アウトプットプラグインは,<match>ディレクティブの引数でログの監視結果を指定し,<match>ディレクティブ内でアウトプットプラグインの設定を定義します。

JP1/IM - Agentでは,「(9)HTTP POSTリクエスト機能(httpプラグイン)」と「(10)標準出力機能(stdoutプラグイン)」で説明したアウトプットプラグインを使用しますが,アウトプットプラグインの定義は<match>ディレクティブ内に単一である必要があります。そのため,copyプラグインを<match>ディレクティブ内に配置し,copyプラグイン内でほかのアウトプットプラグインを定義することで,複数のプラグインでログの監視結果を出力できるようにします。

(a) コピー先指定機能(store)

[Output Settings]でcopyプラグインを指定した場合,<store>ディレクティブ内に使用するアウトプットプラグイン(コピー先)を設定します。<store>ディレクティブは複数設定できるため,複数のプラグインで同じログデータを出力できます。

<store>ディレクティブに指定する内容は,単一のアウトプットプラグインを指定する場合に<match>ディレクティブ内に指定する内容と同様です。

(12) イベント転送機能(rewrite_tag_filterプラグイン)

(6)ログデータの編集機能(record transformerプラグイン)」で編集した,JP1イベントの属性の値を指定して,JP1イベントとしてJP1/IM - Managerに転送するログデータを指定できます。この設定は監視定義ファイル内の[Forward Settings]で指定します。ユーザーは,<rule>ディレクティブ内のパラメーターkeyにJP1イベントの属性,patternにJP1イベントを発行するログの正規表現を指定できます。

ログの正規表現に合致したログデータはJP1イベントとしてJP1/IM - ManagerにPOSTされ,「(10)標準出力機能(stdoutプラグイン)」で標準出力にも出力されます。合致しなかったログデータはJP1/IM - ManagerにPOSTされず,標準出力に出力されます。

詳細については,マニュアル「JP1/Integrated Management 3 - Manager コマンド・定義ファイル・APIリファレンス」の「テキスト形式のログファイルの監視定義ファイル(fluentd_@@trapname@@_tail.conf.template)」(2. 定義ファイル)の[Forward Settings]セクションを参照してください。

(13) ログ出力機能

Fluentdはログ出力機能を持ちます。ログはWinSW(Windows)およびrotatelogs(Windows以外)により,ログファイルに出力されます。ログレベル以外の設定項目については,マニュアル「JP1/Integrated Management 3 - Manager コマンド・定義ファイル・APIリファレンス」(2. 定義ファイル)の「サービス定義ファイル(jpc_プログラム名_service.xml)」および「ユニット定義ファイル(jpc_プログラム名.service)」を参照してください。

Fluentdのログファイルについては,マニュアル「JP1/Integrated Management 3 - Manager運用ガイド」の「12.2.2(5)Fluentdのログ」を参照してください。

(a) ログレベルの指定

<system>セクションで,log_levelを設定して,ログの種別を指定できます。ログの種別は定義ファイル全体に適用されます。指定できるログの種別は,緊急度の高い順に次のとおりです。

  • fatal

  • error

  • warn

  • info

  • debug

  • trace

デフォルトのログレベルはinfoで,info以上の重大度をもつinfo,warn,error,およびfatalログを出力します。

(14) メトリック送信機能

監視定義ファイルごとに,ログ監視が動作していることを表すメトリックを60秒ごとにJP1/IM - Managerに送信します。送信は「(9)HTTP POSTリクエスト機能(httpプラグイン)」の機能を使用して行います。

メトリックがJP1/IM - Managerに保存されることで,ユーザーはトレンド表示機能を使用して,ログ監視が動作しているかを確認できます。また,製品プラグインのIM管理ノードの作成機能では,メトリックの値を参照して,IM管理ノードを作成します。

送信するメトリックを次に示します。太字で書かれた箇所は,監視定義ファイルの[Metric Settings]セクションでユーザーが設定する値です。

fluentd_logtrap_running{jp1_pc_fluentd_hostname="ホスト名", jp1_pc_nodelabel="IM管理ノードのラベル名",jp1_pc_category="カテゴリID",jp1_pc_logtrap_defname="ログ監視名",jp1_pc_trendname="fluentd"} 1

サンプルの値は常に1です。サンプルが保存されている場合,jp1_pc_logtrap_defnameのラベルに設定されたログ監視名のログ監視が,その時刻に行われていることを表します。サンプルが存在しない場合は,その時刻のログ監視は行われていないことを表します。

(15) 複数プロセス起動機能

Fluentdは,デフォルトでは1つのsupervisorプロセスと1つのworkerで起動します。複数プロセス起動機能を使用して,Fluentdのsupervisorプロセスは複数のworkerを起動し,workerごとに分離したプロセスを使用します。この機能を使用するのに必要な定義ファイルの設定は以下の通りです。

これらの設定は,「ログ監視共通定義ファイル(jpc_fluentd_common.conf)」,「テキスト形式のログファイルの監視定義ファイル」,および「Windowsイベントログの監視定義ファイル」で実施します。各定義ファイルの設定内容については,マニュアル「JP1/Integrated Management 3 - Manager コマンド・定義ファイル・APIリファレンス」(2. 定義ファイル)の該当するファイルを参照してください。

(16) 注意事項

(17) 通信機能

(a) 通信プロトコルと認証方法

統合エージェントが使用する通信プロトコルと認証方法を,次に示します。

接続元

接続先

プロトコル

認証方式

Fluentd

統合エージェント制御基盤

HTTP

認証なし

注※

ICMPv6は使用できません。

(b) ネットワーク構成

統合エージェントは,IPv4環境だけのネットワーク構成,またはIPv4環境とIPv6環境が混在するネットワーク構成で使用できます。IPv4環境とIPv6環境が混在するネットワーク構成では,IPv4通信だけに対応しています。

統合エージェントは,次に示すプロキシサーバなしの構成で使用できます。

接続元

接続先

接続の種類

Fluentd

統合エージェント制御基盤

プロキシサーバなし

統合エージェントは,次に示すデータを送信します。

接続元

接続先

送信データ

Fluentd

統合エージェント制御基盤

HTTP POSTプロトコルでJSON形式のデータを送信します。

JSON形式のデータを指定する形式を次に示します。

  • JP1/IM - ManagerのJP1イベント変換APIのメッセージボディーに指定する形式※1

  • JP1/IM - Managerのトレンドデータ書き込みAPIのメッセージボディーに指定する形式※2

注※1

詳細については,マニュアル「JP1/Integrated Management 3 - Manager コマンド・定義ファイル・APIリファレンス」の「5.6.5 JP1イベント変換」の,リクエストのメッセージボディーに関する説明を参照してください。

注※2

詳細については,マニュアル「JP1/Integrated Management 3 - Manager コマンド・定義ファイル・APIリファレンス」の「5.11.3 トレンドデータ書き込み」の,リクエストのメッセージボディーに関する説明を参照してください。