1. ホーム
  2. 研究日誌
  3. 【Hinemos】ログファイル監視で監視対象ファイルの操作による動作の違いについて

STUDY研究日誌

Hinemosをはじめ、
様々な技術のノウハウを発信しています。

【Hinemos】ログファイル監視で監視対象ファイルの操作による動作の違いについて

投稿日: / 更新日:

1.はじめに

こんにちは。 本記事では、Hinemosのログファイル監視における「監視対象ファイルに対する操作」による動作の違いを解説します。

ログ監視を行っている最中に、対象ファイルに対して新規作成・追記・編集・削除といった操作が行われた場合、Hinemosはそれをどのように検知・通知するのでしょうか? 特に、「コマンドによる追記」と「エディタによる編集」では、Hinemosの挙動が劇的に異なる点に注目して検証を行いました。

 

2.前提条件

実行環境

  • マネージャサーバ(OS:Red Hat Enterprise Linux 9)
    ⇒ Hinemosマネージャ(ver7.1)
    ⇒ Hinemos Webクライアント(ver7.1)
  • 監視対象サーバ(OS:Red Hat Enterprise Linux 9)
    ⇒ Hinemosエージェント(ver7.1)

実施内容

  • Hinemos Webクライアント上で「ログファイル監視」を作成
  • 監視対象サーバ側でファイル操作を実施し、挙動を確認

 

3.事前準備

監視設定

Hinemos Webクライアントの「監視設定」パースペクティブで「ログファイル監視(文字列)」を作成します。
今回は /tmp/document を対象とします。

monitoring_1

フィルタ設定例:

  1. 危険:.*ERROR.*
  2. 警告:.*WARN.*
  3. 情報:.*(全件)

monitoring_1

※ 全て「大文字・小文字を区別しない」にチェック。
※ 情報フィルタは全件通知となるため、実運用では注意が必要です。

 

通知設定

「イベント通知」設定を行い、監視結果を確認できるようにします。

event_1

 

4.操作ごとの挙動確認

実際の運用フローに合わせ、ファイルの新規作成から順に挙動を確認します。

4.1 新規作成

まだファイルが存在しない状態で監視を開始し、その後ファイルを作成した場合です。

new_1

挙動と通知

  • Hinemosは新しいファイルの出現を検知し、先頭(1行目)から読み込みを開始します。

  • フィルタ条件にマッチする行があれば通知されます。

4.2 コマンドによる追記(echo)

ログファイル監視で最も一般的な、アプリケーション等がログを追記していくパターンです。

echo_1

挙動と通知

  • 通知: WARN にマッチし、警告イベントが1件通知されます。

  • 解説: echo >> コマンドは、既存ファイルの末尾にデータを足すだけなので、ファイルの管理情報(inode番号)は変わりません。Hinemosは「前回の続き(差分)」だけを読み込みます。

 

4.3 エディタによる編集(vi)

vi などのエディタでファイルを開き、保存した場合の挙動です。

操作内容 vi document で開き、末尾に ERROR: 致命的なエラー を追加して保存(:wq)。

vi_1

挙動と通知

  • 通知: 新規に追加した ERROR だけでなく、過去に通知済みの WARN も含めて再通知される(重複通知)場合があります。

  • 解説: Linuxの vi エディタ等は、保存時に「一時ファイルを作成して、元のファイルを置き換える」という挙動をとることが一般的です。これにより、OS上のファイル管理番号である inode番号 が変化します。

    Hinemosエージェントは、内部で保持している管理情報(readingstatus)と照合した際、**「ファイルパスは同じだが、inodeが異なる=別の新しいファイル(またはローテーションされたファイル)」**と判断します。 その結果、読み込み位置がリセットされ、ファイルの先頭から全行再読み込みが発生します。

    結論: ログ監視中のファイルを vi で直接編集すると、過去ログの大量再通知が発生するリスクがあります。

 

4.4 ファイル内容の消失・上書き

ログローテーションや、cp / mv コマンド等でファイル内容が一新された場合です。

(1) ファイルの上書き (echo >)

ファイルサイズが前回読み込み時より小さくなる(縮小する)、またはinodeが変わるため、Hinemosは先頭から読み直します。

(2) ファイルの削除と作り直し

ファイルが削除された時点で、Hinemosエージェント内部の読み込みステータス(readingstatus)等はクリア(または無効化)されます。その後、再作成されたファイルは「新規ファイル」として扱われ、先頭から読み込まれます。

 

5. 技術的な仕組み(補足)

なぜこのような挙動になるのか、Hinemosエージェントの仕組みを簡単に補足します。

Hinemosエージェントは、ログファイルの読み込み位置を管理するために readingstatus という情報を保持しています。ここでは主に以下の情報を記録しています。

  1. ファイルパス

  2. inode番号(ファイルを一意に識別するID)

  3. オフセット(前回どこまで読んだかのバイト数)

監視実行時、Hinemosは以下のように判断します。

  • inodeが同じ & サイズが増えている: オフセットの続きから読み込む(echo >> のパターン)。

  • inodeが異なる: ファイルが置き換わったと判断。オフセットを0に戻して先頭から読む(vi 保存、ログローテートのパターン)。

  • inodeが同じ & サイズが減っている: 内容がリセットされたと判断。オフセットを0に戻して先頭から読む(cp /dev/null 等で空にしたパターン)。

○編集前後でのinode番号の変化

inode_1

inode_2

左側の数字(inode番号)が、編集前後で変化していることが分かります。 ファイル名は同じ document ですが、OS上では「別のファイル」に置き換わっており、これがHinemosによる全件再読み込み(巻き戻し)のトリガーとなります。

 

6. まとめ

操作 inode変化 Hinemosの挙動 注意点
新規作成 先頭から読込  
追記 (echo >>) なし 差分のみ読込 通常の運用。二重検知なし。
編集 (vi :wq) あり 先頭から再読込 過去ログが再通知される危険あり。
上書き (>) なし(※) 先頭から再読込 サイズ縮小を検知してリセット。

※上書きはinodeが変わらない場合もありますが、サイズ縮小によりリセットがかかります。

運用のポイント Hinemosで監視中のログファイルに対して、vi で直接編集を行うと、予期せぬ「全件再通知」が発生する可能性があります。 テスト等でログを追記したい場合は、エディタを使わず echo コマンド等を利用することをお勧めします。

関連する記事

Hinemos導入はアトミテックにお任せください

見積もりを依頼する

最新情報発信中

Xやメルマガでも、Hinemosの保守、
開発、導入、構築やカスタマイズ等の
お役立ち情報を発信しています。
是非ご登録ください。