監視和診斷指引

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

監視和診斷案例

您可以使用監視來深入瞭解系統運作的程度。 監視是維護服務品質目標的重要部分。 收集監視資料的常見案例包括：

• 確保系統維持良好狀況。
• 追蹤系統和其元件元素的可用性。
• 維護效能，以確保系統的輸送量不會在工作量增加時意外地降級。
• 保證系統符合客戶所建立的任何服務等級協定 (SLA)。
• 保護系統、使用者和其資料的隱私權和安全性。
• 追蹤因稽核或法規目的而執行的作業。
• 監視系統的日常使用情況，並找出若未處理，可能導致問題的趨勢。
• 追蹤發生的問題，從初始報告到分析可能原因、更正、後續軟體更新和部署。
• 追蹤作業和偵錯軟體版本。

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

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

健康狀況監視

如果系統正在執行，而且能夠處理要求，則狀況良好。 健康狀況監視的目的是產生目前系統健康狀況的快照，讓您能夠驗證系統的所有元件是否如預期般運作。

健康狀況監視的需求

如果系統的任何部分被視為健康狀況不良，應該快速 (在幾秒內) 警示操作員。 操作員應該能夠確定系統的哪些部分運作正常，以及哪些部分遭遇問題。 系統健康狀況可以透過號誌燈系統反白顯示︰

• 紅色代表狀況不良 (系統已停止)
• 黃色表示部分狀況良好 (系統是以精簡功能執行)
• 綠色代表完全健全

完整的健康狀況監視系統可讓操作員向下鑽研系統，來檢視子系統和元件的健康狀況狀態。 例如，如果整體系統被描述成健康狀況局部良好，操作員應該能夠放大，並且判斷哪些功能目前無法使用。

資料來源、檢測和資料收集需求

支援健康狀況監視所需的原始資料，可以由下列情況產生：

• 追蹤使用者要求的執行情況。 這項資訊可以用來判斷哪些要求已成功、哪些要求已失敗，以及每個要求花費多長時間。
• 綜合使用者監視。 此程序會模擬使用者所執行的步驟，並遵循預先定義的一連串步驟。 應該擷取每個步驟的結果。
• 記錄例外狀況、錯誤和警告。 可以擷取此資訊，做為內嵌於應用程式程式碼之追蹤陳述式的結果，以及從系統參考之任何服務的事件記錄中擷取資訊。
• 監視系統使用之任何協力廠商服務的健康狀況。 此監視可能需要擷取並剖析這些服務提供的健康狀況資料。 此資訊可能採取各種格式。
• 端點監視。 此機制會在＜可用性監視＞一節中詳細說明。
• 收集環境效能資訊，例如背景 CPU 使用率或 I/O (包括網路) 活動。

分析健康狀況資料

健康狀況監視的主要焦點在於快速指出系統是否正在執行。 如果偵測到重要元件的健康狀況不良，則即時資料的熱分析可以觸發警示 (它無法回應連續的一系列 Ping，例如.) 操作員接著可以採取適當的更正動作。

更進階的系統可能包含對最近和目前工作負載執行冷分析的預測元素。 冷分析可以找出趨勢，並判斷系統是否可能一直保持健康狀況良好，或者系統是否需要其他資源。 此預測元素應該以關鍵效能計量為依據，例如：

• 每個服務或子系統中引導的要求速率。
• 這些要求的回應時間。
• 流入和流出每個服務的資料量。

如果任何計量的值超過定義的臨界值，系統可引發警示，讓操作員或自動調整 (如果有的話) 能夠採取必要的預防動作，以維護系統健康狀況。 這些動作可能包括加入資源、重新啟動一或多個失敗服務，或套用節流至優先順序較低的要求。

可用性監視

真正健康狀況良好的系統需要以可用的元件和子系統組成系統。 可用性監視與健康狀況監視密切相關。 但是健康狀況監視提供系統目前健康狀況的即時檢視，而可用性監視涉及追蹤系統及其元件的可用性，以產生有關系統運作時間的統計資料。

在許多系統中，某些元件 (例如資料庫) 設定有內建備援，以允許發生嚴重錯誤或連線中斷時快速容錯移轉。 在理想情況下，使用者應該不會察覺發生這類失敗。 但從可用性監視的觀點來看，儘可能收集越多有關這類失敗的資訊來判斷原因，然後採取更正動作，以防止它們重複發生。

追蹤可用性所需的資料可能取決於一些低階因素。 這其中許多因素可能是應用程式、系統和環境特定的。 有效的監視系統會擷取對應至這些低階因素的可用性資料，然後將其彙總以提供系統的整體圖片。 例如，在電子商務系統中，可讓客戶下訂單的商務功能可能取決於儲存訂單詳細資料的儲存機制，以及為這些訂單處理貨幣交易的付款系統。 因此，系統下訂單部分的可用性是儲存機制和付款子系統的可用性功能。

可用性監視需求

操作員也應該能夠檢視每個系統和子系統的可用性歷程記錄，並使用此資訊來找出任何可能造成一或多個子系統定期失敗的趨勢(服務是否會在當天對應至尖峰處理時間的特定時間開始失敗？ )

監視解決方案應該提供每個子系統的可用性或無法使用的即時和歷程記錄檢視。 它也應該能夠在一或多個服務失敗或使用者無法連接至服務時快速警示操作員。 這不只會監視每個服務，也會在每位使用者執行的動作嘗試與服務通訊但卻失敗時檢查這些動作。 某種程度來說，有一些連接失敗是正常情況。 有可能是因為暫時性錯誤，但允許系統就特定時段發生的子系統失敗連接數目發出警示，可能會有幫助。

資料來源、檢測和資料收集需求

使用健康狀況監視時，支援可用性監視所需的原始資料，可由綜合使用者監控和記錄任何例外狀況、錯誤和警告產生。 此外，可用性資料也可以取自執行端點監視。 應用程式可以公開一個或多個健康的端點，每個測試皆存取至系統內的功能區域。 監視系統可以依照定義的排程 Ping 每個端點，並收集結果 (成功或失敗)。

必須記錄所有的逾時、網路連線失敗，以及連接重試次數。 所有資料應該加上時間戳記。

分析可用性資料

檢測資料必須加以彙總並相互關聯，以支援下列類型的分析：

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

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

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

這有助於 SLA 用途 (SLA 監視 會在本指南稍後詳細說明。) 停機時間 的定義取決於服務。 舉例來說，Visual Studio Team Services 建置服務將停機時間定義為建置服務無法使用的時間範圍 (總累積分鐘數)。 如果所要求對組建服務執行由客戶起始之作業的連續 HTTP 要求，在整整一分鐘內產生了錯誤代碼或未傳回回應，則視為該服務無法使用一分鐘。

效能監控

由於系統的壓力越來越大 (因為使用者數量增加)，這些使用者存取的資料集大小會成長，而且越可能發生一或多個元件失敗的情況。 通常，在元件失敗之前效能會先降低。 如果您能夠偵測這類降低，就可以採取主動步驟來修正這個狀況。

系統效能取決於許多因素。 每個因素通常是透過關鍵效能指標 (KPI) 來測量，例如，每秒的資料庫交易數，或在指定時間範圍內順利為其提供服務的網路要求數量。 這其中有一些 KPI 可做為特定的效能量值，而其他 KPI 則可衍生自計量的組合。

效能監視的需求

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

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

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

• 並行使用者數目與要求延遲時間的比較 (在使用者傳送要求之後開始處理要求所花費的時間長度)。
• 並行使用者數目與平均回應時間的比較 (在要求開始處理之後完成要求所花費的時間長度)。
• 要求數量與處理錯誤次數。

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

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

所有視覺效果應該允許操作員指定時段。 顯示的資料可能是目前狀況的快照及/或效能的歷程記錄檢視。

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

資料來源、檢測和資料收集需求

您可以藉由監視使用者要求抵達並通過系統的進度，來收集高階效能資料 (輸送量、並行使用者數目、商務交易數目、錯誤率等等)。 這牽涉到在應用程式程式碼的關鍵點中加入追蹤陳述式以及計時資訊。 應該擷取所有錯誤、例外狀況和警告，並有足夠的資料，以讓其與導致其發生的要求相互關聯。 Internet Information Services (IIS) 記錄是另一個有用的來源。

可能的話，您也應該對應用程式使用的任何外部系統擷取效能資料。 這些外部系統可能會提供自己的效能計數器，或其他用於要求效能資料的功能。 如果這不可行，請記錄如下的資訊：每個對外部系統提出之要求的開始時間和結束時間，以及作業的狀態 (成功、失敗或警告)。 例如，您可以使用馬錶方法為要求計時：在要求啟動時啟動計時器，然後在要求完成時停止計時器。

在系統中個別元件的低階效能資料可透過 Windows 效能計數器和 Azure 診斷之類的功能來取得。

分析效能資料

許多分析工作包含依使用者要求類型及/或每個要求傳送至的子系統或服務來彙總效能資料。 有一個使用者要求的範例是將項目加入購物車，或在電子商務系統中執行結帳程序。

另一個常見的需求為以選取的百分位數彙總效能資料。 例如，操作員可能會判斷 99% 的要求、95%的要求，以及 70% 的要求的回應時間。 可能有 SLA 目標或其他針對每個百分位數設定的目標。 進行中的結果應該以近乎即時的方式進行報告，以協助偵測立即問題。 基於統計用途，結果也應該進行長時間彙總。

如果延遲問題影響到效能，操作員應該能夠藉由檢查每個要求執行的每個步驟是否延遲，迅速識別瓶頸的原因。 因此，效能資料必須提供一種方式，讓每個步驟的效能量值相互關聯，以將其繫結至特定的要求。

根據視覺效果需求，可能有助於產生並儲存包含原始資料檢視的資料 Cube。 這個資料 Cube 可以允許對效能資訊進行複雜的特定查詢和分析。

安全性監控

包含機密資料的所有商務系統皆必須實作安全性結構。 安全性機制的複雜度通常是資料機密性的函數。 在需要使用者進行驗證的系統中，您應該記錄：

• 所有的登入嘗試，不論失敗或成功。
• 已驗證的使用者執行的所有作業，以及已驗證的使用者存取的所有資源。
• 當使用者結束工作階段並登出時。

監視應該能夠協助偵測系統上的攻擊。 例如，大量的失敗登入嘗試可能表示暴力密碼破解攻擊。 非預期的要求數目激增可能是分散式阻斷服務 (DDoS) 攻擊的結果。 您必須準備好監視所有資源的所有要求，而不論這些要求的來源為何。 具有登入弱點的系統可能不需要使用者實際登入，就意外地向外界公開資源。

安全性監視的需求

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

• 偵測未經驗證實體嘗試的入侵。
• 識別實體對無權存取資料執行作業的嘗試。
• 判斷系統或系統某些部分是否受到內外攻擊 (例如，惡意的已驗證使用者可能嘗試讓系統當機)。

若要支援這些需求，應該在發生下列情況時通知操作員：

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

提供給操作員的資訊應該包含每個要求來源的主機位址。 如果特定的位址範圍會定期發生安全性違規，這些主機可能遭到封鎖。

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

資料來源、檢測和資料收集需求

安全性是大多數分散式系統的全方位層面。 相關的資料很可能會在整個系統的多個點產生。 您應該考慮採用安全性資訊及事件管理 (SIEM) 方式來收集應用程式、網路設備、伺服器、防火牆、防毒軟體和其他入侵預防項目引發事件所產生的安全性相關資訊。

安全性監視可以納入來自不屬於您應用程式之工具的資料。 這些工具可包括識別外部機構所進行連接埠掃描活動的公用程式，或偵測嘗試對您的應用程式和資料取得未經驗證存取權的網路篩選器。

在所有情況下，收集的資料必須可讓系統管理員判斷任何攻擊的本質，並採取適當的應變措施。

分析安全性資料

安全性監視的功能是產生資料的各種來源。 不同格式和詳細程度通常需要對擷取的資訊進行複雜分析，以將其繫結成資訊的一致執行緒。 除了最簡單的情況外 (例如，偵測大量失敗登入或重複嘗試對重要資源取得未獲授權的存取)，其可能無法對安全性資料執行任何複雜的自動化處理。 反而可能偏好將此資料 (加上時間戳記，但另以其原始形式以外的形式表示) 寫入安全的儲存機制，讓專家能夠手動分析。

SAL 監視

許多支援付款客戶的商務系統保證系統的效能具有 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 使用率的效能計數器。 可能也會報告作業系統錯誤 (例如，無法正確開啟檔案)。

您也應該考慮執行您系統的基礎結構以及元件。 虛擬機器、虛擬網路和儲存體服務全都可以是重要基礎結構層級效能計數器和其他診斷資料的來源。

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

修改系統的元件並部署新版本時，請務必能夠將問題、事件和計量歸因於每個版本。 這項資訊應該繫結回發行管線，這樣可以快速追蹤並修正特定元件版本的問題。

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

檢測應用程式 一節包含您應該擷取之資訊的詳細指引。 但是您可以使用各種策略，在第一時間收集此資訊：

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

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

• 實際使用者監視。 這種方法記錄使用者與應用程式之間的互動，並會遵守每個要求和回應的流程。 此資訊可具有雙重用途：可用來依每位使用者計量使用情況，而且可用來判斷使用者是否接收適當的服務品質 (例如，快速回應時間、低延遲和最少錯誤)。 您可以使用擷取的資料來識別最常發生失敗的關切區域。 您也可以使用資料來識別系統可能因為應用程式中的熱點或某些其他形式的瓶頸而變慢的項目。 如果您仔細實作此方法，或許就能基於偵錯及測試用途而重新建構整個應用程式的使用者流程。

  重要

  您應該考慮將藉由監視真實使用者而擷取的資料視為高度機密，因為其中可能包含機密資料。 如果您儲存擷取的資料，請安全地加以儲存。 如果您想要基於效能監視或偵錯用途來使用資料，請先清除所有的個人識別資訊。

• 綜合使用者監視。 在這種方法中，您可以撰寫自己的測試用戶端，來模擬使用者，並執行可設定但典型的一系列作業。 您可以追蹤測試用戶端的效能，以協助判斷系統的狀態。 您也可以使用測試用戶端的多個執行個體，做為負載測試作業的一部分，來確定系統在壓力下如何回應，以及在這些情況下產生哪一種監視輸出。

  注意

  您可以實作實際和綜合使用者監視，方法是包括程式碼來追蹤方法呼叫的執行情況並計時，以及包括應用程式的其他重要部分。

• 分析。 這個方法主要以監視並改善應用程式效能為目標。 其會在應用程式執行時擷取更低階資訊，而不是在實際和綜合使用者監視的功能層級中作業。 您可以使用定期取樣應用程式的執行狀態 (判斷應用程式在特定時間點正在執行哪一段程式碼)，來實作分析。 您也可以使用於重要連接點 (例如方法呼叫的開始和結束時間) 將探查插入程式碼的檢測，並記錄何時要叫用哪些方法，以及每個呼叫花費多長時間。 然後可分析此資料，以判斷應用程式的哪些部分可能會造成效能問題。

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

如需最大涵蓋範圍，您應該使用這些技術的組合。

檢測應用程式

檢測是監視程序不可或缺的一部分。 唯有當您先擷取可讓您做出有意義之決策的資料時，才能對系統的效能和健康狀況做出有意義的決策。 您使用檢測所收集的資訊應該足以讓您能夠評估效能、診斷問題和做出決策，而不會要求您登入遠端實際執行伺服器，手動執行追蹤 (和偵錯)。 檢測資料通常會包含寫入追蹤記錄的計量和資訊。

追蹤記錄檔的內容可能是由應用程式所寫入的文字資料結果，這是由於追蹤事件而建立的二進位資料 (如果應用程式使用 Windows 的事件追蹤 – ETW)。 它們也可以從系統記錄產生，而這類記錄會記錄由部分基礎結構 (例如網頁伺服器) 所產生的事件。 文字記錄檔訊息通常會設計為人類看得懂的格式，但它們也應該以能讓自動化系統輕鬆剖析的格式來寫入。

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

計量通常只是系統中某個層面或資源在特定時間的量值或計數，並附有一或多個關聯的標籤或維度 (有時稱為「範例」 )。 隔離時計量的單一執行個體通常沒有用。 而是必須改為經過一段時間後擷取計量。 要考量的重點是您應該記錄哪些計量，以及多久一次。 太常產生計量資料可能會對系統造成極大的額外負擔，而不常擷取計量可能會導致您遺漏造成重大事件的情況。 考量將隨度量而有所不同。 例如，伺服器上的 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 雲端服務中啟用 Azure 診斷 文章提供此程序的詳細資料。 某些項目 (例如 IIS 記錄、當機傾印，以及自訂錯誤記錄) 會寫入 Blob 儲存體。 來自 Windows 事件記錄檔、ETW 事件和效能計數器的資料則會記錄在表格儲存體中。 圖 3 說明此機制。

圖 3 - 使用監視代理程式來提取資訊，並寫入至共用儲存體。

針對單一位置中有限數目的節點上執行的小型應用程式，適合使用剛描述的方法來儲存遙測資料。 不過，複雜且高度可調整的全域雲端應用程式可以從數百個 Web 和背景工作角色、資料庫分區和其他服務產生大量的資料。 此大量資料可以輕鬆地超過可搭配單一中央位置使用的 I/O 頻寬。 因此，您的遙測解決方案必須可以調整，以防止它在系統擴充時成為瓶頸。 在理想情況下，您的解決方案應納入某種程度的備援，以降低在部分系統失效時，遺失重要監視資訊 (例如稽核或帳單資料) 的風險。

若要解決這些問題，您可以實作佇列，如圖 4 所示。 在此架構中，本機監視代理程式 (如果可適當設定) 或自訂資料收集服務 (如果不可以) 會將資料張貼至佇列。 非同步執行的個別程序 (圖 4 中的儲存體寫入服務) 會採用此佇列中的資料，並將其寫入共用儲存體。 訊息佇列適用於這種案例，因為其提供「至少一次」語意，並可協助確保已排入佇列的資訊一旦張貼之後就不會遺失。 您可以使用個別的背景工作角色，來實作儲存體寫入服務。

圖 4 - 使用佇列來緩衝檢測資料。

收到資料之後，本機資料收集服務可以將其立即加入至佇列。 佇列可做為緩衝區，而且儲存體寫入服務可以按自己的步調擷取並寫入資料。 佇列預設會根據先進先出運作。 但如果訊息包含必須更快速處理的資料，您可以排定訊息的優先順序，以透過佇列將其加速。 如需詳細資訊，請參閱優先順序佇列模式。 或者，您可以使用不同的通道 (例如服務匯流排主題)，根據所需的分析處理形式將資料引導至不同的目的地。

如需擴充性，您可以執行儲存體寫入服務的多個執行個體。 如果有大量事件，您可以使用事件中樞，將資料分派給不同的計算資源以進行處理和儲存。

合併檢測資料

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

圖 5 - 使用個別服務來合併並清除檢測資料。

儲存檢測資料

先前的討論已描述檢測資料儲存方式相當簡單的檢視。 事實上，其可以合理使用最適合每一種類型可能使用方式的技術，儲存不同類型的資訊。

例如，Azure Blob 和表格儲存體在其存取方式中有一些相似之處。 但對您可用其來執行的作業卻有所限制，而且其保留之資料的細微性相當不同。 如果您需要執行更多的分析作業或需要資料上的全文檢索搜尋功能，可能更適合使用資料儲存體，因為它提供的功能已針對特定類型的查詢和資料存取最佳化。 例如：

• 效能計數器資料可以儲存在 SQL Database 中，以啟用特定分析。
• 追蹤記錄可能更適合儲存於 Azure Cosmos DB。
• 安全性資訊可以寫入 HDFS。
• 需要全文檢索搜尋的資訊可以透過彈性搜尋來儲存 (也可以使用豐富的檢索來加速搜尋)。

您可以實作定期從共用儲存體、磁碟分割擷取資料，並根據其用途篩選資料的其他服務，然後將其寫入至一組適合的資料存放區，如圖 6 所示。 替代方法是在彙總及清除程序中包含此功能，並直接將資料寫入這些存放區，因為會擷取它，而不是將它儲存在中間共用的儲存體區域中。 每一種方法有其優點和缺點。 實作個別分割服務可減少彙總與清除服務的負載，並至少讓部分分割的資料能夠在需要時重新產生 (視共用儲存體中保留的資料量而定)。 不過，它會耗用其他資源。 此外，在從每個應用程式執行個體接收的檢測資料，以及將資料轉換成可採取動作的資訊之間，可能會出現延遲。

圖 6 - 根據分析和儲存體需求分割資料。

基於多個用途，可能需要相同的檢測資料。 例如，效能計數器可以用來提供一段時間後系統效能的歷程記錄檢視。 此資訊可能會與其他使用情況資料結合，來產生客戶帳單資訊。 在這些情況下，相同的資料可能會傳送至多個目的地，例如文件資料庫 (可做為長期存放區，保留帳單資訊) 和多維度存放區 (用於處理複雜的效能分析)。

您也應該考慮需要資料的緊急程度。 提供警示資訊的資料需要快速存取，因此應該保留在快速資料儲存體中，並編製索引或結構化以最佳化警示系統執行的查詢。 在某些情況下，可能需要遙測服務收集每個節點上要格式化的資料，並在本機儲存資料，以便警示系統的本機執行個體可以快速通知您任何問題。 相同的資料可以發送至先前圖表中顯示的儲存體寫入服務，而且如果基於其他用途而需要它，則集中儲存。

用於考量更多的分析、用於報告，以及用於找出歷史趨勢的資訊較不緊急，而且可用支援資料採礦和特定查詢的方式儲存。 如需詳細資訊，請參閱本文件稍後的 支援熱、暖和冷分析 一節。

記錄輪替和資料保留

檢測可以產生相當大量的資料。 這項資料可以保留在幾個地方，從原始記錄檔、追蹤檔案和在每個節點擷取的其他資訊開始，到共用儲存體中保留的這項資料的已合併、已清理和已分割檢視。 在某些情況下，處理並傳送資料之後，就可以從每個節點中移除原始來源資料。 在其他情況下，可能需要或只是有用而儲存原始資訊。 例如，基於偵錯用途產生的資料最好能夠留下可用的原始形式，但在修正任何錯誤之後，接著就能相當快速地將其捨棄。

效能資料的有效期限通常較長，讓它可用來找出效能趨勢，以及進行容量規劃。 此資料的合併檢視通常會在一段有限期間內，保留線上狀態以啟用快速存取。 在這段期間之後，即會將其封存或捨棄。 針對計量和計費收集的資料，客戶可能需要無限期地儲存。 此外，法規需求可能會指定基於稽核及安全性用途所收集的資訊也需要封存和儲存。 此資料也是機密資料，因此可能需要加密或保護以防止竄改。 您絕對不能記錄使用者的密碼，或其他可能可用來認可身分識別詐騙的資訊。 應該先從資料中消除這類詳細資料，再儲存資料。

向下取樣

儲存歷程記錄資料非常有用，讓您能夠找出長期趨勢。 不是儲存整個舊資料，而是可以向下取樣資料，以降低其解析度，並節省儲存體成本。 舉例來說，不是儲存按分鐘的效能指標，您可以改為合併超過一個月的資料，以形成按小時檢視。

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

下列清單總結擷取和儲存記錄資訊的最佳做法：

• 監視代理程式或資料收集服務應該做為程序外服務來執行，而且應該是簡單部署。

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

• 監視和資料收集程序必須保全，而且不得觸發任何階層式錯誤狀況。

• 傳送資訊至資料接收器時，如果發生暫時性失敗，監視代理程式或資料收集服務應該已準備好重新排列遙測資料，以便先傳送最新的資訊 (監視代理程式/資料收集服務可自行斟酌選擇捨棄較舊資料，或將其儲存在本機，並在稍後進行傳輸以趕上新版本)。

分析資料和診斷問題

監視和診斷程序的重要部分是分析收集的資料，以取得系統整體狀態良好的狀況。 您應該已定義自己的 KPI 和效能計量，請務必了解如何建構已收集的資料，以符合您的分析需求。 也請務必了解如何在不同的計量中擷取資料，以及記錄檔如何相互關聯，因為此資訊可以是追蹤一連串事件的關鍵，並有助於診斷引發的問題。

如同 合併檢測資料一節中所述，系統每個部分的資料一般是在本機擷取，但通常需要和在參與系統的其他網站上產生的資料結合。 這項資訊需要小心相互關聯，以確保正確地合併資料。 例如，作業的使用情況資料可能會跨越裝載使用者所連接之網站的節點、執行當做此作業一部分存取之個別服務的節點，以及其他節點上保留的資料儲存體。 此資訊必須繫結在一起，以提供作業的資源和處理使用情況的整體檢視。 某些前置處理和篩選的資料可能會發生在擷取資料的節點上，而彙總和格式化更可能發生在中央節點上。

支援熱、暖和冷分析

基於視覺效果、報告和警示用途分析和重新格式化資料，可以是耗用自己資源集的複雜程序。 某些形式的監視是關鍵時間，而且需要立即分析資料是否有效。 這就是所謂的 熱分析。 範例包括警示所需的分析，以及某些層面的安全性監視 (例如偵測系統上的攻擊)。 基於這些用途所需的資料必須快速可用且結構化，才能有效處理。 在某些案例中，可能需要將分析處理移至保留資料的個別節點。

其他形式的分析時間較不關鍵，而且收到原始資料之後，可能需要一些計算和彙總。 這稱為「暖分析」。 效能分析通常屬於此類別。 在此情況下，隔離的單一效能事件不可能有明顯的統計資料 (可能是突然暴增或問題所造成。) 來自一系列事件的資料應該提供更可靠的系統效能圖。

暖分析也可用來協助診斷效能問題。 健康狀況事件通常是透過執行熱分析來處理，而且可以立即引發警示。 操作員應該能夠藉由檢查來自暖路徑的資料，來掌握健康狀況事件的原因。 此資料應該包含導致問題之事件的相關資訊，而此問題已造成健康狀況事件。

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

操作員也可以使用冷分析來提供預測性健康狀況分析的資料。 操作員可以收集指定時段的歷程記錄資訊，並用於搭配目前的健康狀況資料 (擷取自最忙碌的路徑)，以找出可能很快就會導致健康狀況問題的趨勢。 在這些情況下，可能必須引發警示，以便採取更正動作。

使資料相互關聯

檢測擷取的資料可提供系統狀態的快照，但分析的目的是為了使此資料可採取動作。 例如：

• 什麼會在特定時間於系統層級導致密集 I/O 載入？
• 是大量資料庫作業的結果嗎？
• 這是否反映在資料庫的回應時間、每秒交易數，以及相同連接點的應用程式回應時間？

如果是這樣，可能降低負載的一個補救動作可透過更多的伺服器來分區化資料。 此外，結果中的例外狀況可以由系統任何層級中的錯誤所引起。 某個層級中的例外狀況通常會觸發上面層級中的另一個錯誤。

基於這些理由，您需要能夠使每個層級中不同類型的監視資料相互關聯，以產生系統及在其上執行之應用程式的狀態的整體檢視。 您可以使用此資訊來做出系統是否以可接受方式運作的決策，並決定可做什麼來提升系統品質。

如同 相互關聯資料的資訊一節中所述，您必須確保原始檢測資料包含足夠的內容和活動識別碼資訊，來支援相互關聯事件所需的彙總。 此外，此資料可能會以不同格式保留，並且可能需要剖析此資訊，才能將它轉換成標準化格式，以供分析之用。

疑難排解和診斷問題

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

• 在指定的時間範圍內來自整個系統或指定子系統之事件記錄和追蹤的詳細資訊。
• 由任何指定層級之例外狀況和錯誤所產生的完整堆疊追蹤，而這些例外狀況和錯誤會在指定時段發生於系統或指定的子系統內。
• 在指定的時間範圍期間系統或指定的子系統中任何位置的任何失敗程序的當機傾印。
• 記錄所有使用者或所選使用者在指定時段內所執行之作業的活動記錄。

基於疑難排解用途分析資料，通常需要深厚的技術知識，才能了解系統架構以及構成解決方案的各種元件。 因此，經常需要大程度的手動介入來解譯資料、建立問題的原因，以及建議適當策略來更正它們。 可能只適合以其原始格式儲存此資訊的複本，並讓專家可用來進行冷分析。

視覺化資料和引發警示

任何監視系統的重要層面就是能夠以下列方式呈現資料：操作員可以快速找出任何趨勢或問題。 另一個重點是，如果發生可能需要注意的重大事件，快速通知操作員。

資料簡報可以採取數種形式，包括使用儀表板、警示和報告的視覺效果。

使用儀表板的視覺效果

視覺化資料的最常見方式是使用儀表板，可將資訊顯示為一系列的圖表、圖形或一些其他圖例。 這些項目可以參數化，而且分析人員應該能夠針對任何特定情況選取重要參數 (例如時段)。

儀表板可以階層方式組織。 最上層的儀表板可以提供系統各層面的整體檢視，但能夠讓操作員向下鑽研到詳細資料。 例如，描述系統的整體磁碟 I/O 的儀表板應該允許分析人員檢視每個個別磁碟的 I/O 速率，來確定是否有一或多個特定裝置會導致不當比例的流量。 在理想情況下，儀表板應該也會顯示相關資訊，例如，產生此 I/O 之每個要求的來源 (使用者或活動)。 然後，此資訊可用來判斷 (以及如何) 是否將負載更平均地分散在各個裝置，以及如果加入更多裝置，系統是否能執行的更好。

儀表板可能也會使用色彩編碼或一些其他的視覺提示，來指出出現異常或超出預期範圍的值。 使用上述範例︰

• I/O 速率在經過一段長時間後接近最大容量的磁碟 (熱磁碟) 可以紅色反白顯示。
• I/O 速率以其最大限制定期執行的磁碟 (暖磁碟) 可以黃色反白顯示。
• 呈現正常使用情況的磁碟則可以綠色顯示。

請注意，若要讓儀表板系統有效運作，它必須具有要使用的原始資料。 如果您正在建置自己的儀表板系統，或利用由另一個組織所開發的儀表板，則必須了解您需要以哪些程度的細微性來收集哪些檢測資料，以及應該如何格式化以供儀表板取用。

良好的儀表板不只會顯示資訊，也可讓分析人員提出有關該資訊的特定疑問。 某些系統會提供管理工具，操作員可以用來執行這些工作，並瀏覽基礎資料。 或者，可以根據用來保留此資訊的儲存機制直接查詢，或將其匯入如 Microsoft Excel 的工具，進行進一步的分析和報告。

引發警示

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

警示有助於確保讓系統維持狀況良好、可回應性及安全。 這是任何系統的一個重要部分，可對使用者做出效能、可用性和隱私權保證，而其中的資料可能需要立即處理。 事件若觸發警示，可能需要通知操作員。 警示也可以用來叫用系統函數，例如自動調整。

警示通常取決於下列檢測資料：

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

操作員可能藉由使用多種傳送通道 (例如電子郵件、呼叫器裝置或 SMS 文字訊息) 來接收警示資訊。 警示可能也會指出某種情況的重要性為何。 許多警示系統支援訂閱者群組，而且所有屬於相同群組之成員的操作員都會接收到同一組警示。

警示系統應該是可自訂，而且來自基礎檢測資料的適當值可以當做參數提供。 這種方法可讓操作員篩選資料，並著重於那些臨界值或感興趣的值組合。 請注意，在某些情況下，可將原始檢測資料提供給警示系統。 在其他情況下，可能更適合提供彙總的資料 (例如，如果節點的 CPU 使用率在過去 10 分鐘超過 90%，則可能會觸發警示)。 提供給警示系統的詳細資料也應該包括任何適當的摘要和內容資訊。 此資料可以協助降低誤判事件誤發警示的可能性。

報告

報告可用來產生系統的整體檢視。 它可能會納入歷程記錄資料以及目前的資訊。 報告本身的需求落在兩大類：作業報告和安全性報告。

作業報告通常包括下列層面：

• 彙總統計資料，您可以用來了解整體系統或指定子系統在指定時間範圍內的資源使用率。
• 識別整體系統或指定子系統在指定時段內資源使用狀況的趨勢。
• 監視整個系統或指定子系統在指定時段內發生的例外狀況。
• 根據部署的資源判斷應用程式的效率，並了解是否可以減少資源數量 (和其相關聯的成本)，而不會無謂地影響效能。

安全性報告渉及追蹤客戶使用系統的方式。 其中包含︰

• 稽核使用者作業。 這需要記錄每位使用者執行的個別要求，以及日期和時間。 資料應該結構化，以便讓系統管理員能夠迅速重新建構使用者在指定時段執行作業的順序。
• 依使用者追蹤資源使用。 這需要記錄使用者的每個要求存取組成系統之各種資源的方法，以及時間的長度。 系統管理員可能基於計費用途，而必須能夠使用此資料，依使用者產生指定時段的使用率報告。

在許多情況下，批次程序可以根據定義的排程產生報告 (延遲通常不是問題。) 但如有需要，也應該以特定方式產生。 舉例來說，如果您是將資料儲存在關聯式資料庫，例如 Azure SQL Database，則可以使用 SQL Server Reporting Services 之類的工具來擷取並格式化資料，然後將其呈現為一組報告。

後續步驟

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

相關資源

• 自動調整指引 描述如何藉由減少操作員持續監視系統效能的需求來降低管理的額外負荷，並做出有關加入或移除資源的決策。
• Health Endpoint Monitoring Pattern (健康狀況端點監視模式) 描述如何實作應用程式內的功能檢查，而外部工具可透過公開的端點定期存取此應用程式。
• Priority Queue Pattern (優先順序佇列模式) 會顯示如何排定佇列訊息的優先順序，以便在較不緊急的訊息之前收到緊急要求並加以處理。