在 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
如果每个 pod 存在大量指标，则需要配置足够大的节点才能处理所需的 CPU 和内存使用量。 如果不在具有足够资源的节点或节点池上计划 ama-metrics 副本 pod，该 pod 可能会持续收到 OOMKilled 并进入 CrashLoopBackoff 状态。 为了克服此问题，如果群集上某个节点或节点池具有较多的资源（在系统节点池中）并且你想要在该节点上计划副本，可以在该节点上添加标签 azuremonitor/metrics.replica.preferred=true，这样就会在此节点上计划副本 pod。 如果需要，你还可以创建具有较大节点的其他系统池，并可以将相同的标签添加到其节点或节点池。 此外，最好将标签添加到节点池，而不是节点，这样，如果此标签适用于池中的所有节点，则同一池中的较新节点也可用于计划。
kubectl label nodes <node-name> azuremonitor/metrics.replica.preferred="true"