9.5.4　ログ監視機能

(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.log，funcAlog2.log，funcAlog3.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）は，次のとおりです。

• 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"   : "-"
  }

(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イベントログが監視されず，同様の警告メッセージが出力されます。

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

(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>

(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を指定すると，一時的な通信障害で，接続に失敗した場合に行うリトライの間隔を指定できます。

(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" : {"拡張属性名" : "値", …}
  }

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

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

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

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

(a)　ログレベルの指定

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

• fatal

• error

• warn

• info

• debug

• trace

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

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

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

注※

ICMPv6は使用できません。

(b)　ネットワーク構成

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

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

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

注※1

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

注※2

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