Condividi tramite

Risolvere i problemi relativi alla raccolta di metriche di Prometheus in Monitoraggio di Azure

  • Articolo

Seguire la procedura descritta in questo articolo per determinare la causa della mancata raccolta delle metriche Prometheus come previsto in Monitoraggio di Azure.

I pod di replica eliminano le metriche da kube-state-metrics, destinazioni di scrape personalizzate nelle ama-metrics-prometheus-config destinazioni configmap e scrape personalizzate definite nelle risorse personalizzate. I pod DaemonSet eliminano le metriche dalle destinazioni seguenti nel rispettivo nodo: kubelet, cAdvisornode-exporter, e destinazioni di scrape personalizzate nella ama-metrics-prometheus-config-node mappa di configurazione. Il pod che si vuole visualizzare i log e l'interfaccia utente di Prometheus dipende da quale destinazione scrape si sta analizzando.

Risolvere i problemi relativi all'uso dello script di PowerShell

Se si verifica un errore durante il tentativo di abilitare il monitoraggio per il cluster del servizio Azure Kubernetes, seguire le istruzioni indicate qui per eseguire lo script di risoluzione dei problemi. Questo script è progettato per eseguire una diagnosi di base di per eventuali problemi di configurazione nel cluster ed è possibile inserire i file generati durante la creazione di una richiesta di supporto per una risoluzione più rapida per il caso di supporto.

Limitazione delle metriche

Nella portale di Azure passare all'area di lavoro di Monitoraggio di Azure. Passare a e verificare che le metriche Active Time Series % Utilization e Events Per Minute Ingested % Utilization siano inferiori al Metrics 100%.

Screenshot che mostra come passare alle metriche di limitazione.

Se uno di essi supera il 100%, l'inserimento in questa area di lavoro viene limitato. Nella stessa area di lavoro passare a New Support Request per creare una richiesta per aumentare i limiti. Selezionare il tipo di problema come Service and subscription limits (quotas) e il tipo di quota come Managed Prometheus.

Gap intermittenti nella raccolta dei dati delle metriche

Durante gli aggiornamenti dei nodi, è possibile che si verifichi un gap di 1-2 minuti nei dati delle metriche raccolti dall'agente di raccolta a livello di cluster. Questo divario è dovuto al fatto che il nodo in cui viene eseguito viene aggiornato come parte di un normale processo di aggiornamento. Influisce sulle destinazioni a livello di cluster, ad esempio kube-state-metrics e destinazioni dell'applicazione personalizzate specificate. Si verifica quando il cluster viene aggiornato manualmente o tramite l'aggiornamento automatico. Questo comportamento è previsto e si verifica a causa del nodo in cui viene eseguito l'aggiornamento. Nessuna delle regole di avviso consigliate è interessata da questo comportamento.

Stato pod

Controllare lo stato del pod con il comando seguente:

kubectl get pods -n kube-system | grep ama-metrics
  • Deve essere presente un ama-metrics-xxxxxxxxxx-xxxxx pod di replica, un ama-metrics-operator-targets-*ama-metrics-ksm-* pod e un ama-metrics-node-* pod per ogni nodo nel cluster.
  • Ogni stato del pod deve essere Running e avere un numero uguale di riavvii al numero di modifiche di configmap applicate. Il pod ama-metrics-operator-targets-* potrebbe avere un riavvio aggiuntivo all'inizio e questo è previsto:

Screenshot che mostra lo stato del pod.

Se ogni stato del pod è Running ma uno o più pod hanno riavvii, eseguire il comando seguente:

kubectl describe pod <ama-metrics pod name> -n kube-system
  • Questo comando fornisce il motivo dei riavvii. I riavvii dei pod sono previsti se sono state apportate modifiche alla mappa di configurazione. Se il motivo del riavvio è OOMKilled, il pod non può tenere il passo con il volume delle metriche. Vedere le raccomandazioni sulla scalabilità per il volume delle metriche.

Se i pod sono in esecuzione come previsto, la posizione successiva da controllare è i log del contenitore.

Log dei contenitori

Visualizzare i log del contenitore con il comando seguente:

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

All'avvio, tutti gli errori iniziali vengono stampati in rosso, mentre gli avvisi vengono stampati in giallo. La visualizzazione dei log colorati richiede almeno PowerShell versione 7 o una distribuzione linux.

  • Verificare se si verifica un problema con il recupero del token di autenticazione:
    • Il messaggio Nessuna configurazione presente per la risorsa servizio Azure Kubernetes viene registrata ogni 5 minuti.
    • Il pod viene riavviato ogni 15 minuti per riprovare con l'errore: Nessuna configurazione presente per la risorsa servizio Azure Kubernetes.
      • In tal caso, verificare che la regola di raccolta dati e l'endpoint di raccolta dati esistano nel gruppo di risorse.
      • Verificare anche che l'area di lavoro di Monitoraggio di Azure esista.
      • Verificare che non sia disponibile un cluster del servizio Azure Kubernetes privato e che non sia collegato a un collegamento privato ambito di Monitoraggio di Azure per qualsiasi altro servizio. Questo scenario non è attualmente supportato.

Elaborazione della configurazione

Visualizzare i log del contenitore con il comando seguente:

kubectl logs <ama-metrics-operator-targets pod name> -n kube-system -c config-reader
  • Verificare che non siano presenti errori con l'analisi della configurazione di Prometheus, l'unione con le destinazioni di scrape predefinite abilitate e la convalida della configurazione completa.
  • Se è stata inclusa una configurazione di Prometheus personalizzata, verificare che sia riconosciuta nei log. Se non:
    • Verificare che configmap abbia il nome corretto: ama-metrics-prometheus-config nello spazio dei kube-system nomi.
    • Verificare che nella configmap la configurazione di Prometheus si trova in una sezione denominata prometheus-configdata in come illustrato di seguito: 
      kind: ConfigMap
apiVersion: v1
metadata:
  name: ama-metrics-prometheus-config
  namespace: kube-system
data:
  prometheus-config: |-
    scrape_configs:
    - job_name: <your scrape job here>
  • Se sono state create risorse personalizzate, durante la creazione di monitoraggi pod/servizi dovrebbero essere stati rilevati errori di convalida. Se le metriche delle destinazioni non vengono ancora visualizzate, assicurarsi che i log non visualizzino errori.
kubectl logs <ama-metrics-operator-targets pod name> -n kube-system -c targetallocator
  • Verificare che non siano presenti errori relativi MetricsExtension all'autenticazione con l'area di lavoro monitoraggio di Azure.
  • Verificare che non siano presenti errori relativi OpenTelemetry collector allo smanciamento delle destinazioni.

Esegui questo comando:

kubectl logs <ama-metrics pod name> -n kube-system -c addon-token-adapter
  • Questo comando mostra un errore se si verifica un problema con l'autenticazione con l'area di lavoro monitoraggio di Azure. L'esempio seguente mostra i log senza problemi: Screenshot che mostra il log del token addon.

Se non sono presenti errori nei log, l'interfaccia Prometheus può essere usata per il debug per verificare la configurazione e le destinazioni previste da scarificare.

Interfaccia Prometheus

Ogni ama-metrics-* pod ha l'interfaccia utente in modalità agente Prometheus disponibile sulla porta 9090. Le destinazioni di configurazione personalizzate e risorse personalizzate vengono raschiate dal ama-metrics-* pod e dalle destinazioni del nodo dal ama-metrics-node-* pod. Eseguire il port forward nel pod di replica o in uno dei pod del set di daemon per controllare la configurazione, l'individuazione dei servizi e gli endpoint di destinazione, come descritto qui per verificare che le configurazioni personalizzate siano corrette, le destinazioni previste sono state individuate per ogni processo e non sono presenti errori con l'analisi delle destinazioni specifiche.

Eseguire il comando kubectl port-forward <ama-metrics pod> -n kube-system 9090.

  • Aprire un browser per l'indirizzo 127.0.0.1:9090/config. Questa interfaccia utente ha la configurazione completa dello scrape. Verificare che tutti i processi siano inclusi nella configurazione. Screenshot che mostra i processi di configurazione.

  • Passare a 127.0.0.1:9090/service-discovery per visualizzare le destinazioni individuate dall'oggetto di individuazione del servizio specificato e le relabel_configs hanno filtrato le destinazioni da applicare. Ad esempio, quando mancano metriche da un determinato pod, è possibile trovare se il pod è stato individuato e qual è l'URI. È quindi possibile usare questo URI quando si esaminano le destinazioni per verificare se sono presenti errori di scrape. Screenshot che mostra l'individuazione del servizio.

  • Passare a per visualizzare 127.0.0.1:9090/targets tutti i processi, l'ultima volta che l'endpoint per il processo è stato eliminato ed eventuali errori Screenshot che mostra le destinazioni.

Risorse personalizzate

  • Se sono state incluse risorse personalizzate, assicurarsi che vengano visualizzate in configurazione, individuazione dei servizi e destinazioni.

Impostazione

Screenshot che mostra i processi di configurazione per il monitoraggio dei pod.

Individuazione del servizio

Screenshot che mostra sd per il monitoraggio dei pod.

Target

Screenshot che mostra le destinazioni per il monitoraggio dei pod.

Se non sono presenti problemi e le destinazioni desiderate vengono raschiate, è possibile visualizzare le metriche esatte che vengono raschiate abilitando la modalità di debug.

Modalità di debug

Avviso

Questa modalità può influire sulle prestazioni e deve essere abilitata solo per un breve periodo di tempo a scopo di debug.

Il componente aggiuntivo per le metriche può essere configurato per l'esecuzione in modalità di debug modificando l'impostazione enabled configmap in truedebug-mode seguendo le istruzioni riportate qui.

Se abilitata, tutte le metriche prometheus che vengono raschiate sono ospitate sulla porta 9091. Esegui questo comando:

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

Passare a 127.0.0.1:9091/metrics in un browser per verificare se le metriche sono state raschiate dall'agente di raccolta OpenTelemetry. È possibile accedere a questa interfaccia utente per ogni ama-metrics-* pod. Se le metriche non sono presenti, potrebbe verificarsi un problema con la lunghezza della metrica o del nome dell'etichetta o il numero di etichette. Verificare anche il superamento della quota di inserimento per le metriche prometheus, come specificato in questo articolo.

Nomi delle metriche, nomi di etichette e valori di etichetta

Lo scraping basato su agente presenta attualmente le limitazioni nella tabella seguente:

Proprietà Limite
Lunghezza nome etichetta Minore o uguale a 511 caratteri. Quando questo limite viene superato per qualsiasi serie temporale in un processo, l'intero processo di scrape ha esito negativo e le metriche vengono eliminate da tale processo prima dell'inserimento. È possibile visualizzare up=0 per il processo e anche l'esperienza utente di destinazione mostra il motivo per up=0.
Lunghezza valore etichetta Minore o uguale a 1023 caratteri. Quando questo limite viene superato per qualsiasi serie temporale in un processo, l'intero scrape ha esito negativo e le metriche vengono eliminate dal processo prima dell'inserimento. È possibile visualizzare up=0 per il processo e anche l'esperienza utente di destinazione mostra il motivo per up=0.
Numero di etichette per serie temporale Minore o uguale a 63. Quando questo limite viene superato per qualsiasi serie temporale in un processo, l'intero processo di scrape ha esito negativo e le metriche vengono eliminate da tale processo prima dell'inserimento. È possibile visualizzare up=0 per il processo e anche l'esperienza utente di destinazione mostra il motivo per up=0.
Lunghezza nome di metrica Minore o uguale a 511 caratteri. Quando questo limite viene superato per qualsiasi serie temporale in un processo, viene eliminata solo la serie specifica. MetricextensionConsoleDebugLog contiene tracce per la metrica eliminata.
Nomi di etichette con maiuscole e minuscole diverse Due etichette all'interno dello stesso esempio di metrica, con maiuscole e minuscole diverse vengono considerate come etichette duplicate e vengono eliminate durante l'inserimento. Ad esempio, la serie my_metric{ExampleLabel="label_value_0", examplelabel="label_value_1} temporale viene eliminata a causa di etichette duplicate perché ExampleLabel e examplelabel vengono visualizzate come lo stesso nome di etichetta.

Controllare la quota di inserimento nell'area di lavoro di Monitoraggio di Azure

Se le metriche non sono state rilevate, è prima possibile verificare se i limiti di inserimento vengono superati per l'area di lavoro di Monitoraggio di Azure. Nella portale di Azure è possibile controllare l'utilizzo corrente per qualsiasi area di lavoro di Monitoraggio di Azure. È possibile visualizzare le metriche di utilizzo correnti nel Metrics menu per l'area di lavoro monitoraggio di Azure. Le metriche di utilizzo seguenti sono disponibili come metriche standard per ogni area di lavoro di Monitoraggio di Azure.

  • Serie temporale attiva- Numero di serie temporali univoco inserita di recente nell'area di lavoro nelle 12 ore precedenti
  • Limite serie temporali attive: limite per il numero di serie temporali univoco che possono essere inseriti attivamente nell'area di lavoro
  • Utilizzo % serie temporali attive : percentuale di serie temporali attive correnti in uso
  • Eventi al minuto inseriti: numero di eventi (campioni) ricevuti di recente
  • Limite di inserimento eventi al minuto: numero massimo di eventi al minuto che possono essere inseriti prima di essere limitati
  • Eventi al minuto Utilizzo % inserimento : percentuale del limite di frequenza di inserimento delle metriche corrente util

Fare riferimento alle quote e ai limiti del servizio per le quote predefinite e anche per comprendere cosa può essere aumentato in base all'utilizzo. È possibile richiedere l'aumento della quota per le aree di lavoro di Monitoraggio di Azure usando il Support Request menu per l'area di lavoro monitoraggio di Azure. Assicurarsi di includere l'ID, l'ID interno e la località/area per l'area di lavoro di Monitoraggio di Azure nella richiesta di supporto, disponibile nel menu "Proprietà" per l'area di lavoro monitoraggio di Azure nella portale di Azure.

La creazione dell'area di lavoro di Monitoraggio di Azure non è riuscita a causa di Criteri di Azure valutazione

Se la creazione dell'area di lavoro di Monitoraggio di Azure ha esito negativo e viene visualizzato un errore che indica che la risorsa 'resource-name-xyz' non è stata consentita dai criteri", potrebbe essere presente un criterio di Azure che impedisce la creazione della risorsa. Se sono presenti criteri che applicano una convenzione di denominazione per le risorse o i gruppi di risorse di Azure, sarà necessario creare un'esenzione per la convenzione di denominazione per la creazione di un'area di lavoro di Monitoraggio di Azure.

Quando si crea un'area di lavoro di Monitoraggio di Azure, per impostazione predefinita una regola di raccolta dati e un endpoint di raccolta dati nel formato "azure-monitor-workspace-name" verrà creato automaticamente in un gruppo di risorse nel formato "MA_azure-monitor-workspace-name_location_managed". Attualmente non è possibile modificare i nomi di queste risorse e sarà necessario impostare un'esenzione per il Criteri di Azure per esentare le risorse precedenti dalla valutazione dei criteri. Vedere Criteri di Azure struttura di esenzione.

Passaggi successivi