Personalizzare lo scarto delle metriche di Prometheus nel servizio gestito di Monitoraggio di Azure per Prometheus

  • Articolo

Questo articolo fornisce istruzioni sulla personalizzazione dello scraping delle metriche per un cluster Kubernetes con l'addon delle metriche in Monitoraggio di Azure.

Mappe di configurazione

È possibile configurare quattro diverse mappe di configurazione per fornire la configurazione di scrape e altre impostazioni per il componente aggiuntivo per le metriche. Tutte le mappe di configurazione devono essere applicate allo kube-system spazio dei nomi per qualsiasi cluster.

Nota

Nessuna delle quattro mappe di configurazione esiste per impostazione predefinita nel cluster quando è abilitato Prometheus gestito. A seconda di ciò che deve essere personalizzato, è necessario distribuire uno o tutti questi quattro configmap con lo stesso nome specificato, nello kube-system spazio dei nomi. I pod AMA-Metrics prelevano queste mappe di configurazione dopo averle kube-system distribuite nello spazio dei nomi e verranno riavviate in 2-3 minuti per applicare le impostazioni di configurazione specificate nelle mappe di configurazione.

  1. ama-metrics-settings-configmap Questa mappa di configurazione include le impostazioni semplici che è possibile configurare. È possibile accettare la mappa di configurazione dal repository dell'hub Git precedente, modificare le impostazioni necessarie e applicare/distribuire la mappa di configurazione nello kube-system spazio dei nomi per il cluster
    • alias del cluster (per modificare il valore dell'etichetta cluster in ogni serie temporale/metrica inserita da un cluster)
    • abilitare/disabilitare le destinazioni di scrape predefinite: attivare/disattivare lo scraping predefinito in base alle destinazioni. La configurazione di scrape per queste destinazioni predefinite è già predefinita/predefinita
    • abilitare lo scarto basato sull'annotazione dei pod per spazio dei nomi
    • keep-lists delle metriche: questa impostazione viene usata per controllare quali metriche sono elencate per essere consentite da ogni destinazione predefinita e per modificare il comportamento predefinito
    • intervalli di scrape per le impostazioni predefinite/predefinite.scrape intervals for default/pre-definetargets. 30 secs è la frequenza di scrape predefinita e può essere modificata per ogni destinazione predefinita usando questo configmap
    • modalità di debug: l'attivazione di questo strumento consente di eseguire il debug di problemi di metrica/inserimento mancanti. Per altre informazioni sulla risoluzione dei problemi, vedere
  2. ama-metrics-prometheus-config Questa mappa di configurazione può essere usata per fornire la configurazione dello scrape prometheus per la replica addon. Addon esegue una replica singleton e tutti i servizi a livello di cluster possono essere individuati e raschiati fornendo processi di scrape in questa mappa di configurazione. È possibile prendere il file configmap di esempio dal repository dell'hub Git precedente, aggiungere processi di scrape necessari e applicare/distribuire la mappa di configurazione allo kube-system spazio dei nomi per il cluster. Anche se questa opzione è supportata, si noti che il modo consigliato per eliminare le destinazioni personalizzate consiste nell'usare risorse personalizzate
  3. ama-metrics-prometheus-config-node (Avanzate) Questa mappa di configurazione può essere usata per fornire la configurazione dello scrapeus prometheus per addon DaemonSet in esecuzione in ogni nodo Linux del cluster e qualsiasi destinazione a livello di nodo in ogni nodo può essere raschiata fornendo processi di scrape in questo configmap. Quando si usa questo configmap, è possibile usare $NODE_IP la variabile nella configurazione di scrape, che viene sostituita dall'indirizzo IP del nodo corrispondente nel pod DaemonSet in esecuzione in ogni nodo. In questo modo si ottiene l'accesso per eliminare tutto ciò che viene eseguito su tale nodo dal componente aggiuntivo metriche DaemonSet. Prestare attenzione quando si usano le individuazioni nella configurazione di scrape in questa mappa di configurazione a livello di nodo, perché ogni nodo del cluster configura e individua le destinazioni e raccoglie le metriche ridondanti. È possibile accettare la mappa di configurazione di esempio dal repository dell'hub Git precedente, aggiungere processi di scrape necessari e applicare/distribuire la mappa di configurazione allo kube-system spazio dei nomi per il cluster
  4. ama-metrics-prometheus-config-node-windows (Avanzate) Questa mappa di configurazione può essere usata per fornire la configurazione dello scrapeus prometheus per addon DaemonSet in esecuzione in ogni nodo di Windows nel cluster e le destinazioni a livello di nodo in ogni nodo possono essere raschiate fornendo processi di scrape in questo configmap. Quando si usa questa mappa di configurazione, è possibile usare $NODE_IP la variabile nella configurazione di scrape, che verrà sostituita dall'indirizzo IP del nodo corrispondente nel pod DaemonSet in esecuzione in ogni nodo. In questo modo si ottiene l'accesso per eliminare tutto ciò che viene eseguito su tale nodo dal componente aggiuntivo metriche DaemonSet. Prestare attenzione quando si usano le individuazioni nella configurazione di scrape in questa mappa di configurazione a livello di nodo, perché ogni nodo del cluster configura e individua le destinazioni e raccoglie le metriche ridondanti. È possibile accettare la mappa di configurazione di esempio dal repository dell'hub Git precedente, aggiungere processi di scrape necessari e applicare/distribuire la mappa di configurazione allo kube-system spazio dei nomi per il cluster

Definizioni di risorse personalizzate

Il componente aggiuntivo Metriche di Monitoraggio di Azure supporta lo scraping delle metriche prometheus usando Prometheus - Monitoraggi pod e monitoraggi dei servizi, simile all'operatore OSS Prometheus. L'abilitazione del componente aggiuntivo distribuirà le definizioni di risorse personalizzate di Pod e Monitoraggio dei servizi per consentire di creare risorse personalizzate. Seguire le istruzioni per creare e applicare risorse personalizzate nel cluster.

Configmap delle impostazioni del componente aggiuntivo metriche

Il file ama-metrics-settings-configmap può essere scaricato, modificato e applicato al cluster per personalizzare le funzionalità predefinite del componente aggiuntivo per le metriche.

Abilitare e disabilitare le destinazioni predefinite

La tabella seguente include un elenco di tutte le destinazioni predefinite che il componente aggiuntivo metriche di Monitoraggio di Azure può raschiare per impostazione predefinita e se è abilitato inizialmente. Le destinazioni predefinite vengono raschiate ogni 30 secondi. Una replica viene distribuita in destinazioni a livello di cluster, ad esempio kube-state-metrics. Un DaemonSet viene distribuito anche in destinazioni a livello di nodo, ad esempio kubelet.

Chiave Type Attivata Pod Descrizione
kubelet bool true Linux DaemonSet Scrape kubelet in ogni nodo del cluster K8s senza alcuna configurazione di scrape aggiuntiva.
cadvisor bool true Linux DaemonSet Scrape cadvisor in ogni nodo del cluster K8s senza alcuna configurazione di scrape aggiuntiva.
Solo Linux.
kubestate bool true Replica Linux Scrape kube-state-metrics nel cluster K8s (installato come parte del componente aggiuntivo) senza alcuna configurazione di scrape aggiuntiva.
nodeexporter bool true Linux DaemonSet Scrape node metrics without any extra scrape config (Metriche dei nodi di scrape senza alcuna configurazione aggiuntiva di scrape).
Solo Linux.
coredns bool false Replica Linux Eseguire lo scrape coredns nel cluster K8s senza alcuna configurazione aggiuntiva di scrape.
kubeproxy bool false Linux DaemonSet Scrape kube-proxy in ogni nodo Linux individuato nel cluster K8s senza alcuna configurazione aggiuntiva di scrape.
Solo Linux.
apiserver bool false Replica Linux Raschiare il server API Kubernetes nel cluster K8s senza alcuna configurazione aggiuntiva di scrape.
windowsexporter bool false Windows DaemonSet Raschiare windows-export in ogni nodo del cluster K8s senza alcuna configurazione di scrape aggiuntiva.
Solo Windows.
windowskubeproxy bool false Windows DaemonSet Raschiare windows-kube-proxy in ogni nodo del cluster K8s senza alcuna configurazione di scrape aggiuntiva.
Solo Windows.
prometheuscollectorhealth bool false Replica Linux Eseguire lo scrape delle informazioni sul contenitore prometheus-collector, ad esempio la quantità e le dimensioni delle serie temporali raschiate.

Se si vuole attivare lo scraping delle destinazioni predefinite che non sono abilitate per impostazione predefinita, modificare la mappaama-metrics-settings-configmap di configurazione per aggiornare le destinazioni elencate in default-scrape-settings-enabled in true. Applicare la mappa di configurazione al cluster.

Abilitare lo scarto basato sulle annotazioni dei pod

Per raschiare i pod dell'applicazione senza dover creare una configurazione Prometheus personalizzata, è possibile aggiungere annotazioni ai pod. L'annotazione prometheus.io/scrape: "true" è necessaria affinché il pod venga rasato. Le annotazioni prometheus.io/path e prometheus.io/port indicano il percorso e la porta in cui le metriche sono ospitate nel pod. Le annotazioni per un pod che ospita le metriche in <pod IP>:8080/metrics sono:

metadata:   
  annotations:
    prometheus.io/scrape: 'true'
    prometheus.io/path: '/metrics'
    prometheus.io/port: '8080'

La cancellazione di questi pod con annotazioni specifiche è disabilitata per impostazione predefinita. Per abilitare, in ama-metrics-settings-configmapaggiungere l'espressione regolare per gli spazi dei nomi dei pod con annotazioni che si desidera raschiare come valore del campo podannotationnamespaceregex.

Ad esempio, l'impostazione seguente elimina i pod con annotazioni solo negli spazi dei nomi kube-system e my-namespace:

pod-annotation-based-scraping: |-
    podannotationnamespaceregex = "kube-system|my-namespace"

Per abilitare lo scraping per i pod con annotazioni in tutti gli spazi dei nomi, usare:

pod-annotation-based-scraping: |-
    podannotationnamespaceregex = ".*"

Avviso

L'analisi delle annotazioni dei pod da molti spazi dei nomi può generare un volume molto elevato di metriche a seconda del numero di pod con annotazioni.

Personalizzare le metriche raccolte dalle destinazioni predefinite

Per impostazione predefinita, per tutte le destinazioni predefinite, solo le metriche minime usate nelle regole di registrazione predefinite, gli avvisi e i dashboard di Grafana vengono inseriti come descritto in minimal-ingestion-profile. Per raccogliere tutte le metriche dalle destinazioni predefinite, aggiornare gli elenchi keep-list nella mappa di configurazione delle impostazioni in default-targets-metrics-keep-liste impostare su minimalingestionprofilefalse.

Per consentire più metriche oltre alle metriche predefinite elencate per essere consentite, per tutte le destinazioni predefinite, modificare le impostazioni in default-targets-metrics-keep-list per il processo corrispondente da modificare.

Ad esempio, kubelet è l'impostazione di filtro delle metriche per il kubelet di destinazione predefinito. Usare lo script seguente per filtrare le metriche raccolte per le destinazioni predefinite usando il filtro basato su regex.

kubelet = "metricX|metricY"
apiserver = "mymetric.*"

Nota

Se si usano le virgolette o le barre rovesciate nell'espressione regolare, è necessario eseguirne l'escape usando una barra rovesciata come gli esempi "test\'smetric\"s\"" e testbackslash\\*.

Per personalizzare ulteriormente i processi predefiniti per modificare le proprietà, ad esempio la frequenza di raccolta o le etichette, disabilitare la destinazione predefinita corrispondente impostando il valore configmap per la destinazione su false. Applicare quindi il processo usando una mappa di configurazione personalizzata. Per informazioni dettagliate sulla configurazione personalizzata, vedere Personalizzare lo scarto delle metriche di Prometheus in Monitoraggio di Azure.

Alias del cluster

L'etichetta del cluster aggiunta a ogni serie temporale raschiata usa l'ultima parte dell'ID risorsa di Azure Resource Manager del cluster del servizio Azure Kubernetes completo. Ad esempio, se l'ID risorsa è /subscriptions/00000000-0000-0000-0000-000000000000/resourcegroups/rg-name/providers/Microsoft.ContainerService/managedClusters/myclustername, l'etichetta del cluster è myclustername.

Per eseguire l'override dell'etichetta del cluster nella serie temporale raschiata, aggiornare l'impostazione cluster_alias su qualsiasi stringa prometheus-collector-settings in nella mappa di configurazioneama-metrics-settings-configmap. È possibile creare questa mappa di configurazione se non esiste nel cluster oppure modificare quella esistente se esiste già nel cluster.

La nuova etichetta viene visualizzata anche nell'elenco a discesa dei parametri del cluster nei dashboard di Grafana invece di quello predefinito.

Nota

Sono consentiti solo caratteri alfanumerici. Tutti gli altri caratteri vengono sostituiti con _. Questa modifica consiste nel garantire che i diversi componenti che utilizzano questa etichetta rispettino la convenzione alfanumerica di base.

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.

Per visualizzare ogni metrica che viene raschiata a scopo di debug, l'agente del componente aggiuntivo metriche può essere configurato per l'esecuzione in modalità di debug aggiornando l'impostazione su con l'impostazione debug-mode nella mappa di configurazioneama-metrics-settings-configmap.trueenabled È possibile creare questa mappa di configurazione o modificarne una esistente. Per altre informazioni, vedere la sezione Modalità di debug in Risolvere i problemi relativi alla raccolta di metriche di Prometheus.

Impostazioni dell'intervallo di scrape

Per aggiornare le impostazioni dell'intervallo di scrape per qualsiasi destinazione, è possibile aggiornare la durata nell'impostazione default-targets-scrape-interval-settings per tale destinazione nella mappaama-metrics-settings-configmap di configurazione. È necessario impostare gli intervalli di scrape nel formato corretto specificato in questo sito Web. In caso contrario, il valore predefinito di 30 secondi viene applicato alle destinazioni corrispondenti. Ad esempio, se si vuole aggiornare l'intervallo di scrape per il kubelet processo in 60s , è possibile aggiornare la sezione seguente in YAML:

default-targets-scrape-interval-settings: |-
    kubelet = "60s"
    coredns = "30s"
    cadvisor = "30s"
    kubeproxy = "30s"
    apiserver = "30s"
    kubestate = "30s"
    nodeexporter = "30s"
    windowsexporter = "30s"
    windowskubeproxy = "30s"
    kappiebasic = "30s"
    prometheuscollectorhealth = "30s"
    podannotations = "30s"

e applicare YAML usando il comando seguente: kubectl apply -f .\ama-metrics-settings-configmap.yaml

Configurare processi di raschiatura prometheus personalizzati

È possibile raschiare le metriche di Prometheus usando Prometheus - Monitoraggi pod e monitoraggi del servizio (scelta consigliata), simile all'operatore OSS Prometheus. Seguire le istruzioni per creare e applicare risorse personalizzate nel cluster.

È anche possibile seguire le istruzioni per creare, convalidare e applicare la mappa di configurazione per il cluster. Il formato di configurazione è simile al file di configurazione di Prometheus.

Suggerimenti ed esempi di configurazione di Prometheus

Informazioni su alcuni suggerimenti di esempi in questa sezione.

Usare i modelli pod e monitoraggio dei servizi e seguire la specifica dell'API per creare le risorse personalizzate (PodMonitor e Monitoraggio dei servizi). Si noti che l'unica modifica necessaria per i CR OSS esistenti per essere prelevata da Managed Prometheus è il gruppo di API - azmonitoring.coreos.com/v1. Per altre informazioni, vedere qui

Nota

Quando la configurazione di scrape personalizzata non viene applicata a causa di errori di convalida, la configurazione di scrape predefinita continua a essere usata.

Se si vogliono usare le impostazioni globali applicabili a tutti i processi di scrape e si dispone solo di risorse personalizzate, è comunque necessario creare una mappa di configurazione con solo le impostazioni globali (Impostazioni per ognuna di queste risorse personalizzate sostituiranno quelle nella sezione globale)

Configurazioni di scrape

Attualmente, i metodi supportati per l'individuazione di destinazione per le risorse personalizzate sono pod e monitoraggio dei servizi

Monitoraggi pod e servizi

Le destinazioni individuate usando i monitoraggi dei pod e dei servizi hanno etichette diverse __meta_* a seconda del monitoraggio usato. È possibile usare le etichette nella relabelings sezione per filtrare le destinazioni o sostituire le etichette per le destinazioni.

Vedere gli esempi di pod e monitoraggio dei servizi per i pod e i monitoraggi dei servizi.

Rilabazioni

La relabelings sezione viene applicata al momento dell'individuazione di destinazione e si applica a ogni destinazione per il processo. Negli esempi seguenti vengono illustrati i modi per usare relabelings.

Aggiungi un'etichetta

Aggiungere una nuova etichetta denominata example_label con il valore example_value a ogni metrica del processo. Usare __address__ come etichetta di origine solo perché tale etichetta esiste sempre e aggiunge l'etichetta per ogni destinazione del processo.

relabelings:
- sourceLabels: [__address__]
  targetLabel: example_label
  replacement: 'example_value'

Usare le etichette pod o Monitoraggio dei servizi

Le destinazioni individuate usando i monitoraggi dei pod e dei servizi hanno etichette diverse __meta_* a seconda del monitoraggio usato. Le __* etichette vengono eliminate dopo aver individuato le destinazioni. Per filtrare usandoli a livello di metrica, mantenere prima di tutto l'uso relabelings assegnando un nome di etichetta. metricRelabelings Usare quindi per filtrare.

# Use the kubernetes namespace as a label called 'kubernetes_namespace'
relabelings:
- sourceLabels: [__meta_kubernetes_namespace]
  action: replace
  targetLabel: kubernetes_namespace

# Keep only metrics with the kubernetes namespace 'default'
metricRelabelings:
- sourceLabels: [kubernetes_namespace]
  action: keep
  regex: 'default'

Rilabazione di processi e istanze

È possibile modificare i valori di job e instance etichetta in base all'etichetta di origine, esattamente come qualsiasi altra etichetta.

# Replace the job name with the pod label 'k8s app'
relabelings:
- sourceLabels: [__meta_kubernetes_pod_label_k8s_app]
  targetLabel: job

# Replace the instance name with the node name. This is helpful to replace a node IP
# and port with a value that is more readable
relabelings:
- sourceLabels: [__meta_kubernetes_node_name]]
  targetLabel: instance

Rilabazioni delle metriche

Le rilabazioni delle metriche vengono applicate dopo lo scarto e prima dell'inserimento. Usare la metricRelabelings sezione per filtrare le metriche dopo l'analisi. Negli esempi seguenti viene illustrato come eseguire questa operazione.

Eliminare le metriche in base al nome

# Drop the metric named 'example_metric_name'
metricRelabelings:
- sourceLabels: [__name__]
  action: drop
  regex: 'example_metric_name'

Mantenere solo determinate metriche in base al nome

# Keep only the metric named 'example_metric_name'
metricRelabelings:
- sourceLabels: [__name__]
  action: keep
  regex: 'example_metric_name'

# Keep only metrics that start with 'example_'
metricRelabelings:
- sourceLabels: [__name__]
  action: keep
  regex: '(example_.*)'

Rinominare le metriche

La ridenominazione delle metriche non è supportata.

Filtrare le metriche in base alle etichette

# Keep metrics only where example_label = 'example'
metricRelabelings:
- sourceLabels: [example_label]
  action: keep
  regex: 'example'

# Keep metrics only if `example_label` equals `value_1` or `value_2`
metricRelabelings:
- sourceLabels: [example_label]
  action: keep
  regex: '(value_1|value_2)'

# Keep metrics only if `example_label_1 = value_1` and `example_label_2 = value_2`
metricRelabelings:
- sourceLabels: [example_label_1, example_label_2]
  separator: ';'
  action: keep
  regex: 'value_1;value_2'

# Keep metrics only if `example_label` exists as a label
metricRelabelings:
- sourceLabels: [example_label_1]
  action: keep
  regex: '.+'

Raschiatura basata su TLS

Se si dispone di un'istanza di Prometheus servita con TLS e si vogliono eliminare le metriche da essa, è necessario impostare lo schema su https e impostare le impostazioni TLS nel file configmap o nel rispettivo CRD. È possibile usare la tls_config proprietà di configurazione all'interno di un processo di scrape personalizzato per configurare le impostazioni TLS usando un CRD o una mappa di configurazione. È necessario fornire un certificato ca per convalidare il certificato del server API. Il certificato della CA viene usato per verificare l'autenticità del certificato del server quando Prometheus si connette alla destinazione tramite TLS. Garantisce che il certificato del server sia firmato da un'autorità attendibile.

Il segreto deve essere creato nello spazio dei nomi kube-system e quindi è necessario creare il file configmap/CRD nello spazio dei nomi kube-system. L'ordine di creazione dei segreti è importante. Quando non è presente alcun segreto, ma una mappa CRD/config valida, si troveranno errori nel log dell'agente di raccolta ->no file found for cert....

Di seguito sono riportati i dettagli su come fornire le impostazioni di configurazione TLS tramite un file configmap o CRD.

  • Per specificare l'impostazione di configurazione TLS in un file configmap, creare il certificato autofirmato e la chiave all'interno dell'app abilitata per mtls. Un esempio di tlsConfig all'interno della mappa di configurazione dovrebbe essere simile al seguente:
tls_config:
    ca_file: /etc/prometheus/certs/client-cert.pem
    cert_file: /etc/prometheus/certs/client-cert.pem
    key_file: /etc/prometheus/certs/client-key.pem
    insecure_skip_verify: false
  • Per fornire l'impostazione di configurazione TLS in un CRD, creare il certificato autofirmato e la chiave all'interno dell'app abilitata per mtls. Un esempio di tlsConfig all'interno di un Podmonitor dovrebbe essere simile al seguente:
tlsConfig:
    ca:
        secret:
        key: "client-cert.pem" # since it is self-signed
        name: "ama-metrics-mtls-secret"
    cert:
        secret:
        key: "client-cert.pem"
        name: "ama-metrics-mtls-secret"
    keySecret:
        key: "client-key.pem"
        name: "ama-metrics-mtls-secret"
    insecureSkipVerify: false

Nota

Assicurarsi che il nome del file del certificato e il nome della chiave all'interno dell'app mtls siano nel formato seguente in caso di raschiatura basata su CRD. Ad esempio: secret_kube-system_ama-metrics-mtls-secret_cert-name.pem e secret_kube-system_ama-metrics-mtls-secret_key-name.pem. Il CRD deve essere creato nello spazio dei nomi kube-system. Il nome del segreto deve essere esattamente ama-metrics-mtls-secret nello spazio dei nomi kube-system. Comando di esempio per la creazione di un segreto: kubectl create secret generic ama-metrics-mtls-secret --from-file=secret_kube-system_ama-metrics-mtls-secret_client-cert.pem=secret_kube-system_ama-metrics-mtls--secret_client secret_kube-cert.pem --from-file=secret_kube-system_ama-metrics-mtls-secret_client-key.pem=secret_kube-system_ama-metrics-mtls-secret_client-key.pem -n kube-system

Per altre informazioni sull'autenticazione TLS, potrebbero essere utili i documenti seguenti.

Autenticazione di base

Se si usa basic_auth l'impostazione nella configurazione di prometheus, seguire la procedura :

  1. Creare un segreto nello spazio dei nomi kube-system denominato ama-metrics-mtls-secret

Il valore di password1 è base64encoded La chiave password1 può essere qualsiasi cosa, ma deve corrispondere solo al percorso file scrapeconfig password_file .

apiVersion: v1
kind: Secret
metadata:
  name: ama-metrics-mtls-secret
  namespace: kube-system
type: Opaque
data:
  password1: <base64-encoded-string>
  1. Nell'oggetto configmap per la configurazione di scrape personalizzata usare l'impostazione seguente:
basic_auth:
  username: admin
  password_file: /etc/prometheus/certs/password1

Nota

Assicurarsi che il nome sia ama-metrics-mtls-secret e che si trova nello spazio dei nomi kube-system .

Il percorso /etc/prometheus/certs/ è obbligatorio, ma password1 può essere qualsiasi stringa e deve corrispondere alla chiave per i dati nel segreto creato in precedenza. Questo perché il segreto ama-metrics-mtls-secret viene montato nel percorso /etc/prometheus/certs/ all'interno del contenitore.

Il valore con codifica Base64 viene decodificato automaticamente dai pod dell'agente quando il segreto viene montato come file.

Qualsiasi altra impostazione di configurazione per l'autorizzazione considerata come segreto nella configurazione prometheus deve usare l'alternativa dell'impostazione del file come descritto in precedenza.

Passaggi successivi

Configurare gli avvisi nelle metriche di Prometheus
Eseguire query sulle metriche di Prometheus
Altre informazioni sulla raccolta di metriche di Prometheus