本文介绍对适用于 Prometheus 的 Azure Monitor 托管服务大规模收集指标时可以预期的性能指南。
CPU 和内存
CPU 和内存使用量与每个样本的字节数和抓取的样本数相关。 这些基准基于抓取的默认目标、抓取的自定义指标量，以及节点、pod 和容器的数量。 这些数字仅供参考，因为根据时序数量和每个指标的字节数，使用量仍可能存在很大的差异。
每个 pod 的容量上限目前大约为每分钟 300 万到 350 万个样本，具体取决于每个样本的字节数。
代理由默认包含两个副本的部署（它将根据内存利用率自动由 HPA 配置）和用于擦除指标的 DaemonSet 组成。 DaemonSet 可抓取任何节点级目标，例如 cAdvisor、kubelet 和 Node Exporter。 你也可以通过静态配置，在节点级别配置它以抓取任何自定义目标。 副本集会抓取其他所有内容，例如 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 毫克 | 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"