發行項
08/14/2015

本文章是由機器翻譯。

雲端診斷

掌握 Windows Azure 中的記錄與追蹤

Mike Kelly

許多的程式設計人員像我剛開始撰寫程式碼時我用於列印的陳述式偵錯。我 didn’t 知道如何使用偵錯工具和列印陳述式是一個粗糙，但有效的方式，看看我的程式已執行時執行。稍後，我學會如何使用真實的偵錯工具，並捨棄列印陳述式做為偵錯工具。

向前快轉到開始撰寫程式碼在伺服器上執行的。我找到那些列印陳述式現在請在更複雜的「記錄和追蹤，」標題的任何伺服器應用程式的程式設計人員的基本技巧。

即使您可以將偵錯工具附加至實際執行伺服器應用程式 — 這通常 isn’t 可能會因為在裝載應用程式的電腦上的安全性限制，輕鬆地 aren’t 到執行的伺服器應用程式的問題類型顯露與傳統的偵錯工具。許多伺服器應用程式的分佈在多個的機器上執行並偵錯什麼發生在一部電腦上永遠 isn’t 足夠診斷真實世界的問題。

此外，伺服器應用程式經常執行所控制的 wouldn’t 知道如何使用傳統的偵錯工具的作業人員，並為每個問題 isn’t 迫切需要或不實際，開發人員在呼叫。

在本文中我追蹤和偵錯伺服器應用程式所使用的技術，說明一些基本的記錄。然後我深入探討如何針對 Windows Azure 專案可以採用這些技術。一路看到記錄和追蹤與某些的實際的應用程式使用方式和我告訴您如何使用 Windows PowerShell 管理執行中的服務的診斷。

記錄策略

在理想的情況下，任何伺服器應用程式 — 而且基本上包括任何 Web 應用程式執行 Windows Azure — 有一個記錄和追蹤策略從頭開始設計中。記錄資訊應該夠穩定，來描述幾乎一切發生內每個元件。但是，就像那些列印陳述式新增至我的第一個程式可能會產生許多輸出，所以太可以記錄。設計良好的記錄和追蹤，因此包含方式的調整類型及磁碟區的任何元件中的記錄。這可讓作業人員和開發人員可以專注於特定的異常元件或許甚至在特定電腦上，以取得更多有關完全  what 發生內部它 — 而不會產生很多的雜訊可以大幅會覺得很混亂而且可能是緩慢向下應用程式的記錄檔中。

此外，因為伺服器應用程式會經常分散式應用程式，資訊必須收集和彙總從多部電腦 (或許是在不同的應用程式角色)，以取得完整的什麼圖片上時，發生了特定的問題。因此透過電腦識別交易執行緒的方法是重要允許事實之後的彙總。

在 Windows Azure 可用記錄已成熟透過社群技術預覽 (CTP) 版本。最早記錄 wasn’t 比擷取 Windows Azure 資料表儲存區中的文字做為列印陳述式更複雜。Windows Azure 開始 PDC09 發行開始提供更完整的記錄和追蹤基礎結構根據事件追蹤的 Windows (ETW) 架構。

在 ASP.NET 中支援此 ETW 架構，透過 System.Diagnostics 命名空間中的類別。繼承自，並延伸標準 System.Diagnostics 類別 Microsoft.WindowsAzure.Diagnostics 命名空間可讓 Windows Azure 環境中的記錄架構 System.Diagnostics 做。圖 1 顯示 ETW 由 Windows Azure 診斷的實作方式。

圖 1 Windows 的高階概觀 Azure 診斷

ETW 提供一或多個 TraceSources 哪些程式碼記錄檔中的模型。允許透過每個來源的記錄層級是由一個 SourceSwitch 控制。來源是依序連接到一或多個以不同的方式保存記錄資訊的取用者。

Windows Azure 提供一個標準的消費者或接聽程式保存您 Windows Azure 資料表儲存至產生的記錄資訊，或 Blob 儲存體。您也可以撰寫自己的消費者如果您想要執行一些不同的事件] 資料，或使用現成的消費者 (雖然有些可能必須修改在 Windows Azure 環境中工作)。

的 圖 2 所示，ETW 架構會結合一個 TraceEventType 和每個事件中。第五個嚴重性資料列是最常用的值和它們表示追蹤輸出的相對重要性。請注意暫停、繼續和傳輸類型使用 Windows 通訊基礎 (WCF)。

圖 2 追蹤事件類型

TraceEventType	值	意義
要徑	0x0001	嚴重錯誤或應用程式當機
錯誤	0x0002	可復原的錯誤
警告	0x0004	非重大的問題 — 可能是更嚴重的問題出現的指示
資訊	0x0008	資訊訊息
詳細資訊	0x0010	偵錯追蹤 (例如詳細的執行流程資訊、參數，等等)
啟動	0x0100	邏輯作業的開始
停止	0x0200	停止的邏輯作業
暫停	0x0400	暫止的邏輯作業
履歷表 (英文)	0x0800	正在繼續邏輯作業
傳輸	0x1000	轉移到新的活動

如果您尋找只為真的不正確的項目，您想要確定要擷取要徑及可能的錯誤值。如果您想要大量資訊什麼上，看在上面詳細資訊的所有項目。

記錄策略應該包括使用一致的事件型別和 copious 記錄項目，以進一步的值向下的階層架構。它可能幾乎是依照應用程式的執行流程，如果您的應用程式中啟用所有反白顯示的值的記錄。這可能是重要疑難排解錯誤或問題，在實際執行環境中。

您可以連結接聽程式]、 [來源] 和 [參數]，若要以程式設計的方式，啟用不同層級的輸出，但這通常經由組態檔完成。您可以設定輸出 app.config (如 Windows Azure 背景工作角色) 或 (如 Windows Azure Web 角色) 的 web.config 中。但是，我在本文稍後的詳細說明，放入這 ServiceConfiguration.cscfg 中讓您調整記錄和追蹤選項時執行 Windows Azure 服務，而不需重新部署任何執行中程式碼的更新，或甚至停止服務。Windows Azure 也會公開遠端允許某些記錄選項控制 RESTful 的介面。Windows PowerShell 可使用的 [RESTful 介面。

記錄、追蹤和偵錯輸出

記錄，條款追蹤與偵錯輸出可以有時會交替使用。這個本文我要區分什麼可以通常被稱為 diagnosticoutput 在程式碼中的四個不同的型別。這些是大致次序為由最詳細資訊到最詳細的資訊。

偵錯輸出:這是只能在應用程式的偵錯組建中出現，並排除在編譯時期，從發行的組建 (根據在 Visual Studio 預設定義只在偵錯組建中的編譯時間是否定義偵錯的前置處理器符號) 的資訊。通常，偵錯輸出會包括如您可以協助您尋找其中的程式碼如果不遵從「預期的先決條件的情況下新增導致錯誤或偶數的傾印的資料結構的 Assert 等事項。新增這些可幫助您進行偵錯的演算法在偵錯和測試期間。
追蹤:這些是用來幫助追蹤流程控制和程式的狀態，因為它執行的陳述式。想像一下執行偵錯工具、以及逐步程式碼，以及檢查索引鍵在 [監看式] 視窗中的變數的值。追蹤陳述式被為了複寫在 can’t 附加偵錯工具的情況下該經驗而設計的。理想的情況下，它們應該提供足夠的內容，您可以用來查看哪個路徑會發生在應用程式中每個控制點，並有點跟著在程式碼中讀取追蹤陳述式。和追蹤的前置處理器符號定義編譯時期，而且這兩個版本可以使用偵錯組建時，已啟用追蹤。(根據預設值，Visual Studio 定義 TRACE 偵錯和發行組建，但您可以在當然變更這)
事件記錄:這些是用來擷取執行應用程式的過程中的主要事件的陳述式 — 對於執行個體加入項目至資料庫或交易的開始。事件記錄是不同的因為它會擷取主要的狀態，而不是控制項的流程，詳細的追蹤。
錯誤記錄:這些是特殊的情況下，事件記錄的擷取例外或具有潛在危險的情況。範例包括任何已攔截的例外狀況；情況下您希望能夠存取 can’t 存取另一台電腦上的資源 (和的就當然會適當地處理您的應用程式，但要注意) ；以及錯誤回來從 API don’t 預期錯誤的情況。

錯誤記錄也可以用來操作人員的情況下還 aren’t 發生問題，但指示是他們很快就會 — 對於執行個體已接近最大值] 或 [交易的成功，但需要更多的時間，比平常的配額。這一類的記錄事件可以協助操作配置主動地址問題之前就他們會發生避免在應用程式中的停機時間。

大部分良好的開發人員有放大用至自己的應用程式，包括偵錯輸出來幫助他們在開發，診斷問題及許多開發的某種錯誤記錄的解決方案。

不過，您必須要確定考慮不只是偵錯輸出和錯誤記錄的選項，但也有強大的策略，對於追蹤與事件記錄功能可以協助診斷只在實際執行環境中的 stressful 負載下發生的問題。

而且，請仔細考慮是否有很多什麼您現在將追蹤和偵錯和發行版本中可用，而是 shouldn’t 是偵錯輸出會建置。異常的應用程式，在生產環境中通常會執行發行的組建。如果您將追蹤陳述式會顯示，但停用 (如我解釋如何在稍後再進行) 您可以選擇性地啟用它們從發行的組建中取得非常豐富的類似的偵錯輸出幫助您診斷問題。

追蹤和記錄在 Windows Azure

您可以使用 Windows Azure 記錄現成的右邊 — 它 ’s Windows Azure SDK 的一部份。有一些使用像 Logger.NET、企業程式庫、 log4net 或 Ukadc.Diagnostics 的記錄架構的優點。這些記錄訊息中加入其他的結構，以及可以也協助提供一些稍早提到的 configurability。但是，最有不會被強制在 Windows Azure 環境中工作，而且有些是的不只是一個記錄架構。

此發行項的 [範例] 代碼，我決定使用只是標準 Windows Azure 記錄和追蹤的在最上面的細層的 API 提供動態組態。您可能會發現建立一些 Helper 類別和一個架構為您的記錄和追蹤這的頂端的策略很有幫助，或監看的其他架構，以提供 Windows Azure 版本。

當您使用 Visual Studio 的 Windows Azure 中建立新的服務時，它已經啟用執行基本的記錄。Windows Azure 範本所產生重複使用背景工作角色和網頁角色程式碼具有診斷接聽程式已經設定及啟用。

若要啟用簡單的記錄在 Windows Azure 服務，在 Visual Studio 中使用 Windows Azure 雲霧服務 (Visual C#) 範本中開始新的專案。為專案命名。我的範例中，我會使用 MSDNSampleLoggingService。按一下 [確定]。

新增雲霧服務專案精靈將會執行。在精靈，新增到專案的一個背景工作角色和一個網頁的角色。重新命名 LoggingWorkerRole 和網頁角色，以 LoggingWebRole，背景工作角色，然後按一下 [確定]。Visual Studio 會建立專案。

在此時，您可以探索產生的程式碼。查閱 LoggingWorkerRole 專案中 app.config，並注意下列的程式碼便會出現：

<?xml version="1.0" encoding="utf-8" ?>

<configuration>

  <system.diagnostics>

    <trace autoflush="false" indentsize="4">

      <listeners>

        <add name="AzureDiagnostics" type="Microsoft.WindowsAzure.Diagnostics.DiagnosticMonitorTraceListener, Mi-crosoft.WindowsAzure.Diagnostics, Version=1.0.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35" />

      </listeners>

    </trace>

  </system.diagnostics>

</configuration>

這表示任何記錄和追蹤您執行背景工作角色從您的程式碼的診斷接聽會導向至 Windows Azure 接聽程式 (DiagnosticMonitorTraceListener)，除非您變更此標準的 Windows Azure 連結。為這個服務所建立的網頁角色，您在 web.config 中尋找類似的項目。

如果您看一下在背景工作角色專案 WorkerRole.cs 檔案，也請參閱 OnStart 方法中的這一行：

DiagnosticMonitor.Start("DiagnosticsConnectionString");

和您中執行] 方法請參閱追蹤呼叫：

// This is a sample worker implementation. Replace with your logic.

Trace.WriteLine("LoggingWorkerRole entry point called", "Information");

最後，如果您在服務根 ServiceConfiguration.cscfg 檔案中的樣子，看到這一行工作者角色和 Web 的角色：

<Setting name="DiagnosticsConnectionString" 

         value="UseDevelopmentStorage=true" />

這會告訴 Windows Azure 接聽程式用來保存記錄和追蹤資訊的儲存體帳號。這種情況下記錄資訊會儲存在您的本機電腦上儲存的開發中。藉由切換這 Windows Azure 定域機組儲存帳戶，您可以有前往定域機組儲存的記錄檔。以下是使用本文提供的範例程式碼中該格式的範例：

<Setting name="DiagnosticsConnectionString" 

  value="DefaultEndpointsProtocol=https;AccountName=Xxxxxx;AccountKey=Yyyyyy" />

AccountName 和 AccountKey 值需要自訂您的特定 Azure 帳戶及索引鍵。您可以從儲存帳戶入口網站為您的服務在 windows.azure.com]，以取得此資訊。 AccountName 是第一個部分資料表] 和 [項目] 儲存端點的 URL (前的一部份「 table.core.windows。網路」)。 AccountKey 是基底 64 編碼儲存帳戶的主要存取金鑰。

請注意因為不同的儲存體帳戶，用來診斷您可以儲存您與您的應用程式資料分開的診斷資訊。若要執行此動作設定個別儲存帳戶藉由按一下 [入口網站] 頁面上的 [新增服務]，選取 [儲存帳戶，然後為它提供一個名稱 (MyAppLogs，例項)。您可能會想要設定相似性群組，因此您的記錄檔儲存在相同的區域，為您的服務。

既然您採取 Windows Azure 服務中的追蹤程式碼快速教學，您可以執行簡單的網頁角色專案建立。因此您看到訊息出現在 [偵錯] 視窗中的 OnStart Windows Azure 所提供的預設接聽程式也會指示要偵錯的 [輸出] 視窗在 Visual Studio 中輸出的附註建置：

Information: LoggingWorkerRole entry point called

如果您想要查看記錄檔之後執行的服務, 嗎？預設情況下，Windows Azure 不會保留儲存到記錄檔。您可以告訴它執行這項操作角色 ’s OnStart 方法中加入幾行程式碼：

TimeSpan tsOneMinute = TimeSpan.FromMinutes(1);

DiagnosticMonitorConfiguration dmc =

DiagnosticMonitor.GetDefaultInitialConfiguration();



// Transfer logs to storage every minute

dmc.Logs.ScheduledTransferPeriod = tsOneMinute;

// Transfer verbose, critical, etc. logs

dmc.Logs.ScheduledTransferLogLevelFilter = LogLevel.Verbose;    

// Start up the diagnostic manager with the given configuration

DiagnosticMonitor.Start("DiagnosticsConnectionString", dmc);

加入 WorkerRole.cs 和重新執行這個程式碼會導致 Windows Azure 傳輸記錄檔到開發儲存每一分鐘。您也可以選擇要執行的記錄檔 (請參閱 admin.aspx.cs 在我如何執行這項操作的範例應用程式中的程式碼) 的點播傳輸，或是使用本文稍後所述的 Windows PowerShell 命令。請記住一旦您傳送記錄檔以儲存，您需要的儲存空間，它 ’s 您要刪除不再需要的資訊。

一旦您放大到 Windows Azure 儲存的記錄檔，需要查看儲存資料表，以查看記錄檔的工具。我使用 Cerebrata ’s 雲霧存放 Studio ( cerebrata.com )。Cerebrata 與工具，稱為 Azure 診斷管理員，因為都有，也有可用的工具可用 CodePlex ( codeplex.com ) 上查看定域機組儲存和診斷。記錄檔放在名為的 圖 3 中，您可以看到的 WADLogsTable 資料表中。

圖 3 記錄持續開發存放在

當您查看在儲存記錄時，注意到一些事。第一次，Windows Azure 自動會有些資訊關聯每個記錄的事件：時間戳記、滴答計數 (可提供更詳細的 100 奈秒的資料粒度的計時)，及部署、角色和角色的執行個體的相關資訊。這可讓您如果您想要縮小到特定的執行個體的記錄檔。

第二個，有 ’s 一個層級，以及每個事件相關聯的 EventId。層級會對應到的 圖 2 值 — 記錄資訊將有層級的值的 4，如這些追蹤事件，而這些記錄，錯誤會有一個層級 2。泛用 (如同重複使用程式碼)，透過 Trace.WriteLine 傳送的事件將會有層級 5 (詳細資訊)。

EventId 是您所指定的值。基本的 Trace.WriteLine 呼叫前面所示 doesn’t 可讓您指定它，您必須將 [EventId 使用其他的追蹤方法。

選擇性地啟用追蹤和記錄

一般的應用程式是由多個邏輯的元件所組成。對於執行個體，您可能需要處理的資料模型，Windows Azure 儲存區中的資料庫元件。網頁角色可能會依序被分割成系統管理的元件和使用者元件 (和，甚至可能會被分割成應用程式的需求為基礎的邏輯元件的進一步)。

記錄和追蹤選項，可將連接 — 在啟用何種類型的記錄並在何種層級的詳細資料 — 這些元件。這可讓您選擇性地啟用只需要它，避免雜亂的許多元件的追蹤。

不直接，呼叫追蹤，但使用多個 TraceSource 例項，每個命名空間中通常有一個索引鍵的方法。一個 TraceSource 有相關聯的 SourceSwitch 控制來源的啟用與否，以及在需要何種層級的輸出。重要的是，SourceSwitch 值是未編譯時期，但在執行階段設定。如此一來您可以啟用或從不同部分的應用程式停用診斷的輸出，而不需重新編譯它，或甚至重新部署不同的版本。

WorkerDiagnostics.cs 和 WebDiagnostics.cs 包含設定追蹤來源和範例程式碼中的參數。這裡 ’s 摘錄：

// Trace sources

public TraceSource ConfigTrace;

public TraceSource WorkerTrace;

// Add additional sources here



// Corresponding trace switches to control 

// level of output for each source

public SourceSwitch ConfigTraceSwitch { get; set; }

public SourceSwitch WorkerTraceSwitch { get; set; }

// Add additional switches 1:1 with trace sources here

然後，您角色的 [組態] 檔中您攔截這些到 圖 4 所示的接聽程式。這第一次設定標準的 Windows Azure 診斷接聽程式作為共用的接聽程式讓它可以參考到 <sources> 項目中。然後它會設定兩個來源:WorkerTrace 來源和 ConfigTrace 來源。它也設定對應的參數，您可以調整的輸出層級。 ConfigTrace 提供您最詳細資訊輸出； WorkerTrace 提供您錯誤只。

圖 4 設定追蹤來源和接聽程式

<configuration>

  <system.diagnostics>

    <sharedListeners>

      <add type="Microsoft.WindowsAzure.Diagnostics.DiagnosticMonitorTraceListener, Microsoft.WindowsAzure.Diagnostics, Version=1.0.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35"

        name="AzureDiagnostics">

        <filter type="" />

      </add>

    </sharedListeners>

    <sources>

      <source name="ConfigTrace">

        <listeners>

          <add name="AzureDiagnostics" />

        </listeners>

      </source>

      <source name="WorkerTrace">

        <listeners>

          <add name="AzureDiagnostics" />

        </listeners>

      </source>

    </sources>

    <switches>

      <add name="ConfigTrace" value="Verbose"/>

      <add name="WorkerTrace" value="Error"/>

    </switches>

    <trace>

      <listeners>

        <add name="AzureDiagnostics" />

      </listeners>

    </trace>

  </system.diagnostics>

</configuration>

don’t 必須與來源，相同名稱參數，但它會讓生活更容易。如果他們不 ’re 相同，新增 switchName 屬性到來源項目，以指示參數，控制輸出此來源的名稱。這可讓您跨多個追蹤來源共用單一參數。請注意，追蹤來源] 和 [參數名稱會區分大小寫，而且必須完全符合您傳遞給建構函式，在程式碼中的大小寫。

您可以避免在參數括弧，如果您想要的只將 switchValue 屬性加入至指定這個來源所要的參數值的來源項目。您所使用的參數值實際上會剖析從組態檔，為 [SourceLevels 圖 5 ，也顯示了您傳遞給 TraceSource 呼叫的 TraceEventType 與設定來源 SourceLevel，以判斷什麼通過的互動方式中所定義的其中一個。

圖 5 追蹤來源層級和 TraceEventType

您可能已經注意到 [SourceLevel 是位元只是一個遮罩，在執行階段用來決定是否要記錄事件 TraceEventType 是 ANDed。若要組合，例如警告和活動追蹤指定為參數的值，而不是使用所顯示的符號值的位元欄位內的數值。

除了開關，接聽程式可以有一項 TraceFilter 新增至特定的訊息是否允許透過更複雜的執行階段邏輯。撰寫自訂 TraceFilter 超出這個的發行項的領域，但您 CodePlex ( ukadcdiagnostics.codeplex.com/wikipage?title=LoggingPrimer ) Ukadc.Diagnostics 專案的文件中尋找有用的範例。

什麼記錄在執行階段的變更

這是 ASP.NET 追蹤的運作方式，並將正常運作與部署至 Windows Azure 服務的預設方法。問題在於您能在執行階段變更參數值，和 Windows Azure doesn’t 允許您只取代而不需要重新部署服務的 [web.config 或 app.config。泛型的 ASP.NET 解決方案，這是使用 WebConfiguationManager 改變設定的值，但 Windows Azure doesn’t 目前可讓您可以執行此動作的定域機組部署的服務。

解決方法是鏡像 ServiceConfiguration.cscfg 中的這些參數的值。Windows Azure 讓您編輯該檔案 (或上載新) 透過開發入口網站時，您的服務正在執行。您需要撰寫一些額外的程式碼，不過進行這項工作。

預設 System.Diagnostics 程式碼所知只能在 app.config 或 web.config，設定，但您的角色會透過 RoleEnvironmentChanging 和 RoleEnvironmentChanged 事件中 ServiceConfiguration.cscfg 中取得執行階段的變更的通知。您可以再決定是否要回收 (重新啟動) 角色，或只會更新設定值。後者是您要的追蹤參數。重新啟動該角色，可能會使間歇性問題消失。本文的範例程式碼示範如何執行這項操作 ServiceConfiguration.cscfg (請注意您必須也編輯提供結構描述的 ServiceDefinition.csdef) 來新增數個值，並加入您的角色中的某些程式碼。

測試開發光纖

怎麼測試上開發光纖，don’t 有 Windows Azure 入口網站，以編輯組態，和您在定域機組部署服務嗎?第一次，判定識別碼 Windows Azure 已指派到您正在執行的開發結構服務的部署。您可以在執行服務時顯示開發光纖 UI 從系統匣來查看。這是一個數字，例如 177。

移至服務的二進位碼檔案位置放置所建置的目錄 — 通常 \bin\debug 或 \bin\release 您的服務程式碼之下。您尋找 ServiceConfiguration.cscfg 建置應用程式時所建立的複本。
接下來，使用 [文字編輯器中編輯此檔案，以使用您想要的追蹤參數。對於執行個體在 [範例] 程式碼從關閉的 WebTrace 變更詳細資訊。
下一個 Windows Azure SDK 命令提示字元中 (開始 | 程式集 | Windows Azure SDK v1.1 | Windows Azure SDK 命令提示字元)，執行此命令：

csrun /update:NNN;ServiceConfiguration.cscfg

NNN 是您稍早發現的 Windows Azure 部署識別碼。這將會執行開發結構中按一下 Windows Azure 開發入口網站上的 [設定] 按鈕會替定域機組部署服務 — 更新組態設定，然後觸發該事件。

其他診斷資訊

這份文件有焦點放上的同時使用 System.Diagnostics 您應用程式的記錄檔，Windows Azure 可以也擷取 IIS 的表格式資料記錄，並且失敗要求追蹤 (之前稱為失敗要求緩衝或 FREB) 記錄等等。其中有些會放入一些 Windows Azure 資料表儲存在 Windows Azure blob 儲存。圖 6 列出可用的記錄檔和儲存位置。請注意對於那些不是依預設啟用您通常必須在 web.config 或 Windows Azure 收集這些記錄檔的 app.config 中進行變更。let’s 切入一個不收集預設顯示方式的範例。

圖 6 的 標準 Azure 記錄選項

記錄檔的類型	Windows Azure 儲存格式	收集到的預設值嗎?	備忘稿
Windows Azure 從您的程式碼所產生的記錄檔	資料表	4	必須在 web.config 或 app.config 檔案加入追蹤接聽程式，範例程式碼所示。儲存在 WADLogsTable。
IIS 7.0 的記錄檔	二進位大型物件	4	只有 Web 角色。儲存在 Blob 容器下路徑 wad-iis-logfiles\ < 部署識別碼 > \ < Web 角色名稱 > \ < 角色執行個體 > \W3SVC1。
Windows 診斷基礎結構的記錄檔	資料表	4	診斷服務本身的相關資訊。儲存在 WADDiagnosticInfrastructureLogsTable。
失敗要求記錄檔	二進位大型物件		只有 Web 角色。啟用此選項，設定在 web.config system.WebServer 設定] 下方的追蹤選項。儲存在路徑 wad-iis-failedreqlogfiles\ < 部署識別碼 >] 下的項目容器 \ < Web 角色名稱 > \ < 角色執行個體 > \W3SVC1。
Windows 事件記錄檔	資料表		啟用此選項，藉由設定初始設定時改變 DiagnosticMonitor Configuration.WindowsEventLog。儲存在 WADWindowsEventLogsTable。徐維斌 Marx ’s 部落格 (blog.smarx.com/posts/capturing-filtered-windows-events-with-windows-azure-diagnostics) 說明使用這樣的方法。
效能計數器	資料表		啟用此選項，藉由改變 DiagnosticMonitor 組態。PerformanceCounters。儲存在 WADPerformanceCountersTable。範例程式碼工作者角色設定效能計數器。
損毀傾印	二進位大型物件		藉由呼叫 CrashDumps.EnableCollection 啟用。儲存傾路徑 wad-損毀-印在 Blob 容器中。ASP.NET 會處理大多數的例外狀況，因為這是背景工作角色通常只有用。
自訂的錯誤記錄檔	二進位大型物件		不在這個範圍內文件，但請參閱 Neil Mackenzie ’s 部落格 (nmackenzie.spaces.live.com/blog/cns!B863FF075995D18A!537.entry) 很有幫助的範例，說明如何使用此。

做為範例，let’s 查看如何啟用 FREB 從 IIS Web 角色上的記錄。這示動作來提供與此發行項的 MSDNSampleLoggingService 下載範例程式碼。開啟 [LoggingWebRole web.config 並找出標示為區段 <system.webServer>。請注意的 圖 7 所示的線都已新增至預設的 Windows Azure web.config。這會導致長 15 秒以上，或與狀態碼 400 和 599 (failureDefinitions 項目) 之間的任何要求的失敗記錄。

圖 7 失敗要求的 LoggingWebRole 記錄

<tracing>

  <traceFailedRequests>

    <add path="*">

      <traceAreas>

        <add provider="ASP" verbosity="Verbose" />

        <add provider="ASPNET" 

             areas="Infrastructure,Module,Page,AppServices"

             verbosity="Verbose" />

        <add provider="ISAPI Extension" verbosity="Verbose" />

        <add provider="WWW Server"

             areas="Authentication,Security,Filter,StaticFile,CGI,Compression,Cache,RequestNotifications,Module" 

             verbosity="Verbose" />

      </traceAreas>

      <failureDefinitions timeTaken="00:00:15" statusCodes="400-599" />

    </add>

  </traceFailedRequests>

</tracing>

如果您開啟 about.aspx.cs LoggingWebRole 專案中，請注意 PageLoad 方法中我加入這一行程式碼與任意延遲為 18 的秒：

System.Threading.Thread.Sleep(18000);

這會強制此頁面視為失敗的要求下定義先前指定的負載。

若要到 FREB 記錄檔重建並將應用程式部署到開發結構 (您可能需要按一下工作列上的 [顯示隱藏的圖示] 按鈕，因為它通常隱藏為非使用中) 在工作列的通知區域中找出開發結構控制站]。以滑鼠右鍵按一下它，然後選取 [顯示開發光纖 UI。在執行應用程式時，這會顯示應用程式的相關資訊。

展開 [網頁角色和角色執行個體 (0) 上按一下滑鼠右鍵。選取 [開啟舊檔以開啟記錄檔會被儲存的位置 (請參閱的 圖 8) 在本機電腦上資料夾的本機存放區。在該的資料夾記錄檔位於 \directory\DiagnosticStore 資料夾中。這是因為網頁角色，範例程式碼中設定診斷資訊儲存在開發的儲存體。如果設定 [DiagnosticsConnectionString 定域機組儲存帳戶，保存記錄檔會與該儲存帳戶相關聯的項目儲存體中。您可以使用雲霧存放 Studio 查看 blob 儲存容器，以查看記錄檔。

圖 8 的 開啟記錄檔儲存到本機開發光纖存放裝置

正在執行的服務管理診斷

雖然您可能深檢測您的程式碼，以記錄，通常 don’t 要生產服務正在執行時，所有記錄資訊都保存到儲存。您可以只錯誤和重要的資訊，以更詳細的資訊 (為詳細資訊或資訊記錄) 時，請移至 [保存] 記錄檔隱藏起來。

但是，如果發生問題吗？don’t 要重新部署新的版本，您的服務或問題可能神奇地消失 — 您應該知道如何有效重新開機可能會讓 elusive 消失的問題。

而是，它 ’s 增加要記錄資料表的資訊數量，或同時允許繼續執行異常的程式碼 Blob 儲存更有效率。這是比較容易目前操作時，顯示在您的應用程式問題的原因。

我稍早所述如何微調的哪些記錄傳遞至 Windows Azure 診斷特定 TraceSource 的詳細資料。’s 的上游編輯的取得記錄哪些資訊的排序。此單元我告訴您一般的 Windows Azure 診斷設定，決定通過一個 TraceSource 的資訊如何進入永續性儲存體。

Windows PowerShell Cmdlet 可以管理包括診斷您正在執行 Windows Azure 服務的許多方面。您執行這些從您的本機電腦與它們連線透過網際網路對 Windows Azure 定域機組伺服器執行您的服務、提供資訊，並調整參數。Windows PowerShell 安裝與 Windows 7，並可為 Windows Vista 從 microsoft.com/powershell 下載。code.msdn.microsoft.com/azurecmdlets 從下載 Windows Azure 服務管理指令程式，並遵循安裝它們的說明。的 圖 9 顯示 Windows Azure 診斷相關的命令。

圖 9 的 Windows Azure 管理診斷指令程式

名稱	描述
取得 ActiveTransfers	傳回使用中的診斷傳輸與相關聯的傳輸資訊的集合。
取得 CommonConfigurationLogs	取得所有的記錄緩衝區的常見的設定值。這包括在組態中的變更會輪詢和配置記憶體中的記錄檔緩衝區大小的間隔時間。
取得 DiagnosticAwareRoleInstances	傳回一份具有執行診斷監視器的主動的角色執行個體的 ID。
取得 DiagnosticAwareRoles	列出已順利啟動至少一個診斷監視器的角色集合。
取得 DiagnosticConfiguration	取得緩衝區設定為指定的緩衝區名稱 ([記錄檔]、 [目錄]、 [PerformanceCounters]、 [WindowsEventLogs 或 [DiagnosticInfrastructureLogs])。
設定 CommonConfigurationLogs	所有的記錄緩衝區設定通用的設定值。
設定 FileBasedLog	設定檔為基礎的記錄檔緩衝區的組態。
設定 InfrastructureLog	設定緩衝區設定，為基礎的 Windows Azure 診斷基礎結構所產生的記錄檔。診斷的基礎結構記錄檔是有用的疑難排解診斷系統本身。
設定 PerformanceCounter	設定緩衝區設定，為收集程式服務的效能計數器資料。
設定 WindowsAzureLog	設定基本的 Windows Azure 緩衝區的組態記錄您的服務所產生。
設定 WindowsEventLog	設定您的服務所產生的 Windows 事件記錄檔緩衝區的組態。
開始 OnDemandTransfer	啟動指定的資料緩衝區的點播傳輸。這會將資料移至 Windows Azure 儲存體 (資料表或 blob 儲存)。
停止 ActiveTransfer	停止使用中點播傳輸，指定傳輸的識別碼。

就例如尋找目前的傳輸特定角色執行個體的參數，傳遞部署識別碼 (從 Windows Azure 開發人員入口網站，您將部署服務) 和儲存帳戶名稱和您用來在 app.config 或服務角色的 web.config DiagnosticsConnectionString 金鑰 (請參閱的 [圖 10])。請注意 Windows PowerShell 會提示輸入幾個遺失必要的參數，角色執行個體和緩衝區，我想要的名稱。記錄檔是標準的 Windows Azure 記錄檔。篩選層級是詳細資訊，然後傳送排程每分鐘，就會顯示結果。

圖 10 的 使用 Windows PowerShell 執行服務的診斷設定

的 圖 11 所示，將這個角色組態使用設定 DiagnosticConfiguration] 指令程式。請注意我變更傳輸期間從一分鐘到兩分鐘的時間，並從詳細資訊篩選器為 [錯誤] 中表示記錄錯誤和嚴重的事件將會傳送到永續性儲存體。

圖 11 變更診斷設定從 Windows PowerShell

或許您可以從 Windows PowerShell 從遠端執行最有用的事是立即強制的記錄檔資訊的傳輸。圖 12 示範如何執行這項操作。

圖 12 使用啟動 IIS 記錄檔傳送到 Windows PowerShell

第一次，我查詢記錄檔的任何現有的點播傳輸。沒有限制，在目前的 Windows Azure 診斷實作的特定型別只能有一個隨選傳輸可以會發生一次。由於，沒有進行中我要求，傳遞傳輸部署識別碼的服務]、 [角色] 和 [執行個體]、 [我要傳送記錄檔的類型] 及 [時間間隔的資料中。(記錄] 類型的目錄表示檔案為基礎的記錄，包括 IIS 記錄檔。記錄檔會是 Windows Azure 資料表為基礎記錄 TraceSource 透過傳送)。

我也會傳遞是 Windows Azure 診斷傳送傳送已完成的通知的其中一個通知佇列名稱。透過實驗，我發現是否我 didn’t 傳遞通知佇列，傳輸好像不會發生。我得到 GUID 識別傳輸要求。我接著查詢要求狀態並看到它發行，表示它 ’s 進行中。

目前版本的 Windows Azure 服務管理 Cmdlet doesn’t 似乎顯示時完成要求，但如果您看到您診斷儲存查詢 blob 儲存記錄檔快顯在短時間內容器階層架構中 (或在 Windows Azure 表格儲存體) 如果您要求的資訊儲存在資料表的儲存體的傳輸。

總結

如您在程式碼中定義的 TraceSources 調整設定參數，並使用 Windows Azure 服務管理指令程式，將資訊移至永續性儲存體的組合應該是您能夠完全控制您從 Windows Azure 服務取得何種診斷輸出。

就說最重要的是，您可以如何疑難排解您的實際執行程式碼是開發健全的策略的輸出開發，在早期的診斷，然後依照整個程式碼撰寫該策略。TraceSources 和 Windows Azure 提供設定流向從您的應用程式儲存區的診斷輸出的詳細等級的工具的使用會幫助您點一下 [插入，取得只是當發生問題時，您需要的資訊數量。

有比像在伺服器上的異常行為的程式碼是黑色方塊，您不透明的感覺更糟的是 ’s 執行任何動作。實心的診斷程式碼和此處所描述的工具可讓您開啟該方塊的封面和內部對等。

Mike Kelly 是顧問，著重於軟體開發和整合到較大的公司購併的幫助。他先前處理 15 年在 Microsoft 的產品開發角色以及新興的作法的 [主管]，在 [製程工程的優勢小組以不同。他可以達到 himself@mikekellyconsulting.com

多虧來檢閱本文的下列的技術專家： Sumit Mehrotra、 Michael Levin 和從 Microsoft，Matthew Kerner 以及 Neil Mackenzie 和 Steven Nagy

Share via

雲端診斷

掌握 Windows Azure 中的記錄與追蹤

Mike Kelly

記錄策略

記錄、追蹤和偵錯輸出

追蹤和記錄在 Windows Azure

選擇性地啟用追蹤和記錄

什麼記錄在執行階段的變更

測試開發光纖

其他診斷資訊

正在執行的服務管理診斷

總結

其他資源

Share via

雲端診斷

掌握 Windows Azure 中的記錄與追蹤

Mike Kelly

記錄策略

記錄、 追蹤和偵錯輸出

追蹤和記錄在 Windows Azure

選擇性地啟用追蹤和記錄

什麼記錄在執行階段的變更

測試開發光纖

其他診斷資訊

正在執行的服務管理診斷

總結

其他資源

記錄、追蹤和偵錯輸出