Exchange サーバーからのログ収集を効率化


(この記事は 2015 年 4 月 20 日に Office Blogs に投稿された記事 A better way to collect logs from your Exchange servers の翻訳です。最新情報については、翻訳元の記事をご参照ください。)

 

問題のトラブルシューティングを行ったり、サーバーのパフォーマンスの基準を規定したりするために、各サーバーから手動で診断ログを収集するのは面倒な作業です。ログを収集したものの、問題が発生していた時点のログが他にも必要になり、そのログを収集しようとしたら既に上書きされていたという経験がある方もいらっしゃるのではないでしょうか。

先日、すべての必要な Exchange ログを収集し、別の場所にコピーするスクリプトを作成しました。さらに、すべてのファイルの圧縮も行うため、ユーザーが行うべき作業は、各サーバーでスクリプトを実行し、完了後にデータをアップロードすることだけです。既定では、サーバーからアプリケーションおよびシステム ログのみを収集します。収集するデータはスイッチ (スイッチの全一覧については、ダウンロード ページを参照してください) を使用して指定できるので、発生している問題に関連するデータのみを収集することも可能です。必要なログがわからない場合は、AllPossibleLogs スイッチを使用すると、Exchange のバージョンとそのサーバーでの役割に基づいて、必要なログがすべて収集されます。

このスクリプトは現在、Exchange 2010 と 2013 のみをサポートしています。Exchange 2007 では既定で記録されるログが少ないため、サポートしていません。Exchange 2010 では、問題のトラブルシューティングに利用できるように、既定でログに記録される情報を増やしました (Exchange 2013 ではさらに増えています)。しかし、問題のトラブルシューティングを行うために Exchange サポートが確認する共通のログはすべて、スクリプトを実行した Exchange のバージョンに基づいて収集されます。スクリプトを Exchange 2010 で実行する場合と Exchange 2013 で実行する場合では、ログを圧縮する方法に大きな違いがあります。Exchange 2010 では .NET Framework 4.5 がインストールされていないため、7za.exe ユーティリティを使用してファイルを圧縮します (ファイルを圧縮しないように指定することも可能です)。この機能を利用するためには、スクリプトと同じディレクトリに 7za.exe を配置し、スクリプトを実行する際に SevenZip スイッチを使用します。このユーティリティをダウンロードする必要がある場合、ダウンロードする場所はスクリプトのヘッダーに記載されているのでご確認ください。

このスクリプトを作成した背景

このスクリプトを作成したのは、お客様環境においてパフォーマンス問題のトラブルシューティングを行っていたときでした。サーバーのパフォーマンスの基準を規定するために、毎日 (関連するすべてのサーバーから) 何 GB ものデータを収集し、問題が発生していた時点のデータと比較する必要がありました。この環境では、お客様が手動でデータを収集していたため、ログを収集しようとしたときには、要求したすべてのデータが存在しなかったり、既に上書きされていたりしました。この便利なスクリプトを作成してからは、毎日スクリプトを実行するだけで、適切な情報をすべて収集し、ログが上書きされないようにサーバーの別のドライブに移動させて圧縮しておけるようになりました。お客様は、スクリプトの実行が完了した後にデータをアップロードするだけで済むようになったのです。

スクリプトの実行方法

こちらのページ (英語) から、スクリプトをダウンロードします。Exchange サーバーに保存し、管理者として EMS または PowerShell セッションを開始します。管理者として実行しないと、以下のようにエラーが表示されます。

次に、データを保存する場所と収集するログの種類を指定します。

場所を指定しない場合、データのコピー先として自動的に "C:\MS_Logs_Collection" が選択されます。また、サーバーのドライブ容量を圧迫しないように、選択したドライブに最低 15 GB (データを圧縮しない場合は最低 25 GB) の空き領域があることが自動的に検証されます。

収集すべきデータは、発生している問題によって異なります。判断が付かないときは、AllPossibleLogs スイッチを使用してすべてのログを収集することをお勧めします。これは、問題が発生し、後から根本原因を調査する場合に推奨される方法です。必要なログの種類がわかっている場合には、各ログに対応するスイッチを使用します。たとえば、IIS ログを収集するなら、IISLogs という単一のスイッチを利用できます。このスイッチを指定すると、サーバーにインストールした役割に基づいて、IIS ログと HTTPErr ログが収集されます。両方のログを収集していなかったり、FE ログと BE IIS ログを混同していたりといったケースが多く見受けられますが、こういった間違いがあるとデータを確認するまでにさらに時間がかかってしまうのでご注意ください。IIS および HTTPErr のディレクトリ全体が必要となるわけではないため、このスクリプトでは指定された日数 (既定では 3 日) だけさかのぼってデータを収集します。この日数は DaysWorth スイッチを使用して指定できます。スクリプトで利用可能なスイッチの詳細とその機能については、スクリプトのダウンロード ページ (英語) をご覧ください。

スクリプトの動作とデータの収集方法の例

.\CollectLogsScript.ps1 -FilePath C:\MyLogs -IISLogs -EWSLogs -DaysWorth 1

上記のスクリーンショットのように、スクリプトの進捗を表す進行状況バーが表示されます。データの量が多いと、圧縮が完了して次のログの処理に移行するまでに時間がかかる場合があるので注意が必要です。1 種類のログの収集が完了すると、そのフォルダーを確認し、圧縮したうえでドライブ領域に保存して、元のフォルダーを削除します。この処理は、サーバー名になっているメインのルート フォルダーに含まれる元のサブフォルダーに対してのみ実行されます。ルート フォルダーも圧縮されるので、この場所には .zip ファイルが 1 つだけ存在することになります。このとき .zip ファイルは、元のルート フォルダー名にスクリプトを実行した日付 (M/dd 形式) を追加した名前に変更されます。なお、元のルート フォルダーはこの場所から削除されません。

実行が完了すると、以下のような結果が得られます。

フォルダーの中身は以下のようになります。

追加のデータ (experfwiz、Netmons、ExtraTrace など) を収集する場合、そのデータが同じディレクトリに保存されていれば、CustomData スイッチを使用して収集対象に含めることができます。

.\CollectLogsScript.ps1 -CustomDataDirectory C:\PerfCollection –CustomData

この例では、C:\PerfCollection フォルダーとサブディレクトリからすべてのデータを収集します。これを使用すると、既定では Exchange がログに記録しない追加のディレクトリのデータや、このスクリプトでは収集しない種類のログを収集できます。ただし、コピー、圧縮、アップロードに時間がかかりすぎるため、プロセス ダンプやメモリ ダンプなど、サイズが非常に大きなファイルへの使用はお勧めしません。状況に応じた効果的な使用法をお試しください。

IIS の既定の場所 (C:\inetpub\logs\LogFiles) が変更されている環境のために、このスクリプトには IISLogDirectory というスイッチも用意してあります。このパラメーターに "W3SVC1" または "W3SVC2" の親ディレクトリを追加すると、適切な IIS サブディレクトリが自動的に追加されてログが収集されます。このスイッチの使用方法の例を以下に示します。

.\CollectLogsScript.ps1 –FilePath D:\MS_Logs –IISLogs –IISLogDirectory E:\IISLogs\LogFiles

両方の役割がインストールされた Exchange 2013 で実行した場合、E:\IISLogs\LogFiles\W3SVC1 と E:\IISLogs\LogFiles\W3SVC2 のいずれか、または両方のディレクトリから IIS ログが収集されます。

このスクリプトには、DatabaseFailoverIssue というスイッチも含まれており、最近データベースのフェールオーバーが発生したサーバーから適切なデータを収集することができます。Exchange 2013 サーバーでスクリプトを実行すると、パフォーマンス データ、クラスタリングのイベント ログ、可用性管理ログに加えて、アプリケーションおよびシステム ログが収集されます。Exchange 2010 を利用している場合は、アプリケーション、システム、クラスタリングのログのみが収集されます。最近フェールオーバーの問題が発生したためにこのスイッチを実行する場合は、DAG 内のすべてのサーバーに対してこのスクリプトを実行することを強くお勧めします。これにより、問題の原因を特定するために十分な情報が得られます。データベースのフェールオーバーが発生する理由は複数あるため、この情報をすべて収集することで、既定で記録されるログのうち可能性のあるすべての分野に対応できます。

まとめ

このスクリプトを活用すれば、簡単な方法でサーバーからデータを収集できます。さまざまな問題のトラブルシューティングに必要な情報を収集したり、定期的にログを収集したりといった、これまで手動で行っていた作業の負担を軽減していただけるはずです。また、適切な情報を収集しておらず、再度収集しようとしたときには既に上書きされていたという事態も減らせるかと思います。

サーバーからデータを収集するプロセスを改善するべく、このスクリプトについて問題が報告された場合には修正し、継続的に機能を強化および追加していく予定です。ダウンロード ページに新しいバージョンのスクリプトが追加されていないか、ぜひ今後もチェックしてみてください。

David Paulson

Skip to main content