【実務・中級編】【サイレント障害検知】「0バイトから更新されない」「急激に肥大化した」異常ファイルをFSOで検出するアラート – VBScript (Visual Basic Scripting Edition)解析バイブル

スポンサーリンク

VBScriptを掌握する:FSOで仕掛ける「サイレント障害」検知の極意

業務自動化の現場において、最も恐ろしいのは「エラーで止まること」ではない。「何も起きずに、静かに壊れ続けること」だ。

バッチ処理がサイレントに失敗し、0バイトの空ファイルが残り続ける。あるいは、ログが暴走してディスクを埋め尽くし、システム全体を窒息させる。これらは監視コンソールには上がってこない。だからこそ、我々エンジニアが「番犬」をコードで実装しなければならない。

今日は、VBScriptのFileSystemObject(FSO)を使い、「死んでいるファイル」と「暴走するファイル」を検知し、即座にアラートを上げる堅牢なアーキテクチャを伝授する。

—

1. なぜ「単純なループ」で終わらせてはいけないのか

初心者が書くコードは、単にファイルを列挙してサイズをチェックするだけだ。しかし、これでは本番環境で確実に痛い目を見る。

  • 排他制御の欠如: 処理中にファイルが書き換えられた場合、FSOの `GetFile` は平然と例外を吐く。
  • パスの正規化: 相対パスやUNCパスの混在は、環境移行時に必ずバグを生む。
  • パフォーマンスの罠: 数万件のファイルを走査する場合、無闇にオブジェクトを生成し続けるとメモリリークに近い挙動を示す。

我々が書くべきは、「例外を前提とした防御的プログラミング」である。

—

2. 実装:異常検知エンジンのコアロジック

このスクリプトは、設定された閾値に基づき、0バイトのファイルと巨大化したファイルをリストアップし、ログ出力する。

Option Explicit

‘ — 設定エリア —
Const TARGET_DIR = “C:\App\Logs”
Const MAX_SIZE_BYTES = 104857600 ‘ 100MBを暴走の閾値とする
Const LOG_FILE = “C:\App\Monitor\monitor_result.log”

Dim fso, folder, file
Set fso = CreateObject(“Scripting.FileSystemObject”)

‘ ログ出力用関数
Sub WriteLog(msg)
Dim ts
Set ts = fso.OpenTextFile(LOG_FILE, 8, True) ‘ 8: ForAppending
ts.WriteLine Now & ” : ” & msg
ts.Close
End Sub

‘ メイン処理
If Not fso.FolderExists(TARGET_DIR) Then
WScript.Quit
End If

Set folder = fso.GetFolder(TARGET_DIR)

For Each file In folder.Files
On Error Resume Next ‘ ファイルアクセスエラーを回避

Dim fSize, fName
fSize = file.Size
fName = file.Name

If Err.Number <> 0 Then
WriteLog “アクセス拒否またはロック中: ” & fName
Err.Clear
Else
‘ 検知ロジック
If fSize = 0 Then
WriteLog “[ALERT] 0バイトファイル検知: ” & fName
ElseIf fSize > MAX_SIZE_BYTES Then
WriteLog “[WARNING] 巨大ファイル検知: ” & fName & ” (” & fSize & ” bytes)”
End If
End If
On Error GoTo 0
Next

Set folder = Nothing
Set fso = Nothing

—

3. 運用を成功させるための「3つの鉄則」

1. 「On Error Resume Next」の正しい使い所

VBScriptにおいて例外処理は貧弱だ。しかし、監視対象のファイルが他プロセスによってロックされていることは日常茶飯事である。ここでスクリプト全体を止めないために、`On Error Resume Next` を「スコープを絞って」使い、エラー発生後は速やかに `On Error GoTo 0` に戻す。これがプロの作法だ。

2. ログの「回転(ローテーション)」を忘れるな

このスクリプトをタスクスケジューラで毎分実行すれば、`monitor_result.log` は数ヶ月で肥大化する。運用ツール自身が巨大化しては本末転倒だ。ログファイルが一定サイズを超えたらリネームしてアーカイブする、あるいは古いログを削除するロジックを必ずセットで組み込むこと。

3. データベース連携より「イベントログ」

監視結果をDBに書き込むのは推奨しない。DB接続情報が環境ごとに変わり、保守コストが増大するからだ。Windows環境であれば、`WScript.Shell` の `LogEvent` を使い、Windowsイベントログに書き込むのがベストプラクティスだ。これにより、ZabbixやJP1といった既存の統合監視ツールで「ログ出力=アラート発報」というルールを構築できる。

—

最後に:コードは「生き物」である

今回紹介したコードは、単なるスニペットではない。異常な状態を可視化し、システム全体の健全性を担保するための「守護神」だ。

あなたが構築する自動化システムが、深夜に無言で停止することのないよう、こうした「監視の監視」を徹底してほしい。技術とは、動くものを作ることではない。「壊れたときに、誰よりも早く気づける仕組みを作ること」にこそ、真の価値がある。

健闘を祈る。

タイトルとURLをコピーしました