監控和診斷指引

雲端中執行的分散式應用程式及服務依其本質為包括多個移動組件的複雜軟體片段。 在生產環境中，請務必追蹤使用者使用系統的方式、追蹤資源使用率，以及一般監視系統的健康情況和效能。 您可以使用此資訊當做診斷協助來偵測並更正問題，同時也能夠協助找出潛在的問題並避免發生。

監視和診斷案例

您可以使用監視來深入了解系統運作狀況。 監視是維護服務品質目標的關鍵部分。 收集監視資料的常見案例包括：

• 確保系統保持良好狀態。
• 追蹤系統及其元件元素的可用性。
• 維護效能，以確保系統輸送量不會意外降低，因為工作量增加。
• 保證系統符合與客戶建立的任何服務等級協定（SLA）。
• 保護系統、使用者及其數據的隱私權和安全性。
• 追蹤針對稽核或法規用途執行的作業。
• 監視系統的日常使用狀況，並找出在未解決時可能導致問題的趨勢。
• 追蹤發生的問題，從初始報告到分析可能的原因、整改、後續軟體更新和部署。
• 追蹤作業和偵錯軟體版本。

下列各節將更詳細地說明這些案例。 每個案例的資訊會以下欄格式討論：

1. 案例的簡短概觀。
2. 此案例的一般需求。
3. 支援案例所需的原始檢測數據，以及此資訊的可能來源。
4. 如何分析及合併此原始數據，以產生有意義的診斷資訊。

健康狀態監視

如果系統正在執行且能夠處理要求，則系統狀況良好。 健康情況監視的目的是要產生系統目前健全狀況的快照集，以便確認系統的所有元件都如預期般運作。

健康情況監視的需求

如果系統的任何部分被視為狀況不良，操作員應快速（在幾秒鐘內）發出警示。 操作員應該能夠確定系統的哪些部分正常運作，以及哪些部分發生問題。 系統健康情況可以透過交通燈系統醒目提示：

• 紅色代表狀況不良（系統已停止）
• 部分狀況良好的黃色 （系統正在以降低功能執行）
• 綠色為完全健康

完整的健康情況監視系統可讓操作員向下切入系統，以檢視子系統和元件的健全狀況狀態。 例如，如果整體系統描述為部分狀況良好，操作員應該能夠放大並判斷目前無法使用哪些功能。

數據源、檢測和數據收集需求

支援健康情況監視所需的原始數據，可能會因為下列情況而產生：

• 追蹤使用者要求的執行。 此資訊可用來判斷哪些要求成功、哪些要求失敗，以及每個要求所花費的時間長度。
• 綜合用戶監視。 此程式會模擬使用者所執行的步驟，並遵循預先定義的一系列步驟。 應該擷取每個步驟的結果。
• 記錄例外狀況、錯誤和警告。 這項資訊可以擷取，因為內嵌在應用程式程式代碼中的追蹤語句，以及從系統參考之任何服務的事件記錄檔擷取資訊。
• 監視系統使用之任何第三方服務的健康情況。 這項監視可能需要擷取和剖析這些服務提供的健康情況數據。 這項資訊可能會採用各種格式。
• 端點監視。 此機制會在一節中詳細說明。
• 收集環境效能資訊，例如背景 CPU 使用率或 I/O（包括網路）活動。

分析健康情況數據

健康情況監視的主要重點是快速指出系統是否正在執行。 如果偵測到重要元件狀況不良，立即數據的熱分析可能會觸發警示。 （例如，它無法回應連續的一系列 Ping。然後，操作員可以採取適當的更正動作。

更進階的系統可能包含預測專案，可針對最近和目前的工作負載執行冷分析。 冷分析可以找出趨勢，並判斷系統是否可能保持狀況良好，或系統是否需要額外的資源。 此預測元素應以重大效能計量為基礎，例如：

• 針對每個服務或子系統的要求速率。
• 這些要求的回應時間。
• 流入和流出每個服務的數據量。

如果任何計量的值超過定義的閾值，系統可能會引發警示，讓操作員或自動調整（如果有的話）採取維護系統健康情況所需的預防性動作。 這些動作可能涉及新增資源、重新啟動一或多個失敗的服務，或將節流套用至優先順序較低的要求。

可用性監視

真正狀況良好的系統需要有組成系統的元件和子系統可供使用。 可用性監視與健康情況監視密切相關。 但是，雖然健康情況監視提供系統目前健全狀況的立即檢視，但可用性監視則與追蹤系統的可用性及其元件有關，以產生系統運行時間的相關統計數據。

在許多系統中，某些元件（例如資料庫）會設定內建備援，以允許在發生嚴重錯誤或連線中斷時快速故障轉移。 在理想情況下，使用者不應該知道發生這類失敗。 但從可用性監視的觀點來看，必須盡可能收集這類失敗的相關信息，以判斷原因並採取更正動作，以防止其週期性。

追蹤可用性所需的數據可能取決於一些較低層級的因素。 其中許多因素可能專屬於應用程式、系統和環境。 有效的監視系統會擷取對應至這些低階因素的可用性數據，然後匯總它們，以整體了解系統。 例如，在電子商務系統中，可讓客戶下訂單的商務功能可能會取決於儲存訂單詳細數據的存放庫，以及處理支付這些訂單之貨幣交易的付款系統。 因此，系統訂單放置部分的可用性是存放庫和付款子系統可用性的功能。

可用性監視的需求

操作員也應該能夠檢視每個系統和子系統的歷史可用性，並使用此資訊來找出任何可能導致一或多個子系統定期失敗的趨勢。 （服務在與尖峰處理時間相對應的特定時間開始失敗嗎？

監視解決方案應該提供每個子系統可用性或無法使用的立即和歷程記錄檢視。 當一或多個服務失敗或使用者無法連線到服務時，它也應該能夠快速警示操作員。 這不僅監視每個服務，而且會檢查每個用戶在嘗試與服務通訊時失敗時所執行的動作。 在某種程度上，連線失敗的程度是正常的，可能是因為暫時性錯誤所致。 但是，允許系統針對在特定期間發生的指定子系統的連線失敗數目引發警示可能很有用。

數據源、檢測和數據收集需求

與健康情況監視一樣，由於綜合使用者監視和記錄可能發生的任何例外狀況、錯誤和警告，因此會產生支援可用性監視所需的原始數據。 此外，您可以從執行端點監視取得可用性數據。 應用程式可以公開一或多個健康情況端點，每個測試對系統內功能區域的存取。 監視系統可以遵循定義的排程來偵測每個端點，並收集結果（成功或失敗）。

必須記錄所有逾時、網路連線失敗和連線重試嘗試。 所有數據都應該有時間戳。

分析可用性數據

檢測數據必須匯總並相互關聯，才能支援下列類型的分析：

• 系統與子系統的立即可用性。
• 系統和子系統的可用性失敗率。 在理想情況下，操作員應該能夠將失敗與特定活動相互關聯：系統失敗時發生了什麼事？
• 在發生失敗時，系統或任何子系統的失敗率歷程記錄檢視，以及系統負載（例如，例如使用者要求數目）。
• 系統或任何子系統無法使用的原因。 例如，原因可能是服務未執行、連線中斷、連線但逾時，以及已連線但傳回錯誤。

您可以使用下列公式來計算服務在一段時間內的可用性百分比：

%Availability =  ((Total Time – Total Downtime) / Total Time ) * 100

這適用於 SLA 用途。 （本指南稍後會更詳細地說明 SLA 監視。停機時間的定義取決於服務。 例如，Visual Studio Team Services 組建服務會將停機時間定義為建置服務無法使用的期間（累計總分鐘數）。 如果建置服務的所有連續 HTTP 要求在一分鐘內執行客戶起始的作業，可能會導致錯誤碼或未傳回回應，則會將分鐘視為無法使用。

效能監控

由於系統承受著越來越多的壓力（藉由增加用戶的數量），這些使用者存取的數據集大小就會增加，而且一或多個元件失敗的可能性就越大。 元件失敗通常會在效能降低之前。 如果能夠偵測到這類減少，您可以採取主動步驟來補救這種情況。

系統效能取決於許多因素。 每個因素通常會透過關鍵效能指標（KPI）來測量，例如每秒的資料庫交易數目，或成功在指定時間範圍內服務的網路要求數量。 其中一些 KPI 可能以特定效能量值的形式提供，而其他 KPI 則可能衍生自計量的組合。

效能監視的需求

若要檢查系統效能，操作員通常需要查看包括：

• 使用者要求的回應率。
• 並行使用者要求的數目。
• 網路流量。
• 正在完成商務交易的速率。
• 要求的平均處理時間。

也有助於提供可讓操作員協助找出相互關聯的工具，例如：

• 並行用戶數目與要求延遲時間（用戶傳送要求后開始處理要求所需的時間）。
• 並行用戶數目與平均回應時間（開始處理之後完成要求所需的時間）。
• 要求數量與處理錯誤數目的比較。

除了這個高階功能資訊，操作員應該能夠取得系統中每個元件效能的詳細檢視。 此資料通常會透過低階性能計數器來提供，以追蹤資訊，例如：

• 記憶體使用率。
• 線程數目。
• CPU 處理時間。
• 要求佇列長度。
• 磁碟或網路 I/O 速率和錯誤。
• 寫入或讀取的位元組數目。
• 中間件指標，例如佇列長度。

所有視覺效果都應該允許運算子指定時間週期。 顯示的數據可能是目前狀況的快照集或效能的歷史檢視。

操作員應該能夠根據任何指定時間間隔內任何指定值的任何效能量值來引發警示。

數據源、檢測和數據收集需求

您可以藉由監視使用者要求送達並通過系統，來收集高階效能數據（輸送量、並行用戶數目、商務交易數目、錯誤率等等）。 這牽涉到將追蹤語句併入應用程式程式代碼中的關鍵點，以及計時資訊。 所有錯誤、例外狀況和警告都應該使用足夠的數據來擷取，以便將它們與造成這些錯誤的要求相互關聯。 網際網路資訊服務 （IIS） 記錄檔是另一個有用的來源。

可能的話，您也應該擷取應用程式使用之任何外部系統的效能數據。 這些外部系統可能會提供自己的性能計數器或其他功能來要求效能數據。 如果無法這樣做，請記錄資訊，例如對外部系統提出之每個要求的開始時間和結束時間，以及作業的狀態（成功、失敗或警告）。 例如，您可以使用停止監看法來計時要求：在要求啟動時啟動定時器，然後在要求完成時停止定時器。

系統中個別元件的低階效能數據可透過 Windows 性能計數器和 Azure 診斷 等功能和服務來取得。

分析效能資料

大部分的分析工作都包含依使用者要求類型或傳送每個要求的子系統或服務來匯總效能數據。 使用者要求的範例是將專案新增至購物車，或在電子商務系統中執行結帳程式。

另一個常見的需求是摘要所選百分位數中的效能數據。 例如，操作員可能會判斷 99% 的要求回應時間、95% 的要求和 70% 的要求。 可能會為每個百分位數設定 SLA 目標或其他目標。 應近乎即時地報告進行中的結果，以協助偵測立即的問題。 為了統計目的，結果也應該在較長的時間內匯總。

在影響效能的延遲問題的情況下，操作員應該能夠藉由檢查每個要求所執行之每個步驟的延遲，快速找出瓶頸的原因。 因此，效能數據必須提供讓每個步驟相互關聯效能量值的方法，以將它們系結至特定要求。

視視覺效果需求而定，產生並儲存包含原始數據檢視的數據 Cube 可能很有用。 此數據 Cube 可以允許對效能資訊進行複雜的臨機操作查詢和分析。

安全性監視

包含敏感數據的所有商業系統都必須實作安全性結構。 安全性機制的複雜性通常是數據敏感度的功能。 在要求使用者通過驗證的系統中，您應該記錄：

• 無論是失敗還是成功，所有登入嘗試都會失敗。
• 由所執行的所有作業，以及已驗證使用者所存取之所有資源的詳細數據。
• 當用戶結束會話並註銷時。

監視可能有助於偵測系統上的攻擊。 例如，大量失敗的登入嘗試可能表示暴力密碼破解攻擊。 要求意外激增可能是分散式阻斷服務 （DDoS） 攻擊的結果。 您必須準備好監視所有資源的要求，不論這些要求的來源為何。 具有登入弱點的系統可能會不小心向外界公開資源，而不需要用戶實際登入。

安全性監視的需求

安全性監視的最重要層面應該可讓操作員快速：

• 偵測未經驗證的實體嘗試入侵。
• 識別實體對未獲授與存取權的數據執行作業的嘗試。
• 判斷系統或系統的某些部分是否受到外部或內部的攻擊。 （例如，惡意驗證的使用者可能會嘗試關閉系統。

若要支持這些需求，如果下列情況，應通知操作員：

• 一個帳戶會在指定的期間內重複失敗的登入嘗試。
• 一個已驗證的帳戶會在指定的期間重複嘗試存取禁止的資源。
• 在指定的期間內，會發生大量未經驗證或未經授權的要求。

提供給操作員的信息應該包含每個要求的來源主機位址。 如果安全性違規經常來自特定位址範圍，可能會封鎖這些主機。

維護系統安全性的關鍵部分是能夠快速偵測偏離一般模式的動作。 資訊，例如失敗或成功的登入要求數目，可以可視化方式顯示，以協助偵測活動是否在不尋常的時間出現尖峰。 （此活動的範例是使用者於上午 3：00 登入，並在工作日上午 9：00 開始時執行大量作業。 此資訊也可用來協助設定以時間為基礎的自動調整。 例如，如果操作員觀察到大量的使用者會在一天的特定時間定期登入，操作員可以安排啟動額外的驗證服務來處理工作量，然後在尖峰通過時關閉這些額外的服務。

數據源、檢測和數據收集需求

安全性是大部分分散式系統的完整層面。 相關數據可能會在整個系統中產生於多個點。 您應該考慮採用安全性資訊和事件管理（SIEM）方法來收集應用程式、網路設備、伺服器、防火牆、防病毒軟體和其他入侵預防元素所引發事件所產生的安全性相關信息。

安全性監視可以納入不屬於您應用程式之工具的數據。 這些工具可以包含公用程式，這些公用程式可識別外部機構所執行的埠掃描活動，或偵測嘗試取得應用程式與數據未驗證存取權的網路篩選器。

在所有情況下，收集的數據都必須讓系統管理員判斷任何攻擊的性質，並採取適當的對策。

分析安全性數據

安全性監視的一項功能是數據從中出現的各種來源。 不同的格式和詳細數據層級通常需要對所擷取的數據進行複雜的分析，才能將其系結至一致的信息線程。 除了最簡單的情況（例如偵測大量失敗的登入，或重複嘗試取得未經授權存取重要資源的嘗試），可能無法執行任何複雜的安全性數據自動化處理。 相反地，最好將此數據以時間戳寫入，但以原始形式寫入安全存放庫，以允許專家手動分析。

SLA 監視

支援付費客戶的許多商業系統都會以 SLA 的形式保證系統的效能。 基本上，SLA 指出系統可以在已同意的時間範圍內處理已定義的工作量，而不會遺失重要資訊。 SLA 監視與確保系統能夠符合可測量的 SLA 有關。

SLA 通常以下欄項目定義：

• 整體系統可用性。 例如，組織可能會保證系統在99.9%的時間內可供使用。 這相當於每年的停機時間不超過 9 小時，或大約每周 10 分鐘。
• 作業輸送量。 這個層面通常以一或多個高水標記表示，例如保證系統最多可支援 100,000 個並行使用者要求，或處理 10,000 個並行商務交易。
• 作業回應時間。 系統也可能保證處理要求的速率。 例如，99% 的所有商務交易會在 2 秒內完成，且沒有任何單一交易需要超過 10 秒的時間。

SLA 監視的需求

在最高層級，操作員應該能夠一目了然地判斷系統是否符合已同意的 SLA。 如果不是，運算子應該能夠向下切入並檢查基礎因素，以判斷不合格效能的原因。

可以視覺方式描述的典型高階指標包括：

• 服務運行時間的百分比。
• 應用程式輸送量（以每秒成功交易或作業來測量）。
• 成功/失敗的應用程式要求數目。
• 應用程式和系統錯誤、例外狀況和警告的數目。

所有這些指標都應該能夠依指定的時間週期進行篩選。

雲端應用程式可能會組成一些子系統和元件。 運算子應該能夠選取高階指標，並查看其如何從基礎元素的健康情況組成。 例如，如果整體系統的運行時間低於可接受的值，運算符應該能夠放大並判斷哪些元素造成此失敗。

基於警示目的，如果任何高階指標超過指定的臨界值，系統應該能夠引發事件。 組成高階指標之各種因素的較低層級詳細數據應該可作為警示系統的內容數據。

數據源、檢測和數據收集需求

支援 SLA 監視所需的原始資料類似於效能監視所需的原始數據，以及健康情況和可用性監視的某些層面。 （如需詳細資訊，請參閱這些章節。您可以透過下列方式擷取此資料：

• 執行端點監視。
• 記錄例外狀況、錯誤和警告。
• 追蹤使用者要求的執行。
• 監視系統使用之任何第三方服務的可用性。
• 使用效能計量和計數器。

所有數據都必須計時和時間戳。

分析 SLA 數據

檢測數據必須匯總，才能產生系統整體效能的圖片。 匯總的數據也必須支援向下切入，才能檢查基礎子系統的效能。 例如，您應該能夠：

• 計算指定期間的使用者要求總數，並判斷這些要求的成功率和失敗率。
• 結合使用者要求的回應時間，以產生系統回應時間的整體檢視。
• 分析使用者要求進度，將要求的整體回應時間細分為該要求中個別工作專案的回應時間。
• 將系統的整體可用性判斷為任何特定期間運行時間的百分比。
• 分析系統中個別元件和服務的時間百分比可用性。 這可能涉及剖析第三方服務所產生的記錄。

許多商業系統都必須針對已同意的 SLA 報告實際效能數據，一般為一個月。 如果 SLA 在該期間未符合，此資訊可用來計算客戶的點數或其他形式的還款。 您可以使用分析可用性數據一節中所述的技術來計算服務的可用性。

針對內部用途，組織可能也會追蹤導致服務失敗的事件數目和本質。 瞭解如何快速解決這些問題，或完全消除這些問題，將有助於減少停機時間並符合 SLA。

稽核

根據應用程式的性質，可能會有法定或其他法律法規，以指定稽核使用者作業和記錄所有數據存取的需求。 稽核可以提供將客戶連結到特定要求的證據。 不可否認性是許多電子商務系統中的一個重要因素，可協助維護客戶與負責應用程式或服務的組織之間的信任。

稽核的需求

分析師必須能夠追蹤使用者正在執行的商務作業順序，以便重新建構用戶的動作。 這可能是必要的，只是記錄問題，或作為法醫調查的一部分。

稽核資訊高度敏感。 它可能會包含可識別系統用戶的數據，以及他們正在執行的工作。 因此，稽核資訊很可能採用僅供信任分析師使用的報告形式，而不是支援圖形化作業向下切入的互動式系統。 分析師應該能夠產生一系列報告。 例如，報表可能會列出指定時間範圍內發生的所有用戶活動、詳細說明單一使用者的活動時間順序，或列出針對一或多個資源執行的作業順序。

數據源、檢測和數據收集需求

稽核的主要資訊來源可能包括：

• 管理使用者驗證的安全性系統。
• 記錄使用者活動的追蹤記錄。
• 追蹤所有可識別和無法識別網路要求的安全性記錄。

稽核數據的格式及其儲存方式可能是由法規需求所驅動。 例如，可能無法以任何方式清除數據。 （必須以原始格式錄製。必須保護保存存放庫的存取權，以防止竄改。

分析稽核數據

分析師必須能夠以原始形式完整存取原始數據。 除了產生一般稽核報告的需求之外，分析此數據的工具可能會特製化，並保留在系統外部。

使用量監視

使用量監視會追蹤如何使用應用程式的功能和元件。 操作員可以使用收集的數據來：

• 判斷哪些功能大量使用，並判斷系統中任何潛在的熱點。 高流量元素可能受益於功能分割，甚至復寫，以更平均地分散負載。 操作員也可以使用這項資訊來確認哪些功能不常使用，而且可能是未來版本的系統淘汰或取代候選專案。

• 取得正常使用中系統作業事件的相關信息。 例如，在電子商務網站中，您可以記錄交易數目和負責交易數量的統計數據。 此資訊可用於容量規劃，因為客戶數量增加。

• 偵測（可能間接）使用者對系統的效能或功能感到滿意。 例如，如果電子商務系統中的大量客戶定期放棄購物車，這可能是因為結帳功能有問題。

• 產生帳單資訊。 商業應用程式或多租用戶服務可能會為客戶收取其使用的資源費用。

• 強制執行配額。 如果多租用戶系統中的用戶超過其指定期間處理時間或資源使用量的付費配額，其存取可能會受到限制，也可以進行節流處理。

使用量監視的需求

若要檢查系統使用量，操作員通常需要查看包括：

• 每個子系統所處理的要求數目，並導向至每個資源。
• 每個使用者正在執行的工作。
• 每個使用者佔用的數據記憶體磁碟區。
• 每個使用者正在存取的資源。

運算子也應該能夠產生圖形。 例如，圖表可能會顯示最耗用資源的使用者，或最常存取的資源或系統功能。

數據源、檢測和數據收集需求

使用量追蹤可以在相對較高的層級執行。 它可以記下每個要求的開始和結束時間，以及要求的性質（讀取、寫入等等，視有問題的資源而定）。 您可以透過下列方式取得此資訊：

• 追蹤用戶活動。
• 擷取測量每個資源使用率的性能計數器。
• 監視每個用戶的資源耗用量。

基於計量目的，您也必須能夠識別哪些使用者負責執行哪些作業，以及這些作業所使用的資源。 收集的信息應該足夠詳細，以啟用精確的計費。

問題追蹤

如果系統中發生非預期的事件或行為，客戶和其他使用者可能會回報問題。 問題追蹤涉及管理這些問題、將問題與解決系統中任何根本問題的努力產生關聯，以及通知客戶可能的解決方案。

問題追蹤的需求

操作員通常會使用個別的系統來執行問題追蹤，以便記錄和報告用戶回報的問題詳細數據。 這些詳細數據可能包括使用者嘗試執行的工作、問題的徵兆、事件順序，以及發出的任何錯誤或警告訊息。

數據源、檢測和數據收集需求

問題追蹤數據的初始數據源是第一個回報問題的使用者。 使用者可能可以提供其他數據，例如：

• 損毀傾印（如果應用程式包含在使用者桌面上執行的元件）。
• 螢幕快照集。
• 發生錯誤的日期和時間，以及任何其他環境資訊，例如使用者的位置。

此資訊可用來協助偵錯工作，並協助建構軟體未來版本的待辦專案。

分析問題追蹤數據

不同的使用者可能會回報相同的問題。 問題追蹤系統應該將一般報告產生關聯。

針對每個問題報告，應該記錄偵錯工作的進度。 解決問題時，客戶可以得知解決方案。

如果使用者回報問題追蹤系統中有已知解決方案的問題，操作員應該能夠立即通知用戶解決方案。

追蹤作業和偵錯軟體版本

當使用者回報問題時，使用者通常只會知道它對其作業的立即影響。 使用者只能向負責維護系統的操作員回報自己的體驗結果。 這些體驗通常只是一或多個基本問題的可見徵兆。 在許多情況下，分析師必須深入探討基礎作業的時序，以找出問題的根本原因。 此程序稱為 根本原因分析。

追蹤和偵錯的需求

對於追蹤非預期事件和其他問題，監視數據必須提供足夠的資訊，讓分析師能夠追蹤這些問題的來源，並重新建構所發生的事件序列。 此信息必須足以讓分析師診斷任何問題的根本原因。 開發人員接著可以進行必要的修改，以防止它們重複執行。

數據源、檢測和數據收集需求

疑難解答可能包括追蹤在作業中叫用的所有方法（及其參數），以在客戶提出特定要求時，建置描述系統邏輯流程的樹狀結構。 必須擷取和記錄此流程所產生的例外狀況和警告。

為了支援偵錯，系統可以提供勾點，讓操作員能夠在系統中的關鍵點擷取狀態資訊。 或者，系統可以在選取的作業進度時提供詳細的逐步資訊。 在這個詳細層級擷取數據可能會對系統施加額外的負載，而且應該是暫時程式。 操作員會使用此程式，主要是當發生非常不尋常的一系列事件且難以複寫時，或當一或多個元素的新版本進入系統時，需要仔細監視，以確保元素如預期般運作。

監視和診斷管線

監視大規模分散式系統會帶來重大挑戰。 上一節所述的每一個案例都不應隔離考慮。 雖然可能需要以不同方式處理和呈現此數據，但監視和診斷數據在監視和診斷數據中可能會有很大的重疊。 基於這些原因，您應該全面檢視監視和診斷。

您可以將整個監視和診斷程式設想為包含圖 1 所示階段的管線。

圖 1 - 監視和診斷管線中的階段。

圖 1 強調監視和診斷的數據如何來自各種數據源。 檢測和收集階段涉及識別需要擷取數據的來源、判斷要擷取的數據、擷取數據的方式，以及如何格式化此數據，以便輕鬆檢查。 分析/診斷階段會採用原始數據，並用它來產生有意義的資訊，讓操作員可用來判斷系統的狀態。 操作員可以使用這項資訊來決定可能採取的動作，然後將結果送回檢測和收集階段。 視覺效果/警示階段階段呈現系統狀態的消費性檢視。 它可以使用一系列儀錶板，以近乎即時的方式顯示資訊。 而且它可以產生報表、圖表和圖表，以提供數據的歷史檢視，以協助識別長期趨勢。 如果資訊指出 KPI 可能超過可接受的界限，此階段也可以觸發操作員的警示。 在某些情況下，警示也可以用來觸發自動化程式，以嘗試採取更正動作，例如自動調整。

請注意，這些步驟構成連續流程程式，其中階段會平行進行。 在理想情況下，所有階段都應該動態設定。 在某些時候，特別是當系統已新部署或遇到問題時，可能需要更頻繁地收集擴充數據。 在其他時候，應該可以還原為擷取基本層級的基本資訊，以確認系統正常運作。

此外，整個監視程式應該視為即時持續的解決方案，因為意見反應會受到微調和改進。 例如，您可能從測量許多因素開始，以判斷系統健康情況。 一段時間的分析可能會導致精簡，因為您捨棄了不相關的量值，讓您更精確地專注於所需的數據，同時將背景雜訊降到最低。

監視和診斷數據的來源

監視程式使用的資訊可能來自數個來源，如圖 1 所示。 在應用層級，資訊來自系統程式代碼中併入的追蹤記錄。 開發人員應遵循標準方法來追蹤其程式代碼的控制流程。 例如，方法的專案可以發出追蹤訊息，指定方法的名稱、目前時間、每個參數的值，以及任何其他相關信息。 記錄進入和結束時間也可以證明很有用。

您應該記錄所有例外狀況和警告，並確定您保留任何巢狀例外狀況和警告的完整追蹤。 在理想情況下，您也應該擷取資訊來識別執行程式碼的使用者，以及活動相互關聯資訊（在要求通過系統時追蹤要求）。 而且您應該記錄嘗試存取所有資源，例如消息佇列、資料庫、檔案和其他相依服務。 這項資訊可用於計量和稽核目的。

許多應用程式會使用連結庫和架構來執行一般工作，例如存取資料存放區或透過網路通訊。 這些架構可設定為提供自己的追蹤訊息和原始診斷資訊，例如交易速率和數據傳輸成功和失敗。

執行應用程式的作業系統可以是低階系統資訊的來源，例如指出 I/O 速率、記憶體使用率和 CPU 使用量的性能計數器。 也可能報告操作系統錯誤（例如無法正確開啟檔案）。

您也應該考慮系統執行所在的基礎結構和元件。 虛擬機、虛擬網路和記憶體服務都可以是重要基礎結構層級性能計數器和其他診斷數據的來源。

如果您的應用程式使用其他外部服務，例如 Web 伺服器或資料庫管理系統，這些服務可能會發布自己的追蹤資訊、記錄和性能計數器。 範例包括針對 SQL Server 資料庫執行的追蹤作業的 SQL Server 動態管理檢視，以及用於記錄對網頁伺服器提出要求的 IIS 追蹤記錄。

隨著系統元件的修改和新版本的部署，請務必將問題、事件和計量屬性設為每個版本。 此資訊應該系結回發行管線，以便快速追蹤特定版本的元件問題並加以修正。

系統的任何時間點都可能發生安全性問題。 例如，使用者可能會嘗試使用無效的使用者標識碼或密碼登入。 已驗證的使用者可能會嘗試取得未經授權的資源存取權。 或者，使用者可能會提供無效或過時的密鑰來存取加密的資訊。 成功和失敗要求的安全性相關信息應該一律記錄。

檢測應用程式一節包含您應該擷取之資訊的更多指引。 但您可以使用各種策略來收集這項資訊：

• 應用程式/系統監視。 此策略會在應用程式、應用程式架構、操作系統和基礎結構內使用內部來源。 應用程式程式代碼可以在用戶端要求生命週期期間於值得注意的點產生自己的監視數據。 應用程式可以包含可選擇性啟用或停用的追蹤語句，視情況而定。 您也可以使用診斷架構動態插入診斷。 這些架構通常會提供外掛程式，這些外掛程式可以附加至程式代碼中的各種檢測點，並在這些點擷取追蹤數據。

  此外，您的程式代碼或基礎結構可能會在關鍵點引發事件。 設定為接聽這些事件的監視代理程式可以記錄事件資訊。

• 真正的用戶監視。 此方法會記錄使用者與應用程式之間的互動，並觀察每個要求和回應的流程。 這項資訊可以有兩倍的用途：它可用於每個使用者的計量使用量，並可用來判斷使用者是否收到適當的服務品質（例如，快速響應時間、低延遲和最少的錯誤）。 您可以使用擷取的數據來識別最常發生失敗的問題區域。 您也可以使用數據來識別系統因應用程式熱點或其他形式瓶頸而變慢的元素。 如果您仔細實作此方法，則可能可以重新建構使用者的流程，以便進行偵錯和測試。

  重要

  您應該考慮監視真實使用者所擷取的數據高度敏感，因為它可能包含機密數據。 如果您儲存擷取的數據，請安全地儲存它。 如果您想要使用數據進行效能監視或偵錯，請先去除所有個人資料。

• 綜合用戶監視。 在此方法中，您會撰寫自己的測試用戶端來模擬使用者，並執行可設定但典型的一系列作業。 您可以追蹤測試用戶端的效能，以協助判斷系統的狀態。 您也可以使用測試用戶端的多個實例作為負載測試作業的一部分，以建立系統在壓力下回應的方式，以及在這些條件下產生的監視輸出類型。

  注意

  您可以藉由包含追蹤和時間執行方法呼叫的程式代碼，以及應用程式的其他重要部分，來實作真實和綜合的用戶監視。

• 分析。 此方法主要以監視和改善應用程式效能為目標。 與其在實際和綜合用戶監視的功能層級運作，而是在應用程式執行時擷取較低層級的資訊。 您可以使用應用程式的執行狀態定期取樣來實作分析（判斷應用程式在指定時間點執行的程式代碼段）。 您也可以使用檢測，將探查插入程式代碼的重要階段（例如方法呼叫的開始和結尾），以及記錄叫用方法的時間、時間，以及每個呼叫所花費的時間長度。 然後，您可以分析此數據，以判斷應用程式哪些部分可能會導致效能問題。

• 端點監視。 這項技術會使用應用程式特別公開的一或多個診斷端點來啟用監視。 端點提供應用程式程式代碼的路徑，並可傳回系統健康情況的相關信息。 不同的端點可以專注於功能的各個層面。 您可以撰寫自己的診斷用戶端，以將定期要求傳送至這些端點，並同化回應。 如需詳細資訊，請參閱 健全狀況端點監視模式。

若要達到最大涵蓋範圍，您應該使用這些技術的組合。

檢測應用程式

檢測是監視程式的重要部分。 只有在您第一次擷取可讓您進行這些決策的數據時，才能對系統的效能和健康情況做出有意義的決策。 您使用檢測收集的信息應該足以讓您評估效能、診斷問題及做出決策，而不需要您登入遠端生產伺服器以手動執行追蹤（和偵錯）。 檢測數據通常包含寫入追蹤記錄的計量和資訊。

如果應用程式使用 Windows 事件追蹤，追蹤記錄檔的內容可能是應用程式所寫入的文字數據的結果，或是建立為追蹤事件結果所建立的二進位數據的結果。 它們也可以從系統記錄產生，記錄基礎結構部分所產生的事件，例如網頁伺服器。 文字記錄訊息通常設計成人類可讀取，但也應該以格式撰寫，讓自動化系統輕鬆地剖析它們。

您也應該將記錄分類。 請勿將所有追蹤數據寫入單一記錄，但使用個別記錄來記錄來自系統不同作業層面的追蹤輸出。 然後，您可以從適當的記錄檔讀取來快速篩選記錄訊息，而不必處理單一冗長的檔案。 永遠不要將具有不同安全性需求的資訊（例如稽核資訊和偵錯數據）寫入相同的記錄檔。

計量通常在特定時間是系統中某些層面或資源的量值或計數，其中包含一或多個相關聯的標籤或維度（有時稱為 範例）。 計量的單一實例通常不適用於隔離。 相反地，必須隨著時間擷取計量。 要考慮的重點是您應該記錄哪些計量，以及頻率。 針對計量產生數據的頻率太高，可能會對系統造成顯著的額外負載，而擷取計量不常可能會導致您錯過導致重大事件的情況。 考慮會因計量而異。 例如，伺服器上的CPU使用率可能會從秒到秒有顯著差異，但高使用率只會在幾分鐘內長期存在時才會變成問題。

相互關聯數據的資訊

您可以輕鬆地監視個別的系統層級性能計數器、擷取資源的計量，以及從各種記錄檔取得應用程式追蹤資訊。 但某些形式的監視需要監視管線中的分析和診斷階段，以將從數個來源擷取的數據相互關聯。 此數據可能會在原始數據中採用數種形式，而且分析程式必須提供足夠的檢測數據，才能對應這些不同的窗體。 例如，在應用程式架構層級，工作可能會由線程標識碼來識別。 在應用程式中，相同的工作可能會與執行該工作的使用者的使用者標識符相關聯。

此外，線程與使用者要求之間不太可能有 1：1 對應，因為異步操作可能會重複使用相同的線程來代表多個使用者執行作業。 為了進一步使問題複雜化，單一要求可能會由多個線程處理，因為執行會流經系統。 可能的話，請將每個要求與透過系統傳播為要求內容一部分的唯一活動標識符產生關聯。 （在追蹤資訊中產生和包含活動標識符的技術取決於用來擷取追蹤數據的技術。

所有監視數據都應該以相同的方式進行時間戳。 為了保持一致性，請使用國際標準時間記錄所有日期和時間。 這可協助您更輕鬆地追蹤事件序列。

要包含在檢測數據中的資訊

當您決定需要收集的檢測數據時，請考慮下列幾點：

• 請確定追蹤事件所擷取的資訊是機器和人類可讀取的。 針對這項資訊採用定義完善的架構，以利跨系統自動處理記錄數據，併為讀取記錄的作業和工程人員提供一致性。 包含環境資訊，例如部署環境、進程執行所在的機器、進程的詳細數據，以及呼叫堆疊。

• 只有在需要時才啟用分析，因為它可能會對系統造成重大額外負荷。 每次發生事件時，使用檢測來分析會記錄事件（例如方法呼叫），而取樣只會記錄選取的事件。 選取範圍可以是以時間為基礎的 （每 n 秒一次），或以頻率為基礎的 （每 n 個要求一次）。 如果事件經常發生，檢測分析可能會導致負擔過多，而且本身會影響整體效能。 在此情況下，取樣方法可能比較好。 不過，如果事件的頻率很低，取樣可能會遺漏它們。 在此情況下，檢測可能是較佳的方法。

• 提供足夠的內容，讓開發人員或系統管理員能夠判斷每個要求的來源。 這可能包含某種形式的活動標識碼，可識別要求的特定實例。 它也可能包含可用來將此活動與所執行計算工作和所使用的資源相互關聯的資訊。 請注意，這項工作可能會跨越進程和機器界限。 針對計量，內容也應該包含（直接或間接透過其他相互關聯的信息）參考導致提出要求的客戶。 此內容提供有關擷取監視數據時應用程式狀態的寶貴資訊。

• 記錄所有要求，以及發出這些要求的位置或區域。 這項資訊可協助判斷是否有任何特定位置的熱點。 這項資訊也有助於判斷是否要重新分割應用程式或其使用的資料。

• 仔細記錄並擷取例外狀況的詳細數據。 嚴重偵錯資訊通常會因為例外狀況處理不佳而遺失。 擷取應用程式擲回之例外狀況的完整詳細數據，包括任何內部例外狀況和其他內容資訊。 可能的話，請包含呼叫堆疊。

• 在應用程式的不同元素所擷取的數據中保持一致，因為這可協助分析事件，並將其與使用者要求相互關聯。 請考慮使用完整且可設定的記錄套件來收集資訊，而不是視開發人員採用與實作系統不同部分相同的方法。 從關鍵性能計數器收集數據，例如所執行的 I/O 數量、網路使用率、要求數目、記憶體使用量和 CPU 使用率。 某些基礎結構服務可能會提供自己的特定性能計數器，例如資料庫的連線數目、執行交易的速率，以及成功或失敗的交易數目。 應用程式也可能定義自己的特定性能計數器。

• 記錄對外部服務所做的所有呼叫，例如資料庫系統、Web 服務或其他屬於基礎結構的系統層級服務。 記錄執行每個呼叫所花費時間以及呼叫成功或失敗的相關信息。 可能的話，擷取所有發生暫時性錯誤之重試嘗試和失敗的相關信息。

確保與遙測系統的相容性

在許多情況下，檢測產生的資訊會產生成一系列事件，並傳遞至個別的遙測系統進行處理和分析。 遙測系統通常與任何特定應用程式或技術無關，但預期資訊會遵循架構通常定義的特定格式。 架構有效地指定合約，定義遙測系統可以內嵌的數據欄位和類型。 架構應該一般化，以允許從各種平臺和裝置抵達的數據。

通用架構應包含所有檢測事件通用的欄位，例如事件名稱、事件時間、發件者的IP位址，以及與其他事件相互關聯所需的詳細數據（例如使用者標識碼、裝置標識碼和應用程式識別符）。 請記住，任何數目的裝置可能會引發事件，因此架構不應相依於裝置類型。 此外，各種裝置可能會引發相同應用程式的事件;應用程式可能支援漫遊或某種形式的跨裝置散發。

架構也可能包含與不同應用程式通用之特定案例相關的網域欄位。 這可能是例外狀況、應用程式啟動和結束事件，以及 Web 服務 API 呼叫成功或失敗的相關信息。 所有使用相同網域欄位的應用程式都應該發出相同的事件集，以便建置一組常見的報告和分析。

最後，架構可能包含自定義欄位，以擷取應用程式特定事件的詳細數據。

檢測應用程式的最佳做法

下列清單摘要說明檢測在雲端中執行的分散式應用程式的最佳作法。

• 讓記錄易於讀取且易於剖析。 盡可能使用結構化記錄。 在記錄訊息中簡潔且描述性。

• 在所有記錄中，識別來源，並在寫入每個記錄檔記錄時提供內容和計時資訊。

• 針對所有時間戳使用相同的時區和格式。 這有助於將跨不同地理區域中執行之硬體和服務之作業的事件相互關聯。

• 將記錄分類，並將訊息寫入適當的記錄檔。

• 請勿揭露有關系統的敏感性資訊或用戶的個人資訊。 在記錄此資訊之前清除此資訊，但請確定會保留相關的詳細數據。 例如，從任何資料庫移除標識符和密碼 連接字串，但將其餘資訊寫入記錄檔，讓分析師可以判斷系統正在存取正確的資料庫。 記錄所有重大例外狀況，但可讓系統管理員開啟和關閉較低層級的例外狀況和警告。 此外，擷取並記錄所有重試邏輯資訊。 這項數據有助於監視系統的暫時性健康情況。

• 追蹤行程呼叫，例如對外部 Web 服務或資料庫的要求。

• 請勿將記錄訊息與相同記錄檔中不同的安全性需求混合在一起。 例如，請勿將偵錯和稽核資訊寫入相同的記錄檔。

• 除了稽核事件之外，請確定所有記錄呼叫都是不會封鎖商務作業進度的引發和忘記作業。 稽核事件很例外，因為它們對業務至關重要，而且可分類為商務營運的基本部分。

• 請確定記錄是可延伸的，而且對具體目標沒有任何直接相依性。 例如，與其使用 System.Diagnostics.Trace 撰寫資訊，而是定義公開記錄方法的抽象介面（例如 ILogger），並可透過任何適當方式實作。

• 請確定所有記錄都安全無虞，且絕不會觸發任何串聯錯誤。 記錄不得擲回任何例外狀況。

• 將檢測視為持續反覆的程式，並定期檢閱記錄，而不只是發生問題時。

收集和儲存數據

監視程式的收集階段涉及擷取檢測所產生的資訊、格式化此數據，讓分析/診斷階段更容易取用，以及將轉換的數據儲存在可靠的記憶體中。 您從分散式系統的不同部分收集的檢測數據可以保留在各種位置，且格式不同。 例如，您的應用程式程式代碼可能會產生追蹤記錄檔並產生應用程式事件記錄檔數據，而監視應用程式使用之基礎結構重要層面的性能計數器可以透過其他技術擷取。 應用程式使用的任何第三方元件和服務，都可能會使用個別的追蹤檔案、Blob 記憶體，甚至是自定義數據存放區，以不同格式提供檢測資訊。

數據收集通常是透過可從產生檢測數據的應用程式自主執行的收集服務來執行。 圖 2 說明此架構的範例，其中強調檢測數據收集子系統。

圖 2 - 收集檢測數據。

請注意，這是簡化的檢視。 收集服務不一定是單一進程，而且可能包含在不同計算機上執行的許多組成元件，如下列各節所述。 此外，如果某些遙測數據的分析必須快速執行（熱分析，如本檔稍後支持經常性、暖和冷分析一節所述），在收集服務外部運作的本機組件可能會立即執行分析工作。 圖 2 描述所選事件的這種情況。 分析處理之後，結果可以直接傳送至視覺效果和警示子系統。 在等候處理時，會保留在記憶體中受到暖或冷分析的數據。

針對 Azure 應用程式和服務，Azure 診斷 提供一個可能的解決方案來擷取數據。 Azure 診斷 從每個計算節點的下列來源收集數據、匯總數據，然後將它上傳至 Azure 儲存體：

• IIS 記錄
• IIS 失敗要求記錄檔
• Windows 事件記錄
• 效能計數器
• 損毀傾印
• Azure 診斷基礎結構記錄
• 自訂錯誤記錄檔
• .NET EventSource
• 以資訊清單為基礎的 ETW

如需詳細資訊，請參閱 Azure：遙測基本概念和疑難解答一文。

收集檢測數據的策略

考慮雲端的彈性本質，並避免從系統中每個節點手動擷取遙測數據的必要性，您應該安排將數據傳輸到中央位置並合併。 在跨越多個數據中心的系統中，先依區域收集、合併及儲存數據，然後將區域數據匯總成單一中央系統可能很有用。

若要將頻寬的使用優化，您可以選擇以批次方式以區塊傳送較不緊急的數據。 不過，數據不得無限期延遲，特別是如果數據包含時間敏感性資訊。

提取和推送檢測數據

檢測數據收集子系統可以主動從應用程式每個實例的各種記錄和其他來源擷取檢測數據（ 提取模型）。 或者，它可以作為被動接收者，等候數據從構成應用程式每個實例的元件傳送（ 推送模型）。

實作提取模型的方法之一，就是使用本機與應用程式每個實例一起執行的監視代理程式。 監視代理程式是個別的程式，它會定期擷取本機節點所收集的遙測數據，並將此資訊直接寫入應用程式共用的所有實例的集中式記憶體。 這是 Azure 診斷 實作的機制。 您可以設定 Azure Web 或背景工作角色的每個實例，以擷取儲存在本機的診斷和其他追蹤資訊。 與每個實例一起執行的監視代理程式會將指定的數據複製到 Azure 儲存體。 在 Azure 雲端服務 和 虛擬機器 中啟用診斷一文提供此程式的詳細數據。 某些元素，例如 IIS 記錄、損毀傾印和自定義錯誤記錄，會寫入 Blob 記憶體。 Windows 事件記錄檔、ETW 事件和性能計數器的數據會記錄在數據表記憶體中。 圖 3 說明此機制。

圖 3 - 使用監視代理程式提取資訊和寫入共用記憶體。

使用剛才描述的方法來儲存在單一位置有限節點上執行的小型應用程式遙測數據是可行的。 不過，複雜、可高度擴充的全域雲端應用程式可能會從數百個 Web 角色和背景工作角色、資料庫分區和其他服務產生大量數據。 此數據泛濫很容易使單一中央位置可用的 I/O 頻寬不堪重負。 因此，您的遙測解決方案必須可調整，以防止其作為系統擴充的瓶頸。 在理想情況下，如果您的解決方案應該納入一定程度的備援，以降低在系統失敗時遺失重要監視資訊（例如稽核或計費數據）的風險。

若要解決這些問題，您可以實作佇列，如圖 4 所示。 在此架構中，本機監視代理程式（如果可以適當地設定）或自定義數據收集服務（如果沒有）會將數據張貼至佇列。 以異步方式執行的另一個進程（圖 4 中的記憶體寫入服務）會採用此佇列中的數據，並將它寫入至共用記憶體。 消息佇列適用於此案例，因為它提供「至少一次」語意，協助確保佇列數據在張貼後不會遺失。 您可以使用個別的背景工作角色來實作記憶體寫入服務。

圖 4 - 使用佇列來緩衝檢測數據。

本機數據收集服務可以在收到數據后立即將數據新增至佇列。 佇列可作為緩衝區，記憶體寫入服務可以依自己的步調擷取和寫入數據。 根據預設，佇列會以先進先出的方式運作。 但是，如果訊息包含必須更快速地處理的數據，您可以排定訊息的優先順序，以透過佇列加速訊息。 如需詳細資訊，請參閱 優先順序佇列模式。 或者，您可以根據所需的分析處理形式，使用不同的通道（例如 服務匯流排 主題）將數據導向不同的目的地。

為了獲得延展性，您可以執行記憶體寫入服務的多個實例。 如果有大量的事件，您可以使用事件中樞將數據分派至不同的計算資源進行處理和儲存。

合併檢測數據

數據收集服務從應用程式單一實例擷取的檢測數據會提供該實例健康情況和效能的當地語系化檢視。 若要評估系統的整體健康情況，必須在本機檢視中合併數據的某些層面。 您可以在儲存資料之後執行此作業，但在某些情況下，您也可以在收集數據時達到此目的。 檢測數據可以透過結合數據並做為篩選和清除程式的個別數據匯總服務，而不是直接寫入至共用記憶體。 例如，包含相同相互關聯資訊的檢測數據，例如活動標識元可以合併。 （使用者可能會開始在一個節點上執行商務作業，然後在節點失敗時傳輸至另一個節點，或視負載平衡的設定方式而定。此程式也可以偵測並移除任何重複的數據（如果遙測服務使用消息佇列將檢測數據推送至記憶體，則一律有可能）。 圖 5 說明此結構的範例。

圖 5 - 使用個別服務來合併和清除檢測數據。

儲存檢測數據

先前的討論描繪了檢測數據儲存方式的簡單檢視。 事實上，使用最適合每種類型可能使用的技術來儲存不同類型的資訊是有意義的。

例如，Azure Blob 和數據表記憶體的存取方式有一些相似之處。 但是，它們具有您可以使用它們來執行的作業限制，而且其保存的數據粒度大不相同。 如果您需要對數據執行更多分析作業或需要全文搜索功能，可能更適合使用針對特定查詢和數據存取類型優化的功能的數據記憶體。 例如：

• 性能計數器數據可以儲存在 SQL 資料庫中，以啟用臨機操作分析。
• 追蹤記錄可能會更妥善地儲存在 Azure Cosmos DB 中。
• 安全性資訊可以寫入 HDFS。
• 需要全文搜索的資訊可以透過 Elasticsearch 儲存（也可以使用豐富的索引來加速搜尋）。

您可以實作其他服務，定期從共用記憶體、分割區中擷取數據，並根據數據用途篩選數據，然後將它寫入適當的數據集，如圖 6 所示。 另一種方法是將這項功能包含在合併和清除程式中，並將數據直接寫入這些存放區，因為擷取數據，而不是將它儲存在中繼共用儲存區域中。 每個方法都有其優點和缺點。 實作個別的數據分割服務可減少合併和清除服務的負載，並在必要時至少重新產生部分數據分割數據（視共用記憶體中保留的數據量而定）。 不過，它會取用其他資源。 此外，從每個應用程式實例接收檢測數據，以及將此數據轉換成可操作的信息之間，可能會有延遲。

圖 6 - 根據分析和記憶體需求分割數據。

針對多個用途，可能需要相同的檢測數據。 例如，性能計數器可用來提供一段時間的系統效能歷程記錄檢視。 此資訊可能會與其他使用量數據結合，以產生客戶帳單資訊。 在這些情況下，相同的數據可能會傳送到一個以上的目的地，例如可作為長期存放區來保存帳單資訊的檔資料庫，以及處理複雜效能分析的多維度存放區。

您也應該考慮需要數據有多緊急。 提供警示資訊的數據必須快速存取，因此應該保留在數據儲存空間中，並編製索引或結構化，以優化警示系統執行的查詢。 在某些情況下，遙測服務可能需要收集每個節點上的數據，以在本機格式化和儲存數據，以便警示系統的本機實例快速通知您任何問題。 相同的數據可以分派至先前圖表中顯示的記憶體寫入服務，並在其他用途也需要時集中儲存。

用於更考慮分析、報告和找出歷史趨勢的資訊較不緊急，而且可以以支持數據採礦和臨機操作查詢的方式儲存。 如需詳細資訊，請參閱本檔稍後支援熱、暖和冷分析一節。

記錄輪替和數據保留

檢測可能會產生大量的數據。 此數據可以保留在數個位置，從原始記錄檔、追蹤檔案和其他擷取到每個節點所擷取到共用記憶體中數據之合併、清除和分割檢視的信息開始。 在某些情況下，在處理和傳輸數據之後，可以從每個節點移除原始原始源數據。 在其他情況下，儲存原始資訊可能是必要的，或只是有用的。 例如，為了偵錯目的所產生的數據可能最好以原始形式提供，但在修正任何錯誤之後，就可以快速捨棄。

效能數據通常會有較長的壽命，以便用於找出效能趨勢和容量規劃。 此數據的合併檢視通常會在有限時間內保持在線，以便快速存取。 之後，即可進行封存或捨棄。 針對計量和計費客戶收集的數據可能需要無限期儲存。 此外，法規需求可能會規定針對稽核和安全性目的收集的資訊也需要封存並儲存。 此數據也是機密數據，可能需要加密或受到保護，以防止竄改。 您絕對不應該記錄用戶的密碼或其他可能用來認可身分識別詐騙的資訊。 在儲存數據之前，應該先從數據清除這類詳細數據。

向下取樣

儲存歷程記錄數據很有用，因此您可以找出長期趨勢。 與其完全儲存舊數據，不如將數據向下取樣，以降低其解析度並節省記憶體成本。 例如，您可以合併一個多月的數據，而不是逐分鐘儲存效能指標，以形成每小時檢視。

收集和儲存記錄資訊的最佳做法

下列清單摘要說明擷取和儲存記錄資訊的最佳做法：

• 監視代理程式或數據收集服務應該以跨進程服務的形式執行，而且應該很容易部署。

• 監視代理程式或數據收集服務的所有輸出都應該是與計算機、操作系統或網路通訊協定無關的無從驗證格式。 例如，以 JSON、MessagePack 或 Protobuf 等自我描述格式發出資訊，而不是 ETL/ETW。 使用標準格式可讓系統建構處理管線;以同意格式讀取、轉換和傳送數據的元件可以輕鬆地整合。

• 監視和數據收集程序必須安全無虞，且不得觸發任何串聯錯誤狀況。

• 如果傳送資訊至數據接收時發生暫時性失敗，監視代理程式或數據收集服務應該準備好重新排序遙測數據，以便先傳送最新的資訊。 （監視代理程式/數據收集服務可能會選擇卸除較舊的數據，或將其儲存在本機，稍後再傳輸以自行判斷。

分析數據和診斷問題

監視和診斷程式的重要部分是分析收集的數據，以取得系統整體福祉的圖片。 您應該已定義自己的 KPI 和效能計量，請務必瞭解如何建構已收集的數據，以符合分析需求。 也請務必瞭解在不同計量和記錄檔中擷取的數據如何相互關聯，因為這項資訊對於追蹤一系列事件並協助診斷所發生的問題來說可能是關鍵。

如合併檢測數據一節所述，系統每個部分的數據通常會在本機擷取，但通常必須與參與系統的其他月臺所產生的數據結合。 這項資訊需要仔細的相互關聯，以確保數據能正確結合。 例如，作業的使用方式數據可能會跨越裝載使用者所連線網站的節點、執行作為此作業一部分存取之個別服務的節點，以及保留在另一個節點上的數據記憶體。 此資訊必須系結在一起，才能提供作業資源的整體檢視和處理使用量。 某些前置處理和篩選數據可能會在擷取數據的節點上發生，而匯總和格式設定更有可能發生在中央節點上。

支援熱、暖和冷分析

分析及重新格式化視覺效果、報告和警示數據，可能是一個複雜的程式，會耗用自己的資源集。 某些形式的監視是時間關鍵，需要立即分析數據才能有效。 這稱為 經常性分析。 範例包括警示所需的分析，以及安全性監視的某些層面（例如偵測系統的攻擊）。 這些用途所需的數據必須快速可用並結構化，才能有效率地處理。 在某些情況下，可能需要將分析處理移至保留數據的個別節點。

其他形式的分析較不具時間關鍵性，而且在收到原始數據之後可能需要一些計算和匯總。 這稱為 暖分析。 效能分析通常屬於此類別。 在此情況下，隔離的單一效能事件不太可能具有統計意義。 （可能是突然尖峰或故障造成的。來自一系列事件的數據應該提供更可靠的系統效能畫面。

暖分析也可以用來協助診斷健康情況問題。 健康情況事件通常是透過經常性分析處理，而且可以立即引發警示。 運算子應該能夠藉由檢查暖路徑中的數據，來鑽研健康情況事件的原因。 此數據應該包含導致健康情況事件之問題前的事件相關信息。

某些類型的監視會產生更多的長期數據。 此分析可以在較晚的日期執行，可能根據預先定義的排程執行。 在某些情況下，分析可能需要對一段時間內擷取的大量數據執行複雜的篩選。 這稱為 冷分析。 關鍵需求是數據在擷取后安全地儲存。 例如，使用監視和稽核需要在一般時間點準確了解系統的狀態，但此狀態資訊不需要在收集系統之後立即進行處理。

操作員也可以使用冷分析來提供預測性健康情況分析的數據。 操作員可以在指定的期間內收集歷程記錄資訊，並將其與目前健康情況數據一起使用（從熱路徑擷取），以找出可能很快就會造成健康情況問題的趨勢。 在這些情況下，可能需要引發警示，才能採取更正動作。

使資料相互關聯

檢測擷取的數據可以提供系統狀態的快照集，但分析的目的是讓此數據可採取動作。 例如：

• 在系統層級在特定時間造成大量 I/O 載入的原因為何？
• 這是大量資料庫作業的結果嗎？
• 這是否反映在資料庫回應時間、每秒交易數，以及應用程式回應時間相同的時間？

若是如此，可能會降低負載的一個補救動作可能是將數據分區化到更多伺服器。 此外，由於系統的任何層級發生錯誤，可能會發生例外狀況。 某個層級中的例外狀況通常會觸發上述層級的另一個錯誤。

基於這些原因，您必須能夠讓每個層級的不同類型的監視數據相互關聯，以產生系統狀態及其上執行之應用程式的整體檢視。 然後，您可以使用這項資訊來決定系統是否正常運作，並判斷可以做些什麼來改善系統的品質。

如關聯數據的資訊一節所述，您必須確定原始檢測數據包含足夠的內容和活動標識符資訊，以支援必要的匯總來相互關聯事件。 此外，此數據可能採用不同的格式，而且可能需要剖析這項資訊，以將其轉換成標準化格式進行分析。

疑難排解和診斷問題

診斷需要能夠判斷錯誤或非預期行為的原因，包括執行根本原因分析。 所需的資訊通常包括：

• 事件記錄檔和追蹤的詳細資訊，不論是針對整個系統，還是在指定的時間範圍中指定子系統。
• 完成由系統或指定子系統在指定期間內發生之任何指定層級的例外狀況和錯誤所產生的堆疊追蹤。
• 系統內任何位置或指定子系統在指定時間範圍期間的任何失敗進程損毀傾印。
• 活動記錄，記錄所有使用者或在指定期間內針對所選使用者執行的作業。

基於疑難解答目的分析數據通常需要對系統架構和組成解決方案的各種元件有深入的技術瞭解。 因此，通常需要大量手動介入來解譯數據、建立問題的原因，並建議適當的策略來更正它們。 它可能很適合以原始格式儲存此資訊的複本，並讓專家進行冷分析。

將數據可視化並引發警示

任何監視系統的重要層面是能夠以操作員快速找出任何趨勢或問題的方式呈現數據。 此外，重要的是，如果發生可能需要注意的重大事件，快速通知操作員的能力。

數據呈現可以採用數種形式，包括使用儀錶板、警示和報表的視覺效果。

使用儀錶板的視覺效果

將數據可視化最常見的方法是使用儀錶板，將信息顯示為一系列圖表、圖表或其他圖例。 這些專案可以參數化，分析師應該能夠針對任何特定情況選取重要參數（例如時間週期）。

儀錶板可以階層式組織。 最上層儀錶板可以提供系統各個層面的整體檢視，但可讓操作員向下切入詳細數據。 例如，描述系統整體磁碟 I/O 的儀錶板應該允許分析師檢視每個個別磁碟的 I/O 速率，以確定一或多個特定裝置是否佔不成比例的流量。 在理想情況下，儀錶板也應該顯示相關信息，例如產生此 I/O 的每個要求來源（使用者或活動）。 接著，這項資訊可用來判斷是否（以及如何）將負載平均分散到裝置上，以及如果新增更多裝置，系統是否會執行得更好。

儀錶板也可以使用色彩編碼或其他視覺提示來指出出現異常或超出預期範圍的值。 使用上述範例：

• I/O 速率接近其最大容量的磁碟在較長期間（熱磁碟）可以以紅色醒目提示。
• 具有 I/O 速率的磁碟，可在短時間內以最大限制定期執行（暖磁碟）以黃色反白顯示。
• 顯示正常使用量的磁碟可以以綠色顯示。

請注意，若要讓儀錶板系統有效運作，它必須具有要使用的原始數據。 如果您要建置自己的儀錶板系統，或使用另一個組織開發的儀錶板，您必須瞭解需要收集哪些檢測數據、在哪些層級的數據粒度，以及如何格式化儀錶板來取用。

良好的儀錶板不只會顯示資訊，也可讓分析師對該資訊提出臨機操作問題。 某些系統提供管理工具，操作員可用來執行這些工作並探索基礎數據。 或者，視用來保存此資訊的存放庫而定，可能可以直接查詢此數據，或將其匯入Microsoft Excel 等工具，以便進一步分析和報告。

引發警示

警示是分析監視和檢測數據，並在偵測到重大事件時產生通知的程式。

警示可協助確保系統保持狀況良好、回應且安全。 這是任何讓效能、可用性和隱私權保證給可能需要立即處理數據之使用者之系統的重要部分。 操作員可能需要收到觸發警示之事件的通知。 警示也可以用來叫用系統函式，例如自動調整。

警示通常取決於下列檢測數據：

• 安全性事件。 如果事件記錄檔指出發生重複的驗證或授權失敗，系統可能會受到攻擊，而且應通知操作員。
• 效能計量。 如果特定效能計量超過指定的臨界值，系統必須快速回應。
• 可用性資訊。 如果偵測到錯誤，可能需要快速重新啟動一或多個子系統，或故障轉移至備份資源。 子系統中的重複錯誤可能表示更嚴重的問題。

操作員可能會使用許多傳遞通道來接收警示資訊，例如電子郵件、呼叫器裝置或簡訊簡訊。 警示也可能包含情況有多嚴重。 許多警示系統都支援訂閱者群組，而屬於相同群組成員的所有操作員都可以接收同一組警示。

警示系統應該可自定義，而且基礎檢測數據的適當值可作為參數提供。 此方法可讓運算子篩選數據，並將焦點放在感興趣的值臨界值或組合上。 請注意，在某些情況下，原始檢測數據可以提供給警示系統。 在其他情況下，可能更適合提供匯總的數據。 （例如，如果節點的CPU使用率在過去10分鐘內超過90%，則可以觸發警示。 提供給警示系統的詳細數據也應該包含任何適當的摘要和內容資訊。 此數據可協助降低誤判事件會前往警示的可能性。

報表

報告可用來產生系統的整體檢視。 除了目前的資訊之外，它可能會納入歷程記錄數據。 報告需求本身分為兩大類：作業報告和安全性報告。

工作報告通常包含下列層面：

• 匯總統計數據，讓您在指定的時間範圍中了解整體系統或指定子系統的資源使用率。
• 識別指定期間內整體系統或指定子系統的資源使用量趨勢。
• 監視在指定期間內在整個系統或指定子系統中發生的例外狀況。
• 在已部署的資源方面判斷應用程式的效率，並了解資源量（及其相關聯的成本）是否可以降低，而不會影響不必要的效能。

安全性報告與追蹤客戶的系統使用有關。 它可以包括：

• 稽核用戶作業。 這需要記錄每個使用者執行的個別要求，以及日期和時間。 數據應該結構化，讓系統管理員能夠快速重新建構使用者在特定期間內執行的作業順序。
• 追蹤使用者使用的資源。 這需要記錄使用者每個要求如何存取組成系統的各種資源，以及多久的時間。 系統管理員必須能夠使用此數據，以在指定的期間內由用戶產生使用率報告，可能是為了計費目的。

在許多情況下，批處理可以根據定義的排程產生報告。 （延遲通常不是問題。但是，如有需要，它們也應該以臨機操作的方式產生。 例如，如果您要將資料儲存在關係資料庫中，例如 Azure SQL 資料庫，您可以使用 SQL Server Reporting Services 之類的工具來擷取和格式化數據，並將其呈現為一組報表。

下一步

• Azure 監視器概觀
• 監視、診斷與疑難排解 Microsoft Azure 儲存體
• Microsoft Azure 中的警示概觀
• 使用 Azure 入口網站來檢視服務健康狀態通知
• 什麼是 Application Insights？
• Azure 虛擬機器的效能診斷
• 下載並安裝適用於 Visual Studio 的 SQL Server Data Tools (SSDT)

相關資源

• 自動調整指引 說明如何減少管理額外負荷，方法是減少操作員持續監視系統的效能，以及決定新增或移除資源。
• 健康情況端點監視模式 描述如何在應用程式內實作功能檢查，讓外部工具可以定期透過公開的端點存取。
• 優先順序佇列模式 示範如何排定佇列訊息的優先順序，以便接收緊急要求，並可在較不緊急的訊息之前進行處理。