在 Azure 監視器中大規模抓取 Prometheus 計量
本文提供針對 Prometheus 的 Azure 監視器受控服務大規模收集計量時可預期的效能指導。
CPU 和記憶體
CPU 和記憶體使用量會與每個樣本的位元組數目和所抓取的樣本數目相互關聯。 這些基準測試是以已抓取的預設目標、已抓取的自訂計量數量，以及節點、Pod 和容器的數目。 這些數字用來作為參考，因為使用量仍然會根據每個計量的時間序列和位元組數目而有很大的差異。
每個 Pod 的磁碟區上限目前大約是每分鐘 3-3.5 百萬個樣本，視每個樣本的位元組數目而定。 未來新增分區化時，會解決這項限制。
代理程式包含具有一個複本和 DaemonSet 來抓取計量的部署。 DaemonSet 會抓取任何節點層級目標 (例如 cAdvisor、kubelet 和節點匯出工具)。 您也可以將其設定為使用靜態設定來抓取節點層級的任何自訂目標。 複本集會抓取其他所有項目 (例如 kube-state-metrics) 或可利用服務探索的自訂抓取作業。
複本的小型與大型叢集之間的比較
| 抓取目標 | 已傳送的樣本/分鐘 | 節點計數 | Pod 計數 | Prometheus-收集器 CPU 使用量 (核心) | Prometheus-收集器記憶體使用量 (位元組) |
|---|---|---|---|---|---|
| 預設目標 | 11,344 | 3 | 40 | 12.9 mc | 148 Mi |
| 預設目標 | 260,000 | 340 | 13000 | 1.10 c | 1.70 GB |
| 預設目標 + 自訂目標 |
3.56 百萬 | 340 | 13000 | 5.13 c | 9.52 GB |
DaemonSet 的小型與大型叢集之間的比較
| 抓取目標 | 已傳送的樣本/分鐘總計 | 已傳送的樣本/分鐘/Pod | 節點計數 | Pod 計數 | Prometheus-收集器 CPU 使用量總計 (核心) | Prometheus-收集器記憶體使用量總計 (位元組) | Prometheus-收集器 CPU 使用量/Pod (核心) | Prometheus-收集器記憶體使用量/Pod (位元組) |
|---|---|---|---|---|---|---|---|---|
| 預設目標 | 9,858 | 3,327 | 3 | 40 | 41.9 mc | 581 Mi | 14.7 mc | 189 Mi |
| 預設目標 | 2.3 百萬 | 14,400 | 340 | 13000 | 805 mc | 305.34 GB | 2.36 mc | 898 Mi |
如需更多自訂計量，單一 Pod 的行為會與複本 Pod 相同，視自訂計量的磁碟區而定。
在具有更多資源的 nodepool 上排程 ama-metrics 複本 Pod
每個 Pod 的大量計量需要足夠大的節點，才能處理所需的 CPU 和記憶體使用量。 如果未在具有足夠資源的節點或 nodepool 上排程 ama-metrics 複本集 Pod，則可能會持續取得 OOMKilled，並移至 CrashLoopBackoff。 為了克服此問題，如果您的叢集上有較高資源的節點或 nodepool (在系統 nodepool 中)，而且想要在該節點上排程複本，則您可以在節點上新增標籤 azuremonitor/metrics.replica.preferred=true，而且將會在此節點上排程複本集 Pod。 此外，您也可以視需要建立其他系統集區，並具有較大的節點，而且可以將相同的標籤新增至其節點或 nodepool。 您也可以將標籤新增至 nodepool，而不是節點，因此，當此標籤適用於集區中的所有節點時，也可以使用相同集區中的較新節點進行排程。
kubectl label nodes <node-name> azuremonitor/metrics.replica.preferred="true"