在 Azure Monitor 中大规模抓取 Prometheus 指标
本文提供大规模收集适用于 Prometheus 的 Azure Monitor 托管服务的指标时预期的性能指导。
CPU 和内存
CPU 和内存使用量与每个样本的字节数和抓取的样本数相关。 这些基准基于抓取的默认目标、抓取的自定义指标量，以及节点、pod 和容器的数量。 这些数字仅供参考，因为根据时序数量和每个指标的字节数，使用量仍可能存在很大的差异。
每个 pod 的容量上限目前大约为每分钟 300 万到 350 万个样本，具体取决于每个样本的字节数。 将来添加分片时，将解决此限制。
代理由一个部署组成，该部署带有一个用于抓取指标的副本和 DaemonSet。 DaemonSet 可抓取任何节点级目标，例如 cAdvisor、kubelet 和节点导出程序。 还可以使用静态配置将它配置为抓取节点级别的任何自定义目标。 副本集抓取其他所有内容，例如 kube-state-metrics 或利用服务发现的自定义抓取作业。
小型和大型副本群集的比较
| 抓取目标 | 发送的样本数/分钟 | 节点计数 | Pod 计数 | Prometheus-Collector CPU 使用量（核心数） | Prometheus-Collector 内存使用量（字节） |
|---|---|---|---|---|---|
| 默认目标 | 11,344 | 3 | 40 | 12.9 mc | 148 Mi |
| 默认目标 | 260,000 | 340 | 13000 | 1.10 c | 1.70 GB |
| 默认目标 + 自定义目标 |
356 万 | 340 | 13000 | 5.13 c | 9.52 GB |
小型和大型 DaemonSet 群集的比较
| 抓取目标 | 发送的样本总数/分钟 | 发送的样本数/分钟/Pod | 节点计数 | Pod 计数 | Prometheus-Collector CPU 使用量总计（核心数） | Prometheus-Collector 内存使用量总计（字节） | Prometheus-Collector CPU 使用量/Pod（核心数） | Prometheus-Collector 内存使用量/Pod（字节） |
|---|---|---|---|---|---|---|---|---|
| 默认目标 | 9,858 | 3,327 | 3 | 40 | 41.9 mc | 581 Mi | 14.7 mc | 189 Mi |
| 默认目标 | 230 万 | 14,400 | 340 | 13000 | 805 mc | 305.34 GB | 2.36 mc | 898 Mi |
对于其他自定义指标，单个 pod 的行为与副本 pod 相同，具体取决于自定义指标的数量。
在具有更多资源的节点池上计划 ama-metrics 副本 pod
需要使用一个具有足够 CPU 和内存的节点来保存每个 pod 的大量指标。 如果未将 ama-metrics 副本 pod 调度到具有足够资源的节点或节点池中，则它可能会发生 OOMKilled 并进入 CrashLoopBackoff 状态。 若要修复此问题，可以将标签 azuremonitor/metrics.replica.preferred=true 添加到群集中具有更多资源的节点或节点池（在系统节点池中）。 这可确保将副本 pod 调度到该节点上。 你也可以创建具有更大节点的附加系统池，并添加相同的标签。 最好标记节点池而不是单个节点，以便池中的新节点也可用于调度。
kubectl label nodes <node-name> azuremonitor/metrics.replica.preferred="true"