在 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 相同，視自訂計量的磁碟區而定。
在具有更多資源的節點集區上排程 ama-metrics 複本 Pod
每個 Pod 的大量計量都需要具有足夠 CPU 和記憶體的節點。 如果 ama-metrics 複本 Pod 未排程在具有足夠資源的節點或節點集區上，它可能會得到 OOMKilled 並進入 CrashLoopBackoff。 若要修正此問題，您可以將標籤azuremonitor/metrics.replica.preferred=true新增至叢集上具有較高資源的節點或節點集區（在系統節點集區中）。 這可確保複本 Pod 會在該節點上排程。 您也可以建立具有較大節點的額外系統集區，並新增相同的標籤。 最好為節點集區加上標籤，而不是個別節點，讓集區中的新節點也可用於排程。
kubectl label nodes <node-name> azuremonitor/metrics.replica.preferred="true"