Ř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ě, spusťte skript pro řešení potíží podle těchto pokynů . 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í případu podpory můžete připojit vygenerované soubory.

Omezování metrik

Spravovaná služba Azure Monitoru pro Prometheus má výchozí limity a kvóty pro příjem dat. Když dosáhnete limitů příjmu dat, může dojít k omezování. Můžete požádat o zvýšení těchto limitů. Informace o limitech metrik Prometheus najdete v tématu Omezení služby Azure Monitor.

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

Další informace o monitorování a upozorňování na metriky příjmu dat najdete v tématu Monitorování příjmu metrik pracovního prostoru služby Azure Monitor.

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

Během aktualizací uzlů se může zobrazit 1 až 2minutová mezera v datech metrik pro metriky shromážděné z našeho kolektoru na úrovni clusteru. 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 to cílové položky na celém clusteru, jako jsou metriky stavu kube a vlastní cíle aplikace, které jsou zadané. Tento případ 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 aktualizaci uzlu, na kterém běží. 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

Při správném spuštění služby se vrátí následující seznam podů ve formátu ama-metrics-xxxxxxxxxx-xxxxx :

• ama-metrics-operator-targets-*
• ama-metrics-ksm-*
• 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.

Kontrola konfigurací opětovného označování

Pokud metriky chybí, můžete také zkontrolovat, jestli máte znovu oznamované konfigurace. Při opětovném označování konfigurací se ujistěte, že opětovné označení neodfiltruje cíle a popisky nakonfigurované správně odpovídají cílům. Další informace najdete v dokumentaci ke konfiguraci Relabel Prometheus.

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. Jestliže 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-config data 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í enabled debug-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 metrik 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 ExampleLabel examplelabel se považují za stejný název popisku.

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

Pokud vidíte chybějící metriky, můžete nejprve zkontrolovat, jestli se pro váš pracovní prostor služby Azure Monitor překračujíc 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

Abyste se vyhnuli omezování příjmu metrik, můžete monitorovat a nastavit upozornění na limity příjmu dat. Viz téma Monitorování limitů příjmu dat.

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.

Vytvoření pracovního prostoru služby Azure Monitor selhalo kvůli vyhodnocení služby Azure Policy

Pokud vytvoření pracovního prostoru Služby Azure Monitor selže s chybou oznamující, že zásady zakázaly prostředek resource-name-xyz, může existovat zásada Azure, která brání vytvoření prostředku. Pokud existují zásady, které vynucují zásady vytváření názvů pro vaše prostředky nebo skupiny prostředků Azure, budete muset vytvořit výjimku pro zásady vytváření názvů pro vytvoření pracovního prostoru služby Azure Monitor.

Když vytvoříte pracovní prostor Azure Monitoru, ve výchozím nastavení se ve výchozím nastavení vytvoří pravidlo shromažďování dat a koncový bod shromažďování dat ve formátu azure-monitor-workspace-name automaticky ve skupině prostředků ve formátu "MA_azure-monitor-workspace-name_location_managed". V současné době neexistuje způsob, jak změnit názvy těchto prostředků a pro vyloučení výše uvedených prostředků z vyhodnocení zásad budete muset nastavit výjimku ze služby Azure Policy. Viz struktura výjimek pro Azure Policy.

Další kroky

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