自動調整的最佳做法

  • 發行項

Azure 監視器自動調整僅適用於 Azure 虛擬機器擴展集、Azure 雲端服務、Azure App Service 的 Web Apps 功能和 Azure APIM.

自動調整概念

  • 一個資源只可以有「一項」自動調整設定。
  • 自動調整設定可有一或多個設定檔，而且每個設定檔都能有一或多項自動調整規則。
  • 自動調整設定可水平縮放執行個體，增加執行個體叫做「擴增」，減少執行個體叫做「縮減」。
  • 自動調整設定有執行個體數目的最大、最小和預設值。
  • 自動調整作業一律會讀取相關聯的計量，透過檢查是否超過設定的擴增或縮減閾值來進行調整。 您可以在 Azure 監視器自動調整的常見度量中，檢視自動調整據以調整的度量清單。
  • 所有閾值的計算都在執行個體層級。 例如：「當執行個體計數為 2 且平均 CPU > 80% 時，擴增一個執行個體」。這表示在所有執行個體的平均 CPU 大於 80% 時進行擴增。
  • 所有自動調整失敗都會記錄到活動記錄中。 您接著可以設定活動記錄警示，如此一來，每當自動調整失敗時，您便可透過電子郵件、SMS 或 Webhook 收到通知。
  • 同樣地，所有成功調整規模動作也都會張貼到活動記錄。 接著您可以設定活動記錄警示，如此一來，每當自動調整動作成功時，您便可以透過電子郵件、簡訊或 Webhook 收到通知。 您也可以透過自動調整規模設定上的 [通知] 索引標籤來設定電子郵件或 Webhook 通知，在調整規模動作成功時收到通知。

自動調整最佳做法

使用自動調整時，請使用下列最佳做法。

確定最大值與最小值不同，而且兩者之間有適當差距

若設定的最小值等於 2，而最大值也等於 2，且目前執行個體計數為 2，將不會有任何調整動作。 在執行個體計數的最大值與最小值之間 (含這兩個值)，需保留適當的差距。 在這些限制之間，一定律會自動調整。

自動調整的最小值和最大值會重設手動調整

如果您手動將執行個體計數的值更新為高於最大值或低於最小值，自動調整引擎會自動調整回最小值 (如果低於) 或最大值 (如果高於)。 例如，您設定的範圍是 3 到 6。 如果您有一個執行執行個體正在執行，自動調整引擎會在它下次執行時調整為三個執行個體。 同樣地，如果您以手動方式將規模設定為八個執行個體，在下次執行時，自動調整規模會在它下次執行時將它調整回六個執行個體。 手動調整是暫時的，除非您也同時重設自動調整規則。

請一律使用相應放大和相應縮小規則的組合來執行增加與減少。

如果僅使用組合的其中一個部分，則自動調整將只往單一方向採取動作 (擴增或縮減)，直到達到設定檔中定義的最大或最小執行個體計數。 這不是最佳情況。 最好是在高使用量時擴增資源，以確保可用性。 同樣地，在低使用量時應該縮減資源，以確實節省成本。

當您使用相應縮小和向外延展規則時，最好使用相同的計量來控制這兩者。 否則，可能會同時符合縮減和擴增條件，進而產生某種程度的擺盪。 例如，不建議使用下列規則組合，因為沒有適用於記憶體使用量的縮減規則：

  • 當 CPU > 90% 時，則擴增 1
  • 當記憶體 > 90% 時，則擴增 1​
  • 當 CPU < 45% 時，則縮減 1

在此範例中，您可以有記憶體使用量超過 90%，但 CPU 使用量低於 45% 的情況。 只要符合這兩個條件，這可能會導致擺盪。

為您的診斷計量選擇適當的統計資料

針對診斷度量，您可以選擇 [平均值]、[最小值]、[最大值] 和 [總計] 作為據以調整的計量。 最常用的統計資料是 [平均值] 。

調整特殊計量的閾值時的注意事項

對於特殊計量 (例如 Azure儲存體或 Azure 服務匯流排佇列長度計量)，臨界值目前執行個體數所能使用的平均訊息數。 請謹慎選擇此度量的臨界值。

現在讓我們利用下列範例為您說明，讓您對此行為有更深入的了解：

  • 當儲存體佇列訊息計數 >= 50 時，則增加 1 個計數的執行個體
  • 當儲存體佇列訊息計數 <= 10 時，則減少 1 個計數的執行個體

考量以下發生順序：

  1. 有兩個儲存體佇列執行個體。
  2. 隨著訊息不斷傳入，當您檢閱儲存體佇列時，訊息計數達到 50。 您可能認為自動調整應執行相應放大動作。 但請注意，其仍然是每個執行個體 50/2 = 25 則訊息。 因此，不會進行擴增。 若要執行第一次擴增動作，儲存體佇列中的總訊息計數應達到 100。
  3. 當總訊息計數達到 100 時，
  4. 就會因為執行擴增動作而加入第 3 個儲存體佇列執行個體。 除非佇列中的總訊息計數達到 150 (因為 150/3=50)，否則不會進行下一個擴增動作。
  5. 現在，佇列中的估計訊息數目便會變小。 若有三個執行個體，當所有佇列中的總訊息數相加達到 30 時，會執行第一次相應縮小動作，意即臨界值是每個執行個體的規模為 30/3 = 10 則訊息。

當設定檔中設有多項規則時的調整注意事項

有些情況可能需要您在設定檔中設定多項規則。 當設定多項規則時，自動調整引擎會使用下列自動調整規則：

  • 擴增時，如果符合任何規則，便會執行自動調整。
  • 對於「縮減」，自動調整會要求必須符合所有規則。

為了說明，假設您有四個自動調整規則：

  • 當 CPU < 30% 時，則縮減 1
  • 當記憶體 < 50% 時，則縮減 1​
  • 當 CPU > 75% 時擴增 1
  • 如果記憶體 > 75%，則擴增 1​

然後會發生下列動作：

  • 如果 CPU 是 76%，記憶體是 50%，則擴增。
  • 當 CPU 為 50%，記憶體為 76% 時，我們將進行擴增。

反之，當 CPU 為 25%，記憶體為 51% 時，自動調整「不會」縮減。 若要縮減，CPU 必須達到 29%，而記憶體必須達到 49%。

一律選取安全的預設執行個體計數

預設執行個體計數很重要，因為沒有計量時，自動調整會將服務調整為該計數。 因此，請選取對您工作負載而言最安全的預設執行個體計數。

設定自動調整通知

如果發生任何下列條件，自動調整規模將會張貼到活動記錄中：

  • 自動調整會發出規模調整作業。
  • 自動調整服務成功完成規模調整動作。
  • 自動調整服務未能執行縮放動作。
  • 自動調整服務沒有可用的計量來決定縮放。
  • 重獲計量 (復原) 可據以決定縮放。
  • 自動調整會偵測 Flapping 並中止規模調整嘗試。 在此情況下，您會看到 Flapping 記錄類型。 如果看到此記錄類型，請考慮臨界值的範圍是否過窄。
  • 自動調整會偵測 flapping，但還是可以成功調整規模。 在此情況下，您會看到 FlappingOccurred 記錄類型。 如果您看到此記錄類型，自動調整引擎已嘗試調整規模 (例如，從四個執行個體調整為兩個)，但已判斷此變更會造成擺盪。 相反地，自動調整引擎已調整為不同的執行個體數目 (例如，使用三個執行個體而不是兩個)，就不會再造成擺盪，因此已調整成這個執行個體數目。

您也可以使用活動記錄警示來監視自動調整引擎的健康狀態。 其中一個範例會示範如何建立活動記錄警示以監視訂用帳戶的所有自動調整引擎作業。 另一個範例會示範如何建立活動記錄警示以監視訂用帳戶中所有失敗的相應縮小/相應放大自動調整作業。

除了使用活動記錄警示，您也可以透過自動調整規模設定上的 [通知] 索引標籤，來設定電子郵件或 Webhook 通知，在調整規模動作時收到通知。

使用 TLS 1.2 安全地傳送資料

為了確保資料傳送至 Azure 監視器時的安全性，我們強烈建議您將代理程式設定為至少使用傳輸層安全性 (TLS) 1.2。 我們已發現較舊的 TLS/安全通訊端層 (SSL) 版本容易遭到攻擊。 雖然其目前仍可允許回溯相容性，但我們「不建議」這麼做。 產業正在快速轉向放棄對這些舊版通訊協定的支援。

PCI 安全標準委員會已設定 2018 年 6 月 30 日作為最後期限，在此之後將停用舊版 TLS/SSL，並升級至更安全的通訊協定。 當 Azure 捨棄舊版支援後，如果您的代理程式無法透過 TLS 1.2 (至少) 進行通訊，就無法將資料傳送至 Azure 監視器記錄。

我們建議您「不要」明確地將代理程式設定為只使用 TLS 1.2，除非必要。 建議讓代理程式自動偵測、交涉及利用未來的安全性標準。 否則，您可能會遺漏較新標準的額外安全性，而且如果較新的標準已取代 TLS 1.2，也可能會遇到問題。

下一步