Utilizzo di logging e monitoraggio per i componenti del sistema

Questo documento mostra come configurare logging e monitoraggio per i componenti di sistema in GKE su VMware.

Per impostazione predefinita, Cloud Logging, Cloud Monitoring e Google Cloud Managed Service per Prometheus sono abilitati.

Per maggiori informazioni sulle opzioni, consulta Panoramica di Logging e monitoraggio.

Risorse monitorate

Le risorse monitorate sono il modo in cui Google rappresenta risorse come cluster, nodi, pod e container. Per saperne di più, consulta la documentazione sui tipi di risorse monitorate di Cloud Monitoring.

Per eseguire query su log e metriche, devi conoscere almeno queste etichette delle risorse:

  • project_id: ID progetto del progetto di monitoraggio del logging del cluster. Hai fornito questo valore nel campo stackdriver.projectID del file di configurazione del cluster.

  • location: una regione Google Cloud in cui vuoi archiviare i log di Cloud Logging e le metriche di Cloud Monitoring. È una buona idea scegliere un'area geografica vicina al tuo data center on-premise. Hai fornito questo valore durante l'installazione nel campo stackdriver.clusterLocation del file di configurazione del cluster.

  • cluster_name: nome del cluster che hai scelto al momento della creazione del cluster.

    Puoi recuperare il valore cluster_name per il cluster di amministrazione o per il cluster utente ispezionando la risorsa personalizzata Stackdriver:

    kubectl get stackdriver stackdriver --namespace kube-system \
--kubeconfig CLUSTER_KUBECONFIG --output yaml | grep 'clusterName:'

    dove

    • CLUSTER_KUBECONFIG è il percorso del file kubeconfig del cluster di amministrazione o del cluster utente per cui è richiesto il nome del cluster.

Utilizzo di Cloud Logging

Non devi intraprendere alcuna azione per abilitare Cloud Logging per un cluster. Tuttavia, devi specificare il progetto Google Cloud in cui vuoi visualizzare i log. Nel file di configurazione del cluster, specifichi il progetto Google Cloud nella sezione stackdriver.

Puoi accedere ai log utilizzando Esplora log nella console Google Cloud. Ad esempio, per accedere ai log di un container:

  1. Apri Esplora log nella console Google Cloud per il tuo progetto.
  2. Trova i log per un container in base a:
    1. Fai clic sulla casella a discesa del catalogo dei log in alto a sinistra e seleziona Container Kubernetes.
    2. Selezionare il nome del cluster, poi lo spazio dei nomi e infine un container dalla gerarchia.

Visualizzazione dei log per i controller nel cluster di bootstrap

  1. Trova il nome del pod onprem-admin-cluster-controller / clusterapi-controllers

    Per impostazione predefinita, il nome del cluster tipo è gkectl-bootstrap-cluster.

    "ADMIN_CLUSTER_NAME"
resource.type="k8s_container"
resource.labels.cluster_name="gkectl-bootstrap-cluster"

  2. Modifica la query utilizzando il nome del pod trovato e recupera il log

    resource.type="k8s_container"
resource.labels.cluster_name="gkectl-bootstrap-cluster"
resource.labels.pod_name="POD_NAME"

Utilizzo di Cloud Monitoring

Non è richiesta alcuna azione da parte tua per abilitare Cloud Monitoring per un cluster. Tuttavia, devi specificare il progetto Google Cloud in cui vuoi visualizzare le metriche. Nel file di configurazione del cluster, specifichi il progetto Google Cloud nella sezione stackdriver.

Puoi scegliere tra oltre 1500 metriche utilizzando Metrics Explorer. Per accedere a Metrics Explorer, segui questi passaggi:

  1. Nella console Google Cloud, seleziona Monitoring o utilizza il pulsante seguente:

    Vai a Monitoring

  2. Seleziona Risorse > Metrics Explorer.

Puoi anche visualizzare le metriche nelle dashboard della console Google Cloud. Per informazioni sulla creazione delle dashboard e sulla visualizzazione delle metriche, consulta Creazione delle dashboard.

Visualizzazione dei dati di monitoraggio a livello di parco risorse

Per una visualizzazione complessiva dell'utilizzo delle risorse del tuo parco risorse con i dati di Cloud Monitoring, tra cui GKE su VMware, puoi utilizzare la panoramica di GKE Enterprise nella console Google Cloud. Per saperne di più, consulta Utilizzare la panoramica di GKE Enterprise.

Limiti di quota predefiniti di Cloud Monitoring

Il monitoraggio di GKE su VMware ha un limite predefinito di 6000 chiamate API al minuto per ogni progetto. Se superi questo limite, le tue metriche potrebbero non essere visualizzate. Se hai bisogno di un limite di monitoraggio più elevato, richiedine uno tramite la console Google Cloud.

Utilizzo di Managed Service per Prometheus

Google Cloud Managed Service per Prometheus fa parte di Cloud Monitoring ed è disponibile per impostazione predefinita. I vantaggi di Managed Service per Prometheus includono quanto segue:

  • Puoi continuare a utilizzare il monitoraggio esistente basato su Prometheus senza modificare gli avvisi e le dashboard Grafana.

  • Se utilizzi sia GKE che GKE su VMware, puoi utilizzare lo stesso PromQL per le metriche su tutti i tuoi cluster. Puoi anche utilizzare la scheda PROMQL in Metrics Explorer nella console Google Cloud.

Abilitazione e disabilitazione di Managed Service per Prometheus

Managed Service per Prometheus è abilitato per impostazione predefinita in GKE su VMware.

Per disabilitare Managed Service per Prometheus in un cluster:

  1. Apri l'oggetto Stackdriver denominato stackdriver per la modifica:

    kubectl --kubeconfig CLUSTER_KUBECONFIG --namespace kube-system \
    edit stackdriver stackdriver

  2. Aggiungi la limitazione delle funzionalità enableGMPForSystemMetrics e impostala su false:

    apiVersion: addons.gke.io/v1alpha1
kind: Stackdriver
metadata:
  name: stackdriver
  namespace: kube-system
spec:
  featureGates:
    enableGMPForSystemMetrics: false

  3. Chiudi la sessione di modifica.

Visualizzare i dati delle metriche

Quando Managed Service per Prometheus è abilitato, le metriche per i seguenti componenti hanno un formato diverso per il modo in cui vengono archiviati e sottoposti a query in Cloud Monitoring:

  • kube-apiserver
  • kube-scheduler
  • kube-controller-manager
  • kubelet e cadvisor
  • kube-state-metrics
  • esportatore di nodi

Nel nuovo formato, puoi eseguire query sulle metriche precedenti utilizzando PromQL o MQL (Monitoring Query Language).

Esempio di PromQL:

histogram_quantile(0.95, sum(rate(apiserver_request_duration_seconds_bucket[5m])) by (le))

Per utilizzare MQL, imposta la risorsa monitorata su prometheus_target e aggiungi il tipo Prometheus come suffisso alla metrica.

Esempio di MQL:

fetch prometheus_target
| metric 'kubernetes.io/anthos/apiserver_request_duration_seconds/histogram'
| align delta(5m)
| every 5m
| group_by [], [value_histogram_percentile: percentile(value.histogram, 95)]

Configurazione delle dashboard Grafana con Managed Service per Prometheus

Per utilizzare Grafana con i dati delle metriche di Managed Service per Prometheus, segui i passaggi descritti in Eseguire query utilizzando Grafana per autenticare e configurare un'origine dati Grafana per eseguire query sui dati di Managed Service for Prometheus.

Un set di dashboard Grafana di esempio è fornito nel repository anthos-samples su GitHub. Per installare le dashboard di esempio, segui questi passaggi:

  1. Scarica i file .json di esempio:

    git clone https://github.com/GoogleCloudPlatform/anthos-samples.git
cd anthos-samples/gmp-grafana-dashboards

  2. Se l'origine dati Grafana è stata creata con un nome diverso utilizzando Managed Service for Prometheus, modifica il campo datasource in tutti i file .json:

    sed -i "s/Managed Service for Prometheus/[DATASOURCE_NAME]/g" ./*.json

    Sostituisci [DATASOURCE_NAME] con il nome dell'origine dati nella tua Grafana che puntava al servizio Prometheus frontend.

  3. Accedi all'interfaccia utente di Grafana dal browser e seleziona + Importa dal menu Dashboard.

    Navigazione all'importazione della dashboard in Grafana in corso...

  4. Carica il file .json o copia e incolla i contenuti del file e seleziona Carica. Dopo aver caricato correttamente i contenuti, seleziona Importa. Facoltativamente, puoi anche modificare il nome e l'UID della dashboard prima dell'importazione.

    Importazione della dashboard in Grafana in corso.

  5. La dashboard importata dovrebbe caricarsi correttamente se GKE su VMware e l'origine dati sono configurati correttamente. Ad esempio, il seguente screenshot mostra la dashboard configurata da cluster-capacity.json.

    Dashboard della capacità dei cluster in Grafana.

Risorse aggiuntive

Per ulteriori informazioni su Managed Service per Prometheus, consulta quanto segue:

Utilizzo di Prometheus e Grafana

A partire dalla versione 1.16, Prometheus e Grafana non sono disponibili nei cluster appena creati. Ti consigliamo di utilizzare Managed Service per Prometheus in sostituzione del monitoraggio nel cluster.

Se esegui l'upgrade di un cluster 1.15 in cui sono abilitati Prometheus e Grafana alla versione 1.16, Prometheus e Grafana continueranno a funzionare così com'è, ma non verranno aggiornati né verranno fornite patch di sicurezza.

Se vuoi eliminare tutte le risorse Prometheus e Grafana dopo aver eseguito l'upgrade alla versione 1.16, esegui questo comando:

kubectl --kubeconfig KUBECONFIG delete -n kube-system \
    statefulsets,services,configmaps,secrets,serviceaccounts,clusterroles,clusterrolebindings,certificates,deployments \
    -l addons.gke.io/legacy-pg=true

In alternativa all'utilizzo dei componenti Prometheus e Grafana inclusi nelle versioni precedenti di GKE su VMware, puoi passare a una versione open source della community di Prometheus e Grafana.

Problema noto

Nei cluster utente, Prometheus e Grafana vengono disabilitati automaticamente durante l'upgrade. Tuttavia, i dati di configurazione e metriche non andranno persi.

Per risolvere il problema, dopo l'upgrade, apri monitoring-sample per modificarlo e imposta enablePrometheus su true.

Accesso alle metriche di monitoraggio dalle dashboard di Grafana

Grafana mostra le metriche raccolte dai tuoi cluster. Per visualizzare queste metriche, devi accedere alle dashboard di Grafana:

  1. Recupera il nome del pod Grafana in esecuzione nello spazio dei nomi kube-system di un cluster utente:

    kubectl --kubeconfig [USER_CLUSTER_KUBECONFIG] -n kube-system get pods

    dove [USER_CLUSTER_KUBECONFIG] è il file kubeconfig del cluster utente.

  2. Il pod Grafana ha un server HTTP in ascolto sulla porta localhost TCP 3000. Inoltrare una porta locale alla porta 3000 nel pod, in modo da poter visualizzare le dashboard di Grafana da un browser web.

    Ad esempio, supponiamo che il nome del pod sia grafana-0. Per eseguire il forwarding dalla porta 50000 alla porta 3000 nel pod, inserisci questo comando:

    kubectl --kubeconfig [USER_CLUSTER_KUBECONFIG] -n kube-system port-forward grafana-0 50000:3000

  3. Da un browser web, vai a http://localhost:50000.

  4. Nella pagina di accesso, inserisci admin come nome utente e password.

  5. Se l'accesso va a buon fine, ti verrà richiesto di cambiare la password. Dopo aver cambiato la password predefinita, dovrebbe essere caricata la dashboard della home page di Grafana del cluster utente.

  6. Per accedere ad altre dashboard, fai clic sul menu a discesa Home nell'angolo in alto a sinistra della pagina.

Per un esempio di utilizzo di Grafana, vedi Creare una dashboard Grafana.

Accesso agli avvisi

Prometheus Alertmanager raccoglie gli avvisi dal server Prometheus. Puoi visualizzare questi avvisi nella dashboard Grafana. Per visualizzare gli avvisi, devi accedere alla dashboard:

  1. Il container nel pod alertmanager-0 rimane in ascolto sulla porta TCP 9093. Inoltra una porta locale alla porta 9093 nel pod:

    kubectl --kubeconfig [USER_CLUSTER_KUBECONFIG] port-forward \
   -n kube-system alertmanager-0 50001:9093

  2. Da un browser web, vai a http://localhost:50001.

Modifica della configurazione di Prometheus Alertmanager

Puoi cambiare la configurazione predefinita di Prometheus Alertmanager modificando il file monitoring.yaml del cluster utente. È consigliabile farlo se vuoi indirizzare gli avvisi a una destinazione specifica, anziché tenerli nella dashboard. Puoi scoprire come configurare Alertmanager nella documentazione relativa alla configurazione di Prometheus.

Per modificare la configurazione di Alertmanager, segui questi passaggi:

  1. Crea una copia del file manifest monitoring.yaml del cluster utente:

    kubectl --kubeconfig [USER_CLUSTER_KUBECONFIG] -n kube-system \
   get monitoring monitoring-sample -o yaml > monitoring.yaml

  2. Per configurare Alertmanager, apporta modifiche ai campi in spec.alertmanager.yml. Al termine, salva il manifest modificato.

  3. Applica il manifest al tuo cluster:

    kubectl apply --kubeconfig [USER_CLUSTER_KUBECONIFG] -f monitoring.yaml

Crea una dashboard Grafana

Hai eseguito il deployment di un'applicazione che espone una metrica, verificato che la metrica sia esposta e verificato che Prometheus esegua lo scraping della metrica. Ora puoi aggiungere la metrica a livello di applicazione a una dashboard Grafana personalizzata.

Per creare una dashboard di Grafana, segui questi passaggi:

  1. Se necessario, ottieni l'accesso a Grafana.
  2. Nella dashboard della home page, fai clic sul menu a discesa Home nell'angolo in alto a sinistra della pagina.
  3. Nel menu a destra, fai clic su Nuova dashboard.
  4. Nella sezione Nuovo riquadro, fai clic su Grafico. Viene visualizzata una dashboard del grafico vuota.
  5. Fai clic su Titolo del riquadro e poi su Modifica. Il riquadro Grafico in basso si apre sulla scheda Metriche.
  6. Nel menu a discesa Origine dati, seleziona utente. Fai clic su Aggiungi query e inserisci foo nel campo cerca.
  7. Fai clic sul pulsante Torna alla dashboard nell'angolo in alto a destra dello schermo. Viene visualizzata la tua dashboard.
  8. Per salvare la dashboard, fai clic su Salva dashboard nell'angolo in alto a destra dello schermo. Scegli un nome per la dashboard e fai clic su Salva.

Disattivazione di Prometheus e Grafana

A partire dalla versione 1.16, Prometheus e Grafana non sono più controllati dal campo enablePrometheus nell'oggetto monitoring-sample. Per maggiori dettagli, vedi Utilizzo di Prometheus e Grafana.

Esempio: aggiunta di metriche a livello di applicazione a una dashboard Grafana

Le sezioni seguenti illustrano come aggiungere metriche per un'applicazione. In questa sezione vengono completate le seguenti attività:

  • Esegui il deployment di un'applicazione di esempio che espone una metrica denominata foo.
  • Verifica che Prometheus esponga ed esegua lo scraping dei dati della metrica.
  • Crea una dashboard Grafana personalizzata.

Esegui il deployment dell'applicazione di esempio

L'applicazione di esempio viene eseguita in un singolo pod. Il container del pod espone una metrica, foo, con un valore costante di 40.

Crea il seguente manifest del pod, pro-pod.yaml:

apiVersion: v1
kind: Pod
metadata:
  name: prometheus-example
  annotations:
    prometheus.io/scrape: 'true'
    prometheus.io/port: '8080'
    prometheus.io/path: '/metrics'
spec:
  containers:
  - image: registry.k8s.io/prometheus-dummy-exporter:v0.1.0
    name: prometheus-example
    command:
    - /bin/sh
    - -c
    - ./prometheus_dummy_exporter --metric-name=foo --metric-value=40 --port=8080

Quindi applica il manifest del pod al cluster utente:

kubectl --kubeconfig [USER_CLUSTER_KUBECONFIG] apply -f pro-pod.yaml

Verifica che la metrica sia esposta e recuperata tramite scraping

  1. Il container nel pod prometheus-example rimane in ascolto sulla porta TCP 8080. Inoltra una porta locale alla porta 8080 nel pod:

    kubectl --kubeconfig [USER_CLUSTER_KUBECONFIG] port-forward prometheus-example 50002:8080

  2. Per verificare che l'applicazione esponga la metrica, esegui questo comando:

    curl localhost:50002/metrics | grep foo

    Il comando restituisce il seguente output:

    # HELP foo Custom metric
# TYPE foo gauge
foo 40

  3. Il container nel pod prometheus-0 rimane in ascolto sulla porta TCP 9090. Inoltra una porta locale alla porta 9090 nel pod:

    kubectl --kubeconfig [USER_CLUSTER_KUBECONFIG] port-forward prometheus-0 50003:9090

  4. Per verificare che Prometheus stia eseguendo lo scraping della metrica, accedi a http://localhost:50003/targets, che dovrebbe portarti al pod prometheus-0 nel gruppo di destinazione prometheus-io-pods.

  5. Per visualizzare le metriche in Prometheus, vai a http://localhost:50003/graph. Nel campo di ricerca, inserisci foo e fai clic su Esegui. Nella pagina dovrebbe essere visualizzata la metrica.

Configurazione della risorsa personalizzata Stackdriver

Quando crei un cluster, GKE su VMware crea automaticamente una risorsa personalizzata di Stackdriver. Puoi modificare la specifica nella risorsa personalizzata per eseguire l'override dei valori predefiniti per le richieste e i limiti di CPU e memoria per un componente Stackdriver. Puoi anche sostituire separatamente la dimensione di archiviazione e la classe di archiviazione predefinite.

Esegui l'override dei valori predefiniti per le richieste e i limiti per CPU e memoria

Per ignorare queste impostazioni predefinite:

  1. Apri la risorsa personalizzata Stackdriver in un editor della riga di comando:

    kubectl --kubeconfig=KUBECONFIG -n kube-system edit stackdriver stackdriver

    dove KUBECONFIG è il percorso del file kubeconfig per il cluster. Può essere un cluster di amministrazione o un cluster utente.

  2. Nella risorsa personalizzata Stackdriver, aggiungi il campo resourceAttrOverride nella sezione spec:

    resourceAttrOverride:
      POD_NAME_WITHOUT_RANDOM_SUFFIX/CONTAINER_NAME:
        LIMITS_OR_REQUESTS:
          RESOURCE: RESOURCE_QUANTITY

    Tieni presente che il campo resourceAttrOverride sostituisce tutti i limiti e le richieste predefiniti esistenti per il componente specificato. resourceAttrOverride supporta i seguenti componenti:

    • gke-metrics-agent/gke-metrics-agent
    • stackdriver-log-forwarder/stackdriver-log-forwarder
    • stackdriver-metadata-agent-cluster-level/metadata-agent
    • esportatore-nodi/esportatore-nodi
    • kube-state-metrics/kube-state-metrics

Un file di esempio ha il seguente aspetto 

apiVersion: addons.gke.io/v1alpha1
    kind: Stackdriver
    metadata:
      name: stackdriver
      namespace: kube-system
    spec:
      projectID: my-project
      clusterName: my-cluster
      clusterLocation: us-west-1a
      resourceAttrOverride:
        gke-metrics-agent/gke-metrics-agent:
          requests:
            cpu: 110m
            memory: 240Mi
          limits:
            cpu: 200m
            memory: 4.5Gi

  1. Salva le modifiche ed esci dall'editor della riga di comando.

  2. Controlla l'integrità dei pod:

    kubectl --kubeconfig=KUBECONFIG -n kube-system get pods | grep gke-metrics-agent

    Ad esempio, un pod integro ha il seguente aspetto:

    gke-metrics-agent-4th8r                                1/1     Running   0          5d19h

  3. Controlla le specifiche del pod del componente per assicurarti che le risorse siano impostate correttamente.

    kubectl --kubeconfig=KUBECONFIG -n kube-system describe pod POD_NAME

    dove POD_NAME è il nome del pod che hai appena modificato. Ad esempio, stackdriver-prometheus-k8s-0

    La risposta sarà simile alla seguente:

      Name:         gke-metrics-agent-4th8r
  Namespace:    kube-system
  ...
  Containers:
    gke-metrics-agent:
      Limits:
        cpu: 200m
        memory: 4.5Gi
      Requests:
        cpu: 110m
        memory: 240Mi
      ...

Esegui l'override delle impostazioni predefinite per le dimensioni dello spazio di archiviazione

Per ignorare queste impostazioni predefinite:

  1. Apri la risorsa personalizzata Stackdriver in un editor della riga di comando:

    kubectl --kubeconfig=KUBECONFIG -n kube-system edit stackdriver stackdriver

  2. Aggiungi il campo storageSizeOverride nella sezione spec. Puoi utilizzare il componente stackdriver-prometheus-k8s o stackdriver-prometheus-app. La sezione ha il seguente formato:

    storageSizeOverride:
STATEFULSET_NAME: SIZE

    Questo esempio utilizza l'oggetto statefulset stackdriver-prometheus-k8s e la dimensione 120Gi.

    apiVersion: addons.gke.io/v1alpha1
kind: Stackdriver
metadata:
  name: stackdriver
  namespace: kube-system
spec:
  projectID: my-project
  clusterName: my-cluster
  clusterLocation: us-west-1a
  storageSizeOverride:
    stackdriver-prometheus-k8s: 120Gi

  3. Salva ed esci dall'editor della riga di comando.

  4. Controlla l'integrità dei pod:

    kubectl --kubeconfig=KUBECONFIG -n kube-system get pods | grep stackdriver
    Ad esempio, un pod integro ha il seguente aspetto: 
    stackdriver-prometheus-k8s-0                                2/2     Running   0          5d19h

  5. Controlla le specifiche del pod del componente per assicurarti che venga eseguito l'override delle dimensioni dello spazio di archiviazione in modo corretto.

    kubectl --kubeconfig=KUBECONFIG -n kube-system describe statefulset STATEFULSET_NAME

    La risposta sarà simile alla seguente:

    Volume Claims:
 Name:          my-statefulset-persistent-volume-claim
 StorageClass:  my-storage-class
 Labels:
 Annotations:
 Capacity:      120Gi
 Access Modes:  [ReadWriteOnce]

Esegui l'override delle impostazioni predefinite della classe di archiviazione

Prerequisito

Devi prima creare un oggetto StorageClass che vuoi utilizzare.

Per eseguire l'override della classe di archiviazione predefinita per i volumi permanenti rivendicati dai componenti di logging e monitoraggio:

  1. Apri la risorsa personalizzata Stackdriver in un editor della riga di comando:

    kubectl --kubeconfig=KUBECONFIG -n kube-system edit stackdriver stackdriver

    dove KUBECONFIG è il percorso del file kubeconfig per il cluster. Può essere un cluster di amministrazione o un cluster utente.

  2. Aggiungi il campo storageClassName nella sezione spec:

    storageClassName: STORAGECLASS_NAME

    Tieni presente che il campo storageClassName sostituisce la classe di archiviazione predefinita esistente e si applica a tutti i componenti di logging e monitoraggio con volumi permanenti dichiarati. Un file di esempio ha il seguente aspetto:

    apiVersion: addons.gke.io/v1alpha1
kind: Stackdriver
metadata:
  name: stackdriver
  namespace: kube-system
spec:
  projectID: my-project
  clusterName: my-cluster
  clusterLocation: us-west-1a
  proxyConfigSecretName: my-secret-name
  enableVPC: 
  optimizedMetrics: true
  storageClassName: my-storage-class

  3. Salva le modifiche.

  4. Controlla l'integrità dei pod:

    kubectl --kubeconfig=KUBECONFIG -n kube-system get pods | grep stackdriver

    Ad esempio, un pod integro ha il seguente aspetto:

    stackdriver-prometheus-k8s-0                                1/1     Running   0          5d19h

  5. Controlla le specifiche del pod di un componente per assicurarti che la classe di archiviazione sia impostata correttamente.

    kubectl --kubeconfig=KUBECONFIG -n kube-system describe statefulset STATEFULSET_NAME

    Ad esempio, utilizzando il set stateful stackdriver-prometheus-k8s, la risposta sarà la seguente:

    Volume Claims:
 Name:          stackdriver-prometheus-data
 StorageClass:  my-storage-class
 Labels:
 Annotations:
 Capacity:      120Gi
 Access Modes:  [ReadWriteOnce]

Disattiva le metriche ottimizzate

Per impostazione predefinita, gli agenti per le metriche in esecuzione nel cluster raccolgono e segnalano a Stackdriver un set ottimizzato di metriche relative a container, kubelet e kube-state-metrics. Se hai bisogno di metriche aggiuntive, ti consigliamo di trovarne una sostitutiva nell'elenco delle metriche di GKE Enterprise.

Ecco alcuni esempi di sostituzioni che potresti utilizzare:

Metrica disattivata Sostituzioni
kube_pod_start_time container/uptime
kube_pod_container_resource_requests container/cpu/request_cores
container/memory/request_bytes
kube_pod_container_resource_limits container/cpu/limit_cores
container/memory/limit_bytes

Per disattivare l'impostazione predefinita delle metriche kube-state-metrics di ottimizzazione (non consigliata):

  1. Apri la risorsa personalizzata Stackdriver in un editor della riga di comando:

    kubectl --kubeconfig=KUBECONFIG -n kube-system edit stackdriver stackdriver

    dove KUBECONFIG è il percorso del file kubeconfig per il cluster. Può essere un cluster di amministrazione o un cluster utente.

  2. Imposta il campo optimizedMetrics su false:

    apiVersion: addons.gke.io/v1alpha1
kind: Stackdriver
metadata:
  name: stackdriver
  namespace: kube-system
spec:
  projectID: my-project
  clusterName: my-cluster
  clusterLocation: us-west-1a
  proxyConfigSecretName: my-secret-name
  enableVPC: 
  optimizedMetrics: false
  storageClassName: my-storage-class

  3. Salva le modifiche ed esci dall'editor della riga di comando.

Problema noto: condizione di errore di Cloud Monitoring

(ID problema 159761921)

In determinate condizioni, il pod Cloud Monitoring predefinito, di cui è stato eseguito il deployment per impostazione predefinita in ogni nuovo cluster, può non rispondere. Quando viene eseguito l'upgrade dei cluster, ad esempio, i dati di archiviazione possono essere danneggiati al riavvio dei pod in statefulset/prometheus-stackdriver-k8s.

In particolare, il pod di monitoraggio stackdriver-prometheus-k8s-0 può essere rilevato in loop quando i dati danneggiati impediscono la scrittura di prometheus-stackdriver-sidecar nello spazio di archiviazione del cluster PersistentVolume.

Puoi diagnosticare e recuperare manualmente l'errore seguendo i passaggi riportati di seguito.

Diagnosi dell'errore di Cloud Monitoring

In caso di errore del pod di monitoraggio, i log riporteranno quanto segue:

{"log":"level=warn ts=2020-04-08T22:15:44.557Z caller=queue_manager.go:534 component=queue_manager msg=\"Unrecoverable error sending samples to remote storage\" err=\"rpc error: code = InvalidArgument desc = One or more TimeSeries could not be written: One or more points were written more frequently than the maximum sampling period configured for the metric.: timeSeries[0-114]; Unknown metric: kubernetes.io/anthos/scheduler_pending_pods: timeSeries[196-198]\"\n","stream":"stderr","time":"2020-04-08T22:15:44.558246866Z"}

{"log":"level=info ts=2020-04-08T22:15:44.656Z caller=queue_manager.go:229 component=queue_manager msg=\"Remote storage stopped.\"\n","stream":"stderr","time":"2020-04-08T22:15:44.656798666Z"}

{"log":"level=error ts=2020-04-08T22:15:44.663Z caller=main.go:603 err=\"corruption after 29032448 bytes: unexpected non-zero byte in padded page\"\n","stream":"stderr","time":"2020-04-08T22:15:44.663707748Z"}

{"log":"level=info ts=2020-04-08T22:15:44.663Z caller=main.go:605 msg=\"See you next time!\"\n","stream":"stderr","time":"2020-04-08T22:15:44.664000941Z"}

Ripristino dall'errore di Cloud Monitoring

Per ripristinare Cloud Monitoring manualmente:

  1. Arresta il monitoraggio del cluster. Fai lo scale down dell'operatore stackdriver per impedire il monitoraggio della riconciliazione: 

    kubectl --kubeconfig /ADMIN_CLUSTER_KUBCONFIG --namespace kube-system scale deployment stackdriver-operator --replicas 0

  2. Elimina i carichi di lavoro della pipeline di monitoraggio: 

    kubectl --kubeconfig /ADMIN_CLUSTER_KUBCONFIG --namespace kube-system delete statefulset stackdriver-prometheus-k8s

  3. Elimina gli oggetti PersistentVolumeClaim (PVC) della pipeline di monitoraggio: 

    kubectl --kubeconfig /ADMIN_CLUSTER_KUBCONFIG --namespace kube-system delete pvc -l app=stackdriver-prometheus-k8s

  4. Riavvia il monitoraggio del cluster. Fai lo scale up dell'operatore di Stackdriver per reinstallare una nuova pipeline di monitoraggio e riprendere la riconciliazione: 

    kubectl --kubeconfig /ADMIN_CLUSTER_KUBCONFIG --namespace kube-system scale deployment stackdriver-operator --replicas=1