SharePoint 2010 のデバッグ機能とログ機能
概要: 開発者が構築するソリューションの信頼性とテスト可能性を高める、SharePoint Foundation 2010 の新しいログ機能とデバッグ機能について説明します。
最終更新日: 2011年1月12日
適用対象: Business Connectivity Services | Office 2010 | Open XML | SharePoint Designer 2010 | SharePoint Foundation 2010 | SharePoint Online | SharePoint Server 2010 | Visual Studio
この記事の内容
SharePoint 2010 のデバッグ機能とログ機能の概要
SharePoint 2010 のログ機能
SharePoint 2010 のエラー報告
カスタム SharePoint アプリケーション ページ
SharePoint 2010 の開発者ダッシュボード
まとめ
その他の技術情報
目次
SharePoint 2010 のデバッグ機能とログ機能の概要
SharePoint 2010 のログ機能
SharePoint 2010 のエラー報告
カスタム SharePoint アプリケーション ページ
SharePoint 2010 の開発者ダッシュボード
まとめ
その他の技術情報
.jpg "クリックしてコードを取得")
SharePoint 2010 のデバッグ機能とログ機能の概要
Microsoft SharePoint 2010 は拡張性の高い製品であり、開発者が多様なビジネス ニーズに合わせてカスタマイズできます。SharePoint は Microsoft ASP.NET に基づいているので、開発者は従来の ASP.NET Web サイトで利用できるのと同じデバッグ機能とログ機能を利用できます。SharePoint 2010 では、ASP.NET から提供される機能以外にも、開発者のアプリケーション監視とトラブルシューティングを支援する新しいデバッグ機能とログ機能が導入されています。
この記事では、開発者がカスタム SharePoint 2010 アプリケーションに利用できる各種デバッグ機能とログ機能の概要およびテクニックについて説明します。
SharePoint 2010 のログとデバッグの新機能
優れたアプリケーションには、意図したとおりに動作しない場合や予期しないことが発生した場合に備えて、開発者によるエラー追跡を支援する適切なログ手段が含まれているものです。Microsoft Office SharePoint Server 2007 では、デバッグやトレース ログなど、ASP.NET で利用できる機能をすべて、開発者に提供していました。開発者は、統合ログ サービス (ULS) で SharePoint ログに書き込むこともできましたが、ログ ファイルに直接書き込むには追加の作業が必要でした。
SharePoint 2010 に追加されたログ機能とデバッグ機能によって、開発者はさらに多くの監視とトラブルシューティングの機能をカスタム アプリケーションに含めることができるようになりました。この記事では、SharePoint 2010 の以下の分野の新機能について説明します。
相関トークン
ログ データベース
カスタム エラー ページ
開発者ダッシュボード
SharePoint 2010 のログ機能
Windows SharePoint Services 3.0 および Office SharePoint Server 2007 を実行しているすべてのサーバーは、ULS ログ ファイルとサーバー イベント ログにログ情報を書き込んでいました。ULS ログ ファイルは、ファーム内で SharePoint を実行している各サーバーの {SharePoint Root}\LOGS フォルダーにあり、診断ログ調整の構成によっては大量の情報が含まれることがありました。通常、ログの情報は少ないより多い方が役立ちますが、大量の情報があると、ログ ファイルから特定のエントリを探しにくくなることがあります。SharePoint 2010 では、各ログ エントリに一意性を割り当てることによって、特定のログ エントリの識別作業が容易になりました。この一意性は、"相関トークン" と呼ばれ、エラー発生時にユーザーに示される GUID です。管理者または開発者は、エラーにおけるこの GUID 文字列を使用して、ログ ファイル内の対象エントリを検索できます。これによって、特定のイベントを追跡するためにログ ファイル内のエントリを短時間で検出できるようになりました。
ログ ファイルとイベント ログに含まれる内容の詳細度を特定の基準に基づいて指定するように ULS を構成することもできます。SharePoint 2010 の診断ログ設定を構成する方法については、記事「診断ログ設定を構成する (SharePoint Foundation 2010)」(Microsoft TechNet) を参照してください。
SharePoint ログ データベース
もう 1 つの変更点として、ファーム内の全サーバーのすべてのログ情報が含まれる新しいデータベースも導入されました。この機能には、いくつかの新しいタイマー ジョブを使用します。これらのジョブを有効にすると (既定ではすべて無効)、SharePoint によって、新しい Microsoft SQL Server データベースに診断ログ データが挿入されます。この新しいタイマー ジョブには以下のものがあります。
診断データ プロバイダー: イベント ログ
診断データ プロバイダー: パフォーマンス カウンター - データベース サーバー
診断データ プロバイダー: パフォーマンス カウンター - Web フロント エンド
診断データ プロバイダー: SQL ブロッキング クエリ
診断データ プロバイダー: SQL DMV
診断データ プロバイダー: SQL メモリの DMV
診断データ プロバイダー: トレース ログ
これらの各タイマー ジョブの詳細については、「タイマー ジョブ リファレンス (SharePoint Server 2010)」を参照してください。これらのタイマー ジョブを有効にする最大の利点の 1 つは、さまざまなログをすべて 1 か所にまとめることができ、さまざまなソースから照会できることです。このログ データベースの内容は、Microsoft Business Connectivity Services (BCS) の外部コンテンツ タイプおよびリストを使用して公開することもできます。
SharePoint ULS ログを読み取る
SharePoint 2010 の新しいログ データベースに加え、開発者は、各サーバーの {SharePoint Root}\LOGS フォルダーに作成される未加工の SharePoint ログ ファイルを分析することもできます。一般に、開発者がソリューションを開発するときには、各種サーバーで構成されるファームではなく単一サーバーにすべてがインストールされている分離環境で作業します。ログ ファイルは、単なる大きな固定幅区切りテキスト ファイルなので、テキスト エディターで読み込んで検索できます。
未加工のテキスト ファイルを検索する以外に、多くの開発者が SharePoint ログ ファイルの読み取りに利用できるさまざまなユーティリティを公開しています。「SharePoint ULS viewer」で検索すると、多数のリソースが見つかります。これらのユーティリティには、通知機能や、標準的なテキスト エディターを使用するより簡単に特定の基準で検索とフィルター処理を実行する機能が含まれるものもあります。
SharePoint ULS ログに書き込む
SharePoint ULS ログを読み取ると、SharePoint で生成されるメッセージのトラブルシューティングに役立ちます。ただし、開発者にとっては、ログ ファイルに独自のメッセージを書き込む機能も必要です。SharePoint 2010 では、以下の例に示すように SPDiagnosticsService クラスを使用することによって、ログ ファイルへの書き込みが容易になりました。
try{
...
} catch (Exception ex) {
SPDiagnosticsService.Local.WriteTrace(0, new SPDiagnosticsCategory("MSDN", TraceSeverity.Unexpected, EventSeverity.Error), TraceSeverity.Unexpected, ex.Message, ex.StackTrace);
}
前のコード スニペットは、SharePoint ULS ログに例外の詳細を書き込みます。追加されたエントリを調べると、[Product] 列のエントリが "Unknown" になっていることがわかります。これは、SPDiagnosticsService クラスの既定の動作です。カスタム製品名を追加するには、SPDiagnosticsServiceBase クラスを使用して開発者が独自の診断サービスを実装できます。ただし、カスタム SPDiagnosticsService を操作できるのは、完全に信頼できるファーム ソリューション内からのみであり、サンドボックス ソリューション内からは操作できません。サンドボックスから SPDiagnosticsService クラスを使用して ULS ログに書き込むには、サンドボックス ソリューションから呼び出せる完全信頼プロキシを作成します。次の 2 つのセクションでは、SharePoint ULS ログに書き込む方法について説明します。
カスタム SPDiagnosticsService クラス作成に加え、Microsoft パターンおよびプラクティス グループは、SharePoint ロガーが含まれる Developing Applications for SharePoint 2010 (英語) ガイダンス パッケージをリリースしました。開発者がカスタム アプリケーションを構築するときは、これらすべてのアプローチを検討してください。
カスタム ログ サービスを作成する
カスタム アプリケーションにカスタム ログ サービスを作成するには、SPDiagnosticsServiceBase クラスの新しい実装を作成し、1 つのメソッドを上書きし、ログ ファイルに書き込む方法を用意します。
以下の例は、非サンドボックス ソリューションに新しいクラスを追加し、そのクラスを SPDiagnosticsServiceBase クラスから継承する方法を示しています。
using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;
using Microsoft.SharePoint.Administration;
namespace MSDN.SharePoint.Samples.WriteToUls {
public class LoggingService : SPDiagnosticsServiceBase {
private LoggingService() :
base("MSDN Logging Service", SPFarm.Local) { }
}
}
次に、以下の例に示すように、使用できる製品名とログ カテゴリを登録する ProvideAreas メソッドを実装します。
public const string MSDN_INFO = "MSDN Info";
public const string MSDN_ERROR = "MSDN Error";
private static string PRODUCT_DIAGNOSTIC_NAME = "MSDN Sample";
protected override IEnumerable<SPDiagnosticsArea> ProvideAreas() {
List<SPDiagnosticsArea> areas = new List<SPDiagnosticsArea>{
new SPDiagnosticsArea(PRODUCT_DIAGNOSTIC_NAME, new List<SPDiagnosticsCategory>{
new SPDiagnosticsCategory(MSDN_INFO, TraceSeverity.Verbose, EventSeverity.Information),
new SPDiagnosticsCategory(MSDN_ERROR, TraceSeverity.Unexpected, EventSeverity.Warning),
})
};
return areas;
}
以下の例は最後のステップを示しており、Web パーツなどのカスタム コンポーネントから呼び出せる静的メソッドをいくつか追加することによって、カスタム ログ サービスを使いやすくします。
private static LoggingService _current;
public static LoggingService Current {
get {
if (_current == null)
_current = new LoggingService();
return _current;
}
}
public static void LogMessage(string categoryName, string message) {
SPDiagnosticsCategory category =
LoggingService.Current.Areas[PRODUCT_DIAGNOSTIC_NAME].Categories[categoryName];
LoggingService.Current.WriteTrace(0, category, TraceSeverity.Verbose, message);
}
public static void LogError(string categoryName, string message) {
SPDiagnosticsCategory category =
LoggingService.Current.Areas[PRODUCT_DIAGNOSTIC_NAME].Categories[categoryName];
LoggingService.Current.WriteTrace(0, category, TraceSeverity.Unexpected, message);
}
以下の例に示すように、Web パーツなどのカスタム コンポーネントをプロジェクトに追加し、ログ サービスを呼び出して、ロガーをテストします。
public class WriteToUlsFarmSolutionWebPart : WebPart {
protected override void CreateChildControls() {
Button logInfoButton = new Button { Text = "log info entry" };
logInfoButton.Click += (sender, e) =>
LoggingService.LogMessage(LoggingService.MSDN_INFO, "Sample info message.");
this.Controls.Add(logInfoButton);
Button logErrorButton = new Button { Text = "log error entry" };
logErrorButton.Click += (sender, e) =>
LoggingService.LogMessage(LoggingService.MSDN_ERROR, "Sample error message.");
this.Controls.Add(logErrorButton);
}
}
Web パーツのボタンの 1 つをクリックすると、前のコードが実行され、製品名 MSDN Sample と新しいカテゴリの 1 つを使用して SharePoint ログ ファイルに新しいエントリが追加されます。
サンドボックス ソリューションから ULS ログに書き込む
残念ながら、サンドボックス ソリューション内から ULS ログに直接書き込むことはできません。サンドボックス ソリューションには、分離ユーザー コード サービスからログ サービスにアクセスする権限がないからです。ただし、開発者は、ファーム ソリューションとして展開する完全信頼プロキシを作成でき、任意のサンドボックス ソリューションからこの完全信頼プロキシを利用できます。完全信頼プロキシを作成する手順の詳細については、「How To: Create and Register a Sandbox Proxy」を参照してください。
Microsoft Visual Studio 2010 の SharePoint 開発者ツールを使用してファーム ソリューションを作成し、前に作成したのと同じ SPDiagnosticsServiceBase ログ クラスを作成します。次のステップとして、ログ サービスを呼び出すプロキシを作成します。
以下の例に示すように、プロキシ操作引数を受け取る別のクラスをプロジェクトに追加します。
using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;
using Microsoft.SharePoint.UserCode;
namespace MSDN.SharePoint.Samples.WriteToUls {
[Serializable]
public class LoggingMessageProxyArguments : SPProxyOperationArgs {
public string MessageCategoryName { get; set; }
public string MessageContents { get; set; }
public static string LoggingProxyOperationTypeName {
get {
return "LoggingProxy.LoggingMessageProxyOperation";
}
}
public static string LoggingProxyAssemblyName {
get {
return "MSDN.SharePoint.Samples.WriteToUlsSandboxSolution.Proxy, Version=1.0.0.0, Culture=neutral, PublicKeyToken=[INSERT PROJECT'S PUBLICKEYTOKEN HERE]";
}
}
}
}
次に、以下の例に示すように、完全に信頼できる操作を実行する別のクラスをプロジェクトに追加します。
using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;
using Microsoft.SharePoint.UserCode;
namespace MSDN.SharePoint.Samples.WriteToUls {
public class LoggingMessageProxyOperation : SPProxyOperation {
public override object Execute(SPProxyOperationArgs args) {
LoggingMessageProxyArguments proxyArguments = args as LoggingMessageProxyArguments;
string loggingCategory ;
switch (proxyArguments.MessageCategoryName.ToLower()) {
case LoggingService.MSDN_ERROR:
loggingCategory = LoggingService.MSDN_ERROR;
break;
default:
loggingCategory = LoggingService.MSDN_INFO;
break;
}
// Do full trust action.
LoggingService.LogMessage(loggingCategory, proxyArguments.MessageContents);
}
}
}
プロキシの引数と操作を作成したので、最後のステップとして、このプロキシをファームのユーザー コード サービスに登録します。これを行うには、以下の例に示すように、ファームを対象範囲とする機能のアクティブ化イベントを使用します。
public class LoggingMessageProxyInstallerEventReceiver : SPFeatureReceiver {
public override void FeatureActivated(SPFeatureReceiverProperties properties) {
// Get proxy operation.
LoggingMessageProxyOperation proxyOperation = new SPProxyOperationType(
LoggingMessageProxyArguments.LoggingProxyAssemblyName,
LoggingMessageProxyArguments.LoggingProxyOperationTypeName);
SPUserCodeService ucService = SPUserCodeService.Local;
ucService.ProxyOperationTypes.Add(proxyOperation);
ucService.Update();
}
public override void FeatureDeactivating(SPFeatureReceiverProperties properties) {
// Get proxy operation.
LoggingMessageProxyOperation proxyOperation = new SPProxyOperationType(
LoggingMessageProxyArguments.LoggingProxyAssemblyName,
LoggingMessageProxyArguments.LoggingProxyOperationTypeName);
// Add proxy to user code service.
SPUserCodeService ucService = SPUserCodeService.Local;
ucService.ProxyOperationTypes.Remove(proxyOperation);
ucService.Update();
}
}
このプロジェクトを展開し、プロジェクトに含まれる、ファームを対象範囲とする機能がアクティブ化されると、サンドボックス ソリューション内からプロキシを呼び出せるようになります。以下のコードは、サンドボックス ソリューションに展開された Web パーツから、完全信頼プロキシを使用して SharePoint 2010 ULS ログに書き込む方法を示しています。
public class WriteToUlsSandboxSolutionWebPart : WebPart {
protected override void CreateChildControls() {
LoggingMessageProxyArguments loggingProxyArgs = new LoggingMessageProxyArguments();
Button logInfoButton = new Button { Text = "log info entry" };
logInfoButton.Click += (sender, e) => {
loggingProxyArgs.MessageCategoryName = LoggingService.MSDN_INFO;
loggingProxyArgs.MessageContents = "Sample info message";
var result1 = SPUtility.ExecuteRegisteredProxyOperation(
LoggingMessageProxyArguments.LoggingProxyAssemblyName,
LoggingMessageProxyArguments.LoggingProxyOperationTypeName,
loggingProxyArgs);
};
this.Controls.Add(logInfoButton);
Button logErrorButton = new Button { Text = "log error entry" };
logInfoButton.Click += (sender, e) => {
loggingProxyArgs.MessageCategoryName = LoggingService.MSDN_ERROR;
loggingProxyArgs.MessageContents = "Sample info message";
var result2 = SPUtility.ExecuteRegisteredProxyOperation(
LoggingMessageProxyArguments.LoggingProxyAssemblyName,
LoggingMessageProxyArguments.LoggingProxyOperationTypeName,
loggingProxyArgs);
};
this.Controls.Add(logErrorButton);
}
}
ULS ログにログ イベントおよびトレース イベントを書き込むためのガイドラインについては、SharePoint 2010 SDK の「トレースおよびイベント ログ重要度レベル」を参照してください。
SharePoint 2010 のエラー報告
カスタム プロジェクトに多くのログを追加すると、問題発生時に開発者が追跡するのに役立ちます。それでも、開発者が追跡する必要のあるエラーが引き続き発生する可能性は常にあります。また、SharePoint 2010 で使用される既定のシステム ページの一部を開発者が変更することが必要になる場合もあります。以下の各セクションでは、この 2 つのシナリオについて説明します。
Web アプリケーションの web.config ファイルの使用
ASP.NET アプリケーションでエラーが発生した場合、エラーは未加工の状態で示されるか (web.config ファイルに <customErrors mode="Off" /> 要素が含まれる場合)、エラーの詳細を非表示にしカスタム メッセージを表示するカスタム エラー ページが使用されます (web.config ファイルに <customErrors mode="On" /> 要素が含まれる場合)。
SharePoint 2010 の既定の構成では、カスタム エラーがオンになっており、エラーの詳細は非表示になります。この理由の 1 つは、わかりにくいエラーをユーザーに表示する代わりに、よりわかりやすいエラー ページを表示することにあります。すべての詳細を表示しないもう 1 つの理由は、エラーの全詳細を提供すると、ユーザーに公開する必要のない情報まで公開することになり、セキュリティの不備と見なされる可能性があるからです。
残念ながら、SharePoint から表示されるカスタム エラー メッセージは、開発者が問題をトラブルシューティングするときには不十分であることがあります。カスタム ソリューションを構築するときには、具体的な例外、例外メッセージ、コール スタックの全情報など、すべてのエラー情報が表示されると便利です。Web アプリケーションの web.config ファイルを編集して <customErrors /> 要素のモードを Off に変更すると、これを簡単に実現できます。この場合、Web アプリケーション全体について、未加工の ASP.NET エラー ページが表示されるようになります。以下の例に示すように、Web アプリケーションを対象範囲とする機能を使用し、その機能のアクティブ化イベントと非アクティブ化イベントを実装してこの変更を行うと、このプロセスを自動化できます。
public override void FeatureActivated(SPFeatureReceiverProperties properties) {
SPWebApplication WebApp = (SPWebApplication)properties.Feature.Parent;
foreach (ModificationEntry modEntry in Entries) {
WebApp.WebConfigModifications.Add(
CreateModification(modEntry)
);
}
WebApp.WebService.ApplyWebConfigModifications();
}
public override void FeatureDeactivating(SPFeatureReceiverProperties properties) {
SPWebApplication WebApp = (SPWebApplication)properties.Feature.Parent;
foreach (ModificationEntry modEntry in Entries) {
WebApp.WebConfigModifications.Remove(
CreateModification(modEntry)
);
}
WebApp.WebService.ApplyWebConfigModifications();
}
private struct ModificationEntry {
public string Name;
public string XPath;
public string Value;
public SPWebConfigModification.SPWebConfigModificationType ModType;
// Parameterized contructor.
public ModificationEntry(
string Name, string XPath, string Value,
SPWebConfigModification.SPWebConfigModificationType ModType) {
// Intialize structure instances.
this.Name = Name;
this.XPath = XPath;
this.Value = Value;
this.ModType = ModType;
}
}
private ModificationEntry[] Entries = {
new ModificationEntry(
"mode", "configuration/system.web/customErrors", "Off",
SPWebConfigModification.SPWebConfigModificationType.EnsureAttribute)
};
private SPWebConfigModification CreateModification(ModificationEntry modEntry) {
// Create and return SPWebConfigModification object.
SPWebConfigModification modification;
modification = new SPWebConfigModification(modEntry.Name, modEntry.XPath);
modification.Owner = "MSDN.SharePointDebugger";
modification.Sequence = 0;
modification.Type = modEntry.ModType;
modification.Value = modEntry.Value;
return modification;
}
レイアウトの web.config ファイルの使用
Web アプリケーション内のフォルダーは、ローカルの web.config ファイルによって上書きされる場合を除き、親フォルダーから web.config ファイル設定を継承することに注意してください。SharePoint 2010 固有の http://.../_layouts フォルダーには、カスタム エラーがオンに設定されている独自の web.config ファイルが含まれます。したがって、開発者がカスタム アプリケーション ページを作成したり、SharePoint 2010 アプリケーション ページをトラブルシューティングしたりするときは、{SharePoint Root}\TEMPLATE\LAYOUTS フォルダーにある web.config ファイルを変更するか、カスタム アプリケーション ページが含まれるフォルダーに、カスタム エラーをオフにするカスタム web.config を追加することが必要になる場合があります。
カスタム SharePoint アプリケーション ページ
SharePoint 2010 には、エラー報告、アクセス拒否通知、ログオンとログオフのページなどの用途に使用される多数のシステム アプリケーション ページが含まれています。以前のバージョンの SharePoint では、これらのファイルはハードコードされていました。web.config ファイルで変更できるログオン ページなど、簡単に変更できるページもある一方、独自にコードを記述しないと変更できないページもありました。
SharePoint 2010 では、開発者がカスタム ページの URL を取得する方法を用意し、開発者が独自のシステム アプリケーション ページを作成できるようにすることで、この点が改良されています。これによって、開発者は、カスタム ビジネス ロジックを含めたり、サイトのブランド設定に合わせてブランド設定したりできるカスタム システム アプリケーション ページを作成できます。これらの変更は、GetMappedPage と UpdateMappedPage の 2 つのメソッドを使用して Web アプリケーションに適用できます。変更できるシステム アプリケーション ページのリストは、SPWebApplication.SPCustomPage 列挙にあります。
システム マスター ページの変更は、Web アプリケーションを対象範囲とする機能のアクティブ化イベントと非アクティブ化イベントに実装するのが最良の方法です。まず、カスタム システム アプリケーション ページとして使用するための新しいアプリケーション ページを作成します。次に、Web アプリケーションを対象範囲とする機能を作成し、アクティブ化イベントと非アクティブ化イベントを実装します。以下に例を示します。
public class CustomErrorPagesEventReceiver : SPFeatureReceiver {
public override void FeatureActivated(SPFeatureReceiverProperties properties)
{
SPWebApplication webApp = properties.Feature.Parent as SPWebApplication;
if (webApp != null) {
// Set Access Denied.
if (!webApp.UpdateMappedPage(SPWebApplication.SPCustomPage.AccessDenied,
"/_layouts/CustomErrorPages/AccessDenied.aspx")) {
throw new ApplicationException("Failed setting new access denied page mapping.");
}
// Set Signout.
if (!webApp.UpdateMappedPage(SPWebApplication.SPCustomPage.Signout,
"/_layouts/CustomErrorPages/Signout.aspx")) {
throw new ApplicationException("Failed setting new signout page mapping.");
}
// Set File Not Found.
webApp.FileNotFoundPage = "/_layouts/1033/FileNotFound.htm";
webApp.Update(true);
}
}
public override void FeatureDeactivating(SPFeatureReceiverProperties properties)
{
SPWebApplication webApp = properties.Feature.Parent as SPWebApplication;
if (webApp != null) {
webApp.UpdateMappedPage(SPWebApplication.SPCustomPage.AccessDenied, null);
webApp.UpdateMappedPage(SPWebApplication.SPCustomPage.Signout, null);
webApp.FileNotFoundPage = null;
}
}
}
SharePoint 2010 の開発者ダッシュボード
SharePoint ページに追加したカスタム コンポーネントを開発者がログ記録およびデバッグするのに役立つ SharePoint 2010 のもう 1 つの新機能として、開発者ダッシュボードもあります。ファーム全体に対して開発者ダッシュボードをオンにすると、特定のページ要求のアクティビティとパフォーマンスのスナップショットを取得できます。
図 1. 開発者ダッシュボード
.jpg "開発者ダッシュボード")
単一の SharePoint ページに複数のカスタム コンポーネントが含まれることがあるので、ページで問題のあるコンポーネントをトラブルシューティングする場合に開発者ダッシュボードが非常に役立ちます。1 つのページに複数のカスタム コンポーネントが含まれている場合にページのパフォーマンスが予想外に遅いときは、単純に削除していかない限り、どのコンポーネントがパフォーマンス低下の根本原因であるかを特定しにくいことがあります。このような状況に役立てるために用意されたのが開発者ダッシュボードです。
開発者ダッシュボードには、いくつかのカテゴリの情報が含まれます。ここに提供される情報として、処理にかかった時間の詳細、SQL Server データベース呼び出しおよび Windows Communication Foundation (WCF) サービス呼び出しの数と実行時間の詳細、URL や現在のユーザーの詳細などがあります。
開発者ダッシュボードを構成する
既定では、開発者ダッシュボードはオンになっていません。開発者ダッシュボードを有効にするには、API を使用するか、以下の例のようなカスタム Windows PowerShell スクリプトを使用します。
$contentService = [Microsoft.SharePoint.Administration.SPWebService]::ContentService
$dashboardSetting = $contentService.DeveloperDashboardSettings
$dashboardSetting.DisplayLevel = [Microsoft.SharePoint.Administration.SPDeveloperDashboardLevel]::On
$dashboardSetting.Update()
開発者ダッシュボードに使用できる表示レベルは、2 種類あります。SPDeveloperDashboardLevel.On 列挙オプションを使用すると、ファーム内の全ページについてダッシュボードが有効になります。SPDeveloperDashboardLevel.OnDemand に設定すると、ダッシュボードは無効のままになりますが、ページの右上隅にパフォーマンス カウンターのような画像が追加されます。この画像をクリックすると、そのページに開発者ダッシュボードを追加するポストバックが開始されます。
開発者ダッシュボードについては、SharePoint 2010 SDK の「開発者ダッシュボードの使用」を参照してください。
開発者ダッシュボードには SharePoint プロセスに関する多くの情報が含まれますが、開発者は、ダッシュボードに表示されるカスタム コンポーネントに独自のログを追加することもできます。
開発者ダッシュボードに書き込む
開発者ダッシュボードには、ファーム ソリューションからのみ直接書き込むことができます。ユーザー コード プロセスに分離されているサンドボックス ソリューションから開発者ダッシュボードに書き込むことはできません。開発者ダッシュボードに書き込むには、カスタム コンポーネントを SPMonitoredScope オブジェクトでラップする必要があります。
以下のコードは、開発者ダッシュボードに書き込む方法および入れ子のスコープを作成する方法を示しています。
public class MonitoredWebPart : WebPart {
protected override void CreateChildControls() {
using (SPMonitoredScope scope = new SPMonitoredScope("MonitoredWebPart.CreateChildControls")) {
this.Controls.Add(
new LiteralControl("Turn on the developer dashboard to see entries logged by this Web Part.");
// Trigger a SPRequest & DB round trip.
TriggerSpDatabaseRequest();
TriggerSPRequestObject();
// Simulate a delay.
TriggerSimulatedDelay();
);
}
}
private void TriggerSpDatabaseRequest() {
using (SPMonitoredScope scope = new SPMonitoredScope("MonitoredWebPart.TriggerSpDatabaseRequest")) {
SPList someList = SPContext.Current.Web.Lists[0];
int itemsinList = someList.Items.Count();
}
}
private void TriggerSPRequestObject() {
using (SPMonitoredScope scope = new SPMonitoredScope("MonitoredWebPart.TriggerSPRequestObject")) {
using (SPSite siteCollection = new SPSite(SPContext.Current.Site.Id)) {
string siteCollectionUrl = siteCollection.RootWeb.Url;
}
}
}
private void TriggerSimulatedDelay() {
using (SPMonitoredScope scope = new SPMonitoredScope("MonitoredWebPart.TriggerSimulatedDelay")) {
System.Threading.Thread.Sleep(2000);
}
}
}
図 2. は、前のコード例の Web パーツをページに追加した結果を示しています。
図 2. 開発者ダッシュボードに書き込む
.jpg "開発者ダッシュボードへの書き込み")
開発者ダッシュボードをカスタム マスター ページに追加する
開発者ダッシュボードは、SharePoint 2010 に含まれるマスター ページのいずれかを使用するすべての SharePoint サイトに含まれます。カスタム マスター ページを作成するとき、開発者は、次のようなサーバー コントロールを理想的な位置であるページ下部に追加するだけで、開発者ダッシュボードを追加できます。
<SharePoint:DeveloperDashboard runat="server" />
開発者ダッシュボードを SPDeveloperDashboardLevel.OnDemand に設定すると、アイコンを表示しダッシュボードをレンダリングするダッシュボード ランチャーが使用されます。開発者は、カスタム マスター ページに以下のようなコントロールも追加する必要があります。
<SharePoint:DeveloperDashboardLauncher runat="server" />
このコントロールには、コントロールのレンダリングに使用する配置、テキスト、および画像を変更するためのパブリック プロパティがあります。これらは、SharePoint 2010 SDK の DeveloperDashboardLauncher クラスにあります。
まとめ
SharePoint の最新リリース Microsoft SharePoint 2010 では、開発者向け機能が増強されています。Visual Studio 2010 に含まれる最上級の開発ツールに加え、SharePoint 2010 用に構築するカスタム ソリューションに開発者がログ機能とデバッグ機能を追加するための柔軟性と機能が大幅に向上しています。この記事では、SharePoint 2010 ソリューション構築時に開発者が使用できるようになったログ機能とデバッグ機能の一般的な手順について説明しました。
その他の技術情報
詳細については、次のリソースを参照してください。