Business Connectivity Services の診断ログの概要 (SharePoint Server 2010)

適用先: SharePoint Server 2010

トピックの最終更新日: 2016-11-30

クライアントまたはサーバーでイベント ログとトレース ログを使用することで、Microsoft SharePoint Server 2010 を実行しているサーバーおよび Microsoft Office 2010 クライアント アプリケーションの Microsoft Business Connectivity Services に関連する問題をトラブルシューティングできます。また、イベント ログまたはトレース ログの各エントリにはアクティビティ ID が関連付けられており、これを使用してクライアントまたはサーバーから外部データ ソースに問題を追跡できます。

この記事の内容

• Business Connectivity Services における診断ログ

• アクティビティ ID について

• サーバーの診断ログ

• Office 2010 クライアントでの診断ログ

• 例: 診断ログの使用

Business Connectivity Services における診断ログ

Microsoft Business Connectivity Services が基になっているソリューションでは、SharePoint Server 2010 を実行しているサーバーと Office 2010 クライアントの両方で診断ログが生成されます。ログにはイベント ログとトレース ログの 2 種類があります。どちらも、Microsoft Business Connectivity Services が生成する診断情報を記録します。イベント ログには、エラー メッセージが記録されます。トレース ログには、スタック トレース、情報メッセージなどのさらに詳細な情報が格納されます。通常、イベント ログよりトレース ログの情報の方が詳細です。

ログに記録される各情報項目には、一意の GUID 値であるアクティビティ ID が含まれます。アクティビティ ID 値は、項目の作成、更新、または削除操作が発生したときに、外部システムに送信することもできます。アクティビティ ID を使用することで、操作をサーバーまたはクライアントから外部データ ソースまで追跡できます。アクティビティ ID の詳細については、「アクティビティ ID について」を参照してください。

イベント ログとトレース ログで診断ログのレベルを設定できます。これで各ログに書き込まれる情報の種類と分量が制限されます。以下の表に、イベント ログとトレース ログで設定できるレベルを示します。

イベント ログのレベル

トレース ログのレベル

診断ログは、開発環境と運用環境のどちらでも利用されますが、ログ記録のレベルについての要件は環境の種類によって変化すると考えるべきです。Microsoft Business Connectivity Services において診断ログを計画するときは、業務のニーズと、現在の環境がそのライフサイクルのどの段階にあるかを検討してから、ログ記録のレベルを設定してください。

たとえば、ソリューションの設計段階では、デバッグの目的で両方のログ記録のレベルを "Verbose" (詳細) に設定して、システムの状態に関して生成されるすべてのメッセージを捕捉します。これと反対に運用環境では、トレース ログで "High" (高)、"Monitorable" (モニター可能)、"Unexpected" (原因不明) の各カテゴリのメッセージだけを捕捉し、またイベント ログで "Critical" (重大) と "Error" (エラー) カテゴリのメッセージを捕捉します。このようにすれば、ログ記録用のディスク領域が節約されると共に、ログ記録によるパフォーマンスの低下が低く抑えられます。

アクティビティ ID について

Microsoft Business Connectivity Services が基になっているソリューションの外部データでの作成、更新、または削除操作ごとに、アクティビティ ID と呼ばれる一意の GUID がサーバーと Office クライアントで生成されます。トレース ログまたはイベント ログに記録される操作に関係のあるすべての情報に、アクティビティ ID の値が含まれます。

作成、更新、または削除操作に対して生成されるアクティビティ ID 値は、その操作に関連する他の情報と共に外部システムに送信されます。外部システムにログ メカニズムがある場合、そのシステムでこの値を取得して記録できます。したがって、操作によって SharePoint サーバーまたは Office クライアントのログにエントリが作成された場合、アクティビティ ID 値を使用することで、外部システムまで同じ操作を追跡できます。これにより、問題のエンドツーエンドのトラブルシューティングが容易になります。

多くの場合、"Create" (作成) のような処理ではログに複数のイベントが書き込まれます。このような状況では、その処理に関して記録されたすべてのイベントで同じアクティビティ ID 値が使用されます。これで同じアクティビティ ID 値の繰り返しが特定の処理に関するすべてのイベントを見つける目安になるので、トラブルシューティングに役立ちます。逆に、同じ種類の処理が繰り返されるときは、それぞれの処理インスタンスごとに一意のアクティビティ ID 値が生成されます。たとえば、ある外部コンテンツ タイプのアイテムが 2 回更新された場合、その各更新処理にそれぞれ一意のアクティビティ ID 値が関連付けられます。

サーバーの診断ログ

SharePoint Server サーバーでは、既定で Microsoft Business Connectivity Services のログ記録がオンにされます。既定のログ記録のレベルは次のとおりです。

• イベント ログ: "Critical" および "Error"

• トレース ログ: "Medium" (中)

もしも Microsoft Business Connectivity Services の診断ログがオフになった場合は、SharePoint Server 全体管理の診断ログページで [Business Connectivity Services] を選択して、診断ログをオンにしてください。Windows PowerShell でサーバー上のイベント ログとトレース ログを構成することもできます。たとえば、ログの出力先ドライブを変更したり、ログ記録の詳細度を設定したりできます。

ログ ファイルの場所の設定方法など、SharePoint Server でのログ機能の詳細については、「診断ログを構成する (SharePoint Server 2010)」を参照してください。

Windows PowerShell を使用すると、サーバー上のイベント ログを表示したり、ログをスプレッドシート プログラムなどにエクスポートしたりできます。詳細については、「診断ログを表示する (SharePoint Server 2010)」を参照してください。

Microsoft Business Connectivity Services では、SharePoint Server フロント エンド Web サーバー上のトレース ログに BDC_Shared_Services と SS_Shared_Service という 2 つのカテゴリが出力されます。イベント ビューアーでトレース ログを開き、"SPS_BusinessData" (Microsoft Business Connectivity Services の出力を表す) と "SPS_SecureStoreService" を条件に設定して検索を行えば、これに関連するログ エントリを抽出できます。

Office 2010 クライアントでの診断ログ

Microsoft Business Connectivity Services インフラストラクチャを使用する Microsoft Office 2010 スイート クライアントでは、Microsoft Business Connectivity Services ソリューション用のイベント ログとトレース ログを使用できます。クライアントでの Microsoft Business Connectivity Services のイベント ログは、既定で有効になります。ただし、パフォーマンスを保護するため、エラーと重大エラーのみが記録され、この設定は変更できません。Windows クライアント コンピューターにはイベント ビューアーが含まれており、これを使用してイベント ログを表示できます。特定のバージョンの Windows のイベント ログを表示する方法については、製品のドキュメントを参照してください。

トレース ログは、クライアント コンピューターではパフォーマンスを低下させないために既定では無効になっています。クライアント コンピューターでのトレース ログは、診断が必要な問題が発生している場合にのみ有効にしてください。たとえば、イベント ログのエントリで示されているエラーが、Microsoft Business Connectivity Services に関係するアクティビティによって発生している可能性がある場合は、次に同じ状況が発生した時にトレース ログを有効にして追加データを収集します。

トレース ログを有効にする方法およびログを表示する方法は、コンピューターの Windows のバージョンによって異なります。たとえば、Windows XP を実行するコンピューターでは、logman コマンドを使用するスクリプトを実行することで、トレースを有効にします。Windows Vista 以降では、logman コマンドに加えてパフォーマンス モニターや信頼性モニターのようなシステム ツールを使用できます。トレースを有効にして結果を取得する方法の詳細については、Windows 製品のドキュメントを参照してください。

次のサンプル スクリプトでは、logman コマンドを使用してトレース ログを有効にしています。

rem This script will enable logging, directing log messages to a file specified by the "%FILE_NAME%" given by the user.

@setlocal
@echo off
pushd %~dp0
set PATH_NAME=%TEMP%\BCS
set FILE_NAME=%PATH_NAME%\ETWTraceLog
set TRACE_COLLECTION=BCS
::tracelog -start BCS -guid #b8622a02-c377-46b1-b861-38a787a8e44a -b 128 -flags 0xFFFF -level 5 -f "%FILE_NAME%.etl"
md "%PATH_NAME%" 1>nul 2>nul
logman create trace %TRACE_COLLECTION% -p "{b8622a02-c377-46b1-b861-38a787a8e44a}" 0xFFFF 5 -o "%FILE_NAME%.etl" -ets
echo.
echo Business Connectivity Services tracing has been started. To end press any key.
echo.
pause

サーバーの場合と同様に、クライアントのアイテムでの作成、更新、または削除操作ごとに、一意のアクティビティ ID 値が生成されます。この値は、ログに記録され、操作に関する他の情報と共に外部システムに送信されます。また、アクティビティ ID の値がエラー メッセージに表示されるようにソリューションを構成できます。これにより、ソリューションで発生した問題のトラブルシューティングが容易になります。

例: 診断ログの使用

ここでは、運用環境における診断ログの実際の使い方を簡単なシナリオを例に説明します。ある企業が、Microsoft Business Connectivity Services ベースのタイムカード送信ソリューションを新たに展開したと仮定します。このソリューションでは、ある外部システムを使用して、定期休暇、病気休暇などの社員のタイムカード情報が格納され、社員の欠勤報告のときに社員および給与支払いシステムとの情報交換が行われます。社員とこのシステムとの情報交換には Web パーツが利用されます。

サーバー ファームでは、ログ記録のレベルが次のように Microsoft Business Connectivity Services の既定値に設定されています。

• イベント ログ: "Critical" および "Error"

• トレース ログ: "Medium" (中)

ある社員が、病気休暇の時間数を表す値を送信したところ、本人と上司のどちらにも病気休暇の時間が正常に送信されたことを報告する確認の電子メール メッセージが送られてきませんでした。そこで、社員は社内の技術サポート サービスに電話で問題を報告しました。

サポート担当者は、タイムカード アプリケーションが Microsoft Business Connectivity Services をベースにしていることを承知していました。そこで、イベント ログの内容をチェックしましたが、ユーザーがタイムカード要求を送信した時刻にユーザーの ID に対応付けられたエラーは見つかりませんでした。次に、トレース ログの内容をチェックしたところ、活動の形跡が見つかりました。その時刻にユーザーに関連付けられた "Update" (更新) 処理があったのです。トレース ログに記録されたこの "Update" 処理のアクティビティ ID 値をサポート担当者はメモしました。

サポート担当者は、外部システムでもログ記録がサポートされていることを承知していたので、アクティビティ ID に基づいて、外部システムに記録されたアイテムを探し、問題の "Update" 処理の終了時にログに記録されたエラーの徴候を見つけました。更新が失敗したのは、社員に割り当てられた病気休暇期間が使い果たされていたからです。彼女は、"Update" 処理の終了時に外部システムで直ちに電子メール メッセージが生成されたことを裏づけるログ エントリが存在しないことにも気づきました。こうしてサポート担当者はタイムカード アプリケーションのロジックに誤りがあるとの結論に達しました。病気休暇期間を使い果たして病気休暇支払いが行われなかったのに、社員にそのことを知らせる電子メール メッセージが生成されなかったからです。そこで、彼女はそのアプリケーションを作成した開発チームと、アプリケーションの更新を担当する開発チームに問題を報告しました。

See Also

Concepts

監視の概要 (SharePoint Server 2010)
診断ログを構成する (SharePoint Server 2010)
Business Connectivity Services の概要 (SharePoint Server 2010)