Configurazione di logging e monitoraggio

Google Distributed Cloud (solo software) per bare metal supporta più opzioni per il logging e il monitoraggio dei cluster, inclusi servizi gestiti basati su cloud, strumenti open source e compatibilità convalidata con soluzioni commerciali di terze parti. Questa pagina illustra queste opzioni e fornisce alcune indicazioni di base per selezionare la soluzione appropriata per il tuo ambiente.

Questa pagina è rivolta ad amministratori, architetti e operatori che vogliono monitorare l'integrità delle applicazioni o dei servizi di cui è stato eseguito il deployment, ad esempio per la conformità allo scopo a livello di servizio (SLO). Per scoprire di più sui ruoli comuni e su alcuni esempi di attività a cui facciamo riferimento nei contenuti di Google Cloud, consulta Ruoli e attività comuni degli utenti di GKE Enterprise.

Opzioni per Google Distributed Cloud

Hai a disposizione diverse opzioni di monitoraggio e registrazione per il tuo cluster:

  • Cloud Logging e Cloud Monitoring, abilitati per impostazione predefinita sui componenti di sistema bare metal.
  • Prometheus e Grafana sono disponibili su Cloud Marketplace.
  • Configurazioni convalidate con soluzioni di terze parti.

Cloud Logging e Cloud Monitoring

Google Cloud Observability è la soluzione di osservabilità integrata per Google Cloud. Offre una soluzione di logging, raccolta di metriche, monitoraggio, dashboard e avvisi completamente gestita. Cloud Monitoring monitora i cluster Google Distributed Cloud in modo simile ai cluster GKE basati su cloud.

Cloud Logging e Cloud Monitoring sono abilitati per impostazione predefinita quando crei i cluster con gli account di servizio e i ruoli IAM richiesti. Non puoi disattivare Cloud Logging e Cloud Monitoring. Per ulteriori informazioni sugli account di servizio e sui ruoli richiesti, consulta Configurare gli account di servizio.

Gli agenti possono essere configurati per modificare l'ambito della registrazione e del monitoraggio, nonché il livello delle metriche raccolte:

  • L'ambito della registrazione e del monitoraggio può essere impostato solo sui componenti di sistema (valore predefinito) o per i componenti di sistema e le applicazioni.
  • Il livello delle metriche raccolte può essere configurato per un insieme ottimizzato di metriche (valore predefinito) o per metriche complete.

Per ulteriori informazioni, consulta la sezione Configurare gli agenti Stackdriver per Google Distributed Cloud in questo documento.

Logging e monitoraggio forniscono un'unica soluzione di osservabilità basata su cloud, potente e facile da configurare. Ti consigliamo vivamente di utilizzare Logging e Monitoring quando esegui i workload su Google Distributed Cloud. Per le applicazioni con componenti in esecuzione su Google Distributed Cloud e sull'infrastruttura on-premise standard, puoi valutare altre soluzioni per una visione end-to-end di queste applicazioni.

Prometheus e Grafana

Prometheus e Grafana sono due popolari prodotti di monitoraggio open source disponibili nel Cloud Marketplace:

  • Prometheus raccoglie le metriche delle applicazioni e del sistema.

  • Alertmanager gestisce l'invio di avvisi con diversi meccanismi di avviso.

  • Grafana è uno strumento per la creazione di dashboard.

Ti consigliamo di utilizzare Google Cloud Managed Service per Prometheus, basato su Cloud Monitoring, per tutte le tue esigenze di monitoraggio. Con Google Cloud Managed Service per Prometheus puoi monitorare i componenti di sistema senza costi. Google Cloud Managed Service per Prometheus è compatibile anche con Grafana. Tuttavia, se preferisci un sistema di monitoraggio puramente locale, puoi scegliere di installare Prometheus e Grafana nei tuoi cluster.

Se hai installato Prometheus localmente e vuoi raccogliere le metriche dai componenti di sistema, devi concedere all'istanza Prometheus locale l'autorizzazione per accedere agli endpoint delle metriche dei componenti di sistema:

  • Associa l'account di servizio per l'istanza Prometheus al ruolo predefinito gke-metrics-agent ClusterRole e utilizza il token dell'account di servizio come credenziale per eseguire lo scraping delle metriche dai seguenti componenti di sistema:

    • kube-apiserver
    • kube-scheduler
    • kube-controller-manager
    • kubelet
    • node-exporter

  • Utilizza la chiave e il certificato client memorizzati nel secret kube-system/stackdriver-prometheus-etcd-scrape per autenticare lo scraping delle metriche da etcd.

  • Crea un NetworkPolicy per consentire l'accesso dal tuo spazio dei nomi a kube-state-metrics.

Soluzioni di terze parti

Google ha collaborato con diversi provider di soluzioni di monitoraggio e logging di terze parti per garantire il corretto funzionamento dei loro prodotti con Google Distributed Cloud. tra cui Datadog, Elastic e Splunk. Altre terze parti convalidate verranno aggiunte in futuro.

Per l'utilizzo di soluzioni di terze parti con Google Distributed Cloud sono disponibili le seguenti guide alle soluzioni:

Come funzionano il logging e il monitoraggio per Google Distributed Cloud

Cloud Logging e Cloud Monitoring vengono installati e attivati in ogni cluster quando crei un nuovo cluster di amministrazione o utente.

Gli agenti Stackdriver includono diversi componenti su ogni cluster:

  • Stackdriver Operator (stackdriver-operator-*). Gestisce il ciclo di vita di tutti gli altri agenti Stackdriver di cui è stato eseguito il deployment nel cluster.

  • Risorsa personalizzata Stackdriver. Una risorsa creata automaticamente nell'ambito della procedura di installazione di Google Distributed Cloud.

  • Agente delle metriche GKE (gke-metrics-agent-*). Un DaemonSet basato su OpenTelemetry Collector che estrae le metriche da ciascun nodo in Cloud Monitoring. Sono inclusi anche un DaemonSet node-exporter e un deployment kube-state-metrics per fornire più metriche sul cluster.

  • Stackdriver Log Forwarder (stackdriver-log-forwarder-*). Un DaemonSet Fluent Bit che inoltra i log da ogni macchina a Cloud Logging. Il forwarder dei log memorizza in buffer le voci di log sul nodo localmente e le invia di nuovo per un massimo di 4 ore. Se il buffer si riempie o se il reindirizzatore di log non riesce a raggiungere l'API Cloud Logging per più di 4 ore, i log vengono eliminati.

  • Metadata Agent (stackdriver-metadata-agent-). Un deployment che invia i metadati delle risorse Kubernetes, come pod, deployment o nodi, all'API Config Monitoring for Ops. Questi dati vengono utilizzati per arricchire le query sulle metriche consentendo di eseguire query in base al nome del deployment, al nome del nodo o persino al nome del servizio Kubernetes.

Puoi vedere gli agenti installati da Stackdriver eseguendo il seguente comando:

kubectl -n kube-system get pods -l "managed-by=stackdriver"

L'output di questo comando è simile al seguente:

kube-system   gke-metrics-agent-4th8r                                     1/1     Running   1 (40h ago)   40h
kube-system   gke-metrics-agent-8lt4s                                     1/1     Running   1 (40h ago)   40h
kube-system   gke-metrics-agent-dhxld                                     1/1     Running   1 (40h ago)   40h
kube-system   gke-metrics-agent-lbkl2                                     1/1     Running   1 (40h ago)   40h
kube-system   gke-metrics-agent-pblfk                                     1/1     Running   1 (40h ago)   40h
kube-system   gke-metrics-agent-qfwft                                     1/1     Running   1 (40h ago)   40h
kube-system   kube-state-metrics-9948b86dd-6chhh                          1/1     Running   1 (40h ago)   40h
kube-system   node-exporter-5s4pg                                         1/1     Running   1 (40h ago)   40h
kube-system   node-exporter-d9gwv                                         1/1     Running   2 (40h ago)   40h
kube-system   node-exporter-fhbql                                         1/1     Running   1 (40h ago)   40h
kube-system   node-exporter-gzf8t                                         1/1     Running   1 (40h ago)   40h
kube-system   node-exporter-tsrpp                                         1/1     Running   1 (40h ago)   40h
kube-system   node-exporter-xzww7                                         1/1     Running   1 (40h ago)   40h
kube-system   stackdriver-log-forwarder-8lwxh                             1/1     Running   1 (40h ago)   40h
kube-system   stackdriver-log-forwarder-f7cgf                             1/1     Running   2 (40h ago)   40h
kube-system   stackdriver-log-forwarder-fl5gf                             1/1     Running   1 (40h ago)   40h
kube-system   stackdriver-log-forwarder-q5lq8                             1/1     Running   2 (40h ago)   40h
kube-system   stackdriver-log-forwarder-www4b                             1/1     Running   1 (40h ago)   40h
kube-system   stackdriver-log-forwarder-xqgjc                             1/1     Running   1 (40h ago)   40h
kube-system   stackdriver-metadata-agent-cluster-level-5bb5b6d6bc-z9rx7   1/1     Running   1 (40h ago)   40h

Metriche di Cloud Monitoring

Per un elenco delle metriche raccolte da Cloud Monitoring, consulta Visualizzare le metriche di Google Distributed Cloud.

Configurazione degli agenti Stackdriver per Google Distributed Cloud

Gli agenti Stackdriver installati con Google Distributed Cloud raccolgono i dati relativi ai componenti di sistema per la manutenzione e la risoluzione dei problemi relativi ai cluster. Le sezioni seguenti descrivono la configurazione e le modalità di funzionamento di Stackdriver.

Solo componenti di sistema (modalità predefinita)

Al momento dell'installazione, gli agenti Stackdriver sono configurati per impostazione predefinita per raccogliere log e metriche, inclusi dettagli sulle prestazioni (ad esempio l'utilizzo della CPU e della memoria) e metadati simili, per i componenti di sistema forniti da Google. Sono inclusi tutti i carichi di lavoro nel cluster di amministrazione e, per i cluster di utenti, i carichi di lavoro negli spazi dei nomi kube-system, gke-system, gke-connect, istio-system e config-management-system.

Componenti e applicazioni di sistema

Per attivare il logging e il monitoraggio delle applicazioni oltre alla modalità predefinita, segui i passaggi descritti in Attivare il logging e il monitoraggio delle applicazioni.

Metriche ottimizzate (metriche predefinite)

Per impostazione predefinita, i deployment kube-state-metrics in esecuzione nel cluster raccolgono e segnalano un insieme ottimizzato di metriche di kube a Google Cloud Observability (in precedenza Stackdriver).

Per raccogliere questo insieme ottimizzato di metriche sono necessarie meno risorse, il che migliora le prestazioni e la scalabilità complessive.

Per disattivare le metriche ottimizzate (non consigliato), sostituisci l'impostazione predefinita nella risorsa personalizzata Stackdriver.

Utilizzare Google Cloud Managed Service per Prometheus per componenti di sistema selezionati

Google Cloud Managed Service per Prometheus fa parte di Cloud Monitoring ed è disponibile come opzione per i componenti di sistema. I vantaggi di Google Cloud Managed Service per Prometheus includono:

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

  • Se utilizzi sia GKE sia Google Distributed Cloud, puoi utilizzare lo stesso linguaggio di query Prometheus (PromQL) per le metriche su tutti i tuoi cluster. Puoi anche utilizzare la scheda PromQL in Metrics Explorer nella console Google Cloud.

Attivare e disattivare Google Cloud Managed Service per Prometheus

Google Cloud Managed Service per Prometheus è abilitato per impostazione predefinita in Google Distributed Cloud.

Per disattivare Google Cloud Managed Service per Prometheus:

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

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

  2. Aggiungi il gate di funzionalità enableGMPForSystemMetrics e impostalo 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 enableGMPForSystemMetrics è impostato su true, le metriche per i seguenti componenti hanno un formato diverso per la modalità di archiviazione e 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 PromQL o Monitoring Query Language (MQL):

PromQL

Query PromQL di esempio:

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

MQL

Per utilizzare MQL, imposta la risorsa monitorata su prometheus_target, utilizza il nome della metrica con il prefisso kubernetes.io/anthos e aggiungi il tipo Prometheus come suffisso al nome della metrica.

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 di Grafana con Google Cloud Managed Service per Prometheus

Per utilizzare Grafana con i dati delle metriche di Google Cloud Managed Service per Prometheus, devi prima configurare e autenticare l'origine dati Grafana. Per configurare e autenticare l'origine dati, utilizza il sincronizzatore delle origini dati (datasource-syncer) per generare le credenziali OAuth2 e sincronizzarle con Grafana tramite l'API di origine dati Grafana. Il sincronizzatore dell'origine dati imposta l'URL del server Prometheus (il valore dell'URL inizia con https://monitoring.googleapis.com) nell'origine dati in Grafana.

Segui i passaggi descritti in Eseguire query utilizzando Grafana per autenticare e configurare un'origine dati Grafana per eseguire query sui dati di Google Cloud 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 di 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 rimanda al servizio Prometheus frontend.

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

    Vai all'importazione delle dashboard in Grafana.

  4. Carica il file JSON o copia e incolla i contenuti del file e seleziona Carica. Una volta caricati i contenuti del file, seleziona Importa. Facoltativamente, puoi anche modificare il nome e l'UID della dashboard prima dell'importazione.

    Importazione della dashboard in Grafana.

  5. La dashboard importata dovrebbe caricarsi 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.

    Dashboard della capacità del cluster in Grafana.

Risorse aggiuntive

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

Configurazione delle risorse dei componenti 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 l'impostazione predefinita delle metriche ottimizzate.

Sostituzione delle richieste e dei limiti di CPU e memoria predefiniti per un componente Stackdriver

I cluster con una densità elevata di pod introducono un overhead maggiore per il monitoraggio e la registrazione. In casi estremi, i componenti di Stackdriver potrebbero segnalare un utilizzo prossimo al limite della CPU e della memoria o addirittura essere soggetti a riavvii continui a causa dei limiti delle risorse. In questo caso, per sostituire i valori predefiniti per le richieste e i limiti di CPU e memoria per un componente Stackdriver, svolgi i seguenti passaggi:

  1. Esegui il seguente comando per aprire la risorsa personalizzata Stackdriver in un editor a riga di comando:

    kubectl -n kube-system edit stackdriver stackdriver

  2. Nella risorsa personalizzata Stackdriver, aggiungi la sezione resourceAttrOverridesotto il campo spec:

    resourceAttrOverride:
      DAEMONSET_OR_DEPLOYMENT_NAME/CONTAINER_NAME:
        LIMITS_OR_REQUESTS:
          RESOURCE: RESOURCE_QUANTITY

    Tieni presente che la sezione 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:
  anthosDistribution: baremetal
  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

  3. Per salvare le modifiche alla risorsa personalizzata Stackdriver, salva ed esci dall'editor a riga di comando.

  4. Controlla lo stato del pod:

    kubectl -n kube-system get pods -l "managed-by=stackdriver"

    Una risposta per un pod integro è simile alla seguente:

    gke-metrics-agent-4th8r                1/1     Running   1   40h

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

    kubectl -n kube-system describe pod POD_NAME

    Sostituisci POD_NAME con il nome del pod appena modificato. Ad esempio, gke-metrics-agent-4th8r.

    La risposta è la seguente:

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

Disattivare le metriche ottimizzate

Per impostazione predefinita, i deployment kube-state-metrics in esecuzione nel cluster raccolgono e registrano in Stackdriver un insieme ottimizzato di metriche di Kube. Se hai bisogno di metriche aggiuntive, ti consigliamo di trovarne una sostitutiva nell'elenco delle metriche di Google Distributed Cloud.

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 ottimizzate (non consigliata), procedi nel seguente modo:

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

    kubectl -n kube-system edit stackdriver stackdriver

  2. Imposta il campo optimizedMetrics su false:

    apiVersion: addons.gke.io/v1alpha1
kind: Stackdriver
metadata:
name: stackdriver
namespace: kube-system
spec:
anthosDistribution: baremetal
projectID: my-project
clusterName: my-cluster
clusterLocation: us-west-1a
optimizedMetrics: false

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

Server delle metriche

Metrics Server è l'origine delle metriche delle risorse dei contenitori per varie pipeline di scalabilità automatica. Metrics Server recupera le metriche dai Kubelet e le espone tramite l'API Kubernetes Metrics. HPA e VPA utilizzano poi queste metriche per determinare quando attivare la scalabilità automatica. Il server delle metriche viene scalato utilizzando il ridimensionamento dei componenti aggiuntivi.

In casi estremi, in cui una densità elevata dei pod crea un overhead eccessivo per la registrazione e il monitoraggio, Metrics Server potrebbe essere interrotto e riavviato a causa di limitazioni delle risorse. In questo caso, puoi allocare più risorse al server delle metriche modificando il configmap metrics-server-config nello spazio dei nomi gke-managed-metrics-server e modificando il valore di cpuPerNode e memoryPerNode.

kubectl edit cm metrics-server-config -n gke-managed-metrics-server

I contenuti di esempio del ConfigMap sono:

apiVersion: v1
data:
  NannyConfiguration: |-
    apiVersion: nannyconfig/v1alpha1
    kind: NannyConfiguration
    cpuPerNode: 3m
    memoryPerNode: 20Mi
kind: ConfigMap

Dopo aver aggiornato il ConfigMap, ricrea i pod metrics-server con il seguente comando:

kubectl delete pod -l k8s-app=metrics-server -n gke-managed-metrics-server

Requisiti di configurazione per il logging e il monitoraggio

Esistono diversi requisiti di configurazione per attivare Cloud Logging e Cloud Monitoring con Google Distributed Cloud. Questi passaggi sono inclusi in Configurazione di un account di servizio da utilizzare con Logging e Monitoring nella pagina Attivazione dei servizi Google e nel seguente elenco:

  1. È necessario creare uno spazio di lavoro Cloud Monitoring all'interno del progetto Google Cloud. Per farlo, fai clic su Monitoraggio nella console Google Cloud e segui il flusso di lavoro.

  2. Devi abilitare le seguenti API Stackdriver:

  3. Devi assegnare i seguenti ruoli IAM all'account di servizio utilizzato dagli agenti Stackdriver:

    • logging.logWriter
    • monitoring.metricWriter
    • stackdriver.resourceMetadata.writer
    • monitoring.dashboardEditor
    • opsconfigmonitoring.resourceMetadata.writer

Tag di log

Molti log di Google Distributed Cloud hanno un tag F:

logtag: "F"

Questo tag indica che la voce di log è completa o completa. Per scoprire di più su questo tag, consulta Formato log nelle proposte di progettazione di Kubernetes su GitHub.

Prezzi

Non sono previsti costi per i log di sistema e le metriche della versione Enterprise di Google Kubernetes Engine (GKE).

In un cluster Google Distributed Cloud, i log e le metriche di sistema di Google Kubernetes Engine (GKE) versione Enterprise includono:

  • Log e metriche di tutti i componenti in un cluster di amministrazione.
  • Log e metriche dei componenti nei seguenti spazi dei nomi di un cluster utente: kube-system, gke-system, gke-connect, knative-serving, istio-system, monitoring-system, config-management-system, gatekeeper-system, cnrm-system.

Per ulteriori informazioni, consulta la pagina Prezzi di Google Cloud Observability.

Per informazioni sul credito per le metriche di Cloud Logging, contatta il team di vendita per conoscere i prezzi.