Utilizzo di logging e monitoraggio per i componenti di sistema

Questo documento mostra come configurare la registrazione e il monitoraggio per i componenti di sistema in Google Distributed Cloud (solo software) per VMware.

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

Per saperne di più sulle opzioni, vedi 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 Tipi di risorse monitorate di Cloud Monitoring.

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

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

• location: una Google Cloud regione in cui vuoi instradare e archiviare le metriche di Cloud Monitoring. Specifica la regione durante l'installazione nel campo stackdriver.clusterLocation del file di configurazione del cluster. Ti consigliamo di scegliere una regione vicina al tuo data center on-premise.

  Specifichi il routing e la posizione di archiviazione dei log di Cloud Logging nella configurazione del router dei log. Per saperne di più sul routing dei log, consulta la panoramica su routing e archiviazione.

• cluster_name: il nome del cluster che hai scelto quando l'hai creato.

  Puoi recuperare il valore cluster_name per il cluster amministratore o 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 il quale è richiesto il nome del cluster.

Routing di log e metriche

Stackdriver log forwarder (stackdriver-log-forwarder) invia i log da ogni macchina nodo a Cloud Logging. Analogamente, l'agente delle metriche GKE (gke-metrics-agent) invia le metriche da ogni macchina nodo a Cloud Monitoring. Prima dell'invio di log e metriche, l'operatore Stackdriver (stackdriver-operator) associa il valore del campo clusterLocation nella risorsa personalizzata stackdriver a ogni voce di log e metrica prima che vengano indirizzate a Google Cloud. Inoltre, i log e le metriche sono associati al progetto Google Cloud specificato nella specifica della risorsa personalizzata stackdriver (spec.projectID). La risorsa stackdriver riceve i valori per i campi clusterLocation e projectID dai campi stackdriver.clusterLocation e stackdriver.projectID nella sezione clusterOperations della risorsa Cluster al momento della creazione del cluster.

Tutte le metriche e le voci di log inviate dagli agenti Stackdriver vengono indirizzate a un endpoint di importazione globale. Da qui, i dati vengono inoltrati all'endpoint Google Cloud regionale raggiungibile più vicino per garantire l'affidabilità del trasporto dei dati.

Una volta che l'endpoint globale riceve la metrica o la voce di log, ciò che accade dopo dipende dal servizio:

• Come viene configurato il routing dei log: quando l'endpoint di logging riceve un messaggio di log, Cloud Logging lo passa al router di log. I sink e i filtri nella configurazione del router dei log determinano come instradare il messaggio. Puoi indirizzare le voci di log a destinazioni come i bucket Logging regionali, che archiviano la voce di log, o a Pub/Sub. Per ulteriori informazioni sul funzionamento del routing dei log e su come configurarlo, consulta la panoramica su routing e archiviazione.

  Né il campo clusterLocation nella risorsa personalizzata stackdriver né il campo clusterOperations.location nella specifica del cluster vengono presi in considerazione in questo processo di routing. Per i log, clusterLocation viene utilizzato solo per etichettare le voci di log, il che può essere utile per il filtraggio in Esplora log.

• Come viene configurato il routing delle metriche: quando l'endpoint delle metriche riceve una voce di metrica, Cloud Monitoring la indirizza automaticamente alla posizione specificata dalla metrica. La località nella metrica proviene dal campo clusterLocation nella risorsa personalizzata stackdriver.

• Pianifica la configurazione: quando configuri Cloud Logging e Cloud Monitoring, configura il router dei log e specifica un clusterLocation appropriato con le località che meglio supportano le tue esigenze. Ad esempio, se vuoi che i log e le metriche vengano inviati alla stessa posizione, imposta clusterLocation sulla stessa regione Google Cloud che Log Router utilizza per il tuo progetto Google Cloud .

• Aggiorna la configurazione quando necessario: puoi apportare modifiche in qualsiasi momento alle impostazioni di destinazione per log e metriche in base ai requisiti aziendali, come i piani di ripristino di emergenza. Le modifiche alla configurazione del router dei log nel campo Google Cloud e clusterLocation nella risorsa personalizzata stackdriver hanno effetto rapidamente.

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, specifica 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. Facendo clic sulla casella a discesa del catalogo dei log in alto a sinistra e selezionando Container Kubernetes.
   2. Selezionando 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. Nella Google Cloud console, vai alla pagina Esplora log:

   Vai a Esplora log

   Se utilizzi la barra di ricerca per trovare questa pagina, seleziona il risultato con il sottotitolo Logging.

2. Per visualizzare tutti i log dei controller nel cluster di bootstrap, esegui questa query nell'editor di query:

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

3. Per visualizzare i log di un pod specifico, modifica la query in modo da includere il nome del pod:

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

Utilizzo di Cloud Monitoring

Non devi fare nulla per attivare Cloud Monitoring per un cluster. Tuttavia, devi specificare il Google Cloud progetto in cui vuoi visualizzare le metriche. Nel file di configurazione del cluster, specifica il progetto Google Cloud nella sezione stackdriver.

Puoi scegliere tra oltre 1500 metriche utilizzando Metrics Explorer. Per accedere a Metrics Explorer:

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 nei dashboard nella console Google Cloud . Per informazioni sulla creazione di dashboard e sulla visualizzazione delle metriche, vedi Creazione di dashboard.

Nota: le dashboard GKE mostrano solo le informazioni per i cluster GKE in esecuzione su Google Cloud. Non mostrano informazioni per Google Distributed Cloud.

Visualizzazione dei dati di monitoraggio a livello di parco risorse

Per una visione generale dell'utilizzo delle risorse della tua flotta utilizzando i dati di Cloud Monitoring, inclusi i cluster Google Distributed Cloud, puoi utilizzare la panoramica di Google Kubernetes Engine nella console Google Cloud . Per scoprire di più, consulta Gestire i cluster dalla console Google Cloud .

Limiti di quota predefiniti di Cloud Monitoring

Il monitoraggio di Google Distributed Cloud ha un limite predefinito di 6000 chiamate API al minuto per ogni progetto. Se superi questo limite, le metriche potrebbero non essere visualizzate. Se hai bisogno di un limite di monitoraggio superiore, 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 di Grafana.

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

Abilitazione e disabilitazione di Managed Service per Prometheus

A partire dalla release 1.30.0-gke.1930 di Google Distributed Cloud, Managed Service per Prometheus è sempre abilitato. Nelle versioni precedenti, puoi modificare la risorsa Stackdriver, stackdriver, per abilitare o disabilitare Managed Service per Prometheus. Per disabilitare Managed Service per Prometheus per le versioni del cluster precedenti alla 1.30.0-gke.1930, imposta spec.featureGates.enableGMPForSystemMetrics nella risorsa stackdriver su false.

Visualizzazione dei dati delle metriche

Quando Managed Service per Prometheus è abilitato, le metriche per i seguenti componenti hanno un formato diverso per la modalità di archiviazione ed esecuzione di query in Cloud Monitoring:

• kube-apiserver
• kube-scheduler
• kube-controller-manager
• kubelet e cadvisor
• kube-state-metrics
• node-exporter

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

Esempio di PromQL:

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

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 Query con Grafana per autenticare e configurare un'origine dati Grafana per eseguire query sui dati di Managed Service per Prometheus.

Un insieme di dashboard Grafana di esempio è fornito nel repository anthos-samples su GitHub. Per installare le dashboard di esempio:

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 da 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 in Grafana che puntava al servizio Prometheus frontend.

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

   

4. Carica il file .json oppure copia e incolla il contenuto del file e seleziona Carica. Una volta caricato correttamente il contenuto del file, seleziona Importa. Se vuoi, puoi anche modificare il nome e l'UID del dashboard prima dell'importazione.

   

5. Il caricamento del dashboard importato dovrebbe avvenire correttamente se Google Distributed Cloud e l'origine dati sono configurati correttamente. Ad esempio, lo screenshot seguente mostra la dashboard configurata da cluster-capacity.json.

   

Risorse aggiuntive

Per ulteriori informazioni su Managed Service per Prometheus, consulta le seguenti risorse:

• Google Cloud Managed Service per Prometheus

• Le metriche del control plane GKE sono compatibili con PromQL

• Utilizzo di Managed Service per Prometheus per le applicazioni utente su Google Distributed Cloud

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 come sostituto del monitoraggio in-cluster.

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

Se vuoi eliminare tutte le risorse Prometheus e Grafana dopo 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 Google Distributed Cloud, puoi passare a una versione della community open source di Prometheus e Grafana.

Problema noto

Nei cluster utente, Prometheus e Grafana vengono disattivati automaticamente durante gli upgrade. Tuttavia, i dati di configurazione e delle metriche non vengono persi.

Per risolvere questo problema, dopo l'upgrade apri monitoring-sample per la modifica e imposta enablePrometheus su true.

Accesso alle metriche di monitoraggio dalle dashboard di Grafana

Grafana mostra le metriche raccolte dai 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 TCP localhost 3000. Inoltra una porta locale alla porta 3000 nel pod, in modo da poter visualizzare i dashboard di Grafana da un browser web.

   Ad esempio, supponiamo che il nome del pod sia grafana-0. Per inoltrare la 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 su 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à chiesto di cambiare la password. Dopo aver modificato la password predefinita, dovrebbe essere caricata la 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 Crea una dashboard Grafana.

Accedere agli avvisi

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

1. Il container nel pod alertmanager-0 è 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 su http://localhost:50001.

Modifica della configurazione di Prometheus Alertmanager

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

Per modificare la configurazione di Alertmanager:

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, modifica i campi in spec.alertmanager.yml. Al termine, salva il manifest modificato.

3. Applica il manifest al cluster:

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

Creare una dashboard Grafana

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

Per creare una dashboard Grafana:

1. Se necessario, accedi a Grafana.
2. Nella dashboard Home, 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 pannello, quindi su Modifica. Si apre il riquadro inferiore Grafico nella scheda Metriche.
6. Dal menu a discesa Origine dati, seleziona user. 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 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, quindi fai clic su Salva.

Disabilitazione 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 la procedura per aggiungere metriche per un'applicazione. In questa sezione, completa le seguenti attività:

• Esegui il deployment di un'applicazione di esempio che espone una metrica denominata foo.
• Verifica che Prometheus esponga ed estragga la metrica.
• Crea una dashboard Grafana personalizzata.

Esegui il deployment dell'applicazione di esempio

L'applicazione di esempio viene eseguita in un unico 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 sottoposta a scraping

1. Il container nel pod prometheus-example è 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 è 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, vai su http://localhost:50003/targets, che dovrebbe indirizzarti al pod prometheus-0 nel gruppo di target prometheus-io-pods.

5. Per visualizzare le metriche in Prometheus, vai su http://localhost:50003/graph. Nel campo Ricerca, inserisci foo, poi fai clic su Esegui. La pagina deve mostrare la metrica.

Configurazione della risorsa personalizzata Stackdriver

Quando crei un cluster, Google Distributed Cloud crea automaticamente una risorsa personalizzata Stackdriver. Puoi modificare la specifica nella risorsa personalizzata per ignorare i valori predefiniti per le richieste e i limiti di CPU e memoria per un componente Stackdriver e puoi ignorare separatamente le dimensioni e la classe di archiviazione predefinite.

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

Per eseguire l'override di questi valori predefiniti:

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ò trattarsi di un cluster di amministrazione o di 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. I seguenti componenti sono supportati da resourceAttrOverride:

   • gke-metrics-agent/gke-metrics-agent
   • stackdriver-log-forwarder/stackdriver-log-forwarder
   • stackdriver-metadata-agent-cluster-level/metadata-agent
   • node-exporter/node-exporter
   • 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 e chiudi l'editor della riga di comando.

2. Controlla lo stato dei tuoi 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 la specifica 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 è 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
         ...
         

Ignorare i valori predefiniti delle dimensioni dello spazio di archiviazione

Per eseguire l'override di questi valori predefiniti:

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 questo formato:

   storageSizeOverride:
   STATEFULSET_NAME: SIZE
   

   Questo esempio utilizza statefulset stackdriver-prometheus-k8s e dimensioni 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 lo stato dei tuoi 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 la specifica del pod del componente per assicurarti che le dimensioni dello spazio di archiviazione siano state sostituite correttamente.

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

   La risposta è simile alla seguente:

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

Sostituisci le impostazioni predefinite della classe di archiviazione

Prerequisito

Devi prima creare una 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ò trattarsi di un cluster di amministrazione o di 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 rivendicati. 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 lo stato dei tuoi 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 la specifica 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 lo stateful set stackdriver-prometheus-k8s, la risposta è simile alla seguente:

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

Disattivare le metriche ottimizzate

Per impostazione predefinita, gli agenti delle metriche in esecuzione nel cluster raccolgono e segnalano a Stackdriver un insieme ottimizzato di metriche di container, kubelet e kube-state-metrics. Se hai bisogno di altre metriche, ti consigliamo di trovare una sostituzione nell'elenco delle metriche di Google Distributed Cloud.

Ecco alcuni esempi di sostituzioni che potresti utilizzare:

Metrica disabilitata	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 ottimizzate (non consigliato):

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ò trattarsi di un cluster di amministrazione o di 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 e chiudi l'editor della riga di comando.

Problema noto: condizione di errore di Cloud Monitoring

(ID problema 159761921)

In determinate condizioni, il pod Cloud Monitoring predefinito, che viene deployment per impostazione predefinita in ogni nuovo cluster, può smettere di rispondere. Quando i cluster vengono aggiornati, ad esempio, i dati di archiviazione possono danneggiarsi quando i pod in statefulset/prometheus-stackdriver-k8s vengono riavviati.

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

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

Diagnosi dell'errore di Cloud Monitoring

Quando il pod di monitoraggio non è riuscito, i log segnalano 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"}

Recupero dall'errore di Cloud Monitoring

Per eseguire manualmente il ripristino di Cloud Monitoring:

1. Interrompi il monitoraggio del cluster. Ridimensiona l'operatore stackdriver per impedire la riconciliazione del monitoraggio:

   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 le 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. Aumenta le dimensioni dell'operatore 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