sidecar Prometheus precedente

Il formato di esposizione Prometheus è una convenzione utilizzata da molte applicazioni, in particolare su Kubernetes, per esportare le proprie metriche. Prometheus è uno strumento di monitoraggio open source ampiamente utilizzato per raccogliere, archiviare ed eseguire query su tali metriche. Offriamo diversi modi per integrare le metriche in stile Prometheus con Cloud Monitoring.

Metodo Stato del supporto Note
Google Cloud Managed Service per Prometheus (consigliato) La versione di cui è stato eseguito il deployment automatico è disponibile in tutti gli ambienti
La raccolta gestita è disponibile in tutti gli ambienti Kubernetes.
La raccolta gestita tramite gcloud è disponibile nelle versioni 1.22 e successive di GKE 		Offre la massima compatibilità con l'ecosistema open source tramite PromQL
Con prezzi inferiori alle metriche esterne
Server Prometheus con raccoglitore Stackdriver Deprecato
L'assistenza dipende dalla versione del server Prometheus 		Le metriche in stile Prometheus vengono importate come metriche esterne.
Metriche del carico di lavoro GKE Deprecato
Supportato nelle versioni di GKE da 1.20.8-gke.2100 a 1.23, ma non più disponibile a partire dalla versione 1.24. 		Non addebitabile durante il ritiro

Il resto della pagina descrive come configurare e utilizzare Prometheus con Cloud Operations for GKE utilizzando il raccoglitore Stackdriver.

Il codice sorgente per l'integrazione è disponibile pubblicamente.

Prima di iniziare

Assicurati di aver già creato un cluster GKE con Cloud Operations for GKE abilitato e installato un server Prometheus.

Prometheus non fornisce il supporto integrato per Windows Server. Come soluzione alternativa, puoi eseguire il deployment del server Prometheus in un pool di nodi Linux aggiuntivo per acquisire le metriche di Windows e inviarle nuovamente al raccoglitore Stackdriver nel pool di nodi Linux.

Prima di installare il raccoglitore Stackdriver, esamina attentamente i seguenti requisiti:

Installazione del raccoglitore

Per eseguire il deployment del raccoglitore Stackdriver, procedi come segue:

  1. Identifica l'oggetto da aggiornare con il suo nome e il tipo di controller. Sono supportati solo i tipi di controller deployment e statefulset.

  2. Imposta le seguenti variabili di ambiente:

    • KUBE_NAMESPACE: spazio dei nomi in base al quale eseguire lo script.
    • KUBE_CLUSTER: parametro del nome del cluster Sidecar.
    • GCP_REGION: parametro dell'area geografica di Google Cloud di Sidecar.
    • GCP_PROJECT: parametro di progetto Google Cloud di Sidecar.
    • DATA_DIR: directory dei dati di Sidecar. Questa è la directory che ospita il volume condiviso in cui scrive il tuo server Prometheus. Nelle istruzioni seguenti, questa variabile è impostata sul valore /data.
    • DATA_VOLUME: nome del volume condiviso in DATA_DIR che contiene i dati di Prometheus. Nelle istruzioni successive, questa variabile è impostata su data-volume.
    • SIDECAR_IMAGE_TAG: versione immagine Docker per la sidecar Prometheus. L'ultima release è disponibile in Container Registry.

  3. Esegui lo script seguente e fornisci i due parametri identificati nel passaggio iniziale di questa procedura:

    kube/patch.sh 
    #!/bin/sh

set -e
set -u

CLEAN_UP_ORPHANED_REPLICA_SETS='--clean-up-orphaned-replica-sets'
usage() {
  echo -e "Usage: $0 <deployment|statefulset> <name> [${CLEAN_UP_ORPHANED_REPLICA_SETS}]\n"
}

if [  $# -le 1 ]; then
  usage
  exit 1
fi

SHOULD_CLEAN_UP=${3:-}

# Override to use a different Docker image name for the sidecar.
export SIDECAR_IMAGE_NAME=${SIDECAR_IMAGE_NAME:-'gcr.io/stackdriver-prometheus/stackdriver-prometheus-sidecar'}

kubectl -n "${KUBE_NAMESPACE}" patch "$1" "$2" --type strategic --patch "
spec:
  template:
    spec:
      containers:
      - name: sidecar
        image: ${SIDECAR_IMAGE_NAME}:${SIDECAR_IMAGE_TAG}
        imagePullPolicy: Always
        args:
        - \"--stackdriver.project-id=${GCP_PROJECT}\"
        - \"--prometheus.wal-directory=${DATA_DIR}/wal\"
        - \"--stackdriver.kubernetes.location=${GCP_REGION}\"
        - \"--stackdriver.kubernetes.cluster-name=${KUBE_CLUSTER}\"
        #- \"--stackdriver.generic.location=${GCP_REGION}\"
        #- \"--stackdriver.generic.namespace=${KUBE_CLUSTER}\"
        ports:
        - name: sidecar
          containerPort: 9091
        volumeMounts:
        - name: ${DATA_VOLUME}
          mountPath: ${DATA_DIR}
"
if [[ "${SHOULD_CLEAN_UP}" == "${CLEAN_UP_ORPHANED_REPLICA_SETS}" ]]; then
  # Delete the replica sets from the old deployment. If the Prometheus Server is
  # a deployment that does not have `revisionHistoryLimit` set to 0, this is
  # useful to avoid PVC conflicts between the old replica set and the new one
  # that prevents the pod from entering a RUNNING state.
  kubectl -n "${KUBE_NAMESPACE}" get rs | grep "$2-" | awk '{print $1}' | xargs kubectl delete -n "${KUBE_NAMESPACE}" rs
fi

Dopo l'esecuzione corretta dello script, il raccoglitore Stackdriver viene aggiunto come sidecar ai pod per l'oggetto identificato nel passaggio 1 della procedura. Le due righe dello script commentate non sono pertinenti alla raccolta di dati delle metriche dai cluster GKE. Tuttavia, queste due righe sono pertinenti quando vuoi inserire un valore generico MonitoredResource.

Per rendere permanenti le modifiche alla configurazione, devi eseguire ulteriori passaggi. Questi passaggi sono descritti nelle sezioni successive.

Convalida dell'installazione

Per convalidare l'installazione del raccoglitore Stackdriver, esegui il comando seguente:

kubectl -n "${KUBE_NAMESPACE}" get <deployment|statefulset> <name> -o=go-template='{{$output := "stackdriver-prometheus-sidecar does not exist."}}{{range .spec.template.spec.containers}}{{if eq .name "sidecar"}}{{$output = (print "stackdriver-prometheus-sidecar exists. Image: " .image)}}{{end}}{{end}}{{printf $output}}{{"\n"}}'

  • Se il sidecar Prometheus è stato installato correttamente, l'output dello script elenca l'immagine utilizzata da Container Registry. Nell'esempio seguente, la versione dell'immagine è 0.4.3. La tua installazione potrebbe essere diversa:

    stackdriver-prometheus-sidecar exists. Image: gcr.io/stackdriver-prometheus/stackdriver-prometheus-sidecar:0.4.3

  • In caso contrario, l'output dello script mostra:

    stackdriver-prometheus-sidecar does not exist.

Per determinare se il tuo carico di lavoro è aggiornato e disponibile, esegui:

kubectl -n "${KUBE_NAMESPACE}" get <deployment|statefulset> <name>

Rendere definitiva la modifica alla configurazione

Dopo aver verificato che il collettore sia stato installato correttamente, aggiorna la configurazione del cluster per rendere permanenti le modifiche:

  1. Configura il server Prometheus in modo che scriva in un volume condiviso. Nei seguenti passaggi di esempio, si presume che DATA_DIR sia stato impostato su /data e DATA_VOLUME sia stato impostato su data-volume:

    1. Assicurati che il pod Prometheus abbia un volume condiviso:

      volumes:
  - name: data-volume
    emptyDir: {}

    2. Fai in modo che Prometheus monta il volume al di sotto di /data:

      volumeMounts:
- name: data-volume
  mountPath: /data

    3. Chiedi al server Prometheus di scrivere nel volume condiviso in /data aggiungendo quanto segue al relativo container args:

      --storage.tsdb.path=/data

  2. Utilizzando gli strumenti che utilizzi per gestire la configurazione dei tuoi carichi di lavoro, applica di nuovo la configurazione al cluster e includi il contenitore di raccolta Stackdriver come sidecar nella nuova configurazione:

    - name: sidecar
  image: gcr.io/stackdriver-prometheus/stackdriver-prometheus-sidecar:[SIDECAR_IMAGE_TAG]
  args:
  - "--stackdriver.project-id=[GCP_PROJECT]"
  - "--prometheus.wal-directory=/data/wal"
  - "--prometheus.api-address=[API_ADDRESS]"
  - "--stackdriver.kubernetes.location=[GCP_REGION]"
  - "--stackdriver.kubernetes.cluster-name=[KUBE_CLUSTER]"
  ports:
  - name: sidecar
    containerPort: 9091
  volumeMounts:
  - name: data-volume
    mountPath: /data

    Nell'espressione precedente, [API_ADDRESS] si riferisce all'indirizzo API di Prometheus's, che in genere è http://127.0.0.1:9090.

Per ulteriori dettagli sulla configurazione per il commerciante, consulta la documentazione relativa al file collaterale di Stackdriver Prometheus.

Visualizzazione delle metriche

Prometheus è configurato per esportare le metriche nella suite operativa di Google Cloud come metriche esterne.

Per visualizzare queste metriche:

  1. In Cloud Console, seleziona Monitoring:

    Vai a Monitoring

  2. Nel riquadro di navigazione di Monitoring, fai clic su Metrics Explorer.

  3. Nel menu Trova tipo di risorsa e metrica:

    • Seleziona Container Kubernetes (k8s_container) per Tipo di risorsa.
    • Nel campo Metrica, seleziona un'opzione con il prefisso external/prometheus/. Ad esempio, potresti selezionare external/prometheus/go_memstats_alloc_bytes.

    Nell'esempio seguente, è stato aggiunto un filtro per visualizzare le metriche per un cluster specifico. Filtrare in base al nome del cluster è utile quando hai più cluster:

    Esempio di metrica Prometheus per un container Kubernetes.

Gestione dei costi per le metriche derivate da Prometheus

In genere, Prometheus è configurato per raccogliere tutte le metriche esportate dall'applicazione e, per impostazione predefinita, il raccoglitore Stackdriver invia queste metriche a Cloud Monitoring. Questa raccolta include metriche esportate dalle librerie da cui dipende l'applicazione. Ad esempio, la libreria client Prometheus esporta molte metriche sull'ambiente dell'applicazione.

Puoi configurare filtri nel raccoglitore Stackdriver per selezionare le metriche da importare in Cloud Monitoring. Ad esempio, per importare solo le metriche generate da kubernetes-pods e kubernetes-service-endpoints, aggiungi la seguente istruzione --include all'avvio di stackdriver-prometheus-sidecar:

 --include={job=~"kubernetes-pods|kubernetes-service-endpoints"}

Per ulteriori informazioni, consulta la documentazione relativa a sidecar di Stackdriver Prometheus.

Puoi anche stimare il contributo di queste metriche alla tua fattura.

Problemi di integrazione di Prometheus

Nessun dato visualizzato in Cloud Monitoring.

Se dopo aver eseguito i passaggi di installazione non vengono visualizzati dati in Cloud Monitoring, cerca nei messaggi del raccoglitore i messaggi di errore.

Se i log non contengono messaggi di errore evidenti, attiva il logging di debug passando il flag --log.level=debug al raccoglitore. Affinché la modifica di logging abbia effetto, devi riavviare il raccoglitore. Dopo aver riavviato il raccoglitore, cerca i messaggi di errore nei log del raccoglitore.

Per verificare che i dati vengano inviati a Cloud Monitoring, puoi inviare le richieste ai file utilizzando il parametro della riga di comando --stackdriver.store-in-files-directory, quindi controllare i file in questa directory.

Autorizzazione negata

Se noti errori di autorizzazione negata dall'API Monitoring, consulta i requisiti descritti nella sezione Prima di iniziare. Assicurati che i tuoi account di servizio dispongano dell'autorizzazione appropriata. Se utilizzi l'identità del carico di lavoro, assicurati di creare una relazione tra KSA e GSA.

Uso delle regole di registrazione e delle metriche non visibili in Cloud Monitoring.

Quando utilizzi i ruoli di registrazione, se possibile, importa la metrica non elaborata in Cloud Monitoring e utilizza le funzionalità di Cloud Monitoring per aggregare i dati quando crei un grafico o una dashboard.

Se l'importazione della metrica non elaborata non è disponibile, aggiungi una voce static_metadata nella configurazione del collector&s3. Questa opzione richiede di conservare le etichette job e instance. Ad esempio, la configurazione attuale è valida:

  • La configurazione del server Prometheus:

    groups:
- name: my-groups
  rules:
  - record: backlog_avg_10m
    expr: avg_over_time(backlog_k8s[10m])
  - record: backlog_k8s
    expr: sum(total_lag) by (app, job, instance)

  • La configurazione del tuo raccoglitore Prometheus:

    static_metadata:
  - metric: backlog_avg_10m
    type: gauge

Non sono supportate le regole di registrazione che modificano o rimuovono le etichette job o instance.

Nelle metriche mancano le etichette job e instance Prometheus.

Il raccoglitore Stackdriver per Prometheus crea una piattaforma MonitoredResource per Cloud Monitoring per i tuoi oggetti Kubernetes da etichette Prometheus note. Quando modifichi i descrittori delle etichette, il raccoglitore non può scrivere le metriche in Monitoring.

Ho visto "serie temporali duplicate" o "scritture fuori ordine" nei log.

Questi errori sono causati dalla scrittura due volte dei dati delle metriche nella stessa serie temporale. Si verificano quando gli endpoint Prometheus utilizzano la stessa metrica due volte da una singola risorsa monitorata in Cloud Monitoring.

Ad esempio, un container Kubernetes potrebbe inviare metriche Prometheus su più porte. Poiché la risorsa monitorata k8s_container non monitora le risorse in base alla porta, Monitoring rileva che stai scrivendo due punti della stessa serie temporale. Per evitare questa situazione, aggiungi un'etichetta di metrica in Prometheus che differenzia la serie temporale. Ad esempio, potresti utilizzare l'etichetta __meta_kubernetes_pod_annotation_prometheus_io_port, perché rimane costante in tutti i riavvii del container.

Vedo che il tipo di metrica deve essere X, ma contiene Y" errori nei log.

Questi errori sono causati dalla modifica del tipo di metrica Prometheus per un descrittore della metrica esistente. Le metriche di Cloud Monitoring vengono digitate rigorosamente e non supportano la modifica di un tipo di metrica tra contatore, contatore e altri.

Per modificare un tipo di metrica, devi eliminare i descrittori della metrica corrispondenti e crearne uno nuovo. L'eliminazione di un descrittore della metrica rende inaccessibili i dati delle serie temporali esistenti.

Ho notato che prima potevo visualizzare i tipi di metriche di Prometheus, ma ora non riesco a trovarli.

Prometheus è preconfigurato per esportare le metriche in Cloud Monitoring come metriche esterne. Quando i dati vengono esportati, Monitoring crea il descrittore della metrica appropriata per la metrica esterna. Se non vengono scritti dati per questo tipo di metrica per almeno 24 mesi, il descrittore della metrica è soggetto a eliminazione.

Non è garantito che i descrittori delle metriche inutilizzati vengano eliminati dopo 24 mesi, ma Monitoring si riserva il diritto di eliminare tutti i descrittori delle metriche di Prometheus non utilizzati nei 24 mesi precedenti.

Norme sul ritiro

L'integrazione di Prometheus con Cloud Monitoring è soggetta alle norme sul ritiro degli agenti.