Problemen met het verzamelen van metrische prometheus-gegevens in Azure Monitor oplossen

Artikel
03/20/2024

Volg de stappen in dit artikel om de oorzaak te bepalen van prometheus-metrische gegevens die niet worden verzameld zoals verwacht in Azure Monitor.

Metrische gegevens voor replicapods worden verwijderd uit kube-state-metrics, aangepaste scrapedoelen in de ama-metrics-prometheus-config configuratiemap en aangepaste scrapedoelen die zijn gedefinieerd in de aangepaste resources. DaemonSet pods scrapen metrische gegevens van de volgende doelen op hun respectieve knooppunt: kubelet, cAdvisor, node-exporteren aangepaste scrape-doelen in de ama-metrics-prometheus-config-node configmap. De pod die u wilt weergeven van de logboeken en de Gebruikersinterface van Prometheus, is afhankelijk van het doel dat u onderzoekt.

Problemen oplossen met behulp van PowerShell-script

Als er een fout optreedt tijdens het inschakelen van bewaking voor uw AKS-cluster, volgt u de instructies die hier worden vermeld om het script voor probleemoplossing uit te voeren. Dit script is ontworpen om een basisdiagnose van eventuele configuratieproblemen in uw cluster uit te voeren en u kunt de gegenereerde bestanden bij het maken van een ondersteuningsaanvraag voor een snellere oplossing voor uw ondersteuningsaanvraag.

Beperking van metrische gegevens

Navigeer in Azure Portal naar uw Azure Monitor-werkruimte. Ga naar Metrics en controleer of de metrische gegevens Events Per Minute Ingested % UtilizationActive Time Series % Utilization lager zijn dan 100%.

Als een van deze meer dan 100% is, wordt de opname in deze werkruimte beperkt. Navigeer in dezelfde werkruimte naar New Support Request het maken van een aanvraag om de limieten te verhogen. Selecteer het probleemtype als Service and subscription limits (quotas) en het quotumtype als Managed Prometheus.

Onregelmatige hiaten in het verzamelen van metrische gegevens

Tijdens knooppuntupdates ziet u mogelijk een tussenruimte van 1 tot 2 minuten in metrische gegevens voor metrische gegevens die zijn verzameld van de collector op clusterniveau. Dit gat komt doordat het knooppunt waarop het wordt uitgevoerd, wordt bijgewerkt als onderdeel van een normaal updateproces. Dit is van invloed op clusterbrede doelen, zoals metrische gegevens van kube-state en aangepaste toepassingsdoelen die zijn opgegeven. Dit gebeurt wanneer uw cluster handmatig of via automatisch bijwerken wordt bijgewerkt. Dit gedrag wordt verwacht en treedt op omdat het knooppunt wordt uitgevoerd wanneer het wordt bijgewerkt. Geen van onze aanbevolen waarschuwingsregels wordt beïnvloed door dit gedrag.

Podstatus

Controleer de podstatus met de volgende opdracht:

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

Er moet één ama-metrics-xxxxxxxxxx-xxxxx replicapod, één ama-metrics-operator-targets-*, één ama-metrics-ksm-* pod en een ama-metrics-node-* pod zijn voor elk knooppunt in het cluster.
Elke podstatus moet zijn Running en een gelijk aantal herstarts hebben voor het aantal wijzigingen in de configuratiekaart dat is toegepast. De pod ama-metrics-operator-targets-* kan aan het begin een extra herstart hebben en dit is verwacht:

Als elke podstatus Running maar een of meer pods opnieuw zijn opgestart, voert u de volgende opdracht uit:

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

Deze opdracht geeft de reden voor het opnieuw opstarten. Het opnieuw opstarten van pods wordt verwacht als er wijzigingen in de configuratiemap zijn aangebracht. Als de reden voor het opnieuw opstarten is OOMKilled, kan de pod het volume met metrische gegevens niet bijhouden. Zie de aanbevelingen voor schaalaanpassing voor het volume metrische gegevens.

Als de pods worden uitgevoerd zoals verwacht, controleert u de containerlogboeken op de volgende plaats.

Containerlogboeken

Bekijk de containerlogboeken met de volgende opdracht:

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

Bij het opstarten worden eventuele initiële fouten rood afgedrukt, terwijl waarschuwingen geel worden afgedrukt. (Voor het weergeven van de gekleurde logboeken is ten minste PowerShell versie 7 of een Linux-distributie vereist.)

Controleer of er een probleem is met het ophalen van het verificatietoken:
- Het bericht Geen configuratie aanwezig voor de AKS-resource wordt elke 5 minuten geregistreerd.
- De pod wordt elke 15 minuten opnieuw opgestart om het opnieuw te proberen met de fout: Er is geen configuratie aanwezig voor de AKS-resource.
  - Zo ja, controleert u of de regel voor gegevensverzameling en het eindpunt voor gegevensverzameling aanwezig zijn in uw resourcegroep.
  - Controleer ook of de Azure Monitor-werkruimte bestaat.
  - Controleer of u geen privé-AKS-cluster hebt en of het niet is gekoppeld aan een Azure Monitor Private Link-bereik voor een andere service. Dit scenario wordt momenteel niet ondersteund.

Configuratieverwerking

Bekijk de containerlogboeken met de volgende opdracht:

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

Controleer of er geen fouten zijn bij het parseren van de Prometheus-configuratie, het samenvoegen met eventuele standaard scrapedoelen ingeschakeld en het valideren van de volledige configuratie.
Als u wel een aangepaste Prometheus-configuratie hebt opgenomen, controleert u of deze wordt herkend in de logboeken. Zo niet:
- Controleer of uw configuratiemap de juiste naam heeft: ama-metrics-prometheus-config in de kube-system naamruimte.
- Controleer of uw Prometheus-configuratie zich in de configuratiemap bevindt onder een sectie die wordt aangeroepen prometheus-config , data zoals hier wordt weergegeven:
```
kind: ConfigMap
apiVersion: v1
metadata:
  name: ama-metrics-prometheus-config
  namespace: kube-system
data:
  prometheus-config: |-
    scrape_configs:
    - job_name: <your scrape job here>
```
Als u aangepaste resources hebt gemaakt, zou u validatiefouten moeten zien tijdens het maken van pod-/servicemonitors. Als u de metrische gegevens van de doelen nog steeds niet ziet, controleert u of in de logboeken geen fouten worden weergegeven.

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

Controleer of er geen fouten zijn met MetricsExtension betrekking tot verificatie met de Azure Monitor-werkruimte.
Controleer of er geen fouten zijn opgetreden bij het OpenTelemetry collector scrapen van de doelen.

Voer de volgende opdracht uit:

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

Met deze opdracht wordt een fout weergegeven als er een probleem is met verificatie met de Azure Monitor-werkruimte. In het onderstaande voorbeeld ziet u logboeken zonder problemen:

Als de logboeken geen fouten bevatten, kan de Prometheus-interface worden gebruikt voor foutopsporing om te controleren of de verwachte configuratie en doelen worden gesloopt.

Prometheus-interface

Elke ama-metrics-* pod heeft de gebruikersinterface van de Prometheus-agentmodus die beschikbaar is op poort 9090. Aangepaste configuratie- en aangepaste resourcesdoelen worden door de ama-metrics-* pod en de knooppuntdoelen door de ama-metrics-node-* pod verwijderd. Port-forward naar de replicapod of een van de daemon-set pods om de eindpunten voor configuratie, servicedetectie en doelen te controleren, zoals hier wordt beschreven om te controleren of de aangepaste configuraties juist zijn, de beoogde doelen zijn gedetecteerd voor elke taak en er zijn geen fouten met het scrapen van specifieke doelen.

Voer de opdracht kubectl port-forward <ama-metrics pod> -n kube-system 9090 uit.

Open een browser naar het adres 127.0.0.1:9090/config. Deze gebruikersinterface heeft de volledige scrape-configuratie. Controleer of alle taken zijn opgenomen in de configuratie.
Ga naar de 127.0.0.1:9090/service-discovery doelen die zijn gedetecteerd door het servicedetectieobject dat is opgegeven en wat de relabel_configs de doelen hebben gefilterd. Als u bijvoorbeeld metrische gegevens van een bepaalde pod mist, kunt u vinden of die pod is gedetecteerd en wat de URI ervan is. Vervolgens kunt u deze URI gebruiken bij het bekijken van de doelen om te zien of er scrapefouten zijn.
Ga naar 127.0.0.1:9090/targets alle taken weergeven, de laatste keer dat het eindpunt voor die taak is verwijderd en eventuele fouten

Aangepaste resources

Als u aangepaste resources hebt opgenomen, controleert u of ze worden weergegeven onder configuratie, servicedetectie en -doelen.

Configuratie

Servicedetectie

Doelen

Als er geen problemen zijn en de beoogde doelen worden geschraapt, kunt u de exacte metrische gegevens bekijken die worden geschraapt door de foutopsporingsmodus in te schakelen.

Foutopsporingsmodus

Waarschuwing

Deze modus kan van invloed zijn op de prestaties en mag alleen korte tijd worden ingeschakeld voor foutopsporing.

De invoegtoepassing voor metrische gegevens kan worden geconfigureerd om te worden uitgevoerd in de foutopsporingsmodus door de instelling enabled van de configmap onder debug-mode te true wijzigen door de instructies hier te volgen.

Wanneer deze optie is ingeschakeld, worden alle prometheus-metrische gegevens die worden gesroot, gehost op poort 9091. Voer de volgende opdracht uit:

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

Ga naar 127.0.0.1:9091/metrics in een browser om te zien of de metrische gegevens zijn geschraapt door de OpenTelemetry Collector. Deze gebruikersinterface is toegankelijk voor elke ama-metrics-* pod. Als er geen metrische gegevens zijn, kan er een probleem zijn met de lengte van de metrische naam of het aantal labels. Controleer ook of het opnamequotum voor metrische gegevens van Prometheus wordt overschreden, zoals opgegeven in dit artikel.

Metrische namen, labelnamen en labelwaarden

Op agents gebaseerde scraping heeft momenteel de beperkingen in de volgende tabel:

Eigenschappen	Grenswaarde
Lengte van labelnaam	Kleiner dan of gelijk aan 511 tekens. Wanneer deze limiet voor een bepaalde tijdreeks in een taak wordt overschreden, mislukt de hele scrapetaak en worden metrische gegevens verwijderd uit die taak voordat ze worden opgenomen. U kunt de reden voor up=0 voor die taak zien en u ziet ook de reden voor up=0.
Lengte van labelwaarde	Kleiner dan of gelijk aan 1023 tekens. Wanneer deze limiet voor een bepaalde tijdreeks in een taak wordt overschreden, mislukt de hele scrape en worden metrische gegevens uit die taak verwijderd voordat ze worden opgenomen. U kunt de reden voor up=0 voor die taak zien en u ziet ook de reden voor up=0.
Aantal labels per tijdreeks	Kleiner dan of gelijk aan 63. Wanneer deze limiet voor een bepaalde tijdreeks in een taak wordt overschreden, mislukt de hele scrapetaak en worden metrische gegevens verwijderd uit die taak voordat ze worden opgenomen. U kunt de reden voor up=0 voor die taak zien en u ziet ook de reden voor up=0.
Lengte van metrische naam	Kleiner dan of gelijk aan 511 tekens. Wanneer deze limiet voor een bepaalde tijdreeks in een taak wordt overschreden, wordt alleen die bepaalde reeks verwijderd. MetricextensionConsoleDebugLog bevat traceringen voor de verwijderde metrische gegevens.
Labelnamen met verschillende behuizingen	Twee labels in hetzelfde metrische voorbeeld, waarbij verschillende behuizingen worden behandeld als dubbele labels en worden verwijderd wanneer ze worden opgenomen. De tijdreeks `my_metric{ExampleLabel="label_value_0", examplelabel="label_value_1}` wordt bijvoorbeeld verwijderd vanwege dubbele labels en `ExampleLabelexamplelabel` worden gezien als dezelfde labelnaam.

Opnamequotum controleren in Azure Monitor-werkruimte

Als u metrische gegevens mist, kunt u eerst controleren of de opnamelimieten voor uw Azure Monitor-werkruimte worden overschreden. In Azure Portal kunt u het huidige gebruik voor elke Azure Monitor-werkruimte controleren. U kunt de huidige metrische gegevens over gebruik bekijken in het Metrics menu voor de Azure Monitor-werkruimte. De volgende metrische gegevens over gebruik zijn beschikbaar als standaardmetrieken voor elke Azure Monitor-werkruimte.

Actieve tijdreeks: het aantal unieke tijdreeksen dat onlangs is opgenomen in de werkruimte gedurende de afgelopen 12 uur
Actieve tijdreekslimiet : de limiet voor het aantal unieke tijdreeksen dat actief kan worden opgenomen in de werkruimte
Gebruik van actieve tijdreekspercentage : het percentage actieve tijdreeksen dat wordt gebruikt
Opgenomen gebeurtenissen per minuut - Het aantal gebeurtenissen (voorbeelden) per minuut dat onlangs is ontvangen
Opgenomen limiet voor gebeurtenissen per minuut: het maximum aantal gebeurtenissen per minuut dat kan worden opgenomen voordat de limiet wordt beperkt
Gebeurtenissen per minuut opgenomen % gebruik: het percentage van de huidige metrische opnamesnelheidslimiet die wordt gebruikt

Raadpleeg servicequota en -limieten voor standaardquota en om te begrijpen wat er kan worden verhoogd op basis van uw gebruik. U kunt quotumverhoging aanvragen voor Azure Monitor-werkruimten met behulp van het Support Request menu voor de Azure Monitor-werkruimte. Zorg ervoor dat u de id, interne id en locatie/regio voor de Azure Monitor-werkruimte opneemt in de ondersteuningsaanvraag, die u kunt vinden in het menu Eigenschappen voor de Azure Monitor-werkruimte in Azure Portal.

Volgende stappen

Bekijk overwegingen voor het verzamelen van metrische gegevens op grote schaal.

Share via