（十一）—— 健康端點監(jiān)控模式

云計算設計模式（十一）——健康端點監(jiān)控模式

實施外部工具可以定期通過暴露終端訪問應用程序中的功能檢查。這個模式可以幫助驗證的應用和服務被正確執(zhí)行。

背景和問題

它是很好的做法，并且通常是一個業(yè)務需求，并監(jiān)控web應用程序，和中間層和共享服務，以確保它們是可用的，并執(zhí)行正確的。然而，它更難以監(jiān)測在云中運行比它要監(jiān)控本地服務的服務。舉例來說，你不必完全控制主機環(huán)境，而服務通常依賴于平臺，供應商和其他公司提供其他服務。

也有一些影響云托管的應用，如網(wǎng)絡延遲，性能和下面的計算和存儲系統(tǒng)的可用性，以及它們之間的網(wǎng)絡帶寬的因素很多。由于任何這些因素的服務可能完全或部分失敗。因此，您必須定期驗證服務正在執(zhí)行正確，以確?？捎眯裕@可能是您的服務級別協(xié)議（SLA）的一部分所要求的水平。

解決方案

通過將請求發(fā)送到應用程序的端點實施健康監(jiān)測。該應用程序應該執(zhí)行必要的檢查，并返回其狀態(tài)的指示。

一種保健監(jiān)測檢查通常結合了兩個因素：檢查（如果有的話）的應用程序或服務響應于所述請求發(fā)送到健康驗證端點執(zhí)行，并且結果由工具或框架正在執(zhí)行健康檢查驗證的分析。的響應代碼表示的應用程序的狀態(tài)和任選的任何組件或服務，它使用。的延遲或響應時間檢查由監(jiān)測工具或框架進行。圖1示出了該模式的執(zhí)行的概述。

圖1 - 模式概述

附加的檢查，可能如下進行：在該應用程序的運行狀況監(jiān)視代碼包括：

• 檢查云存儲或可用性和響應時間的數(shù)據(jù)庫。
• 檢查位于所述應用程序內，或位于其它地方，但應用程序使用的其他資源或服務。

幾個現(xiàn)有的服務和工具可用于監(jiān)視 web 應用程序通過提交一個請求到一組可配置的端點，并評價針對一組可配置的規(guī)則的結果。它相對容易地創(chuàng)建一個服務端點，其唯一的目的是要在系統(tǒng)上執(zhí)行一些功能測試。

這可以通過監(jiān)控工具來執(zhí)行典型的檢查包括：

• 驗證的響應代碼。例如，200 的 HTTP 響應（OK）的指示應用程序作出反應而不會出現(xiàn)錯誤。該監(jiān)控系統(tǒng)也可能會檢查是否有其他響應代碼，給出的結果更全面的指標。
• 檢查響應的內容，以檢測錯誤，甚至當返回 200（OK）的狀態(tài)碼。這可以檢測到影響返回的網(wǎng)頁或服務響應的僅有部分的錯誤。例如，檢查一個頁面的標題或尋找某個特定的詞組，表示正確的頁面被退回。
• 測量響應時間，這表明網(wǎng)絡延遲和應用程序把執(zhí)行請求的時間相結合。增加的值可以指示一個新興的問題與該應用程序或網(wǎng)絡。
• 檢查資源或位于該應用程序之外的服務，如由應用程序使用，以從全局高速緩存?zhèn)鬟f內容的內容分發(fā)網(wǎng)絡。
• 檢查 SSL 證書過期。
• 測量用于該應用程序的 URL 的 DNS 查詢的響應時間，以便測量的 DNS 延遲和 DNS 故障。
• 驗證返回的 DNS 查詢，以確保正確輸入的URL。這有助于通過在 DNS 服務器上成功的攻擊，以避免惡意請求的重定向。

它也是有用的，在可能情況下，以內部部署和托管的位置運行，從這些不同的檢查，以測量和來自不同地方比較的響應時間。理想情況下，你應該監(jiān)視那些貼近客戶，以得到每個位置的性能進行精確的視圖位置的應用程序。除了提供一個更為堅固的檢查機制，其結果可能會影響部署位置的選擇的應用程序，以及是否在一個以上的數(shù)據(jù)中心部署。

試驗還應該對所有客戶使用，以確保應用程序正常工作的所有顧客的服務實例運行。例如，如果客戶的存儲空間分布在多個存儲賬戶，在監(jiān)測過程中，必須檢查所有的這些。

問題和注意事項

在決定如何實現(xiàn)這個模式時，請考慮以下幾點：

• 如何驗證響應。例如，僅僅是一個200（OK）狀態(tài)碼足以驗證應用程序是否工作正常？雖然這提供了應用程序的可用性的最基本的措施，而且是最小執(zhí)行這個模式中，它提供了有關操作，趨勢，并在應用中可能即將出現(xiàn)的問題的信息很少。

Note

確保應用程序不會正確地當目標資源是發(fā)現(xiàn)和處理僅返回200狀態(tài)碼。在某些情況下，使用母版頁來承載目標網(wǎng)頁的時候，例如，服務器可能會返回一個 200 OK 狀態(tài)碼，而不是一個 404 未找到的代碼，即使沒有找到目標內容頁面。

• 端點的數(shù)量，以暴露于一個應用程序。一種方法是將暴露的至少一個端點的應用程序所使用的核心服務，而另一個用于輔助或低優(yōu)先級的服務，使得不同級別的重要性將被分配給每個監(jiān)控結果。也可以考慮暴露多個端點，如為每個核心服務，以提供額外的監(jiān)控粒度。舉例來說，一個健康的驗證檢查可以檢查數(shù)據(jù)庫，存儲和應用程序使用外部地理編碼服務;每個都需要不同級別的正常運行時間和響應時間。應用程序可能仍然是健康的，如果地理編碼服務，或其他一些后臺任務，是幾分鐘不可用。
• 是否使用相同的終點監(jiān)測作為用于一般訪問，而是設計為健康驗證檢查一個特定的路徑;例如，/健康檢查/{GUID}/對一般接入端點。這允許應用程序內的某些功能測試由監(jiān)測工具，例如添加新的用戶注冊，登錄，以及將一個測試的順序被執(zhí)行，同時也證實，一般接入終端是可用的。
• 收集在服務響應于監(jiān)控請求，以及如何返回該信息的信息類型。大多數(shù)現(xiàn)有的工具和框架只看該 HTTP 狀態(tài)代碼端點的回報。要恢復和驗證其他信息，可能需要創(chuàng)建一個自定義監(jiān)控實用程序或服務。
• 多少信息收集。在檢查過程中進行過度處理可以重載應用和影響其他用戶，并且所花費的時間可能超過監(jiān)控系統(tǒng)的超時，使得它標志著該應用程序為不可用。大多數(shù)的應用包括儀表，如錯誤處理程序，并且記錄性能和詳細的錯誤信息的性能計數(shù)器，這可能是足夠的，而不是從一個健康驗證檢查返回的附加信息。
• 如何配置安全監(jiān)控端點保護他們免受公眾使用;這可能暴露該應用程序的惡意攻擊，風險敏感信息的曝光，還是吸引拒絕服務（DoS）攻擊。典型地，這應該在應用程序的配置來完成，以便它可以容易地更新，而無需重新啟動該應用程序?？梢钥紤]使用以下一種或多種技術：通過要求認證?Secure 端點。這可以通過使用在請求報頭中的身份驗證的安全密鑰或通過傳遞憑證與請求來實現(xiàn)，條件是，監(jiān)控服務或工具支持認證。
• Use 一個不起眼的或隱藏的端點。例如，暴露在端點上一個不同的 IP 地址，以所使用的默認的應用程序的 URL，一個非標準的 HTTP 端口上配置端點，和/或使用復雜的路徑測試頁。它通常可以指定在應用程序配置額外的端點地址和端口，并為這些端點的 DNS 服務器（如果需要），以避免直接指定 IP 地址添加條目。
• Expose 上接受一個參數(shù)的端點的方法，諸如鍵的值或操作模式的值。根據(jù)不同的請求時收到的代碼可以執(zhí)行特定測試或一組測試，或者返回一個 404 這個參數(shù)提供的值（未找到）錯誤，如果不能被識別的參數(shù)值。所識別的參數(shù)值可以在該應用程序的配置進行設置。

Note1

DoS 攻擊是可能對一個單獨的端點，它執(zhí)行基本功能測試，而不會影響應用程序的動作的影響較小。理想情況下，應避免使用測試可能暴露敏感信息。如果你必須返回，可能是對攻擊者有用的信息，考慮如何將保護端點免受未經(jīng)授權的訪問數(shù)據(jù)。在這種情況下，僅僅依靠默默無聞是不夠的。還應該考慮使用 HTTPS 連接和加密的任何敏感數(shù)據(jù)，盡管這會增加服務器上的負載。

• 如何訪問正在使用認證固定的端點。不是所有的工具和框架可被配置為包括與健康驗證請求的憑證。例如，微軟的 Azure 內置健康驗證功能無法提供身份驗證憑據(jù)。一些第三方的替代品，可以是 Pingdom 的，Panopta，NewRelic 的，和 Statuscake。
• 如何確保監(jiān)控代理是否正確地履行。一種方法是，以暴露一個端點僅返回來自應用程序的配置或可被用來測試劑的隨機值的值。

Note2

還要確保監(jiān)控系統(tǒng)進行自身檢查，如自檢和內置的測試，以避免它在發(fā)出假陽性結果。

何時使用這個模式

這種模式非常適合于：

• 監(jiān)控網(wǎng)站和 Web 應用程序，以驗證可用性。
• 監(jiān)控網(wǎng)站和 Web 應用程序，以檢查其是否工作正常。
• 監(jiān)控中間層或共享服務來檢測和隔離故障，可能影響其他應用程序。
• 要在應用程序中補充現(xiàn)有的儀器，如性能計數(shù)器和錯誤處理程序。衛(wèi)生檢驗檢查并不能取代的日志和審計中的應用程序的需求。儀表能夠提供有價值的信息為現(xiàn)有的框架，監(jiān)視計數(shù)器和錯誤日志來檢測故障或其他問題。然而，它不能提供的信息，如果該應用程序是不可用的。

例子

下面的代碼示例，從 HealthCheckController 類的 HealthEndpointMonitoring.Web 項目采取包括可以下載本指南的樣品，演示露出一個端點進行一系列健康檢查。

該 CoreServices 方法，如下所示，執(zhí)行在應用程序中使用的服務的一系列檢查。如果所有的測試中沒有錯誤執(zhí)行，該方法返回一個 200（OK）狀態(tài)碼。如果有任何的測試引發(fā)了異常，該方法返回一個 500（內部錯誤）狀態(tài)碼。當發(fā)生錯誤時的方法，可任選地返回附加信息，如果該監(jiān)控工具或框架能夠利用它。

public ActionResult CoreServices()  
{  
  try  
  {  
    // Run a simple check to ensure the database is available.  
    DataStore.Instance.CoreHealthCheck();  
?
    // Run a simple check on our external service.  
    MyExternalService.Instance.CoreHealthCheck();  
  }  
  catch (Exception ex)  
  {  
    Trace.TraceError("Exception in basic health check: {0}", ex.Message);  
?
    // This can optionally return different status codes based on the exception.  
    // Optionally it could return more details about the exception.  
    // The additional information could be used by administrators who access the  
    // endpoint with a browser, or using a ping utility that can display the  
    // additional information.  
    return new HttpStatusCodeResult((int)HttpStatusCode.InternalServerError);  
  }  
  return new HttpStatusCodeResult((int)HttpStatusCode.OK);  
}

該 ObscurePath 方法顯示了如何讀取應用程序配置的路徑，并用它作為測試端點。這個例子也說明了如何接受一個 ID 作為參數(shù)，并用它來檢查有效的請求。

public ActionResult ObscurePath(string id)  
{  
  // The id could be used as a simple way to obscure or hide the endpoint.  
  // The id to match could be retrieved from configuration and, if matched,   
  // perform a specific set of tests and return the result. It not matched it  
  // could return a 404 Not Found status.  
?
  // The obscure path can be set through configuration in order to hide the endpoint.  
  var hiddenPathKey = CloudConfigurationManager.GetSetting("Test.ObscurePath");  
?
  // If the value passed does not match that in configuration, return 403 "Not Found".  
  if (!string.Equals(id, hiddenPathKey))  
  {  
    return new HttpStatusCodeResult((int)HttpStatusCode.NotFound);  
  }  
?
  // Else continue and run the tests...  
  // Return results from the core services test.  
  return this.CoreServices();  
}

該 TestResponseFromConfig 方法顯示了如何可以公開執(zhí)行一個指定的配置設定值檢查的端點。

public ActionResult TestResponseFromConfig()  
{  
  // Health check that returns a response code set in configuration for testing.  
  var returnStatusCodeSetting = CloudConfigurationManager.GetSetting(  
                                                          "Test.ReturnStatusCode");  
?
  int returnStatusCode;  
?
  if (!int.TryParse(returnStatusCodeSetting, out returnStatusCode))  
  {  
    returnStatusCode = (int)HttpStatusCode.OK;  
  }  
?
  return new HttpStatusCodeResult(returnStatusCode);  
}

監(jiān)控端點在 Azure 中托管的應用程序

在Azure應用程序監(jiān)控終端的一些選項包括：

• 使用微軟的Azure，的內置功能，如管理服務或流量管理器。
• 使用第三方服務或Microsoft系統(tǒng)中心操作管理器的框架等。
• 創(chuàng)建一個自定義的工具，或者在您自己的或托管的服務器上運行的服務。

注意： 盡管 Azure 提供一個合理的全面的監(jiān)控選項，您可以決定使用額外的服務和工具，以提供額外的信息。

Azure 管理服務提供了各地的警報規(guī)則建立了一個全面的內置監(jiān)控機制。管理服務網(wǎng)頁中的 Azure 管理門戶 Alerts 部分，可以配置高達每認購10警報規(guī)則為您服務。這些規(guī)則指定一條件和用于服務諸如 CPU 負載的閾值，或每秒請求或錯誤的數(shù)量，并且該服務可以自動發(fā)送電子郵件通知給你在每個規(guī)則定義的地址。

您可以監(jiān)視具體費用取決于您選擇適合您的應用程序的托管機制的條件下（如網(wǎng)站，云服務，虛擬機，或移動服務），但所有這些，包括創(chuàng)建使用網(wǎng)絡端點警報規(guī)則的能力您在為您服務的設置指定。此端點應該及時地作出反應，以使警報系統(tǒng)可以檢測到該應用程序是否正常運行。

注意： 有關創(chuàng)建監(jiān)視警報的詳細信息，請參閱 MSDN 上的管理服務。

如果你的主機在 Azure 云服務網(wǎng)絡和工作角色或虛擬機應用程序時，您可以采取的內置服務在Azure中所謂的流量管理器中的一個優(yōu)勢。流量管理器是一個路由和負載平衡服務，可以將請求分發(fā)到您的云服務托管的應用程序基于一系列的規(guī)則和設置的具體實例。

除了請求路由，流量管理坪的 URL，端口和相對你定期指定的路徑來確定其規(guī)則中定義的應用程序的實例是活動的，并響應請求。如果它檢測到一個狀態(tài)代碼 200（OK）它標志著應用程序可用，其他狀態(tài)的代碼會導致流量管理器來標記應用程序離線。您可以查看流量管理器控制臺的狀態(tài)和配置規(guī)則來重新路由請求被響應的應用程序的其他實例。

但是，請記住，流量管理器將只等待10秒鐘，以接收來自監(jiān)控URL的響應。因此，你應該確保你的健康驗證碼這個時間范圍內執(zhí)行，允許網(wǎng)絡延遲從流量管理器往返于您的應用程序，然后再返回。

注意： 有關使用 Windows 流量管理器來監(jiān)視你的應用程序的更多信息，請參閱 MSDN 上微軟 Azure Traffic Manager 的。流量管理器在多個數(shù)據(jù)中心部署指南進行了討論。