前回のエントリについて
前回のエントリはこちら。
追加コストなし、標準機能だけでファイルサーバーのアクセスログ取る方法
前回はWindows Serverの標準機能である「監査ログ」を使って、ファイルサーバーのログ取りに挑戦した。結果、ものすごい量のログが秒刻みで生成されて、目的のログ探しには少し不便かもしれない、ということになった。
今回は「FAccLog Free」を導入
そこで今回は、別ソフトを導入して、ファイルサーバーのログ管理をする方法を試してみる。
有償のログ管理・解析ソフトはSI業者がいくつも販売していて、まあ、お金をかければほぼ何でもできる、という状態。もしこの道を選ぶのであれば、ネットで検索してよさげな業者さんに声をかけて見積もりを取る、で解決。
しかしここでは、有償という選択はしない。あくまで無償で探してみた。
すると、だいこくネットさん制作の「FAccLog Free」にたどり着いた。
FAccLog Free
早速ダウンロードして圧縮ファイルを解凍するとこうなる。
サーバーで使うものなので、まずはReadmeをじっくり読破。
どうやら、Windows Serverの「監査ログ」とは無関係で、クライアントから受信するパケットを捕まえてログにするもよう。ハード互換性重視の「ソケット受信方式」か、スピード重視の「ドライバ受信方式」のどちらかを選ぶだけで、インストールの必要もないとのこと。
とりあえずデータドライブにフォルダを移動して、Readmeに従って、「ドライバ受信方式」用に、sysファイルをちゃちゃっと移動。準備はこれだけのようなので、早速、FAccLogFree.exeを叩いてみた。
FAccLogFree.exeを起動
とりあえず真っ白。
Readmeに従って、「編集」メニュー→「オプション」を開き、設定項目をいろいろ変更するわけだが、ほとんどデフォルトのままでいいような気がするので、「ログファイルの取得」だけチェックを入れて「設定」を押し、ソフトを再起動。
設定後、再起動
再起動後、「ファイル」メニュー→「収集開始」で完了。
おおー、すげぇ～。
たったこれだけの設定で次々ログが取れていく！
なお、前回設定した、グループポリシーの「コンピュータの構成」→「Windowsの設定」→「セキュリティの設定」→「ローカル ポリシー」→「監査ポリシー」→「オブジェクト アクセスの監査」を「成功」から「監査しない」に設定変更しても、ちゃんとFAccLogではログが取れていることを確認。
ちょっと脱線するが、この「監査ポリシー」、ドメインコントローラの場合、いろいろONになっているが、ログの溜まるスピードがただでさえ半端ないので、要らなければOFFにしてしまうのもいいのかもしれない。と思い、現在、「ログオン イベントの監査」のみで運用してみているところ。
さて、ログが取れていることに感動して、ポチッとFAccLogを閉じたら、次立ち上げた時にログが取れていなかった。ケアレスミスだが、FAccLogは終了するとログ収集が停止する。つまり、「閉じる」のではなく、「表示」メニュー→「タスクトレイに格納」するようにしよう。
これでこのエントリは「結論。ファイルサーバーのログ取りには、FAccLogを使わせていただきましょう。」と締めるつもりだった。
SEPPとの同居でサーバがトラブルに
しかし…。FAccLogを動かしておいて数時間が過ぎた頃、ちょっとした事件が起こった。
ファイルサーバーに同居させているウイルス対策ソフトの管理ツール「Symantec Endpoint Protection Manager」が誤動作を起こし、クライアントの管理が停止していて、なおかつ、これまたこのファイルサーバーに同居させているイントラネット（Windows SharePoint Services 3.0）まで動作を停止していたのだ。
厳密に言うと、これらのサービスが停止していたわけではない。タスクトレイのSymantec Endpoint Protection（SEPP）のアイコンが出たり消えたりしていたことから、おそらく、「ネットワーク脅威に当たる活動が起こっているんだけど、SEPPには止められなくて、無限ループのような状態に入っている」という印象だった。
タスクマネージャを見ると、FAccLogのCPU使用率が40%程度まで上がっていることが確認できたので、まあまずこれが原因だなと踏み、すぐにFAccLogを終了。
すると、数分後、SEPPもイントラも、何事もなかったかのように平常に戻った。
障害の切り分け方法を探るが…
この障害の切り分けのベクトルには、2つの方向性があると見た。ひとつは、CPU負荷が高すぎるのではないか、という方向。そしてもうひとつは、SEPPがネットワーク脅威と認識している、という方向。
まず、前者の負荷について調査するため、FAccLogの「編集」メニュー→「オプション」→「アクセスログの書込のみ」にチェックを入れて様子を見てみる。
すると、約6時間後、サーバーがハングアップしてしまった。何の入力も受け付けない状態になってしまったので、やむを得ず、手動で強制電源オフ→再起動。
イベントビューアを見てみると、FAccLog起動直後から、「システム」にエラー（イベント333）が断続的に書き込まれていた。イベントの説明には次のように記載があった。
「レジストリが開始した I/O 操作で回復不可能なエラーが発生しました。レジストリのシステム イメージを登録しているファイルの１つをレジストリが読み取ることができないか、書き込むことができないか、または消去できません。」
うーんわからん。
さらにエラーが出る…
そして、FAccLog起動から約4.5時間後には「アプリケーション」にエラー（イベント2424）。ソースは「Windows SharePoint Services 3 Search」。説明は以下の通り。
「コンテンツ ソースにアクセスできないため、更新を開始できませんでした。エラーを解決し、更新を再試行してください。」
まあ、WSSにまで障害が及んだということか。
さらには、FAccLog起動から約5時間後に、以降1分ジャスト毎に、「システム」にエラー（イベント2019）が書き込まれている。このエラーの説明は以下。
「プールが空であるため、サーバーはシステムの非ページ プールから割り当てることができませんでした。」
これもさっぱり意味が…。
まあ意味がイマイチ理解できないが、事実として、サーバーの中が大変なことになってしまっていた、ということは言える。
もちろん犯人はFAccLogなわけだが、やはりSEPPが噛んでいるような気が……。
