はじめに

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

ログ監視を行っている最中に、対象ファイルに対して新規作成・追記・編集・削除といった操作が行われた場合、
Hinemosはそれをどのように検知・通知するか説明いたします

前提条件

実行環境

・マネージャサーバ（OS：Red Hat Enterprise Linux 9）
⇒ Hinemosマネージャ（ver7.1）
⇒ Hinemos Webクライアント（ver7.1）

・監視対象サーバ（OS：Red Hat Enterprise Linux 9）
⇒ Hinemosエージェント（ver7.1）

実施内容

・Hinemos Webクライアント上で「ログファイル監視」を作成

・監視対象サーバ側でファイル操作を実施し、挙動を確認

事前準備

監視設定

Hinemos Webクライアントの「監視設定」パースペクティブで「ログファイル監視（文字列）」を作成します。

今回は「/tmp/document」を対象とします。

フィルタ設定例：

・危険：.*ERROR.*

・警告：.*WARN.*

・情報：.*（全件）

※ 全て「大文字・小文字を区別しない」にチェック。

※ 情報フィルタは全件通知となるため、実運用では注意が必要です。

通知設定

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

操作ごとの挙動確認

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

新規作成

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

echo "INFO: 新規ファイルです" > document

〇挙動と通知

・挙動：Hinemosは新しいファイルの出現を検知し、先頭（1行目）から読み込みを開始します

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

コマンドによる追記（echo）

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

# 初期状態
INFO: 起動しました

# 実行コマンド
echo "WARN: 設定に注意が必要です" >> document

# 実行後
INFO: 起動しました
WARN: 設定に注意が必要です

〇挙動と通知

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

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

エディタによる編集（vi）

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

# 初期状態
INFO: 起動しました
WARN: 設定に注意が必要です

# viで1行追記
ERROR: 異常が発生しました

# 実行後
INFO: 起動しました
WARN: 設定に注意が必要です
ERROR: 異常が発生しました

〇操作内容

「vi document」で開き、末尾にERROR: 致命的なエラーを追加して保存（:wq）

〇挙動と通知

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

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

Hinemosエージェントは、内部で保持している管理情報（readingstatus）と照合した際、**「ファイルパスは同じだが、
inodeが異なる＝別の新しいファイル（またはローテーションされたファイル）」**と判断します。

その結果、読み込み位置がリセットされ、ファイルの先頭から全行再読み込みが発生します。

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

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

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

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

echo "ERROR: 新しい内容で上書き" > document

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

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

rm document
echo "INFO: 再作成" > document

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

技術的な仕組み（補足）

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

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

1.ファイルパス

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

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

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

・inodeが同じ ＆ サイズが増えている: オフセットの続きから読み込む（echo >> のパターン）

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

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

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

左側の数字（inode番号）が、編集前後で変化していることが分かります。

ファイル名は同じ document ですが、OS上では「別のファイル」に置き換わっており、これがHinemosによる全件再読み込み（巻き戻し）のトリガーとなります。

おわりに

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

運用のポイント Hinemosで監視中のログファイルに対して、vi で直接編集を行うと、予期せぬ「全件再通知」が発生する可能性があります。

テスト等でログを追記したい場合は、エディタを使わず echo コマンド等を利用することをお勧めします。