Azure 監視器中的成本最佳化
成本最佳化是指設法減少不必要的費用，並提升營運效率。 您可以了解不同設定選項和機會來減少 Azure 監視器收集的資料量，藉此大幅降低其成本。 使用本文之前，您應該先閱讀 Azure 監視器成本和使用量，以了解 Azure 監視器收費的不同方式，以及如何檢視每月帳單。
本文將說明 Azure 監視器的成本最佳化，而這屬於 Azure Well-Architected Framework 的一部分。 Azure Well-Architected Framework 是一組指導原則，可以用來提高工作負載的品質。 該架構包含五個卓越的架構要素：
Azure 監視器記錄
設計檢查清單
- 判斷是否要在相同的 Log Analytics 工作區中結合操作資料和安全性資料。
- 針對每個 Log Analytics 工作區通常收集的資料量設定定價層。
- 設定資料保留和封存。
- 將用於偵錯、疑難排解和稽核的資料表設定為基本記錄。
- 限制工作區從資料來源收集的資料。
- 定期分析收集的資料，以識別趨勢和異常狀況。
- 建立資料收集過高的警示。
- 考慮使用每日上限作為預防性措施，以確保您不會超過特定預算。
- 針對 Log Analytics 工作區設定 Azure Advisor 成本建議的警示。
組態建議
| 建議 |
優點 |
| 判斷是否要在相同的 Log Analytics 工作區中結合操作資料和安全性資料。 |
因為如果已啟用 Sentinel，則 Log Analytics 工作區中的所有資料都會受限於 Microsoft Sentinel 定價，因此合併此資料可能會對成本造成影響。 請參閱設計 Log Analytics 工作區策略，了解為環境制定此決策並與其他要素中準則達到平衡的詳細資料。 |
| 針對每個 Log Analytics 工作區通常收集的資料量設定定價層。 |
根據預設，Log Analytics 工作區會使用隨用隨付定價，沒有最低資料量。 如果您收集的資料量夠多，則可以使用承諾用量層來大幅降低成本，這可讓您藉由承諾每日最低的資料收集量來換取較低費率。 如果您在單一區域中的各個工作區上收集的資料夠多，您可以將這些工作區連結至專用叢集，並使用叢集定價來合併其收集的資料量。
請參閱 Azure 監視器記錄成本計算和選項，以取得關於定額層的詳細資料，以及最適合您使用量層級的階層判斷指引。 請參閱使用量和估計成本，以檢視不同定價層的使用量估計成本。 |
| 設定互動式和長期資料保留。 |
若在 Log Analytics 工作區中保留資料超過預設的 31 天則須付費 (在已啟用 Microsoft Sentinel 的工作區上為 90 天，而 Application Insights 資料也是 90 天)。 請考量您的特定需求，讓資料可方便記錄查詢使用。 您可以藉由設定長期保留來大幅降低成本，這可讓您將資料保留最多十二年，而且仍可使用搜尋作業或將一組資料還原至工作區來偶爾存取資料。 |
| 將用於偵錯、疑難排解和稽核的資料表設定為基本記錄。 |
Log Analytics 工作區中專為基本記錄設定的資料表可降低擷取成本，但功能有限，查詢記錄也會收費。 如果您不常查詢這些資料表，而且不會將其用於警示，此查詢成本可能會高於降低擷取成本抵銷的費用。 |
| 限制工作區從資料來源收集的資料。 |
Azure 監視器成本的主要因素是 Log Analytics 工作區中收集的資料量，因此您應確保收集的資料量不超過評估服務和應用程式健康情況和效能所需的資料。 請參閱設計 Log Analytics 工作區結構，了解為環境制定此決策並與其他要素中準則達到平衡的詳細資料。
權衡取捨：成本與監視需求之間可能會有所取捨。 例如，您可能能夠透過高採樣速率更快地偵測效能問題，但您可能也想要較低的採樣速率來節省成本。 大部分環境都會有多個不同收集類型的資料來源，因此您必須使特定需求與每個資料來源的成本目標達到平衡。 如需針對不同資料來源設定收集方式的建議，請參閱 Azure 監視器中的成本最佳化。 |
| 定期分析收集的資料，以識別趨勢和異常狀況。 |
使用 Log Analytics 工作區深入解析來定期檢閱工作區中收集的資料量。 此功能除了可協助您了解不同來源所收集的資料量之外，還會識別資料收集中可能導致成本過高的異常和上升趨勢。 使用分析 Log Analytics 工作區中的使用量中所述的方法，進一步分析資料收集，以判斷是否有其他設定可以進一步減少使用量。 當您新增一組新的資料來源 (例如一組新的虛擬機器或將新的服務上線) 時，這會特別重要。 |
| 建立資料收集過高的警示。 |
為了避免非預期的帳單，您應該在遇到過多使用量時主動收到通知。 通知可讓您在計費週期結束時，解決任何潛在的異常。 |
| 考慮使用每日上限作為預防性措施，以確保您不會超過特定預算。 |
每日上限會在達到您設定的限制之後，停用 Log Analytics 工作區中的資料收集。 這不應該當做降低成本的方法，如使用每日上限的時機中所述。
如果您設定每日上限，除了在達到上限時建立警示之外，請確定您也會建立警示規則，以在達到某個百分比時收到通知 (例如 90%)。 這可讓您在因為上限而停止資料收集之前，調查並解決資料增加的原因。 |
| 針對 Log Analytics 工作區設定 Azure Advisor 成本建議的警示。 |
當有機會將成本最佳化時，Log Analytics 工作區的 Azure Advisor 建議會主動提醒您。 針對下列成本建議建立 Azure Advisor 警示：- 請考慮在所選資料表上設定符合成本效益的基本記錄方案 - 我們已識別出每月擷取超過 1 GB 的資料表，這些資料表符合低成本基本記錄行動數據方案資格。 基本記錄方案可讓您查詢各項功能，以較低的成本進行偵錯和疑難排解。
- 請考慮變更定價層- 根據您的目前使用量，調查變更您的定價 (承諾用量) 層以接收折扣並降低成本。
- 請考慮移除未使用的還原資料表 - 您在工作區中啟用了一或多個具有已還原資料的資料表。 如果您不再使用還原的資料，請刪除資料表以避免不必要的費用。
- 偵測到資料擷取異常 - 我們已根據您在前三週的擷取，發現過去一週的擷取率要高得多。 請記下這項變更，以及成本的預期變更。
您也可以從 Log Analytics 工作區資源功能表中選取 [概觀]>[建議] 或 [Advisor 建議] 來檢視自動產生的建議。 |
Azure 資源
設計檢查清單
組態建議
| 建議 |
優點 |
| 僅從 Azure 資源收集重要的資源記錄資料。 |
當您建立診斷設定來將 Azure 資源的資源記錄傳送至 Log Analytics 資料庫時，只指定您需要的類別。 診斷設定不支援資源記錄的細微篩選，但您可以使用工作區轉換，針對使用支援資料表的資源進行篩選，以篩選不必要的資料。 如需如何設定診斷設定和使用轉換來篩選資料的詳細資訊，請參閱 Azure 監視器中的診斷設定。 |
警示
設計檢查清單
- 活動記錄警示、服務健康情況警示和資源健康情況警示是免費的。
- 使用記錄搜尋警示時，請將記錄搜尋警示頻率降至最低。
- 使用計量警示時，請將所監視的資源數目降至最低。
組態建議
| 建議 |
優點 |
| 請記住，活動記錄警示、服務健康情況警示和資源健康情況警示是免費的。 |
Azure 監視器活動警示、服務健康情況警示和資源健康情況警示是免費的。 如果這些警示類型可達到您的監視目的，請使用這些類型。 |
| 使用記錄搜尋警示時，請將記錄搜尋警示頻率降至最低。 |
設定記錄搜尋警示時，請記住評估規則的頻率越高，成本就越高。 請據以設定規則。 |
| 使用計量警示時，請將所監視的資源數目降至最低。 |
某些資源類型支援計量警示規則，這些規則可以監視相同類型的多個資源。 針對這些資源類型，請記住，如果規則監視許多資源，規則的成本可能會提高。 若要降低成本，您可以縮小計量警示規則的範圍，或使用記錄搜尋警示規則，這麼做可降低監視大量資源的成本。 |
虛擬機器
設計檢查清單
- 從 Log Analytics 代理程式遷移至 Azure 監視器代理程式，以進行細微的資料篩選。
- 從代理程式篩選不需要的資料。
- 判斷是否要使用 VM 深入解析及要收集的資料。
- 減少效能計數器的輪詢頻率。
- 確定 VM 不會傳送重複的資料。
- 使用 Log Analytics 工作區深入解析來分析可計費的成本，並找出節省成本的機會。
- 將您的 SCOM 環境遷移至 Azure 監視器 SCOM 受控執行個體。
組態建議
| 建議 |
描述 |
| 從 Log Analytics 代理程式遷移至 Azure 監視器代理程式，以進行細微的資料篩選。 |
如果您仍有使用 Log Analytics 代理程式的 VM，請將其遷移至 Azure 監視器代理程式，以利用更好的資料篩選功能，並搭配不同的 VM 集合使用獨特設定。 Log Analytics 代理程式的資料收集設定會在工作區上完成，因此所有代理程式都會接收到相同的設定。 Azure 監視器代理程式使用的資料收集規則可以根據不同 VM 集合的特定監視需求進行調整。 Azure 監視器代理程式也可讓您使用轉換來篩選所收集的資料。 |
| 從代理程式篩選不需要的資料。 |
篩選您不用於警示或分析的資料，以減少資料擷取成本。 請參閱使用 Azure 監視器監視虛擬機器：收集資料，了解如何針對不同監視案例收集資料，並請參閱控制成本，取得篩選資料以降低成本的特定指引。 |
| 判斷要使用 VM 深入解析收集哪些資料。 |
VM 深入解析是一項絕佳的功能，可快速開始監視您的 VM，並提供強大的功能，例如對應和效能趨勢檢視。 如果您未使用對應功能或其收集的資料，則應該停用 VM 深入解析設定中的程序和相依性資料收集，以節省資料擷取成本。 |
| 減少效能計數器的輪詢頻率。 |
如果您使用資料收集規則傳送效能資料至 Log Analytics 工作區，您可以減少其輪詢頻率，以減少收集的資料量。 |
| 確定 VM 不會傳送重複的資料。 |
如果您將代理程式設為多宿主或建立類似的資料收集規則，請務必將唯一資料傳送至每個工作區。 如需對所收集資料進行分析的相關指引，請參閱在 Log Analytics 工作區中分析使用量，以確保您不會收集重複的資料。 如果您在代理程式之間遷移，請繼續使用 Log Analytics 代理程式，直到您遷移至 Azure 監視器代理程式，而不是同時使用這兩者，除非您可以確保每個代理程式都是收集唯一的資料。 |
| 使用 Log Analytics 工作區深入解析來分析可計費的成本，並找出節省成本的機會。 |
Log Analytics 工作區深入解析會顯示每個資料表中和從每個 VM 中收集的可計費資料。 請使用此資訊來識別您的最上層機器和資料表，因為其代表您可藉由篩選資料來降低成本的最佳機會。 使用此深入解析和分析 Log Analytics 工作區中的使用量中的記錄查詢，進一步分析設定變更的影響。 |
| 將您的 SCOM 環境遷移至 Azure 監視器 SCOM 受控執行個體。 |
將現有的 SCOM 環境遷移至 Azure 監視器 SCOM 受控執行個體，以支援任何無法由 Azure 監視器取代的管理組件。 SCOM 受控執行個體不需要維護本機管理伺服器和資料庫伺服器，可降低維護 SCOM 基礎結構的整體成本。 |
容器
設計檢查清單
- 透過 Azure 監視器適用於 Prometheus 的受管理服務啟用計量收集。
- 設定代理程式收集以修改容器深入解析中的資料收集。
- 依容器深入解析修改計量資料的收集設定。
- 如果您未在 Azure 入口網站中使用容器深入解析體驗，請停用計量資料的容器深入解析收集。
- 如果您未定期查詢容器記錄資料表，或將其用於警示，請將其設定為基本記錄。
- 限制非必要資源記錄的收集。
- 使用 AKS 資源記錄的資源專屬記錄，並將資料表設定為基本記錄。
- 使用 OpenCost 收集 Kubernetes 成本的詳細資料。
組態建議
| 建議 |
優點 |
| 透過 Azure 監視器適用於 Prometheus 的受管理服務啟用計量收集。 請確認不要同時將 Prometheus 計量傳送至 Log Analytics 工作區。 |
您可以藉由啟用受控 Prometheus，使用 Azure 監視器適用於 Prometheus 的受管理服務，從叢集抓取 Prometheus計量。 請注意，您可以設定容器深入解析來收集Log Analytics工作區中的 Prometheus 計量，但不建議這麼做，因為受控 Prometheus 中的資料是多餘的，且將會產生額外的成本。 如需詳細資訊，請參閱受控 Prometheus 定價。 |
| 設定代理程式以修改容器深入解析中的資料收集。 |
分析容器深入解析收集的資料，如最佳化容器深入解析的監視成本中所述，並調整您的設定，以停止收集不需要的資料。 |
| 依容器深入解析修改計量資料的收集設定。 |
若要深入了解如何修改計量資料收集的頻率和容器深入解析所收集的命名空間，請參閱啟用成本最佳化設定。 |
| 如果您未在 Azure 入口網站中使用容器深入解析體驗，請停用計量資料的容器深入解析收集。 |
容器深入解析會收集許多與受控 Prometheus 相同的計量值。 若要停用這些計量的收集，您可以將容器深入解析設定為只收集記錄和事件，如在容器深入解析中啟用成本最佳化設定中所述。 此設定會停用 Azure 入口網站中的容器深入解析體驗，但您可以使用 Grafana 將 Prometheus 計量和 Log Analytics 視覺化，以分析容器深入解析所收集的記錄資料。 |
| 如果您未定期查詢容器記錄資料表，或將其用於警示，請將其設定為基本記錄。 |
將您的容器深入解析結構描述轉換為 ContainerLogV2，其可與基本記錄相容，而且可以節省大量成本，如最佳化容器深入解析的監視成本中所述。 |
| 限制非必要資源記錄的收集。 |
AKS 叢集的控制平面記錄會實作為 Azure 監視器中的資源記錄。 建立診斷設定以將此資料傳送至 Log Analytics 工作區。 如需您應該收集哪些類別的建議，請參閱收集 AKS 叢集的控制平面記錄。 |
| 使用 AKS 資源記錄的資源專屬記錄，並將資料表設定為基本記錄。 |
AKS 可支援資源記錄的 Azure 診斷模式或資源專屬模式。 指定資源記錄以啟用針對基本記錄設定資料表的選項，這可針對偶爾查詢且不會用於警示的記錄減少擷取費用。 |
| 使用 OpenCost 收集 Kubernetes 成本的詳細資料。 |
OpenCost 是開放原始碼的廠商中立 CNCF 沙箱專案，可讓您了解 Kubernetes 成本，並可支援 AKS 成本可見度。 其可將客戶專屬的 Azure 定價和詳細的成本資料匯出至 Azure 儲存體，以協助叢集管理員分析及分類成本。 |
Application Insights
設計檢查清單
- 變更為工作區型 Application Insights。
- 使用取樣來調整收集的資料量。
- 限制 Ajax 呼叫的數目。
- 停用不必要的模組。
- 預先彙總來自任何 TrackMetric 呼叫的計量。
- 盡可能限制使用自訂計量。
- 確定使用更新的軟體開發套件 (SDK)。
- 使用記錄層級限制不需要的主機追蹤和一般追蹤記錄。
組態建議
| 建議 |
優點 |
| 變更為工作區型 Application Insights。 |
請確定您的 Application Insights 資源是以工作區為基礎。 工作區型 Application Insights 資源可以套用新的成本節省工具，例如基本記錄、承諾用量層，以及依資料類型保留和長期保留。 |
| 使用取樣來調整收集的資料量。 |
取樣是您可用來調整 Application Insights 所收集資料量的主要工具。 使用取樣來減少從應用程式傳送的遙測量，這對計量的扭曲程度最小。 |
| 限制 Ajax 呼叫的數目。 |
限制可回報的 Ajax 呼叫次數 (在每個頁面檢視中)，或停用 Ajax 報告功能。 如果您停用 Ajax 呼叫，也會停用 JavaScript 相互關聯。 |
| 停用不必要的模組。 |
編輯 ApplicationInsights.config以關閉您不需要的集合模組。 例如，您可能會決定效能計數器或相依性資料是不必要的。 |
| 預先彙總來自任何 TrackMetric 呼叫的計量。 |
如果您在應用程式中呼叫 TrackMetric，便可以使用接受一批測量之平均及標準差計算的多載來減少流量。 或者，您也可以使用預先彙總套件。 |
| 限制自訂計量的使用。 |
Application Insights 選項 [啟用自訂計量維度的警示] 可能會增加成本。 使用此選項可能會導致額外建立預先彙總計量。 |
| 確定使用更新的軟體開發套件 (SDK)。 |
舊版的 ASP.NET Core SDK 和背景工作角色服務 SDK 預設會收集許多計數器，這些計數器會收集作為自訂計量。 使用更新版本僅指定必要的計數器。 |
| 限制不必要的追蹤記錄。 |
Application Insights 有數個可能的記錄來源。 記錄層級可用來微調和減少追蹤記錄遙測。 記錄也可以套用至主機。 例如，使用 Azure Kubernetes Service (AKS) 的客戶應該調整控制平面和資料平面記錄。 同樣地，使用 Azure 函式的客戶應該調整記錄層級和範圍 ，以將記錄量和成本最佳化。 |
後續步驟