Condividi tramite

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

Questo articolo fornisce istruzioni sulla personalizzazione della raccolta delle metriche per un cluster Kubernetes con il componente aggiuntivo delle metriche in Azure Monitor.

Mappe di Configurazione

È possibile configurare quattro differenti configmap per fornire la configurazione di scorporo e altre impostazioni per il componente aggiuntivo per le metriche. Tutti gli oggetti config-map devono essere applicati allo spazio dei nomi kube-system per qualsiasi cluster.

Nota

Nessuna delle quattro configmap 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 spazio dei nomi kube-system. I pod AMA-Metrics prelevano queste configmap dopo averle distribuite nello spazio dei nomi kube-system e verranno riavviate in 2-3 minuti per applicare le impostazioni di configurazione specificate nelle configmap.

  1. ama-metrics-settings-configmap Questa mappa di configurazione ha le seguenti impostazioni semplici che è possibile configurare. È possibile ottenere la configmap dal repository GitHub sopra menzionato, modificare le impostazioni necessarie e applicare/distribuire la configmap nello spazio dei nomi kube-system del vostro 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 scorporo predefinite: attivare/disattivare lo scorporo predefinito in base alle destinazioni. La configurazione di scraping per queste destinazioni predefinite è già incorporata.
    • abilitare lo scorporo basato sull'annotazione dei pod per spazio dei nomi
    • Lista delle metriche consentite: questa impostazione viene usata per controllare quali metriche sono elencate come consentite da ciascuna destinazione predefinita e per modificare il comportamento predefinito.
    • intervalli di scorporo per le impostazioni predefinite/pre-definetargets. 30 secs è la frequenza di scorporo predefinita e può essere modificata per ogni destinazione predefinita usando questa configmap
    • modalità di debug: l'attivazione di questo strumento consente di eseguire il debug di problemi di metrica/inserimento mancanti. Altre informazioni sulla risoluzione dei problemi
  2. ama-metrics-prometheus-config È possibile usare questa mappa di configurazione per fornire la configurazione dello scorporo di Prometheus per la replica del componente aggiuntivo. Addon esegue una replica singleton e tutti i servizi a livello di cluster possono essere individuati e raschiati fornendo processi di scorporo in questa configmap. È possibile usare la configmap di esempio dal repository GitHub sopra menzionato, aggiungere i necessari scrape jobs e applicare/distribuire la configmap al namespace kube-system 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) È possibile usare questa configmap per fornire la configurazione dello scorporo di Prometheus per il componente aggiuntivo DaemonSet in esecuzione in ogni nodo Linux del cluster; inoltre, è possibile scorporare le destinazioni a livello di nodo in ogni nodo fornendo processi di scorporo in questa configmap. Quando si usa questa configmap, è possibile usare la variabile $NODE_IP nella configurazione di scorporo, 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 raccogliere tutto ciò che viene eseguito su tale nodo dall'addon di metriche DaemonSet. Prestare attenzione quando si usano le individuazioni nella configurazione di scorporamento in questa mappa di configurazione a livello di nodo, poiché ogni nodo del cluster configura e individua la/e destinazione/i e raccoglie le metriche ridondanti. È possibile accettare la configmap di esempio dal repository dell'hub Git precedente, aggiungere processi di scorporamento necessari e applicare/distribuire la configmap allo spazio dei nomi kube-system per il cluster
  4. ama-metrics-prometheus-config-node-windows (Avanzate) È possibile usare questa configmap per fornire la configurazione dello scorporo di Prometheus per il componente aggiuntivo DaemonSet in esecuzione in ogni nodo Windows nel cluster; inoltre, è possibile scorporare le destinazioni a livello di nodo in ogni nodo fornendo processi di scorporo in questa configmap. Quando si usa questa configmap, è possibile usare la variabile $NODE_IP nella configurazione di scorporo, 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 raccogliere tutto ciò che viene eseguito su tale nodo dall'addon di metriche DaemonSet. Prestare attenzione quando si usano le individuazioni nella configurazione di scorporamento in questa mappa di configurazione a livello di nodo, poiché ogni nodo del cluster configura e individua la/e destinazione/i e raccoglie le metriche ridondanti. È possibile accettare la configmap di esempio dal repository dell'hub Git precedente, aggiungere processi di scorporamento necessari e applicare/distribuire la configmap allo spazio dei nomi kube-system per il cluster

Definizioni di risorse personalizzate

Il componente aggiuntivo Metriche di Monitoraggio di Azure supporta lo scorporo delle metriche di Prometheus usando Prometheus - Monitoraggi di Pod e Monitoraggi dei servizi, simile all'operatore Prometheus del software open source. 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

ama-metrics-settings-configmap può essere scaricato, modificato e applicato al cluster per personalizzare le funzionalità predefinite del componente aggiuntivo 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ò scorporare per impostazione predefinita e se è abilitato inizialmente. Le destinazioni predefinite vengono scorporate 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 Tipo Attivata Pod Descrizione
kubelet bool true Linux DaemonSet Kubelet di scorporo in ogni nodo del cluster K8s senza alcuna configurazione di scorporo aggiuntiva.
cadvisor bool true Linux DaemonSet Cadvisor di scorporo in ogni nodo del cluster K8s senza alcuna configurazione di scorporo aggiuntiva.
Solo Linux.
kubestate bool true Replica Linux Metriche-stato-kube di scorporo nel cluster K8s (installato come parte del componente aggiuntivo) senza alcuna configurazione di scorporo aggiuntiva.
nodeexporter bool true Linux DaemonSet Metriche dei nodi di scorporo senza configurazione di scorporo extra.
Solo Linux.
coredns bool false Replica Linux Eseguire lo scorporo coredns nel cluster K8s senza alcuna configurazione aggiuntiva di scorporo.
kubeproxy bool false Linux DaemonSet Proxy di kube di scorporo in ogni nodo Linux individuato nel cluster K8s senza alcuna configurazione aggiuntiva di scorporo.
Solo Linux.
apiserver bool false Replica Linux Scorporare il server API Kubernetes nel cluster K8s senza alcuna configurazione aggiuntiva di scorporo.
windowsexporter bool false Windows DaemonSet Scorporare Windows-exporter in ogni nodo del cluster K8s senza alcuna configurazione di scorporo aggiuntiva.
Solo per Windows.
windowskubeproxy bool false Windows DaemonSet Scorporare windows-kube-proxy in ogni nodo del cluster K8s senza alcuna configurazione di scorporo aggiuntiva.
Solo per Windows.
prometheuscollectorhealth bool false Replica Linux Eseguire lo scorporo delle informazioni sul contenitore Prometheus-collector, ad esempio la quantità e le dimensioni delle serie temporali raschiate.

Se si desidera attivare lo scorporo delle destinazioni predefinite che non sono abilitate per impostazione predefinita, modificare la configmapama-metrics-settings-configmap per aggiornare le destinazioni elencate in default-scrape-settings-enabled in true. Applicare la configmap al cluster.

Abilitare lo scorporo basato sulle annotazioni dei pod

Per scorporare 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 scorporato. 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'

L'estrazione dei dati da 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 scorporare come valore del campo podannotationnamespaceregex.

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

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

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 tutti i target predefiniti, vengono ingerite solo le metriche minime utilizzate nelle regole di registrazione predefinite, negli avvisi e nei dashboard di Grafana, come descritto in minimal-ingestion-profile. Per raccogliere tutte le metriche dalle destinazioni predefinite, aggiornare i keep-list nella configmap delle impostazioni in default-targets-metrics-keep-liste impostare minimalingestionprofile su false.

Per consentire più metriche oltre a quelle predefinite elencate come consentite per qualsiasi obiettivo predefinito, modificare le impostazioni in default-targets-metrics-keep-list per il lavoro corrispondente che si desidera modificare.

Ad esempio, kubelet è l'impostazione di filtraggio 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. Esegui il job usando una configmap personalizzata. Per informazioni dettagliate sulla configurazione personalizzata, vedere Personalizzare lo scorporo 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 o dell'ID risorsa di Azure Resource Manager abilitato . Ad esempio, se l'ID risorsa è /subscriptions/aaaa0a0a-bb1b-cc2c-dd3d-eeeeee4e4e4e/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 configmapama-metrics-settings-configmap. È possibile creare questa configmap 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 differenti componenti che utilizzano questa etichetta rispettino la convenzione alfanumerica di base. Se si abilitano le regole di registrazione e avviso, assicurarsi di usare il nome dell'alias del cluster nel parametro del nome del cluster del modello di onboarding delle regole per il funzionamento delle regole.

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 enabled su true nell'impostazione debug-mode nella configmapama-metrics-settings-configmap. È possibile creare questa configmap 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 scorporo

Per aggiornare le impostazioni dell'intervallo di scorporo per qualsiasi destinazione, è possibile aggiornare la durata nell'impostazione default-targets-scrape-interval-settings per tale destinazione nella configmapama-metrics-settings-configmap. È necessario impostare gli intervalli di scorporo 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 desidera aggiornare l'intervallo di scorporo per il processo kubelet 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"

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

Configurare compiti di scraping di Prometheus personalizzati

È possibile estrarre le metriche di Prometheus usando Prometheus - Pod Monitor e Service Monitor (scelta consigliata), simile all'operatore Prometheus del software open source. Seguire le istruzioni per creare e applicare risorse personalizzate nel cluster.

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

Suggerimenti ed esempi di configurazione di Prometheus

Impara alcuni suggerimenti dagli esempi in questa sezione.

Utilizzare i template Pod Monitor e Service Monitor e seguire la specifica dell'API per creare le risorse personalizzate (PodMonitor e ServiceMonitor). Si noti che l'unica modifica necessaria per i CR del software open source esistenti per essere prelevata da Managed Prometheus è il gruppo di API - azmonitoring.coreos.com/v1. Vedere qui per altre informazioni

Nota

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

Impostazioni globali

Il formato di configurazione per le impostazioni globali è uguale a quello supportato dalla configurazione del prometheus oss

global:
  scrape_interval: <duration>
  scrape_timeout: <duration>
  external_labels:
    <labelname1>: <labelvalue>
    <labelname2>: <labelvalue>
scrape_configs:
  - <job-x>
  - <job-y>

Le impostazioni fornite nella sezione globale si applicano a tutti i processi di scrape (sia quelli in Configmap che nelle risorse personalizzate), ma vengono sovrascritte se specificate nei singoli processi.

Nota

Se si desidera usare le impostazioni globali applicabili a tutti i processi di scorporo e si dispone solo di risorse personalizzate, è comunque necessario creare una configmap con solo le impostazioni globali (Le impostazioni per ognuna di queste nelle risorse personalizzate sostituiranno quelle nella sezione globale)

Configurazioni dello scorporo

Attualmente, i metodi supportati per l'individuazione delle destinazioni per le risorse personalizzate sono i pod e il monitoraggio del servizio.

Monitoraggio di Pod e servizi

Gli obiettivi individuati usando i monitor dei pod e dei servizi hanno etichette __meta_* differenti, a seconda del tipo di monitor usato. È possibile usare le etichette nella sezione relabelings per filtrare le destinazioni o sostituire le etichette per le destinazioni.

Vedere gli esempi di Monitoraggio di Pod e dei servizi dei monitoraggi di Pod e servizi.

Ri-etichettature

La sezione relabelings 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__ solamente come etichetta di origine poiché tale etichetta esiste sempre e aggiunge l'etichetta per ogni destinazione del lavoro.

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

Usare le etichette Monitoraggio di Pod e servizi

Gli obiettivi individuati usando i monitor dei pod e dei servizi hanno etichette __meta_* differenti, a seconda del tipo di monitor usato. Le etichette __* vengono eliminate dopo l'individuazione delle destinazioni. Per filtrare utilizzandoli a livello delle metriche, prima mantenerli usando relabelings assegnando loro un nome di etichetta. Usare metricRelabelings 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'

Rietichettatura di processi e istanze

È possibile modificare i valori dell'etichetta job e instance 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

Nota

Se si hanno configurazioni di rietichettatura, assicurarsi che la rietichettatura non filtri le destinazioni e che le etichette configurate corrispondano correttamente alle destinazioni.

Ri-etichettature delle metriche

Le ri-etichettature delle metriche vengono applicate dopo lo scorporo e prima dell'inserimento. Usare la sezione metricRelabelings per filtrare le metriche dopo lo scorporo. Gli esempi seguenti illustrano come farlo.

Rilasciare 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: '.+'

Autenticazione di base e token portatore

Per utilizzare le impostazioni basic_auth o bearer_token nella configurazione di Prometheus, seguire i passi seguenti:

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

    Il nome della chiave password1 può essere qualsiasi cosa purché corrisponda al nome del file nel password_file percorso del file nella configurazione dello scrape di Prometheus nel passaggio successivo. Il valore della chiave deve essere codificato in base64.

    apiVersion: v1
kind: Secret
metadata:
  name: ama-metrics-mtls-secret
  namespace: kube-system
type: Opaque
data:
  password1: <base64-encoded-string>

    Il ama-metrics-mtls-secret segreto viene caricato sui ama-metrics pod nel percorso /etc/prometheus/certs/ e viene reso disponibile allo scraper di Prometheus. La chiave (password1 nell'esempio precedente) sarà il nome del file. Il valore è decodificato in base64 e aggiunto come contenuto del file all'interno del contenitore.

  2. Quindi, nella configurazione di scrape personalizzata in configmap specificare il percorso file:

    Autenticazione di base

    Il username campo deve contenere la stringa del nome utente effettiva. Il password_file campo deve contenere il percorso del file che contiene la password.

    # Sets the `Authorization` header on every scrape request with the
# configured username and password.
basic_auth:
  username: <username string>
  password_file: /etc/prometheus/certs/password1

    Token di connessione

    Il bearer_token_file campo deve contenere il percorso del file che contiene il token.

    # Sets the `Authorization` header on every scrape request with the bearer token
# read from the configured file. It is mutually exclusive with `bearer_token`.
bearer_token_file: /etc/prometheus/certs/password1

Altre informazioni su queste impostazioni sono disponibili nella documentazione di Prometheus scrape_config.

Se si usano sia l'autenticazione di base che l'autenticazione TLS, vedere la sezione seguente. Per altri dettagli, vedere la sezione note seguente.

Scorporo basato su TLS

Se vuoi eseguire lo scraping delle metriche di Prometheus da un endpoint https, la configurazione di Prometheus, PodMonitor o ServiceMonitor dovrebbe avere il scheme impostato su https e includere impostazioni TLS aggiuntive.

  1. Creare un segreto nello spazio dei nomi kube-system con nome ama-metrics-mtls-secret. Ogni coppia chiave-valore specificata nella sezione dati dell'oggetto segreto verrà montata come file separato in questo percorso /etc/prometheus/certs con nomi di file uguali alle chiavi specificate nella sezione dati. I valori dei segreti devono essere codificati in base64.

    Di seguito è riportato un esempio di YAML di un segreto:

    apiVersion: v1
kind: Secret
metadata:
  name: ama-metrics-mtls-secret
  namespace: kube-system
type: Opaque
data:
  <certfile>: base64_cert_content    
  <keyfile>: base64_key_content

    Il ama-metrics-mtls-secret segreto viene caricato sui ama-metrics pod nel percorso /etc/prometheus/certs/ e viene reso disponibile allo scraper di Prometheus. La chiave (password1 nell'esempio precedente) sarà il nome del file. Il valore è decodificato in base64 e aggiunto come contenuto del file all'interno del contenitore.

  2. Quindi, nella configurazione Prometheus, PodMonitor o ServiceMonitor specificare il percorso file:

  • Per specificare l'impostazione di configurazione TLS in un file configmap, seguire l'esempio seguente:
tls_config:
   # CA certificate to validate API server certificate with.
   ca_file: /etc/prometheus/certs/<certfile>

   # Certificate and key files for client cert authentication to the server.
   cert_file: /etc/prometheus/certs/<certfile>
   key_file: /etc/prometheus/certs/<keyfile>

   # Disable validation of the server certificate.
   insecure_skip_verify: false

Autenticazione di base e TLS

Se si vogliono usare le impostazioni di autenticazione di base e TLS nel file configmap/CRD, assicurarsi che il segreto ama-metrics-mtls-secret includa tutte le chiavi nella sezione dei dati con i valori con codifica Base64 corrispondenti, come illustrato di seguito:

apiVersion: v1
kind: Secret
metadata:
  name: ama-metrics-mtls-secret
  namespace: kube-system
type: Opaque
data:
  certfile: base64_cert_content    # used for TLS
  keyfile: base64_key_content      # used for TLS
  password1: base64-encoded-string # used for basic auth
  password2: base64-encoded-string # used for basic auth

Nota

Nota

Il /etc/prometheus/certs/ percorso è 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 ama-metrics quando il segreto viene montato come file.

Verificare che il nome del segreto sia ama-metrics-mtls-secret e che si trovi nello spazio dei nomi kube-system.

Il segreto deve essere creato per primo e quindi deve essere creato il file configmap, PodMonitor o ServiceMonitor nello spazio dei nomi kube-system. L'ordine di creazione dei segreti è importante. Quando non è presente alcun segreto, ma un oggetto configmap, PodMonitor o ServiceMonitor che punta al segreto, l'errore seguente si troverà nei log del contenitore ama-metrics prometheus-collector: no file found for cert....

Per altre informazioni sulle impostazioni di configurazione TLS, seguire questa configurazione.

Passaggi successivi

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