Řešení potíží s shromažďováním metrik Prometheus ve službě Azure Monitor

Postupujte podle kroků v tomto článku a určete příčinu neshromažďování metrik Prometheus podle očekávání ve službě Azure Monitor.

Replika podu vystřihová metriky z kube-state-metricsvlastních cílů výstřižků v objektu ama-metrics-prometheus-config configmap a vlastních cílů výstřižků definovaných ve vlastních prostředcích. Pody DaemonSet z následujících cílů v příslušném uzlu zšrotují metriky: kubelet, cAdvisor, node-exportera vlastní cíle výstřižků v konfigurační mapě ama-metrics-prometheus-config-node . Pod, pro který chcete zobrazit protokoly a uživatelské rozhraní Prometheus, závisí na tom, který cíl výstřižku prošetřujete.

Řešení potíží pomocí skriptu PowerShellu

Pokud při pokusu o povolení monitorování clusteru AKS dojde k chybě, postupujte podle zde uvedených pokynů a spusťte skript pro řešení potíží. Tento skript je navržený tak, aby pro všechny problémy s konfigurací vašeho clusteru udělal základní diagnostiku a při vytváření žádosti o podporu pro rychlejší vyřešení vašeho případu podpory můžete chytnout vygenerované soubory.

Omezování metrik

Na webu Azure Portal přejděte do svého pracovního prostoru služby Azure Monitor. Přejděte na Metrics metriky Active Time Series % Utilization a Events Per Minute Ingested % Utilization ověřte, že jsou nižší než 100 %.

Pokud je některý z nich větší než 100 %, omezuje se příjem dat do tohoto pracovního prostoru. Ve stejném pracovním prostoru přejděte a New Support Request vytvořte žádost o zvýšení limitů. Vyberte typ problému jako Service and subscription limits (quotas) a typ kvóty jako Managed Prometheus.

Přerušované mezery v shromažďování dat metrik

Během aktualizací uzlů se může v datech metrik shromážděných z našeho kolektoru na úrovni clusteru zobrazit 1 až 2minutová prodleva. Tato mezera je způsobená tím, že se uzel, na kterém běží, aktualizuje jako součást normálního procesu aktualizace. Ovlivňuje cíle na úrovni clusteru, jako jsou metriky stavu kube a vlastní cíle aplikace, které jsou zadané. Nastane, když se cluster aktualizuje ručně nebo prostřednictvím automatického aktualizace. Toto chování je očekávané a dochází k němu kvůli uzlu, na kterém běží při aktualizaci. Toto chování neovlivní žádná z našich doporučených pravidel upozornění.

Stav podu

Pomocí následujícího příkazu zkontrolujte stav podu:

kubectl get pods -n kube-system | grep ama-metrics

• Měl by existovat jeden ama-metrics-xxxxxxxxxx-xxxxx pod repliky, jeden ama-metrics-operator-targets-*, jeden ama-metrics-ksm-* pod a ama-metrics-node-* pod pro každý uzel v clusteru.
• Každý stav podu by měl mít Running stejný počet restartování jako počet použitých změn konfigurační mapy. Pod ama-metrics-operator-targets-* může mít na začátku další restartování a očekává se toto:

Pokud je Running každý stav podu, ale jeden nebo více podů se restartuje, spusťte následující příkaz:

kubectl describe pod <ama-metrics pod name> -n kube-system

• Tento příkaz poskytuje důvod restartování. Pokud byly provedeny změny mapy konfigurace, očekává se restartování podu. Pokud je OOMKilleddůvodem restartování, pod nemůže držet krok s objemem metrik. Podívejte se na doporučení škálování pro objem metrik.

Pokud jsou pody spuštěné podle očekávání, dalším místem, kde zkontrolujete, jsou protokoly kontejneru.

Protokoly kontejnerů

Zobrazte protokoly kontejneru pomocí následujícího příkazu:

kubectl logs <ama-metrics pod name> -n kube-system -c prometheus-collector

Při spuštění se všechny počáteční chyby vytisknou červeně, zatímco upozornění se vytisknou žlutě. (Zobrazení barevných protokolů vyžaduje alespoň PowerShell verze 7 nebo linuxovou distribuci.)

• Ověřte, jestli nedošlo k problému se získáním ověřovacího tokenu:
  • Zpráva Žádná konfigurace pro prostředek AKS se zaprotokoluje každých 5 minut.
  • Pod se restartuje každých 15 minut a zkusí to znovu s chybou: Pro prostředek AKS neexistuje žádná konfigurace.
    • Pokud ano, zkontrolujte, jestli ve vaší skupině prostředků existuje pravidlo shromažďování dat a koncový bod shromažďování dat.
    • Ověřte také, že pracovní prostor služby Azure Monitor existuje.
    • Ověřte, že nemáte privátní cluster AKS a že není propojený s oborem služby Private Link služby Azure Monitor pro žádnou jinou službu. Tento scénář se v současné době nepodporuje.

Zpracování konfigurace

Zobrazte protokoly kontejneru pomocí následujícího příkazu:

kubectl logs <ama-metrics-operator-targets pod name> -n kube-system -c config-reader

• Ověřte, že nedošlo k žádným chybám při analýze konfigurace Prometheus, sloučení s výchozími povolenými cíli výstřižků a ověřením úplné konfigurace.
• Pokud jste zahrnuli vlastní konfiguraci Prometheus, ověřte, že je rozpoznána v protokolech. Pokud ne:
  • Ověřte, že vaše mapa konfigurace má správný název: ama-metrics-prometheus-config v kube-system oboru názvů.
  • Ověřte, že v konfigurační mapě je vaše konfigurace Prometheus pod oddílem, který se nazývá prometheus-configdata níže:

    kind: ConfigMap
    apiVersion: v1
    metadata:
      name: ama-metrics-prometheus-config
      namespace: kube-system
    data:
      prometheus-config: |-
        scrape_configs:
        - job_name: <your scrape job here>
    

• Pokud jste vytvořili vlastní prostředky, měli byste při vytváření monitorování podů nebo služeb vidět všechny chyby ověření. Pokud metriky z cílů pořád nevidíte, ujistěte se, že se v protokolech nezobrazují žádné chyby.

kubectl logs <ama-metrics-operator-targets pod name> -n kube-system -c targetallocator

• Ověřte, že nedošlo k MetricsExtension žádným chybám v souvislosti s ověřováním v pracovním prostoru služby Azure Monitor.
• Ověřte, že nedošlo k žádným chybám týkajícím OpenTelemetry collector se výstřižků cílů.

Spusťte následující příkaz:

kubectl logs <ama-metrics pod name> -n kube-system -c addon-token-adapter

• Tento příkaz zobrazí chybu, pokud došlo k problému s ověřováním v pracovním prostoru služby Azure Monitor. Následující příklad ukazuje protokoly bez problémů:

Pokud protokoly neobsahují žádné chyby, můžete k ladění použít rozhraní Prometheus k ověření očekávané konfigurace a cílů, které se šrotují.

Rozhraní Prometheus

Každý ama-metrics-* pod má uživatelské rozhraní pro režim agenta Prometheus dostupné na portu 9090. Vlastní konfigurace a cíle vlastních prostředků jsou šrotovány podem ama-metrics-* a cíli uzlu podem ama-metrics-node-* . Přeposílání portů do podu repliky nebo jednoho z podů nastavených démonem pro kontrolu konfigurace, zjišťování služeb a cílů koncových bodů, jak je popsáno zde, abyste ověřili správnost vlastních konfigurací, byly zjištěny zamýšlené cíle pro každou úlohu a nedošlo k žádným chybám při výstřižku konkrétních cílů.

Spusťte příkaz kubectl port-forward <ama-metrics pod> -n kube-system 9090.

• Otevřete prohlížeč na adresu 127.0.0.1:9090/config. Toto uživatelské rozhraní má úplnou konfiguraci výstřižku. Ověřte, že jsou všechny úlohy zahrnuté v konfiguraci.

• Přejděte k 127.0.0.1:9090/service-discovery zobrazení cílů zjištěných zadaným objektem zjišťování služby a toho, co relabel_configs filtrovaly cíle, které mají být. Pokud například chybí metriky z určitého podu, můžete zjistit, jestli byl tento pod zjištěn a jaký je jeho identifikátor URI. Tento identifikátor URI pak můžete použít při pohledu na cíle a zjistit, jestli nedošlo k nějakým chybám.

• Přejděte na 127.0.0.1:9090/targets zobrazení všech úloh, čas posledního vyřazení koncového bodu pro danou úlohu a všech chyb.

Vlastní prostředky

• Pokud jste zahrnuli vlastní prostředky, ujistěte se, že se zobrazují v rámci konfigurace, zjišťování služeb a cílů.

Konfigurace

Zjišťování služeb

Cíle

Pokud nedojde k žádným problémům a zamýšlené cíle se šrotují, můžete zobrazit přesné metriky, které se šrotují, povolením režimu ladění.

Režim ladění

Upozorňující

Tento režim může mít vliv na výkon a měl by být povolený jen na krátkou dobu pro účely ladění.

Doplněk metrik lze nakonfigurovat tak, aby běžel v režimu ladění změnou nastavení enableddebug-mode konfigurační mapy na true následující pokyny.

Pokud je tato možnost povolená, všechny metriky Prometheus, které jsou šrotované, jsou hostované na portu 9091. Spusťte následující příkaz:

kubectl port-forward <ama-metrics pod name> -n kube-system 9091

V prohlížeči přejděte a 127.0.0.1:9091/metrics podívejte se, jestli se metriky nešrotovaly kolekcí OpenTelemetry. K tomuto uživatelskému rozhraní je možné přistupovat pro každý ama-metrics-* pod. Pokud tam metriky nejsou, může dojít k problému s délkou názvu metriky nebo popisku nebo počtem popisků. Zkontrolujte také překročení kvóty příjmu dat pro metriky Prometheus, jak je uvedeno v tomto článku.

Názvy metrik, názvy popisků a hodnoty popisků

Výstřižky založené na agentech aktuálně mají omezení v následující tabulce:

Vlastnost	Limit
Délka názvu popisku	Méně než nebo rovno 511 znakům. Pokud dojde k překročení tohoto limitu pro libovolnou časovou řadu v úloze, celá úloha výstřižku selže a metriky se z této úlohy před příjmem dat vyřadí. Zobrazí se hodnota up=0 pro danou úlohu a také cílové uživatelské rozhraní zobrazuje důvod pro up=0.
Délka hodnoty popisku	Menší než nebo rovno 1023 znakům. Pokud dojde k překročení tohoto limitu pro všechny časové řady v úloze, celý výstřižek selže a metriky se z této úlohy před příjmem dat vyřadí. Zobrazí se hodnota up=0 pro danou úlohu a také cílové uživatelské rozhraní zobrazuje důvod pro up=0.
Počet popisků na časnou řadu	Menší než nebo rovno 63. Pokud dojde k překročení tohoto limitu pro libovolnou časovou řadu v úloze, celá úloha výstřižku selže a metriky se z této úlohy před příjmem dat vyřadí. Zobrazí se hodnota up=0 pro danou úlohu a také cílové uživatelské rozhraní zobrazuje důvod pro up=0.
Délka názvu metriky	Méně než nebo rovno 511 znakům. Pokud je tento limit překročen pro každou časovou řadu v úloze, dojde pouze k vyřazení konkrétní řady. MetricextensionConsoleDebugLog obsahuje trasování pro vynechanou metriku.
Názvy popisků s různými písmeny	Dva popisky ve stejném vzorku metriky, s různou velikostí textu se považují za duplicitní popisky a při ingestování se zahodí. Časová řada my_metric{ExampleLabel="label_value_0", examplelabel="label_value_1} se například zahodí kvůli duplicitním popiskům, protože ExampleLabelexamplelabel se považují za stejný název popisku.

Kontrola kvóty příjmu dat v pracovním prostoru služby Azure Monitor

Pokud se vám metriky zmeškaly, můžete nejprve zkontrolovat, jestli se pro váš pracovní prostor služby Azure Monitor překročí limity příjmu dat. Na webu Azure Portal můžete zkontrolovat aktuální využití libovolného pracovního prostoru služby Azure Monitor. Aktuální metriky využití můžete zobrazit v Metrics nabídce pracovního prostoru služby Azure Monitor. Následující metriky využití jsou k dispozici jako standardní metriky pro každý pracovní prostor služby Azure Monitor.

• Aktivní časová řada – počet jedinečných časových řad nedávno přijatých do pracovního prostoru za posledních 12 hodin
• Limit aktivní časové řady – limit počtu jedinečných časových řad, které je možné aktivně ingestovat do pracovního prostoru
• Využití aktivní časové řady % – procento aktuálně využívané aktivní časové řady
• Počet přijatých událostí za minutu – počet událostí (ukázek) za minutu, které byly nedávno přijaty
• Limit přijatých událostí za minutu – maximální počet událostí za minutu, které je možné ingestovat před omezováním
• Počet přijatých událostí za minutu – procento aktuálního limitu rychlosti příjmu metrik je util

Projděte si kvóty a omezení služeb pro výchozí kvóty a také zjistěte, co se dá na základě vašeho využití zvýšit. Navýšení kvóty pro pracovní prostory služby Azure Monitor můžete požádat pomocí Support Request nabídky pro pracovní prostor služby Azure Monitor. Ujistěte se, že do žádosti o podporu zahrnete ID, interní ID a umístění nebo oblast pracovního prostoru služby Azure Monitor, které najdete v nabídce Vlastnosti pracovního prostoru služby Azure Monitor na webu Azure Portal.

Další kroky

• Projděte si důležité informace o shromažďování metrik ve velkém měřítku.