Inviare le metriche Prometheus all'area di lavoro Log Analytics con Container Insights

  • Articolo

Questo articolo descrive come inviare metriche Prometheus dal cluster Kubernetes monitorato da Informazioni dettagliate contenitore a un'area di lavoro Log Analytics. Prima di eseguire questa configurazione, è necessario assicurarsi di scorporare le metriche di Prometheus dal cluster usando il servizio gestito per Prometheus di Monitoraggio di Azure, che è il metodo consigliato per il monitoraggio dei cluster. Usare la configurazione descritta in questo articolo solo se si vogliono anche inviare gli stessi dati a un'area di lavoro Log Analytics in cui è possibile analizzarli usando query di log e avvisi per la ricerca log.

Questa configurazione richiede la configurazione del componente aggiuntivo di monitoraggio per l'agente di Monitoraggio di Azure, che corrisponde a quello usata da Informazioni dettagliate contenitore per inviare dati a un'area di lavoro Log Analytics. Richiede l'esposizione dell'endpoint delle metriche Prometheus tramite gli esportatori o i pod e quindi la configurazione del componente aggiuntivo di monitoraggio per l'agente di Monitoraggio di Azure usato da Informazioni dettagliate contenitore, come illustrato nel diagramma seguente.

Diagramma dell'architettura di monitoraggio dei contenitori che invia metriche Prometheus ai log di Monitoraggio di Azure.

Impostazioni di scorporo di Prometheus (per le metriche archiviate come log)

Lo scorporo attivo delle metriche da Prometheus viene eseguito da una delle due prospettive seguenti e le metriche vengono inviate all'area di lavoro configurata di Log Analytics:

  • A livello di cluster: definito nella sezione ConfigMap [Prometheus data_collection_settings.cluster].
  • A livello di nodo: definito nella sezione ConfigMap [Prometheus_data_collection_settings.node].
Endpoint Ambito Esempio
Annotazione pod A livello di cluster prometheus.io/scrape: "true"
prometheus.io/path: "/mymetrics"
prometheus.io/port: "8000"
prometheus.io/scheme: "http"
Servizio Kubernetes A livello di cluster http://my-service-dns.my-namespace:9100/metrics
http://metrics-server.kube-system.svc.cluster.local/metrics​
URL/endpoint Per nodo e/o cluster a livello di cluster http://myurl:9101/metrics

Quando si specifica un URL, Informazioni dettagliate contenitore scorpora solo l'endpoint. Quando si indica il servizio Kubernetes, il nome del servizio viene risolto con il server DNS del cluster per ottenere l'indirizzo IP. Il servizio risolto viene quindi scorporato.

Ambito Chiave Tipo di dati valore Descrizione
A livello di cluster Specificare uno dei tre metodi seguenti per scorporare gli endpoint per le metriche.
urls String Matrice delimitata da virgole Endpoint HTTP (con specifica di indirizzo IP o percorso URL valido). Ad esempio: urls=[$NODE_IP/metrics]. ($NODE_IP è un parametro specifico di Informazioni dettagliate contenitore e può essere utilizzato al posto di un indirizzo IP del nodo. Deve essere tutto maiuscolo.)
kubernetes_services String Matrice delimitata da virgole Matrice di servizi Kubernetes per scorporare le metriche da kube-state-metrics. I nomi di dominio completi devono essere usati qui. Ad esempio, kubernetes_services = ["http://metrics-server.kube-system.svc.cluster.local/metrics",http://my-service-dns.my-namespace.svc.cluster.local:9100/metrics]
monitor_kubernetes_pods Booleano true o false Se impostato su true nelle impostazioni a livello di cluster, l'agente di Informazioni dettagliate contenitore scorpora i pod Kubernetes nell'intero cluster per le annotazioni Prometheus seguenti:
prometheus.io/scrape:
prometheus.io/scheme:
prometheus.io/path:
prometheus.io/port:
prometheus.io/scrape Booleano true o false Abilita lo scorporo del pod e monitor_kubernetes_pods deve essere impostato su true.
prometheus.io/scheme String http Per impostazione predefinita, lo scorporo viene eseguito su HTTP.
prometheus.io/path String Matrice delimitata da virgole Percorso della risorsa HTTP da cui recuperare le metriche. Se il percorso delle metriche non è /metrics, definirlo con questa annotazione.
prometheus.io/port String 9102 Specificare una porta da cui eseguire lo scorporo. Se la porta non è impostata, il valore predefinito è 9102.
monitor_kubernetes_pods_namespaces String Matrice delimitata da virgole Elenco di spazi dei nomi consentito per lo scorporo delle metriche dai pod Kubernetes.
Ad esempio, monitor_kubernetes_pods_namespaces = ["default1", "default2", "default3"]
A livello di nodo urls String Matrice delimitata da virgole Endpoint HTTP (con specifica di indirizzo IP o percorso URL valido). Ad esempio: urls=[$NODE_IP/metrics]. ($NODE_IP è un parametro specifico di Informazioni dettagliate contenitore e può essere utilizzato al posto di un indirizzo IP del nodo. Deve essere tutto maiuscolo.)
A livello di nodo o a livello di cluster interval String 60 s Il valore predefinito dell'intervallo di raccolta è di un minuto (60 secondi). È possibile modificare la raccolta per[prometheus_data_collection_settings.node] e/o [prometheus_data_collection_settings.cluster] in unità temporali come s, m e h.
A livello di nodo o a livello di cluster fieldpass
fielddrop		 String Matrice delimitata da virgole È possibile specificare determinate metriche da raccogliere o meno dall'endpoint impostando l'elenco consentiti (fieldpass) e non consentiti (fielddrop). È prima necessario impostare l'elenco elementi consentiti.

Configurare ConfigMaps per specificare la configurazione dello scorporo Prometheus (per le metriche archiviate come log)

Per configurare il file di configurazione ConfigMap per il cluster, usare la procedura seguente. ConfigMaps è un elenco globale e può essere applicato un solo ConfigMap all'agente. Non è possibile altre ConfigMaps prevalgano sulle raccolte.

  1. Scaricare il file YAML ConfigMap del modello e salvarlo come container-azm-ms-agentconfig.yaml. Se è già stato distribuito un oggetto ConfigMap nel cluster e si vuole aggiornarlo con una configurazione più recente, è possibile modificare il file ConfigMap usato in precedenza.

  2. Modificare il file YAML ConfigMap con le personalizzazioni per scorporare le metriche di Prometheus.

    Per raccogliere i servizi Kubernetes a livello di cluster, configurare il file ConfigMap usando l'esempio seguente:

    prometheus-data-collection-settings: |- ​
# Custom Prometheus metrics data collection settings
[prometheus_data_collection_settings.cluster] ​
interval = "1m"  ## Valid time units are s, m, h.
fieldpass = ["metric_to_pass1", "metric_to_pass12"] ## specify metrics to pass through ​
fielddrop = ["metric_to_drop"] ## specify metrics to drop from collecting
kubernetes_services = ["http://my-service-dns.my-namespace:9102/metrics"]

  3. Eseguire il comando kubectl seguente: kubectl apply -f <configmap_yaml_file.yaml>.

    Esempio: kubectl apply -f container-azm-ms-agentconfig.yaml.

La modifica della configurazione può richiedere alcuni minuti prima di rendere effettiva la modifica. Tutti i pod ama-logs nel cluster verranno riavviati. Al termine dei riavvii, viene visualizzato un messaggio simile al seguente e include il risultato configmap "container-azm-ms-agentconfig" created.

Verificare la configurazione

Per verificare che la configurazione sia stata applicata correttamente a un cluster, usare il comando seguente per esaminare i log da un pod agente: kubectl logs ama-logs-fdf58 -n=kube-system.

Se si verificano errori di configurazione dai pod dell'agente di Monitoraggio di Azure, l'output mostra errori simili all'esempio seguente:

***************Start Config Processing******************** 
config::unsupported/missing config schema version - 'v21' , using defaults

Sono disponibili anche errori relativi all'applicazione delle modifiche di configurazione per la revisione. Sono disponibili le opzioni seguenti per eseguire ulteriori operazioni di risoluzione dei problemi relativi alle modifiche di configurazione e allo scorporo delle metriche di Prometheus:

  • Dai log di un pod agente utilizzando lo stesso comando kubectl logs.

  • Da dati live. I log dei dati live mostrano errori simili all'esempio seguente:

    2019-07-08T18:55:00Z E! [inputs.prometheus]: Error in plugin: error making HTTP request to http://invalidurl:1010/metrics: Get http://invalidurl:1010/metrics: dial tcp: lookup invalidurl on 10.0.0.10:53: no such host

  • Dalla tabella KubeMonAgentEvents nell'area di lavoro Log Analytics. I dati vengono inviati ogni ora con gravità Avviso per gli errori di scorporo e gravità Errore per gli errori di configurazione. Se non sono presenti errori, la voce nella tabella contiene dati con informazioni sulla gravità, che non segnalano errori. La proprietà Tags contiene altre informazioni sul pod e sull'ID contenitore in cui si è verificato l'errore e anche la prima occorrenza, l'ultima occorrenza e il conteggio nell'ultima ora.

  • Per Azure Red Hat OpenShift v3.x e v4.x, controllare i log dell'agente di Monitoraggio di Azure eseguendo una ricerca nella tabella ContainerLog per verificare se la raccolta di log di openshift-azure-logging è abilitata.

Gli errori impediscono all'agente di Monitoraggio di Azure di analizzare il file, causandone il riavvio e l'utilizzo della configurazione predefinita. Dopo aver corretto gli errori in ConfigMap nei cluster diversi da Azure Red Hat OpenShift v3.x, salvare il file YAML e applicare gli oggetti ConfigMaps aggiornati eseguendo il comando kubectl apply -f <configmap_yaml_file.yaml.

Per Azure Red Hat OpenShift v3.x, modificare e salvare gli oggetti ConfigMaps aggiornati eseguendo il comando oc edit configmaps container-azm-ms-agentconfig -n openshift-azure-logging.

Eseguire query sui dati delle metriche di Prometheus

Per visualizzare le metriche di Prometheus scorporate da Monitoraggio di Azure ed eventuali errori di configurazione/scorporo segnalati dall'agente, vedere Eseguire query sui dati delle metriche di Prometheus.

Visualizzare le metriche di Prometheus in Grafana

Informazioni dettagliate contenitore supporta la visualizzazione delle metriche archiviate nell'area di lavoro Log Analytics nei dashboard di Grafana. È stato fornito un modello che è possibile scaricare dal repository del dashboard di Grafana. Usare il modello per iniziare e farvi riferimento per informazioni su come eseguire query su altri dati dai cluster monitorati per visualizzarli nei dashboard personalizzati di Grafana.

Passaggi successivi