Lync Server 2013 の集中ログ サービスの概要

 

トピック最終更新日時: 2013-02-22

集中ログ サービスは、広範または狭い範囲で、制御されたデータ収集のための手段を提供するように設計されています。 展開内のすべてのサーバーから同時にデータを収集したり、トレースする特定の要素を定義したり、トレース フラグを設定したり、単一のコンピューターから検索結果を返したり、すべてのサーバーのすべてのデータを集計したりできます。 集中ログ サービスは、デプロイ内のすべてのサーバーで実行されます。 集中ログ サービスのアーキテクチャは、次のエージェントとサービスで構成されます。

• 一元化されたログ サービス エージェント ClsAgent.exeは、コントローラーと通信し、管理者によってコントローラーが発行したコマンドを受信するサービス実行可能ファイルです。 エージェントは、各 Lync Server コンピューターでサービスとして実行されます。 エージェントはコマンドを受信すると、コマンドを実行し、定義されたコンポーネントにメッセージを送信してトレースを行い、トレース ログをディスクに書き込みます。 また、コンピューターのトレース ログを読み取り、要求されたときにトレース データをコントローラーに送信します。 ClsAgent は、 TCP 50001、TCP 50002、TCP 50003 の各ポートでコマンド をリッスンします。

• 集中ログ サービス コントローラー ClsControllerLib.dllは、Lync Server Management Shell とClsController.exeのコマンド実行エンジンです。 CLSControllerLib.dll、スタート、停止、フラッシュ、および検索のコマンドを ClsAgent に送信します。 検索コマンドが送信されると、結果のログがClsControllerLib.dllに返され、集計されます。 コントローラーは、エージェントにコマンドを送信し、それらのコマンドの状態を受信し、検索スコープ内の任意のコンピューター上のすべてのエージェントから返される検索ログ ファイル データを管理し、ログ データを意味のある順序付けられた出力セットに集約する役割を担います。 次のトピックの情報は、Lync Server Management Shell の使用に焦点を当てています。 ClsController.exeは、Lync Server Management Shell で使用できる機能のサブセットに限定されます。 ClsController.exeのヘルプは、既定のディレクトリ C:\Program Files\Common Files\Microsoft Lync Server 2013\ClsAgent を入力 ClsController して、コマンド ラインで使用できます。

ClsController と ClsAgent の通信

コマンドは、Windows Server コマンド ライン インターフェイスを使用するか、Lync Server Management Shell を使用して発行します。 コマンドは、ログイン先のコンピューターで実行され、ClsAgent にローカルまたは展開内の他のコンピューターとプールに送信されます。

ClsAgent は、すべてのインデックス ファイルを保持します。ローカル コンピューターに存在する CACHE ファイル。 ClsAgent は、CacheFileLocalFolders オプションで定義されたボリューム間で均等に分散されるように割り当てます。各ボリュームの 80% を超える消費を行うことはありません (つまり、ローカル キャッシュの場所とパーセンテージは Set-CsClsConfiguration コマンドレットを使用して構成できます)。 ClsAgent は、ローカル コンピューターから古いキャッシュされたイベント トレース ログ (.etl) ファイルのエージングも担当します。 2 週間後 (つまり、 Set-CsClsConfiguration コマンドレットを使用して時間枠を構成できます)、これらのファイルはファイル共有にコピーされ、ローカル コンピューターから削除されます。 詳細については、「 Set-CsClsConfiguration」を参照してください。 検索要求を受信すると、検索条件を使用して、エージェントによって管理されているインデックスの値に基づいて検索を実行するキャッシュされた .etl ファイルのセットを選択します。

注意

ローカル コンピューターからファイル共有に移動されたファイルを ClsAgent で検索できます。 ClsAgent がファイルをファイル共有に移動すると、ファイルのエージングと削除は ClsAgent で管理されません。 ファイル共有内のファイルのサイズを監視し、ファイルを削除またはアーカイブするための管理タスクを定義する必要があります。

Snooper.exe や、テキスト ファイルを読み取ることのできるツール (Notepad.exe など) を含むさまざまなツールを使用して、結果のログ ファイルの読み取りと分析を行うことができます。 Snooper.exeは Lync Server 2013 デバッグ ツールの一部であり、.https://go.microsoft.com/fwlink/?LinkId=285257

OCSLogger と同様に、一元化ログ サービスにはトレース対象のコンポーネントがいくつか用意されており、TF_COMPONENTやTF_DIAGなどのフラグを選択するためのオプションが用意されています。 一元的なログ サービスでは、OCSLogger のログ レベル オプションも保持されます。

コマンド ライン ClsController よりも Lync Server Management Shell を使用する最も重要な利点は、問題領域、カスタム フラグ、およびログ レベルを対象とする選択したプロバイダーを使用して、新しいシナリオを構成して定義できることです。 ClsController で使用可能なシナリオは、実行可能ファイル用に定義されるシナリオに制限されます。

以前のバージョンでは、管理者とサポート担当者が展開内のコンピューターからトレース ファイルを収集できるようにするために OCSLogger.exe が提供されていました。 OCSLogger には、長所と同時に短所も存在しました。 ログは一度に 1 台のコンピューター上でしか収集できませんでした。 OCSLogger のコピーを使用して複数のコンピューターにログオンすることは可能でしたが、最終的にログが複数作成され、結果を集計するのが容易ではありませんでした。

ユーザーがログの検索を要求すると、ClsController が (選択したシナリオに基づいて) 要求の送信先コンピューターを特定します。 また、.etl ファイルが保存されているファイル共有に検索を送信する必要があるかどうかを判断します。 検索結果が ClsController に返されると、コントローラーが結果をマージして時系列の 1 つの結果セットを作成し、ユーザーに提供します。 ユーザーは、ローカル コンピューターに検索結果を保存して、以降の分析に使用できます。

ログ記録セッションを開始したら、解決しようとする問題に関連するシナリオを指定します。 常に実行することのできるシナリオは 2 つあります。 そのうちの 1 つは AlwaysOn シナリオにする必要があります。 名前が示すとおり、このシナリオを展開内で常に実行し、すべてのコンピューター、プール、およびコンポーネントに関する情報を収集する必要があります。

大事な

既定では、AlwaysOn シナリオは展開内で実行されません。 このシナリオは明示的に開始する必要があります。 開始したシナリオは明示的に停止されるまで実行され、実行状態はコンピューターを再起動しても保持されます。 シナリオの開始と停止の詳細については、「 集中ログ サービスの開始を使用して Lync Server 2013 でログをキャプチャする」と「Lync Server 2013 の 集中ログ サービスの停止の使用」を参照してください。

問題が発生した場合は、報告された問題に関連する 2 つ目のシナリオを開始します。 問題を再現し、2 つ目のシナリオのログ記録を停止します。 報告された問題に関連するログの検索を開始します。 集計されたログのコレクションによって、展開のサイト スコープまたはグローバル スコープ内のすべてのコンピューターからのトレース メッセージを含むログ ファイルが生成されます。 分析可能なデータ以上のデータが検索から返された場合は (通常、信号対ノイズ比とも呼ばれ、この場合はノイズが多すぎる状態です)、パラメーターを絞り込んで別の検索を実行します。 この時点で、問題を明確にするために役立つパターンの特定を開始できます。 最終的には、いくつかの絞り込み検索を実行した後で問題に関連するデータが見つかり、根本原因を特定できます。

ヒント

Lync Server で問題のシナリオが表示されたら、まず「問題について既に知っていることは何ですか?」 問題の境界を定量化する場合は、Lync Server の運用エンティティの大部分を排除できます。
ユーザーが連絡先を検索するときに現在の結果を取得していないことがわかっているシナリオ例を検討します。 メディア コンポーネント、エンタープライズ VoIP、会議、その他の多くのコンポーネントで問題を探しても意味がありません。 実際はどこに問題が存在するのか (クライアントなのか、サーバー側の問題なのか) がわからないためです。 連絡先は Active Directory からユーザー レプリケーターによって収集され、アドレス帳サーバー (ABServer) を使用してクライアントに配信されます。 ABServer は、既定では午前 1 時 30 分に (ユーザー レプリケーターが更新内容を書き込む) RTC データベースから更新を取得してアドレス帳ファイルにまとめます。 Lync Server クライアントは、ランダム化されたスケジュールで新しいアドレス帳を取得します。 プロセスのしくみを理解しているため、ユーザー レプリケーターによって Active Directory から収集されるデータ、ABServer がアドレス帳ファイルを取得して作成していない、またはアドレス帳ファイルをダウンロードしていないクライアントに関連する問題の潜在的な原因の検索を減らすことができます。