Sidecar di Prometheus precedente

Mantieni tutto organizzato con le raccolte Salva e classifica i contenuti in base alle tue preferenze.

Il formato di esposizione di Prometheus è una convenzione utilizzata da molte applicazioni, in particolare su Kubernetes, per esportare le 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 piena compatibilità con l'ecosistema open source tramite PromQL
Con prezzi inferiori a metriche esterne
Server Prometheus con il raccoglitore Stackdriver Obsoleto
L'assistenza dipende dalla versione del server Prometheus
Le metriche di 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 verrà interrotto dalla 1.24 in poi
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 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 al raccoglitore Stackdriver nel pool di nodi Linux.

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

Installazione del raccoglitore

Per eseguire il deployment del raccoglitore Stackdriver, procedi nel seguente modo:

  1. Identifica l'oggetto da aggiornare mediante il 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 per eseguire lo script.
    • KUBE_CLUSTER: parametro del nome del cluster di Sidecar.
    • GCP_REGION: parametro per le regioni di Google Cloud di Sidecar.
    • GCP_PROJECT: parametro del progetto Google Cloud di Sidecar.
    • DATA_DIR: directory dei dati di Sidecar. Questa è la directory che ospita il volume condiviso in cui scrive il server Prometheus. Nelle istruzioni successive, 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 dell'immagine Docker per il file collaterale di Prometheus. La release più recente è disponibile in Container Registry.
  3. Esegui il seguente script e fornisci i due parametri identificati nel passaggio iniziale di questa procedura:

    #!/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 nello script commentate non sono pertinenti alla raccolta dei dati delle metriche dai cluster GKE. Tuttavia, queste due righe sono pertinenti quando vuoi compilare un elemento generico MonitoredResource.

Devi eseguire ulteriori passaggi per rendere permanenti le modifiche alla configurazione. Questi passaggi sono descritti nelle sezioni successive.

Convalida dell'installazione

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

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"}}'

  • Una volta installata la sidecar Prometheus, l'output dello script elenca l'immagine utilizzata da Container Registry. Nell'esempio seguente, la versione dell'immagine è 0.4.3. Nell'installazione, la versione 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 permanente la modifica della configurazione

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

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

    1. Assicurati che sia presente un volume condiviso nel pod Prometheus:

      volumes:
        - name: data-volume
          emptyDir: {}
      
    2. Chiedi a Prometheus di montare il volume sotto /data:

      volumeMounts:
      - name: data-volume
        mountPath: /data
      
    3. Fornisci al server Prometheus la scrittura nel volume condiviso in /data aggiungendo quanto segue al container args:

      --storage.tsdb.path=/data
      
  2. Utilizzando gli strumenti che utilizzi per gestire la configurazione dei carichi di lavoro, applica nuovamente la configurazione al cluster e includi il container raccoglitore 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, che in genere è http://127.0.0.1:9090.

Per ulteriori dettagli sulla configurazione del raccoglitore, consulta la documentazione relativa a sidecar 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. Nella console Google Cloud, seleziona Monitoring:

    Vai a Monitoring

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

  3. Nel menu Trova risorsa e metrica:

    • Seleziona Container Kubernetes (k8s_container) come 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. Il filtro per nome 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 le metriche esportate dalle librerie da cui dipende l'applicazione. Ad esempio, la libreria client Prometheus esporta molte metriche sull'ambiente dell'applicazione.

Puoi configurare i 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 quando avvii stackdriver-prometheus-sidecar:

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

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

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

Problemi di integrazione di Prometheus

Nessun dato viene visualizzato in Cloud Monitoring.

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

Se i log non contengono messaggi di errore evidenti, attiva il logging di debug passando il flag --log.level=debug al raccoglitore. Devi riavviare il raccoglitore per applicare la modifica del logging. 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 e quindi ispezionare i file in questa directory.

Autorizzazione negata

Se noti errori di autorizzazione negati dall'API Monitoring, consulta i requisiti descritti in 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 GPA.

Utilizzo le regole di registrazione e le metriche non vengono visualizzate in Cloud Monitoring.

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

Se l'importazione della metrica non elaborata non è possibile, aggiungi una voce static_metadata nella configurazione del raccoglitore. Per questa opzione è necessario 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 tua configurazione del raccoglitore Prometheus:

    static_metadata:
      - metric: backlog_avg_10m
        type: gauge
    

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

Nelle mie metriche mancano le etichette Prometheus job e instance.

Il raccoglitore Stackdriver per Prometheus crea una risorsa MonitoredResource di Cloud Monitoring per gli oggetti Kubernetes da etichette Prometheus note. Quando modifichi i descrittori delle etichette, il raccoglitore non è in grado di scrivere le metriche in Monitoring.

I log sono contrassegnati da errori di "serie temporali duplicate" o di "scritture fuori ordine".

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

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

Visualizzo un errore "tipo di metrica deve essere X, ma è Y" nei log.

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

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

Sicuramente ho già visto le metriche di Prometheus, ma ora non riesco a trovarle.

Prometheus è preconfigurato per esportare le metriche in Cloud Monitoring come metriche esterne. Quando i dati vengono esportati, Monitoring crea il descrittore della metrica appropriato per la metrica esterna. Se nessun dato di questo tipo di metrica viene scritto per almeno 24 mesi, il descrittore della metrica viene eliminato.

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

Norme sul ritiro

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