適用於 Prometheus 的 Azure 監視器受管理服務，可讓您大規模收集和分析計量。 Prometheus 計量會儲存在 Azure 監視器工作區中。 工作區支援各種分析工具 (例如 Azure 受控 Grafana)、搭配 PromQL 的 Azure 監視器計量瀏覽器，以及開放原始碼工具 (例如 PromQL 和 Grafana)。
本文提供最佳做法來組織化您的 Azure 監視器工作區，以符合您的規模需求及不斷增加的資料擷取量。
拓撲設計準則
單一 Azure 監視器工作區就足以用於許多使用案例。 有些組織會建立多個工作區，以便更符合其需求。 當您確定建立其他工作區的正確準則時，您請建立符合您需求的最低數量工作區，同時針對最小系統管理額外負荷進行最佳化。
以下是必須將 Azure 監視器工作區分割成多個工作區的案例：
| 狀況 | 最佳做法 |
|---|---|
| 主權雲端 | 使用多個主權雲端時，請在每個雲端建立 Azure 監視器工作區。 |
| 合規性或法規需求 | 如果您受限於規定在特定區域中儲存資料的法規，請根據需求為每個區域建立 Azure 監視器工作區。 |
| 區域性調整 | 當您管理多區域組織的計量時，例如具有區域帳戶的大型服務或金融機構，請為每個區域建立 Azure 監視器工作區。 |
| Azure 租用戶 | 針對多個 Azure 租用戶，請在每個租用戶中建立 Azure 監視器工作區。 不支援跨租戶資料查詢。 |
| 部署環境 | 為每個部署環境建立個別的工作區，以維護開發、測試、生產前和生產環境的離散計量。 |
| 服務限制與配額 | Azure 監視器工作區具有預設擷取限制，您可開啟支援票證來提高上限。 如果您接近上限，或估計將超過擷取上限，請考慮要求增加或將工作區分割成兩個以上的工作區。 |
服務限制與配額
Azure 監視器工作區的計量設有預設配額和限制：每分鐘擷取一百萬個事件。 隨著使用量增長，當您需要擷取更多指標時，您可以要求增加。 如果您的容量需求特別大，且資料擷取需求即將超過單一 Azure 監視器工作區的限制，請考量建立多個 Azure 監視器工作區。 使用 Azure 監視器工作區平台計量來監視使用率和限制。 如需限制和配額的詳細資訊，請參閱 Azure 監視器服務限制和配額。
請考慮下列管理 Azure 監視器工作區限制和配額的最佳做法：
| 最佳做法 | 說明 |
|---|---|
| 監視擷取限制和使用率並建立相關警示。 | 在 Azure 入口網站中，瀏覽至您的 Azure 監視器工作區。 移至 [計量]，並確認計量 [啟用時間序列百分比使用率] 和 [每分鐘事件擷取百分比使用率] 都低於 100%。 設定 Azure 監視器警示來監視使用率，並在使用率大於 80% 的限制時引發警示。 如需監視使用率和限制的詳細資訊，請參閱如何監視服務限制和配額。 |
| 當使用率超過目前限制的 80% 時，要求增加限制。 | 隨著 Azure 使用率的增長，擷取的資料量也可能隨之增加。 如果您的資料擷取超過或接近 80% 的擷取限制，建議您要求增加限制。 若要要求增加限制，請參閱 要求增加擷取限制。 |
| 估算您的預測規模。 | 隨著您的使用率增長，您會擷取更多計量到工作區，請估算預測的規模和成長率。 根據您的預測，要求提高限制。 |
| 使用 Azure 監視器側車容器搭配遠端寫入來擷取。 | 如果您使用 Azure 監視器側車容器和遠端寫入，將計量擷取到 Azure 監視器工作區，請考慮下列限制： |
| DCR/DCE 限制。 | 這些限制會套用至將 Prometheus 計量傳送至 Azure 監視器工作區的資料收集規則 (DCR) 和資料收集端點 (DCE)。 若要監視這些限制，請參閱 檢視和監視 DCR 限制。 這些限制無法增加。 請考慮建立其他 DCR 和 DCE，將擷取負載分散到多個端點。 這種方法有助於最佳化效能，並確保資料處理效率。 如需建立 DCR 和 DCE 的詳細資訊，請參閱 如何為現有的 Azure 監視器工作區建立自定義數據收集端點（DCE）和自定義數據收集規則（DCR），以內嵌 Prometheus 計量。 |
最佳化大量資料的效能
擷取
若要最佳化擷取，請考慮下列最佳做法：
| 最佳做法 | 說明 |
|---|---|
| 識別高基數計量。 | 識別有高基數的計量，或產生許多時間序列的計量。 Azure 監視器工作區計量使用洞察 提供有關時間序列和事件使用量的資訊，以供計量使用和成本優化之參考。 識別高基數指標後，通過移除不必要的標籤來最佳化它們，以減少時間序列的數量。 |
| 使用 Prometheus 設定以最佳化資料引入。 | Azure 受控 Prometheus 提供 Configmap，您可以設定其中所含的設定並用來最佳化擷取。 如需詳細資訊，請參閱 ama-metrics-settings-configmap 和 ama-metrics-prometheus-config-configmap。 這些設定所遵循的格式與 Prometheus 設定檔相同。 如需自訂集合的相關資訊，請參閱在適用於 Prometheus 的 Azure 監視器受管理服務中自訂抓取 Prometheus 計量。 例如，請考慮下列事項： scrape_interval 和 scrape_timeout。metric_relabel_configs 從擷取卸除特定標籤。 如需詳細資訊，請參閱 Prometheus 設定。 |
使用 configmap、視需要變更設定，並將 configmap 套用至叢集的 kube 系統命名空間。 如果您使用遠端寫入和 Azure 監視器工作區，請在 Prometheus 設定中直接套用擷取期間自訂。
查詢
若要最佳化查詢，請考慮下列最佳做法：
使用錄製規則將查詢效能最佳化
Prometheus 錄製規則可用來預先計算常用或計算成本昂貴的查詢，使其更有效率且更快速地進行查詢。 錄製規則特別適用於大量計量，其中查詢原始資料可能會很慢且需要大量資源。 如需詳細資訊，請參閱錄製規則。 Azure Managed Prometheus 提供受控且可調整的方式，透過 Azure 受控 Prometheus 規則群組的協助，建立和更新錄製規則。
建立規則群組之後，Azure 受控 Prometheus 就會自動載入並開始評估它們。 從 Azure 監視器工作區查詢規則群組，例如其他 Prometheus 計量。
錄製規則有下列優點：
改善查詢效能 錄製規則可用來預先計算複雜的查詢，使其更快速地稍後進行查詢。 預先計算複雜的查詢可在查詢這些計量時減少 Prometheus 上的負載。
效率與縮短查詢時間 錄製規則會預先計算查詢結果，以減少查詢數據所花費的時間。 這特別適用於有多個面板的儀表板或高基數計量。
單純 錄製規則可簡化 Grafana 或其他視覺效果工具中的查詢，因為它們可以參考預先計算的計量。
下列範例顯示 Azure 受控 Prometheus 規則群組中所定義的錄製規則：
"record": "job:request_duration_seconds:avg ",
"expression": "avg(rate(request_duration_seconds_sum[5m])) by (job)",
"labels": { "workload_type": "job"
},
"enabled": true
若為更複雜的計量，請建立可彙總多個計量或執行更高階計算的錄製規則。 在下列範例中，instance:node_cpu_utilisation:rate5m 會計算 CPU 未閒置時的 CPU 使用率
"record": "instance:node_cpu_utilisation:rate5m",
"expression": "1 - avg without (cpu) (sum without (mode)(rate(node_cpu_seconds_total{job=\"node\", mode=~\"idle|iowait|steal\"}[5m])))",
"labels": {
"workload_type": "job"
},
"enabled": true
請考慮下列最佳化錄製規則的最佳做法：
| 最佳做法 | 說明 |
|---|---|
| 識別大量計量。 | 著重於經常查詢且有高基數的計量。 |
| 最佳化規則評估間隔。 | 若要在資料有效期限與計算負載之間取得平衡，請調整錄製規則的評估間隔。 |
| 監視效能。 | 監視查詢效能，並視需要調整錄製規則。 |
| 限制範圍以最佳化規則。 | 若要加快錄製規則的速度，請將它們限制在特定叢集的範圍內。 如需詳細資訊，請參閱將規則限制為特定叢集。 |
在查詢中使用篩選
使用篩選來最佳化 Prometheus 查詢必須精簡查詢，只傳回必要的資料、減少處理的資料量並改善效能。 以下是精簡 Prometheus 查詢的一些常見技巧。
| 最佳做法 | 說明 |
|---|---|
| 使用標籤篩選。 | 標籤篩選有助於將資料縮小到您所需的範圍。 Prometheus 允許您使用 {label_name="label_value"} 語法進行篩選。 如果您在多個叢集上擁有大量計量，則限制時間序列的簡單方式就是使用 cluster 篩選。例如，不要查詢 container_cpu_usage_seconds_total，而是依叢集篩選 container_cpu_usage_seconds_total{cluster="cluster1"}。 |
| 套用時間範圍選取器。 | 使用特定時間範圍可大幅減少查詢的資料量。 例如，不要查詢過去七天的所有資料點 http_requests_total{job="myapp"}，而是使用 http_requests_total{job="myapp"}[1h] 查詢最後一小時的資料點。 |
| 使用彙總與分組。 | 彙總函式可用來摘要資料，比處理原始資料點更有效率。 彙總資料時，請使用 by 依特定標籤分組，或使用 without 來排除特定標籤。例如，按作業分組的總和請求： sum(rate(http_requests_total[5m])) by (job)。 |
| 在查詢中及早篩選。 | 若要從一開始就限制資料，請盡早在查詢中套用篩選。 例如，與其使用 sum(rate(http_requests_total[5m])) by (job)，不如先篩選，然後彙總：sum(rate(http_requests_total{job="myapp"}[5m])) by (job)。 |
| 盡可能不要使用 regex。 | Regex 篩選功能很強大，但計算成本也很高。 請盡可能使用完全相符。 例如，不使用 http_requests_total{job=~"myapp.*"}，而是使用 http_requests_total{job="myapp"}。 |
| 對歷程記錄資料使用 offset。 | 如果您要比較目前的資料與歷程記錄資料，請使用 offset 修飾元。例如，若要比較目前的要求與 24 小時前的要求，請使用 rate(http_requests_total[5m]) - rate(http_requests_total[5m] offset 24h)。 |
| 限制圖表中的資料點數目。 | 建立圖表時，請限制資料點數目，以改善呈現效能。 使用步驟參數來控制解析度。 例如，在 Grafana 中：設定較高的步驟值以減少資料點數目： http_requests_total{job="myapp"}[1h:10s]。 |
平行查詢
在 Prometheus 中執行大量平行查詢可能會造成效能瓶頸，而且會影響 Prometheus 伺服器的穩定性。 若要有效率地處理大量平行查詢，請遵循下列最佳做法：
| 最佳做法 | 說明 |
|---|---|
| 分散查詢負載。 | 將查詢分散到不同的時間間隔或 Prometheus 執行個體，藉此分散查詢負載。 |
| 交錯查詢。 | 排程查詢以不同的間隔執行，避免產生同時查詢執行尖峰。 |
如果您在執行許多平行查詢時仍有問題，請建立支援票證以要求增加查詢限制。
警示和錄製規則
最佳化高延展性的警示和錄製規則
Prometheus 警示和錄製規則可以定義為 Prometheus 規則群組。 一個規則群組最多可以包含 20 個警示或錄製規則。 為每個工作區建立最多 500 個規則群組，以容納所需的警示/規則數目。 若要提高此限制，請開啟支援票證
定義錄製規則時，請考慮評估間隔，以最佳化每個規則的時間序列數目和規則評估的效能。 評估間隔可以介於 1 分鐘到 24 小時之間。 預設為 1 分鐘。
使用「資源健康狀態」來檢視錄製規則狀態的查詢
設定「資源健康狀態」，以在入口網站中檢視 Prometheus 規則群組的健康情況。 「資源健康狀態」可讓您偵測錄製規則中的問題，例如不正確的設定或查詢節流問題。 如需設定資源健康狀態的詳細資訊，請參閱 檢視 Prometheus 規則群組的資源健康狀態。