Nota
L'accesso a questa pagina richiede l'autorizzazione. È possibile provare ad accedere o modificare le directory.
L'accesso a questa pagina richiede l'autorizzazione. È possibile provare a modificare le directory.
Personalizzare la raccolta di metriche di Prometheus dal cluster Kubernetes descrive come usare ConfigMap per personalizzare lo scarto delle metriche di Prometheus dalle destinazioni predefinite nel cluster Kubernetes. Questo articolo descrive come usare ConfigMap per creare processi di scrape personalizzati per altre destinazioni e personalizzazione.
ConfigMaps
Nella tabella seguente vengono descritti gli oggetti ConfigMap usati per creare processi di scraping personalizzati. Queste mappe di configurazione non esistono per impostazione predefinita nel cluster quando è abilitato Prometheus gestito.
| ConfigMap | Description |
|---|---|
ama-metrics-prometheus-config (Scelta consigliata) |
Quando viene creato un file ConfigMap con questo nome, i processi di scorporo definiti vengono eseguiti dal pod di replica delle metriche di Monitoraggio di Azure in esecuzione nel cluster. |
ama-metrics-prometheus-config-node (Avanzate) |
Specificare la configurazione dello scrape di Prometheus per il DaemonSet addon che viene eseguito su ogni nodo Linux nel cluster e per qualsiasi target a livello di nodo su ciascun nodo. Vedere Installazione avanzata. |
ama-metrics-prometheus-config-node-windows (Avanzate) |
Specificare la configurazione di scraping di Prometheus per l'addon DaemonSet eseguito su ogni nodo Windows del cluster e per qualsiasi destinazione a livello di nodo su ciascun nodo. Vedere Installazione avanzata. |
Creare il file di configurazione di Prometheus
Invece di modificare ama-metrics-prometheus-configdirettamente , è più semplice creare un file di configurazione e quindi convertirlo in configMap. Per informazioni dettagliate sulle diverse sezioni di questo file, vedere Impostazioni di configurazione di Scrape di seguito.
Creare un file di configurazione di Prometheus scrape denominato prometheus-config usando il formato seguente. Nella sezione scrape_configs vengono elencate le configurazioni di scrape e opzionalmente è possibile usare la sezione globale per impostare globalmente scrape_interval, scrape_timeout, e external_labels. Per informazioni dettagliate sulle opzioni per una configurazione di scraping, fare riferimento al riferimento di configurazione di scraping su Prometheus.io.
global:
scrape_interval: <duration>
scrape_timeout: <duration>
external_labels:
<labelname1>: <labelvalue>
<labelname2>: <labelvalue>
scrape_configs:
- <job-x>
- <job-y>
Di seguito è riportato un file di configurazione prometheus scrape di esempio:
global:
scrape_interval: 30s
scrape_configs:
- job_name: my_static_config
scrape_interval: 60s
static_configs:
- targets: ['my-static-service.svc.cluster.local:1234']
- job_name: prometheus_example_app
scheme: http
kubernetes_sd_configs:
- role: service
relabel_configs:
- source_labels: [__meta_kubernetes_service_name]
action: keep
regex: "prometheus-example-service"
Suggerimento
Vedere gli esempi di Prometheus di configurazioni di scorporo per un cluster Kubernetes.
Convalidare il file di configurazione dello scrape
L'agente usa uno strumento personalizzato promconfigvalidator per convalidare la configurazione di Prometheus assegnata tramite ConfigMap. Se la configurazione non è valida, la configurazione personalizzata viene rifiutata dall'agente. Dopo aver creato il file di configurazione di Prometheus, è possibile usare questo strumento per convalidare la configurazione prima di creare un oggetto ConfigMap per l'agente.
Lo strumento promconfigvalidator viene fornito all'interno del pod di componenti aggiuntivi delle metriche di Monitoraggio di Azure. È possibile usare uno qualsiasi dei pod ama-metrics-node-* nello spazio dei nomi kube-system nel cluster per scaricare lo strumento per la convalida. Usare kubectl cp per scaricare lo strumento e la relativa configurazione con il comando seguente.
for podname in $(kubectl get pods -l rsName=ama-metrics -n=kube-system -o json | jq -r '.items[].metadata.name'); do kubectl cp -n=kube-system "${podname}":/opt/promconfigvalidator ./promconfigvalidator; kubectl cp -n=kube-system "${podname}":/opt/microsoft/otelcollector/collector-config-template.yml ./collector-config-template.yml; chmod 500 promconfigvalidator; done
Dopo aver copiato il file eseguibile e il file yaml, individuare il percorso del file di configurazione prometheus. Sostituire quindi <config path> nel comando ed eseguire il validator con il comando seguente.
./promconfigvalidator/promconfigvalidator --config "<config path>" --otelTemplate "./promconfigvalidator/collector-config-template.yml"
Se non viene fornito alcun percorso con il parametro facoltativomerged-otel-config.yaml, l'esecuzione del validator genera il file output di configurazione unito. Non usare questo file unito generato automaticamente perché viene usato solo a scopo di convalida e debug degli strumenti.
Distribuire il file di configurazione come ConfigMap
Il file di configurazione di Prometheus personalizzato viene utilizzato come campo denominato prometheus-config all'interno di ConfigMap ama-metrics-prometheus-config, ama-metrics-prometheus-config-node o ama-metrics-prometheus-config-node-windows nello spazio dei nomi kube-system. Creare un file ConfigMap dal file di configurazione di scrape rinominando il file di configurazione di Prometheus in prometheus-config senza estensione di file ed eseguendo uno o più dei comandi di esempio seguenti, a seconda di quale ConfigMap si vuole creare per la configurazione del processo di scrape personalizzata.
Creare un ConfigMap da utilizzare con il replica set:
kubectl create ConfigMap ama-metrics-prometheus-config --from-file=prometheus-config -n kube-system
Verrà creato un oggetto ConfigMap denominato ama-metrics-prometheus-config nello kube-system spazio dei nomi . Per verificare se sono presenti problemi di convalida, elaborazione o unione della configurazione, è possibile esaminare i pod di replica ama-metrics
Creare ConfigMap da usare da Linux DaemonSet:
kubectl create ConfigMap ama-metrics-prometheus-config-node --from-file=prometheus-config -n kube-system
Verrà creato un oggetto ConfigMap denominato ama-metrics-prometheus-config-node nello kube-system spazio dei nomi . Per verificare se sono presenti problemi con la convalida, l'elaborazione o l'unione della configurazione, è possibile esaminare i pod daemonset di Linux.
Creare ConfigMap da usare da Windows DaemonSet
kubectl create ConfigMap ama-metrics-prometheus-config-node-windows --from-file=prometheus-config -n kube-system
Verrà creato un oggetto ConfigMap denominato ama-metrics-prometheus-config-node-windows nello kube-system spazio dei nomi . Per verificare se sono presenti problemi con la convalida, l'elaborazione o l'unione della configurazione, è possibile esaminare i ama-metrics-win-node pod deamonset di Windows
Risoluzione dei problemi
Se è stata creata correttamente la ConfigMap nello spazio dei nomi kube-system e ancora non vengono visualizzate le destinazioni personalizzate che vengono scorporate, verificare la presenza di errori nei log del pod di replica per configmap ama-metrics-prometheus-config o pod DaemonSet per configmap ama-metrics-prometheus-config-node usando log kubectl e assicurarsi che non siano presenti errori nella sezione Avviare l'unione della configurazione predefinita e personalizzata di Prometheus con prefisso prometheus-config-merge
Configurazioni dello scorporo
Attualmente, i metodi supportati di individuazione di destinazione per una configurazione di scorporo sono static_configs o kubernetes_sd_configs per specificare o individuare le destinazioni.
Una configurazione statica include un elenco di destinazioni statiche ed eventuali etichette aggiuntive da aggiungere a tali destinazioni come illustrato di seguito.
scrape_configs:
- job_name: example
- targets: [ '10.10.10.1:9090', '10.10.10.2:9090', '10.10.10.3:9090' ... ]
- labels: [ label1: value1, label1: value2, ... ]
Le destinazioni rilevate utilizzando kubernetes_sd_configs hanno ciascuna etichette __meta_* diverse a seconda del ruolo indicato. È possibile usare le etichette nella sezione relabel_configs per filtrare le destinazioni o sostituire le etichette per le destinazioni.
Rivalutare le configurazioni
La sezione relabel_configs 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 relabel_configs.
Aggiungere 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.
relabel_configs:
- source_labels: [__address__]
target_label: example_label
replacement: 'example_value'
Usare le etichette di individuazione dei servizi Kubernetes
Se un lavoro usa kubernetes_sd_configs per scoprire i target, ogni ruolo ha etichette __meta_* associate per le metriche. Le etichette __* vengono eliminate dopo l'individuazione delle destinazioni. Per filtrare utilizzandoli a livello delle metriche, prima mantenerli usando relabel_configs assegnando loro un nome di etichetta. Usare metric_relabel_configs per filtrare.
# Use the kubernetes namespace as a label called 'kubernetes_namespace'
relabel_configs:
- source_labels: [__meta_kubernetes_namespace]
action: replace
target_label: kubernetes_namespace
# Keep only metrics with the kubernetes namespace 'default'
metric_relabel_configs:
- source_labels: [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'
relabel_configs:
- source_labels: [__meta_kubernetes_pod_label_k8s_app]
target_label: 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
relabel_configs:
- source_labels: [__meta_kubernetes_node_name]
target_label: instance
Configurazioni delle etichette delle metriche
Le configurazioni di etichetta delle metriche vengono applicate dopo lo scorporo e prima dell'inserimento. Usare la sezione metric_relabel_configs per filtrare le metriche dopo lo scorporo. Vedere gli esempi seguenti.
Rilasciare le metriche in base al nome
# Drop the metric named 'example_metric_name'
metric_relabel_configs:
- source_labels: [__name__]
action: drop
regex: 'example_metric_name'
Mantenere solo determinate metriche in base al loro nome
# Keep only the metric named 'example_metric_name'
metric_relabel_configs:
- source_labels: [__name__]
action: keep
regex: 'example_metric_name'
# Keep only metrics that start with 'example_'
metric_relabel_configs:
- source_labels: [__name__]
action: keep
regex: '(example_.*)'
Filtrare le metriche in base alle etichette
# Keep metrics only where example_label = 'example'
metric_relabel_configs:
- source_labels: [example_label]
action: keep
regex: 'example'
# Keep metrics only if `example_label` equals `value_1` or `value_2`
metric_relabel_configs:
- source_labels: [example_label]
action: keep
regex: '(value_1|value_2)'
# Keep metrics only if `example_label_1 = value_1` and `example_label_2 = value_2`
metric_relabel_configs:
- source_labels: [example_label_1, example_label_2]
separator: ';'
action: keep
regex: 'value_1;value_2'
# Keep metrics only if `example_label` exists as a label
metric_relabel_configs:
- source_labels: [example_label_1]
action: keep
regex: '.+'
Rinominare le metriche La ridenominazione delle metriche non è supportata.
Annotazioni
Se si desidera aggiungere etichette a tutti i processi nella configurazione personalizzata, aggiungere in modo esplicito etichette usando metrics_relabel_configs per ogni processo. Le etichette esterne globali non sono supportate tramite la configurazione prometheus basata su ConfigMap.
relabel_configs:
- source_labels: [__address__]
target_label: example_label
replacement: 'example_value'
Autenticazione di base e token portatore
Se si usano nome utente, password o credenziali come testo non crittografato nella configurazione di scrape, non sono necessarie modifiche aggiuntive. I valori specificati nella configurazione verranno utilizzati per l'estrazione dei dati. Se stai utilizzando i parametri di configurazione username_file o password_file (o eventuali impostazioni di configurazione _file) per le impostazioni basic_auth o bearer_token nella tua configurazione di prometheus, segui i passaggi riportati di seguito:
Creare un segreto nello spazio dei nomi
kube-systemcon nomeama-metrics-mtls-secret.Il nome della chiave
password1può essere qualsiasi cosa purché corrisponda al nome del file nelpassword_filepercorso 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-secretsegreto viene caricato suiama-metricspod nel percorso/etc/prometheus/certs/e viene reso disponibile allo scraper di Prometheus. La chiave (password1nell'esempio precedente) sarà il nome del file. Il valore è decodificato in base64 e aggiunto come contenuto del file all'interno del contenitore.Specificare il percorso file nella configurazione di scrape personalizzata in ConfigMap:
Autenticazione di base Il
usernamecampo deve contenere la stringa del nome utente effettiva. Ilpassword_filecampo 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/password1Token di connessione Il
bearer_token_filecampo 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
Per altre informazioni su queste impostazioni , vedere la documentazione di Prometheus scrape_config .
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.
Creare un segreto nello spazio dei nomi
kube-systemcon nomeama-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_contentIl
ama-metrics-mtls-secretsegreto viene caricato suiama-metricspod nel percorso/etc/prometheus/certs/e viene reso disponibile allo scraper di Prometheus. La chiave sarà il nome del file. Il valore è decodificato in base64 e aggiunto come contenuto del file all'interno del contenitore.Specificare il percorso file nella configurazione di Prometheus, PodMonitor o ServiceMonitor:
- Usare l'esempio seguente per specificare l'impostazione di configurazione TLS in un oggetto ConfigMap:
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 desidera usare sia l'autenticazione di base che il token di connessione (credenziali basate su file) e le impostazioni di autenticazione TLS in ConfigMap, assicurarsi che il segreto ama-metrics-mtls-secret includa tutte le chiavi nella sezione dati con i valori con codifica base64 corrispondenti, come illustrato nell'esempio seguente:
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
Annotazioni
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 si trova nello kube-system spazio dei nomi.
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 un segreto, ma vi è un oggetto ConfigMap, PodMonitor o ServiceMonitor che punta a quel segreto, l'errore seguente apparirà nei log del contenitore ama-metrics prometheus-collector: no file found for cert....
Per altre informazioni sulle impostazioni di configurazione di TLS, vedere tls_config.
Installazione avanzata: configurare processi di raccolta personalizzati di Prometheus per il DaemonSet
Il pod di replica ama-metrics utilizza la configurazione personalizzata di Prometheus e scorpora le destinazioni specificate. Per un cluster con un numero elevato di nodi e pod e un volume elevato di metriche da scorporare, alcune delle destinazioni di scorporo personalizzate applicabili possono essere scaricate dal pod di replica singola ama-metrics al pod DaemonSet ama-metrics.
La ama-metrics-prometheus-config-node ConfigMap è simile alla ConfigMap del replica-set e può essere creata per avere configurazioni di scrape statiche su ciascun nodo. La configurazione di scrape deve avere come destinazione solo un singolo nodo e non deve utilizzare l'individuazione del servizio o le annotazioni dei pod. In caso contrario, ogni nodo tenta di scorporare tutte le destinazioni ed effettua molte chiamate al server API Kubernetes.
Le destinazioni di scrape personalizzate possono seguire lo stesso formato usando static_configs con le destinazioni e usando la $NODE_IP variabile di ambiente e specificando la porta da raschiare. Ogni pod del DaemonSet accetta la configurazione, scorpora le metriche e le invia per tale nodo.
La configurazione seguente node-exporter è una delle destinazioni predefinite per i pod DaemonSet. Usa la $NODE_IP variabile di ambiente, già impostata per ogni ama-metrics contenitore del componente aggiuntivo per specificare una porta specifica nel nodo.
- job_name: nodesample
scrape_interval: 30s
scheme: http
metrics_path: /metrics
relabel_configs:
- source_labels: [__metrics_path__]
regex: (.*)
target_label: metrics_path
- source_labels: [__address__]
replacement: '$NODE_NAME'
target_label: instance
static_configs:
- targets: ['$NODE_IP:9100']
Impostazioni di configurazione di Scrape
Le sezioni seguenti descrivono le impostazioni supportate nel file di configurazione prometheus usato in ConfigMap. Per altre informazioni su queste impostazioni, vedere le informazioni di riferimento sulla configurazione di Prometheus .
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.
Annotazioni
Se si vogliono usare le impostazioni globali applicabili a tutti i processi di scrape e si dispone solo di risorse personalizzate , è comunque necessario creare un oggetto ConfigMap con solo le impostazioni globali(Impostazioni per ognuna di queste risorse personalizzate sostituiranno quelle nella sezione globale)