Scrape Prometheus metriky ve velkém měřítku ve službě Azure Monitor
Tento článek obsahuje pokyny k výkonu, který lze očekávat při shromažďování metrik ve velkém měřítku pro spravovanou službu Azure Monitor pro Prometheus.
Procesor a paměť
Využití procesoru a paměti koreluje s počtem bajtů každého vzorku a počtem odebraných vzorků. Tyto srovnávací testy jsou založené na výchozích cílech oškrábaných, objemu oškrábaných vlastních metrik a počtu uzlů, podů a kontejnerů. Tato čísla jsou míněná jako reference, protože využití se stále může výrazně lišit v závislosti na počtu časových řad a bajtů na metriku.
Horní limit objemu na pod je v současné době přibližně 3 až 3,5 milionu vzorků za minutu v závislosti na počtu bajtů na vzorek. Toto omezení se řeší při budoucím přidání horizontálního dělení.
Agent se skládá z nasazení s jednou replikou a daemonSet pro scrapování metrik. DaemonSet seškrábe všechny cíle na úrovni uzlu, jako jsou cAdvisor, kubelet a node export. Můžete ho také nakonfigurovat tak, aby se na úrovni uzlu se statickými konfiguracemi vyškrábaly všechny vlastní cíle. Sada replik oškrábe všechno ostatní, například kube-state-metrics nebo vlastní úlohy scrape, které využívají zjišťování služby.
Porovnání malého a velkého clusteru pro repliku
Scrapování cílů | Odeslané ukázky za minutu | Počet uzlů | Počet podů | Prometheus-Collector využití procesoru (jádra) | Prometheus-Collector využití paměti (bajty) |
---|---|---|---|---|---|
výchozí cíle | 11,344 | 3 | 40 | 12,9 mc | 148 km |
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ého a velkého clusteru pro daemonSets
Scrapování cílů | Odeslané ukázky / Celkem minut | Odeslané ukázky / minuta / pod | Počet uzlů | Počet podů | Prometheus-Collector využití procesoru celkem (jádra) | Prometheus-Collector celkové využití paměti (bajty) | Prometheus-Collector využití procesoru / podů (jader) | Prometheus-Collector využití paměti /podů (bajtů) |
---|---|---|---|---|---|---|---|---|
výchozí cíle | 9,858 | 3,327 | 3 | 40 | 41,9 mc | 581 km | 14,7 mc | 189 km |
výchozí cíle | 2,3 milionu | 14,400 | 340 | 13000 | 805 mc | 305,34 GB | 2,36 mc | 898 km |
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 více prostředky
Velký objem metrik na pod vyžaduje dostatečně velký uzel, aby mohl zvládnout požadované využití procesoru a paměti. Pokud se pod repliky ama-metrics neplánuje na uzlu nebo fondu uzlů, který má dostatek prostředků, může dál získávat OOMKilled a přejít na CrashLoopBackoff. Pokud máte v clusteru uzel nebo fond uzlů s vyššími prostředky (ve fondu systémových uzlů) a chcete na tomto uzlu naplánovat repliku, můžete na tento uzel přidat popisek azuremonitor/metrics.replica.preferred=true
a pod repliky se na tomto uzlu naplánuje. V případě potřeby můžete také vytvořit další systémové fondy s většími uzly a přidat stejný popisek k jejich uzlům nebo fondu uzlů. Je také lepší přidat popisky do fondu uzlů místo uzlů, aby bylo možné pro plánování použít i novější uzly ve stejném fondu, pokud je tento popisek použitelný pro všechny uzly ve fondu.
kubectl label nodes <node-name> azuremonitor/metrics.replica.preferred="true"
Další kroky
Váš názor
https://aka.ms/ContentUserFeedback.
Připravujeme: V průběhu roku 2024 budeme postupně vyřazovat problémy z GitHub coby mechanismus zpětné vazby pro obsah a nahrazovat ho novým systémem zpětné vazby. Další informace naleznete v tématu:Odeslat a zobrazit názory pro