Freigeben über

Windows Azure 1.4 診斷工具整體彙總

  • Artikel

英文原文已於 2011 年 8 月 24 日星期三發佈

我知道網路上已有許多討論使用 Windows Azure 之診斷工具的部落格討論及文章。事實上，當我在提供這項產品最近所提供的詳細資訊時，這確實曾經造成困擾。我發現有一大堆的各式文章散落於不同版本的 Azure 中，因此要了解哪些功能適合與最新版的 Azure SDK (1.4) 一起搭配使用，十分費時費力。所以我希望能夠利用這篇文章，涵蓋一起使用 Azure 診斷工具與 1.4 版 SDK 時所要注意的各項重點。

 

一如多數人所知，Azure 所含的內建追蹤接聽程式，可以接受 Trace.* 命令 (如 Trace.Write、Trace.WriteLine、Trace.TraceInformation 等)，並將其儲存在記憶體中。不過，您必須執行某些動作，才可將其移至永久儲存體中。這些動作可能是手動傳輸資料，也可能是設定傳輸執行時間的排程。除此之外，您也可能會選擇移動事件記錄檔中的資訊、擷取效能計數器、移動 IIS 記錄檔及自訂記錄檔。

 

除了前述的所有一般記錄及除錯工具之外，您也可將您的部署設定成允許 RDP 到託管您應用程式的 Azure 伺服器，以及啟用 IntelliTrace，在已部署的應用程式中執行一定程度的偵錯及疑難排解。以下就來探討這些不同的作業。

 

您如果要設定不同的診斷元件 (例如將資料永久存入儲存體的頻率、應配置的儲存體空間量、由何者執行所要擷取的計數器等)，在標準 Web Role Azure 應用程式隨附的 WebRole.cs 檔案 (我認為除了 VM 角色之外的大部分 Azure 功能，都具有類似 WebRole 類別的設計，如「背景工作角色」專案的 WorkerRole.cs 檔案) 中撰寫程式碼，應是最容易達成目標的方式。在我們進入程式碼部分之前，您應先檢視您的 Azure Role 專案，檢查 [設定] 索引標籤上的方塊有無出現「指定診斷結果的儲存體帳戶認證:」。請使用方塊中的選擇器按鈕，選取您的 Azure 儲存帳號；請勿使用本機開發。如此一來，新的連線字串將儲存到專案 "Microsoft.WindowsAzure.Plugins.Diagnostics.ConnectionString" 之中。

 

現在我們就來看看 Web 角色類別中的整個程式碼區塊，然後我將依照不同的特性分別說明：

 

public override bool OnStart()

{

   // For information on handling configuration changes

   // see the MSDN topic at https://go.microsoft.com/fwlink/?linkid=166357\&clcid=0x404 (可能為英文網頁)

 

   try

   {

       //initialize the settings framework

                Microsoft.WindowsAzure.CloudStorageAccount.SetConfigurationSettingPublisher((configName, configSetter) =>

       {

          configSetter(RoleEnvironment.GetConfigurationSettingValue(configName));

       });

 

       //get the storage account using the default Diag connection string

       CloudStorageAccount cs =

          CloudStorageAccount.FromConfigurationSetting(

          "Microsoft.WindowsAzure.Plugins.Diagnostics.ConnectionString");

 

       //get the diag manager

       RoleInstanceDiagnosticManager dm = cs.CreateRoleInstanceDiagnosticManager(

          RoleEnvironment.DeploymentId,

          RoleEnvironment.CurrentRoleInstance.Role.Name,

          RoleEnvironment.CurrentRoleInstance.Id);

 

       //get the current configuration

       DiagnosticMonitorConfiguration dc = dm.GetCurrentConfiguration();

 

       //if that failed, get the values from config file

       if (dc == null)

          dc = DiagnosticMonitor.GetDefaultInitialConfiguration();

 

       //Windows Azure Logs

       dc.Logs.BufferQuotaInMB = 10;

       dc.Logs.ScheduledTransferLogLevelFilter = LogLevel.Verbose;

       dc.Logs.ScheduledTransferPeriod = TimeSpan.FromMinutes(5);

 

       //Windows Event Logs

       dc.WindowsEventLog.BufferQuotaInMB = 10;

       dc.WindowsEventLog.DataSources.Add("System!*");

       dc.WindowsEventLog.DataSources.Add("Application!*");

       dc.WindowsEventLog.ScheduledTransferPeriod = TimeSpan.FromMinutes(15);

 

       //Performance Counters

       dc.PerformanceCounters.BufferQuotaInMB = 10;

       PerformanceCounterConfiguration perfConfig =

          new PerformanceCounterConfiguration();

       perfConfig.CounterSpecifier = @"\Processor(_Total)\% Processor Time";

       perfConfig.SampleRate = System.TimeSpan.FromSeconds(60);

      dc.PerformanceCounters.DataSources.Add(perfConfig);

       dc.PerformanceCounters.ScheduledTransferPeriod = TimeSpan.FromMinutes(10);

 

       //Failed Request Logs

       dc.Directories.BufferQuotaInMB = 10;

       dc.Directories.ScheduledTransferPeriod = TimeSpan.FromMinutes(30);

 

       //Infrastructure Logs

       dc.DiagnosticInfrastructureLogs.BufferQuotaInMB = 10;

       dc.DiagnosticInfrastructureLogs.ScheduledTransferLogLevelFilter =

          LogLevel.Verbose;

       dc.DiagnosticInfrastructureLogs.ScheduledTransferPeriod =

          TimeSpan.FromMinutes(60);

 

       //Crash Dumps

       CrashDumps.EnableCollection(true);

 

       //overall quota; must be larger than the sum of all items

       dc.OverallQuotaInMB = 5000;

 

       //save the configuration

       dm.SetCurrentConfiguration(dc);

   }

   catch (Exception ex)

   {

       System.Diagnostics.Trace.Write(ex.Message);

   }

 

   return base.OnStart();

}

 

首先讓我們先仔細地看看這組程式碼。我會從取得診斷所需之連線字串的值著手，以便能夠連線到所要使用的儲存帳號。之後我們將會使用這個儲存帳號，儲存診斷監視設定類別。當我取得該類別之後，就可以開始設定各種記錄元件。

 

Windows Azure 記錄檔是儲存所有 Trace.* 呼叫之處。我將記錄檔容量上限設定成 10MB，由其儲存資料表中的重要資料，並且每隔 5 分鐘將所有等級為「詳細資訊」以上的資料寫入，永久儲存在其中。順便提一下，您如需 Windows Azure 用於儲存此記錄資料的各種表格與佇列清單，請參閱下列網頁： https://msdn.microsoft.com/zh-tw/library/hh180875.aspx   及 https://msdn.microsoft.com/zh-tw/library/microsoft.windowsazure.diagnostics.diagnosticmonitorconfiguration.aspx基礎結構記錄檔與診斷記錄檔幾乎完全相同。

 

我在事件檢視器項目中加入了我想要擷取到 WindowsEventLog 類別之 DataSources 清單中的各個記錄檔。我可以在此處提供 "Application!*"、"System!*" 或 "UserData!*" 三種值。其他屬性則與 Windows Azure 記錄檔說明中所述的屬性相同。

 

若是效能計數器，您必須指出您所要擷取的計數器，以及計數器採樣資料的頻率。在上述範例中，我加入了 CPU 計數器，並將其設定成每 60 秒採樣資料一次。

 

最後我還啟用了當機傾印的擷取功能，以及將所有記錄資料的整體配額變更為大約 5GB，然後再儲存這些變更。請注意，您應提高整體配額，否則可能會收到指出您的儲存體不足以進行上述變更的例外。5GB 目前算是安全的數字，但應隨您的需要而適度調整。

 

現在萬事俱備，可以發佈應用程式了。當您從 Visual Studio 發佈應用程式時，應注意下列事項：

 

 

您應在 [發佈設定] 對話方塊中，核取 [啟用 IntelliTrace] (Enable IntelliTrace) 方塊，稍後我將詳細解說這點。此外我會建議您按一下 [設定遠端桌面連接...] (Configure Remote Desktop connections…) 連結。我發現在某些情況下，這是唯一能夠解決問題的方法。由於遠端桌面的說明文件距離現在可能有一點年代久遠，因此我建議您選擇使用此對話方塊，而不要手動編輯組態檔案。如此會帶出類似以下的對話方塊：

 

 

此處要注意的要點：

  1. 您可以使用任何一種憑證，但前提是您必須擁有該憑證的 PFX 檔案。請注意，您必須將此憑證上傳到您的託管服務，才可發佈應用程式。
  2. [使用者名稱] 欄位可以是任何設定值；這會建立使用該使用者名稱及密碼的本機帳戶。

 

至此您已經完成所有對話方塊的設定，並可發佈您的應用程式了。請按一下您的應用程式加以啟動，確定您的 Web 角色程式碼是否已執行。執行之後，應可檢查應用程式的診斷設定，確定您的自訂項目是否均已套用，如下圖所示 (注意：我使用免費的 CodePlex 工具管理 Azure，您可以從下列網址下載此工具： https://wapmmc.codeplex.com/ (可能為英文網頁)):

 

 

執行一部分的程式碼且在下一次 Windows Azure 記錄檔的排定傳輸時段之後，我即可檢視 WADLogsTable 中所顯示之我的 Trace.* 呼叫，如下圖所示：

 

 

此外，由於我設定了允許 RDP 進入我的應用程式，因此，當我按一下 Web 角色時，會在 Azure 開發人員入口網站的工具列上，啟用進行 RDP 與應用程式之間連線的選項 ：

 

 

現在我已經有我可以使用之應用程式相關的所有記錄檔與追蹤，並可在需要進一步調查問題時，讓 RDP 連線到伺服器。另外我已啟用了另一項很棒的功能 IntelliSense。由於 IntelliSense 不在這篇文章的說明範圍內，因此，建議您可以參考下列網址所提供的一些實用資訊： https://blogs.msdn.com/b/jnak/archive/2010/06/07/using-intellitrace-to-debug-windows-azure-cloud-services.aspx (可能為英文網頁) 及 https://blogs.msdn.com/b/ianhu/archive/2010/03/16/intellitrace-what-we-collect.aspx (可能為英文網頁)。若已啟用 IntelliTrace，當我在 [Visual Studio 伺服器總管] 中檢視我的託管服務時，會顯示如下：

 

 

我可以在我的應用程式執行個體上按一下滑鼠右鍵，然後選取 [檢視 IntelliTrace 記錄檔] 功能表項目。如此會從 Azure 下載 IntelliTrace 記錄檔，並在 Visual Studio 中開啟這些檔案，如下所示：

 

 

一如圖片所示，我可以看到原先所使用的執行緒、之前所發出的例外、系統資訊、之前所載入的模組等。我將診斷資訊的整體儲存體配置設為 5MB，藉此模擬例外狀況進行測試。還記得我在前文中說過儲存體配置大小應大於 5GB 嗎？我在變更之後發佈了我的應用程式，然後在數分鐘後下載 IntelliTrace 記錄檔。毫無疑問地，在記錄檔的第二頁，我看到了下圖中所標示的錯誤：

 

 

看完本篇文章之後，相信您對於 Windows Azure 1.4 的診斷工具應該有了一個完整初步了解。我們可以擷取追蹤事件、事件記錄檔、效能計數器、IIS 記錄檔、當機傾印及任何自訂的診斷記錄檔。如有需要，我也可以 RDP 到伺服器，進行進一步的疑難排解。我不只可以從我的應用程式下載 IntelliTrace 記錄檔，也可以在我的 Visual Studio 2010 本機執行個體上執行一定程度的偵錯。

這是翻譯後的部落格文章。英文原文請參閱 Windows Azure 1.4 Diagnostics All Up Overview