Výstřižky metrik Prometheus ve velkém měřítku ve službě Azure Monitor
Tento článek obsahuje pokyny k výkonu, které se dají očekávat, když se metriky shromažďování ve velkém měřítku pro spravovanou službu Azure Monitor pro Prometheus dají očekávat.
Procesor a paměť
Využití procesoru a paměti koreluje s počtem bajtů každého vzorku a počtem vzorků sešrotovaných. Tyto srovnávací testy jsou založené na výchozích cílech sešrotovaných, objemech vlastních metrik a počtu uzlů, podů a kontejnerech. Tato čísla jsou určená jako odkaz, protože využití se může výrazně lišit v závislosti na počtu časových řad a bajtů na metrice.
Horní limit objemu na pod je v současné době přibližně 3–3,5 milionu vzorků za minutu v závislosti na počtu bajtů na vzorek. Toto omezení se řeší při přidání horizontálního dělení v budoucnu.
Agent se skládá z nasazení s jednou replikou a procesem DaemonSet pro metriky scrapování. DaemonSet sešrotuje všechny cíle na úrovni uzlů, jako jsou cAdvisor, kubelet a exportér uzlů. Můžete ho také nakonfigurovat tak, aby se šrotily jakékoli vlastní cíle na úrovni uzlu pomocí statických konfigurací. Sada replik šrotuje všechno ostatní, například kube-state-metrics nebo vlastní úlohy výstřižků, které využívají zjišťování služeb.
Porovnání malých a velkých clusterů pro repliku
Výstřižky cílů | Odeslané ukázky / minuta | Počet uzlů | Počet podů | Využití procesoru kolektoru Prometheus (jádra) | Využití paměti kolektoru Prometheus (bajty) |
---|---|---|---|---|---|
výchozí cíle | 11,344 | 3 | 40 | 12,9 mc | 148 Mi |
výchozí cíle | 260,000 | 340 | 13000 | 1.10 c | 1,70 GB |
výchozí cíle + vlastní cíle |
3,56 milionu | 340 | 13000 | 5.13 c | 9,52 GB |
Porovnání malých a velkých clusterů pro daemonSets
Výstřižky cílů | Odeslané vzorky / minuta celkem | Ukázky odeslané / minuta / pod | Počet uzlů | Počet podů | Celkové využití procesoru kolektoru Prometheus (jádra) | Celkové využití paměti kolektoru Prometheus (bajty) | Využití procesoru kolektoru Prometheus / Pod (jádra) | Využití paměti kolektoru Prometheus / Pod (bajty) |
---|---|---|---|---|---|---|---|---|
výchozí cíle | 9,858 | 3,327 | 3 | 40 | 41,9 mc | 581 Mi | 14,7 mc | 189 Mi |
výchozí cíle | 2,3 milionu | 14,400 | 340 | 13000 | 805 mc | 305,34 GB | 2,36 mc | 898 Mi |
U dalších vlastních metrik se jeden pod chová stejně jako pod repliky v závislosti na objemu vlastních metrik.
Naplánování podu repliky ama-metrics ve fondu uzlů s dalšími prostředky
Velký objem metrik na pod potřebuje uzel s dostatečným využitím procesoru a paměti. Pokud pod repliky ama-metrics není naplánovaný v uzlu nebo fondu uzlů s dostatečnými prostředky, může se dostat do OOMKilled a přejít do CrashLoopBackoff. Pokud chcete tento problém vyřešit, můžete ho azuremonitor/metrics.replica.preferred=true
přidat do uzlu nebo fondu uzlů v clusteru s vyšším počtem prostředků (ve fondu systémových uzlů). Tím zajistíte, že pod repliky se na tomto uzlu naplánuje. Můžete také vytvořit další systémové fondy s většími uzly a přidat stejný popisek. Je lepší označit fondy uzlů spíše než jednotlivé uzly, aby se nové uzly ve fondu mohly použít i pro plánování.
kubectl label nodes <node-name> azuremonitor/metrics.replica.preferred="true"
Další kroky
- Řešení potíží se shromažďováním dat Prometheus