Gestione delle metriche di GKE

Google Kubernetes Engine (GKE) semplifica l'invio di metriche a Cloud Monitoring. In Cloud Monitoring, le metriche possono completare dashboard personalizzate, generare avvisi, creare obiettivi del livello di servizio o essere recuperati da servizi di monitoraggio di terze parti utilizzando l'API Monitoring.

G K E fornisce diverse fonti di metriche:

  • Metriche di sistema: metriche dai componenti di sistema essenziali, che descrivono risorse di basso livello come CPU, memoria e archiviazione.
  • Managed Service for Prometheus: consente di monitorare e creare avvisi sui tuoi carichi di lavoro utilizzando Prometheus, senza dover gestire e utilizzare manualmente Prometheus su larga scala.
  • Metriche del carico di lavoro (deprecate): metriche esposte da qualsiasi carico di lavoro G K E (ad esempio un CronJob o un deployment per un'applicazione).

Metriche di sistema

Quando viene creato un cluster, G K E raccoglie per impostazione predefinita alcune metriche emesse dai componenti di sistema.

Puoi scegliere se inviare o meno metriche dal tuo cluster G K E a Cloud Monitoring. Se scegli di inviare le metriche a Cloud Monitoring, devi inviare le metriche di sistema.

Tutte le metriche di sistema di G K E vengono importate in Cloud Monitoring con il prefisso kubernetes.io.

Prezzi

Cloud Monitoring non addebita alcun costo per l'importazione delle metriche di sistema di G K E. Scopri di più sui prezzi di Cloud Monitoring.

Configurazione della raccolta di metriche di sistema

Per attivare la raccolta delle metriche di sistema, passa il valore SYSTEM al flag --monitoring dei comandi gcloud container clusters create o gcloud container clusters update.

Per disattivare la raccolta delle metriche di sistema, utilizza il valore NONE per il flag --monitoring. Se la raccolta delle metriche di sistema è disattivata, le informazioni di base come l'utilizzo della CPU, l'utilizzo della memoria e del disco non sono disponibili per un cluster nella sezione G K E di Google Cloud Console. Inoltre, la dashboard di G Suite Cloud Monitoring non contiene informazioni sul cluster.

Consulta Configurazione di Cloud Operations for GKE per ulteriori dettagli sull'integrazione di Cloud Monitoring con G K E.

Elenco delle metriche di sistema

Le metriche di sistema includono metriche di componenti di sistema essenziali che sono importanti per la funzionalità Kubernetes di base. Consulta l'elenco completo delle metriche di sistema.

Metriche del carico di lavoro

Se il tuo cluster G KE utilizza le metriche del carico di lavoro, esegui la migrazione a Managed Service for Prometheus prima di eseguire l'upgrade del cluster a G K E 1.24, dal momento che il supporto delle metriche del carico di lavoro viene rimosso in G K E 2.24.

Le versioni G K E 1.20.8-gke.2100 o successive e precedenti di G K E precedenti alla 1,24 offrono una pipeline di raccolta delle metriche completamente gestita per estrarre le metriche in stile Prometheus esposte da qualsiasi carico di lavoro di G K E (ad esempio un CronJob o un deployment per un'applicazione) e di inviare tali metriche a Cloud Monitoring.

Tutte le metriche raccolte dalla pipeline delle metriche del carico di lavoro G K E vengono importate in Cloud Monitoring con il prefisso workload.googleapis.com.

I vantaggi delle metriche relative al carico di lavoro di G K E includono:

  • Configurazione semplice: con un singolo comando kubectl per eseguire il deployment di una risorsa personalizzata PodMonitor, puoi iniziare a raccogliere le metriche. Non è richiesta l'installazione manuale di un agente.
  • Altamente configurabile: regola gli endpoint di scraping, la frequenza e altri parametri.
  • Completamente gestita: Google mantiene la pipeline, quindi puoi concentrarti sulle tue applicazioni.
  • Controlla i costi: gestisci i costi di Cloud Monitoring facilmente tramite filtri di metriche flessibili.
  • Open standard: configura le metriche del carico di lavoro utilizzando la risorsa personalizzata PodMonitor, che è modellata sulla risorsa PodMonitor dell'operatore Prometheus.
  • Prezzi migliori: prezzi più intuitivi, prevedibili e più bassi.
  • Supporto Autopilot: supporta i cluster G K E Standard e G K E.

Requisiti

Le metriche del carico di lavoro G K E richiedono la versione del piano di controllo G K E 1.20.8-gke.2100 o successive e non supportano i carichi di lavoro G K E Windows.

Se abiliti la pipeline delle metriche del carico di lavoro, devi abilitare anche la raccolta delle metriche di sistema.

Passaggio 1: abilita la pipeline delle metriche del carico di lavoro

Per abilitare la pipeline di raccolta delle metriche del carico di lavoro in un cluster G K E esistente, segui questi passaggi:

CONSOLE

  1. In Google Cloud Console, vai all'elenco dei cluster G K E:

    Vai ai cluster Kubernetes

  2. Fai clic sul nome del cluster.

  3. Nella riga "Cloud Monitoring", fai clic sull'icona Modifica.

  4. Nella finestra di dialogo "Modifica Cloud Monitoring" che compare, conferma che sia selezionata l'opzione Abilita Cloud Monitoring.

  5. Nel menu a discesa, seleziona Carichi di lavoro.

  6. Fai clic su OK.

  7. Fai clic su Salva modifiche.

GCLOUD

  1. Apri una finestra del terminale in cui è installata l'interfaccia a riga di comando di Google Cloud. Un modo per farlo è utilizzare Cloud Shell.

  2. In Cloud Console, attiva Cloud Shell.

    Attiva Cloud Shell

    Nella parte inferiore di Cloud Console, viene avviata una sessione Cloud Shell che mostra un prompt della riga di comando. Cloud Shell è un ambiente shell con l'interfaccia a riga di comando di Google Cloud già installata e con valori già impostati per il progetto attuale. L'inizializzazione della sessione può richiedere alcuni secondi.

  3. Esegui questo comando:

    gcloud beta container clusters update [CLUSTER_ID] \
      --zone=[ZONE] \
      --project=[PROJECT_ID] \
      --monitoring=SYSTEM,WORKLOAD
    

    Il valore WORKLOAD per il flag --monitoring dei comandi gcloud beta container clusters create o gcloud beta container clusters update consente di attivare la pipeline di raccolta delle metriche del carico di lavoro.

Se abiliti la pipeline di raccolta delle metriche del carico di lavoro, viene eseguito il deployment di un agente per la raccolta delle metriche su ogni nodo in grado di raccogliere le metriche delle applicazioni emesse dai carichi di lavoro Kubernetes.

Consulta Configurazione di Cloud Operations for GKE per ulteriori dettagli sull'integrazione di Cloud Monitoring con G K E.

Passaggio 2: configura le metriche raccolte

1) Crea una risorsa personalizzata PodMonitor denominata my-pod-monitor.yaml:


apiVersion: monitoring.gke.io/v1alpha1
kind: PodMonitor
metadata:
  # POD_MONITOR_NAME is how you identify your PodMonitor
  name: [POD_MONITOR_NAME]
  # POD_NAMESPACE is the namespace where your workload is running, and the
  # namespace of your PodMonitor object
  namespace: [POD_NAMESPACE]
spec:
  # POD_LABEL_KEY and POD_LABEL_VALUE identify which pods to collect metrics
  # from. For example, POD_LABEL_KEY of app.kubernetes.io/name and
  # POD_LABEL_VALUE of mysql would collect metrics from all pods with the label
  # app.kubernetes.io/name=mysql
  selector:
    matchLabels:
      [POD_LABEL_KEY]: [POD_LABEL_VALUE]
  podMetricsEndpoints:
    # CONTAINER_PORT_NAME is the name of the port of the container to be scraped
    # Use the following command to list all ports exposed by the container:
    # kubectl get pod [POD_NAME] -n [POD_NAMESPACE] -o json | jq '.items[].spec.containers[].ports[]?' | grep -v null
    # If the port for your metrics does not have a name, modify your application's pod spec
    # to add a port name.
  - port: [CONTAINER_PORT_NAME]

2) Inizializza la credenziale utilizzando l'interfaccia a riga di comando di Google Cloud per configurare kubectl:

gcloud container clusters get-credentials [CLUSTER_ID] --zone=[ZONE]

3) Esegui il deployment della risorsa personalizzata PodMonitor:

kubectl apply -f my-pod-monitor.yaml

Prezzi

Cloud Monitoring addebita i costi per l'importazione delle metriche del carico di lavoro G K E in base al numero di campioni importati. Scopri di più sui prezzi di Cloud Monitoring.

Gestione dei costi

Per gestire i costi, inizia determinare quali metriche del carico di lavoro sono più utili per le tue esigenze di monitoraggio. La pipeline di metriche del carico di lavoro G K E fornisce controlli granulari per trovare il giusto compromesso tra l'acquisizione di metriche dettagliate e la necessità di mantenere bassi i costi.

Molte applicazioni espongono una vasta gamma di metriche Prometheus e, per impostazione predefinita, la pipeline delle metriche del carico di lavoro G K E estrae tutte le metriche da ogni pod selezionato ogni 60 secondi.

Per ridurre il costo delle metriche, puoi utilizzare le seguenti tecniche:

  1. Modifica della frequenza di scraping: per ridurre il costo delle metriche, ti consigliamo di ridurre la frequenza di scraping quando appropriato. Ad esempio, è possibile che un KPI pertinente per l'attività commerciale si modifichi abbastanza lentamente da poter essere criptato ogni dieci minuti. In PodMonitor, imposta interval per controllare la frequenza di scraping.

  2. Filtraggio delle metriche: identifica le metriche non utilizzate in Cloud Monitoring e utilizza metricRelabelings per garantire che solo le metriche utili per le dashboard, gli avvisi o gli SLO vengano inviate a Cloud Monitoring.

Ecco un esempio concreto di una risorsa personalizzata PodMonitor che utilizza entrambe le tecniche:

apiVersion: monitoring.gke.io/v1alpha1
kind: PodMonitor
metadata:
  name: prom-example
  namespace: gke-workload-metrics
spec:
  selector:
    matchLabels:
      app: example
  podMetricsEndpoints:
  - port: metrics
    path: /metrics
    scheme: http

    # (1) scrape metrics less frequently than the default (once every 60s)
    interval: 10m

    metricRelabelings:

    - # (2) drop the irrelevant metric named "foo" and all metrics
      # with the prefix "bar_"
      sourceLabels: [__name__]
      regex: foo|bar_.*
      action: drop

    - # (3) keep only metrics with a subset of values for a particular label
      sourceLabels: [region]
      regex: us-.*
      action: keep

Per identificare le metriche con il maggior numero di campioni importati, utilizza la metrica monitoring.googleapis.com/collection/attribution/write_sample_count:

  1. In Cloud Console, seleziona Monitoring:

    Vai a Monitoring

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

  3. Nel campo Metrica, seleziona monitoring.googleapis.com/collection/attribution/write_sample_count.

  4. Facoltativamente, filtra solo per le metriche del carico di lavoro G K E:

    • Fai clic su Aggiungi filtro.

    • Nel campo Etichetta, seleziona metric_domain.

    • Nel campo Valore, inserisci workload.googleapis.com.

    • Fai clic su Fine.

  5. Facoltativamente, raggruppa il numero di campioni importati da spazio dei nomi Kubernetes, area geografica G K E, progetto Google Cloud o il tipo di risorsa monitorata:

    • Fai clic su Raggruppa per.

    • Per raggruppare in base allo spazio dei nomi Kubernetes, seleziona attribution_dimension e attribution_id.

    • Per raggruppare i dati in base all'area geografica G K E, seleziona località.

    • Per raggruppare in base al progetto Cloud, seleziona resource_container.

    • Per raggruppare in base al tipo di risorsa monitorata, seleziona resource_type.

  6. Ordina l'elenco delle metriche in ordine decrescente facendo clic sul titolo della colonna Valore sopra l'elenco delle metriche.

Questi passaggi mostrano le metriche con la frequenza più elevata di campioni importati in Cloud Monitoring. Poiché le metriche del carico di lavoro G K E vengono addebitate in base al numero di campioni importati, presta attenzione alle metriche con la frequenza di importazione più elevata. Valuta se puoi ridurre la frequenza di scraping di queste metriche o se puoi interrompere la loro raccolta.

Infine, sono disponibili molte risorse per comprendere il costo delle metriche di G K E importate in Cloud Monitoring e per ottimizzare tali costi. Consulta la guida all'ottimizzazione dei costi per conoscere altri modi per ridurre il costo di Cloud Monitoring.

Versioni precedenti di G K E

Per raccogliere le metriche delle applicazioni in un cluster con una versione del piano di controllo G K E inferiore a 1.20.8-gke.2100, utilizza la collaterale Stackdriver Prometheus.

Risolvere i problemi

Se le metriche del carico di lavoro non sono disponibili in Cloud Monitoring come previsto, di seguito sono riportati alcuni passaggi che puoi seguire per risolvere il problema.

Conferma che il cluster soddisfa i requisiti minimi

Assicurati che il tuo cluster G K E stia eseguendo il piano di controllo versione 1.20.8-gke.2100 o successiva. In caso contrario, esegui l'upgrade del tuo piano di controllo del cluster.

Conferma che le metriche del carico di lavoro siano abilitate

Assicurati che il tuo cluster G K E sia configurato per abilitare la pipeline di raccolta delle metriche del carico di lavoro seguendo questi passaggi:

CONSOLE

  1. In Google Cloud Console, vai all'elenco dei cluster G K E:

    Vai ai cluster Kubernetes

  2. Fai clic sul nome del cluster.

  3. Nel riquadro Dettagli del cluster, verifica che "Workload" sia incluso nello stato di Cloud Monitoring. Se "Workload" non è visualizzato qui, abilita le metriche del carico di lavoro.

GCLOUD

  1. Apri una finestra del terminale con l'interfaccia a riga di comando gcloud installata. Un modo per farlo è utilizzare Cloud Shell.

  2. In Cloud Console, attiva Cloud Shell.

    Attiva Cloud Shell

    Nella parte inferiore di Cloud Console, viene avviata una sessione Cloud Shell che mostra un prompt della riga di comando. Cloud Shell è un ambiente shell con l'interfaccia a riga di comando di Google Cloud già installata e con valori già impostati per il progetto attuale. L'inizializzazione della sessione può richiedere alcuni secondi.

  3. Esegui questo comando:

    gcloud container clusters describe [CLUSTER_ID] --zone=[ZONE]
    

    Nell'output di questo comando, cerca la riga monitoringConfig:. Un paio di righe dopo, verifica che la sezione enableComponents: includa WORKLOADS. Se WORKLOADS non è visualizzato qui, abilita le metriche del carico di lavoro.

Verificare che le metriche vengano raccolte dall'applicazione

Se non riesci a visualizzare le metriche della tua applicazione in Cloud Monitoring, i passaggi seguenti possono aiutarti a risolvere i problemi. Questi passaggi utilizzano un'applicazione di esempio a fini dimostrativi, ma puoi applicare gli stessi passaggi riportati di seguito per risolvere i problemi di qualsiasi applicazione.

I primi passaggi riportati di seguito consentono di eseguire il deployment di un'applicazione di esempio che puoi utilizzare per i test. I passaggi rimanenti mostrano i passaggi da seguire per risolvere i problemi relativi alla mancata visualizzazione delle metriche di tale applicazione in Cloud Monitoring.

  1. Crea un file denominato prometheus-example-app.yaml contenente quanto segue:

    # This example application exposes prometheus metrics on port 1234.
    apiVersion: apps/v1
    kind: Deployment
    metadata:
      labels:
        app: prom-example
      name: prom-example
      namespace: gke-workload-metrics
    spec:
      selector:
        matchLabels:
          app: prom-example
      template:
        metadata:
          labels:
            app: prom-example
        spec:
          containers:
          - image: nilebox/prometheus-example-app@sha256:dab60d038c5d6915af5bcbe5f0279a22b95a8c8be254153e22d7cd81b21b84c5
            name: prom-example
            ports:
            - name: metrics-port
              containerPort: 1234
            command:
            - "/main"
            - "--process-metrics"
            - "--go-metrics"
    
  2. Inizializza la credenziale con l'interfaccia a riga di comando di Google Cloud per configurare kubectl:

    gcloud container clusters get-credentials [CLUSTER_ID] --zone=[ZONE]
    
  3. Crea lo spazio dei nomi gke-workload-metrics:

    kubectl create ns gke-workload-metrics
    
  4. Esegui il deployment dell'applicazione di esempio:

    kubectl apply -f prometheus-example-app.yaml
    
  5. Verifica che l'applicazione di esempio sia in esecuzione con questo comando:

    kubectl get pod -n gke-workload-metrics -l app=prom-example
    

    L'output dovrebbe avere il seguente aspetto:

    NAME                            READY   STATUS    RESTARTS   AGE
    prom-example-775d8685f4-ljlkd   1/1     Running   0          25m
    
  6. Verifica che l'applicazione mostri le metriche come previsto

    Utilizzando uno dei pod restituiti dal comando riportato sopra, controlla che l'endpoint della metrica funzioni correttamente:

    POD_NAME=prom-example-775d8685f4-ljlkd
    NAMESPACE=gke-workload-metrics
    PORT_NUMBER=1234
    METRICS_PATH=/metrics
    kubectl get --raw /api/v1/namespaces/$NAMESPACE/pods/$POD_NAME:$PORT_NUMBER/proxy/$METRICS_PATH
    

    Se utilizzi l'applicazione di esempio riportata sopra, dovresti ricevere un output simile al seguente:

    # HELP example_random_numbers A histogram of normally distributed random numbers.
    # TYPE example_random_numbers histogram
    example_random_numbers_bucket{le="0"} 501
    example_random_numbers_bucket{le="0.1"} 1.75933011554e+11
    example_random_numbers_bucket{le="0.2"} 3.50117676362e+11
    example_random_numbers_bucket{le="0.30000000000000004"} 5.20855682325e+11
    example_random_numbers_bucket{le="0.4"} 6.86550977647e+11
    example_random_numbers_bucket{le="0.5"} 8.45755380226e+11
    example_random_numbers_bucket{le="0.6"} 9.97201199544e+11
    ...
    
  7. Crea un file denominato my-pod-monitor.yaml contenente quanto segue:

    # Note that this PodMonitor is in the monitoring.gke.io domain,
    # rather than the monitoring.coreos.com domain used with the
    # Prometheus Operator.  The PodMonitor supports a subset of the
    # fields in the Prometheus Operator's PodMonitor.
    apiVersion: monitoring.gke.io/v1alpha1
    kind: PodMonitor
    metadata:
      name: example
      namespace: gke-workload-metrics
    # spec describes how to monitor a set of pods in a cluster.
    spec:
      # selector determines which pods are monitored.  Required
      # This example matches pods with the `app: prom-example` label
      selector:
        matchLabels:
          app: prom-example
      podMetricsEndpoints:
        # port is the name of the port of the container to be scraped.
      - port: metrics-port
        # path is the path of the endpoint to be scraped.
        # Default /metrics
        path: /metrics
        # scheme is the scheme of the endpoint to be scraped.
        # Default http
        scheme: http
        # interval is the time interval at which metrics should
        # be scraped. Default 60s
        interval: 20s
    
  8. Crea questa risorsa PodMonitor:

    kubectl apply -f my-pod-monitor.yaml
    

    Dopo aver creato la risorsa PodMonitor, la pipeline delle metriche del carico di lavoro G K E rileverà i pod appropriati e inizierà automaticamente a eseguirne di scrack. La pipeline invierà le metriche raccolte a Cloud Monitoring

  9. Verifica che l'etichetta e lo spazio dei nomi siano impostati correttamente nel PodMonitor. Aggiorna i valori NAMESPACE e SELECTOR riportati di seguito in modo che riflettano namespace e matchLabels nella risorsa personalizzata PodMonitor. Quindi, esegui questo comando:

    NAMESPACE=gke-workload-metrics
    SELECTOR=app=prom-example
    kubectl get pods --namespace $NAMESPACE --selector $SELECTOR
    

    Dovresti vedere un risultato come questo:

    NAME                            READY   STATUS    RESTARTS   AGE
    prom-example-7cff4db5fc-wp8lw   1/1     Running   0          39m
    
  10. Verifica che il PodMonitor sia in stato di pronto.

    Esegui questo comando per restituire tutti i podMonitor che hai installato nel cluster:

    kubectl get podmonitor.monitoring.gke.io --all-namespaces
    

    Dovresti vedere un output simile al seguente:

    NAMESPACE              NAME      AGE
    gke-workload-metrics   example   2m36s
    

    Identifica il PodMonitor pertinente dal set restituito ed esegui questo comando (sostituendo example nel comando seguente con il nome del tuo PodMonitor):

    kubectl describe podmonitor.monitoring.gke.io example --namespace gke-workload-metrics
    

    Esamina i risultati restituiti da kubectl describe e verifica che la condizione "Pronto" sia "Vero". Se il valore è Falso, cerca gli eventi che indicano perché non è pronto.

  11. In seguito, verificheremo che queste metriche siano effettivamente ricevute da Cloud Monitoring. Nella sezione Cloud Monitoring di Google Cloud Console, vai a Metrics Explorer.

  12. Nel campo Metrica, digita example_requests_total.

  13. Nel menu a discesa visualizzato, seleziona workload.googleapis.com/example_requests_total.

    Questa metrica example_requests_total è una delle metriche di Prometheus emesse dall'applicazione di esempio.

    Se il menu a discesa non viene visualizzato o se non è visibile workload.googleapis.com/example_requests_total nel menu a discesa, prova di nuovo tra qualche minuto.

    Tutte le metriche sono associate alla risorsa Container di Kubernetes (k8s_container). Puoi utilizzare il campo Tipo di risorsa di Metrics Explorer per selezionare k8s_container. Puoi anche raggruppare in base a qualsiasi etichetta, ad esempio namespace_name o pod_name.

    Questa metrica può essere utilizzata ovunque in Cloud Monitoring o interrogata tramite l'API Cloud Monitoring. Ad esempio, per aggiungere questo grafico a una dashboard esistente o nuova, fai clic sul pulsante Salva grafico nell'angolo in alto a destra e seleziona la dashboard desiderata in una finestra di dialogo.

Verifica la presenza di errori di invio all'API Cloud Monitoring

Le metriche inviate a Cloud Monitoring devono rispettare i limiti delle metriche personalizzate. Gli errori verranno visualizzati nei log di controllo di Cloud Monitoring.

Utilizzando Cloud Logs Explorer, cerca nei log con questo filtro di log (sostituisci PROJECT_ID con il nome del progetto):

resource.type="audited_resource"
resource.labels.service="monitoring.googleapis.com"
protoPayload.authenticationInfo.principalEmail=~".*-compute@developer.gserviceaccount.com"
resource.labels.project_id="[PROJECT_ID]"
severity>=ERROR

Tieni presente che verranno mostrati gli errori per tutte le scritture su Cloud Monitoring per il progetto, non solo per quelle del cluster.

Verifica la quota di importazione di Cloud Monitoring

  1. Vai alla pagina Quote dell'API Cloud Monitoring
  2. Seleziona il progetto pertinente
  3. Espandi la sezione Richieste di importazione delle serie temporali
  4. Verifica che il valore della Quota di errori di superamento della quota per "Richieste di importazione della serie temporale" al minuto sia 0. In questo caso, il grafico "Quota ha superato il numero di errori" indicherà "Non sono disponibili dati per l'intervallo di tempo selezionato".
  5. Se la percentuale di utilizzo di picco supera il 100%, valuta la possibilità di selezionare meno pod, selezionare meno metriche o richiedere un limite di quota più alto per la quota monitoring.googleapis.com/ingestion_requests.

Conferma il deployment del DaemonSet

Assicurati che il deployment del tuo cluster sia eseguito con le metriche del carico di lavoro DaemonSet. Puoi verificare che tutto funzioni come previsto utilizzando kubectl:

  1. Inizializza la credenziale con l'interfaccia a riga di comando di Google Cloud per configurare kubectl:

    gcloud container clusters get-credentials [CLUSTER_ID] --zone=[ZONE]
    
  2. Verifica che il DaemonSet di metriche del carico di lavoro sia presente e in stato integro. Esegui questo comando:

    kubectl get ds -n kube-system workload-metrics
    

    Se il deployment dei componenti è riuscito, verrà visualizzato un output simile al seguente:

    NAME               DESIRED   CURRENT   READY   UP-TO-DATE   AVAILABLE   AGE
    workload-metrics   3         3         3       3            3           2m
    

    Il numero di repliche riportato sopra deve corrispondere al numero di nodi GKE GKE nel tuo cluster. Ad esempio, un cluster con 3 nodi avrà DESIRED = 3. Dopo alcuni minuti, i numeri READY e AVAILABLE devono corrispondere al numero DESIRED. In caso contrario, potrebbe esserci un problema con il deployment.

Altre metriche

Oltre alle metriche di sistema e alle metriche del carico di lavoro descritte sopra, alcune metriche aggiuntive disponibili per un cluster G K E includono: