Questa documentazione riguarda la versione più recente di Knative serving, che utilizza i parchi risorse e Anthos Service Mesh. Scopri di più.

La versione precedente (Cloud Run for Anthos) è stata archiviata, ma la documentazione rimane disponibile per gli utenti esistenti.

Versioni disponibili

Più recente
Archivia

Questa pagina è stata tradotta dall'API Cloud Translation.

Risoluzione dei problemi locali

Questo tutorial mostra come risolvere un guasto Servizio Knative serving che utilizza gli strumenti di Stackdriver per il rilevamento e e un flusso di lavoro di sviluppo.

Questo "case study" dettagliato associato al guida alla risoluzione dei problemi utilizza un progetto di esempio che provoca errori di runtime al momento del deployment, che dovrai individuare e correggere risolvere il problema.

Obiettivi

Scrivi, crea ed esegui il deployment di un servizio su Knative serving
Utilizzare Cloud Logging per identificare un errore
Recupera l'immagine del contenitore da Container Registry per un'analisi della causa principale
Correggi il problema "production" e migliorare il servizio per mitigare i problemi futuri

Costi

In questo documento utilizzi i seguenti componenti fatturabili di Google Cloud:

Per generare una stima dei costi basata sull'utilizzo previsto, utilizza il Calcolatore prezzi. I nuovi utenti di Google Cloud potrebbero essere idonei per una prova gratuita.

Prima di iniziare

Questo tutorial presuppone che tu abbia Knative serving installati e configurati sul tuo cluster.
Assicurati che l'ambiente a riga di comando sia configurato e che gli strumenti siano aggiornati:
- Cluster GKE su Google Cloud
- Cluster GKE esterni a Google Cloud

Installa curl per provare il servizio.
Installa Docker in locale.

Assemblaggio del codice

Crea passo dopo passo un nuovo servizio di chat Knative serving. Ti ricordiamo che questo servizio crea intenzionalmente un errore di runtime per l'esercizio di risoluzione dei problemi.

Crea un nuovo progetto:

Node.js

Creare un progetto Node.js definendo il pacchetto di servizio, le dipendenze iniziali e alcune operazioni comuni.

Crea una directory hello-service:
```
mkdir hello-service
cd hello-service
```

Genera un file package.json:

npm init --yes
npm install --save express@4

Apri il nuovo file package.json nell'editor e configura uno script start per eseguire node index.js. Al termine, il file avrà il seguente aspetto:

{
  "name": "hello-service",
  "version": "1.0.0",
  "description": "",
  "main": "index.js",
  "scripts": {
      "start": "node index.js",
      "test": "echo \"Error: no test specified\" && exit 1"
  },
  "keywords": [],
  "author": "",
  "license": "ISC",
  "dependencies": {
      "express": "^4.17.1"
  }
}

Se continui a sviluppare questo servizio oltre il tutorial immediato, valuta inserendo la descrizione, l'autore e valutando la licenza. Per ulteriori dettagli, consulta la documentazione di package.json.

Python

Crea una nuova directory hello-service:
```
mkdir hello-service
cd hello-service
```

Crea un file requirements.txt e copia le dipendenze al suo interno:

Flask==3.0.3
pytest==8.2.0; python_version > "3.0"
# pin pytest to 4.6.11 for Python2.
pytest==4.6.11; python_version < "3.0"
gunicorn==22.0.0
Werkzeug==3.0.3

Vai

Crea una directory hello-service:
```
mkdir hello-service
cd hello-service
```

Crea un progetto Go inizializzando un nuovo modulo Go:

go mod init <var>my-domain</var>.com/hello-service

Puoi aggiornare il nome specifico come preferisci: devi aggiornare il nome se il codice venga pubblicato in un repository di codice raggiungibile dal web.

Java

Crea un progetto Maven:

mvn archetype:generate \
  -DgroupId=com.example \
  -DartifactId=hello-service \
  -DarchetypeArtifactId=maven-archetype-quickstart \
  -DinteractiveMode=false

Copia le dipendenze nell'elenco delle dipendenze pom.xml (tra gli elementi <dependencies>):

<dependency>
  <groupId>com.sparkjava</groupId>
  <artifactId>spark-core</artifactId>
  <version>2.9.4</version>
</dependency>
<dependency>
  <groupId>org.slf4j</groupId>
  <artifactId>slf4j-api</artifactId>
  <version>2.0.12</version>
</dependency>
<dependency>
  <groupId>org.slf4j</groupId>
  <artifactId>slf4j-simple</artifactId>
  <version>2.0.12</version>
</dependency>

Copia l'impostazione di compilazione in pom.xml (sotto gli elementi <dependencies>):

<build>
  <plugins>
    <plugin>
      <groupId>com.google.cloud.tools</groupId>
      <artifactId>jib-maven-plugin</artifactId>
      <version>3.4.0</version>
      <configuration>
        <to>
          <image>gcr.io/PROJECT_ID/hello-service</image>
        </to>
      </configuration>
    </plugin>
  </plugins>
</build>

Crea un servizio HTTP per gestire le richieste in entrata:

Node.js

const express = require('express');
const app = express();

app.get('/', (req, res) => {
  console.log('hello: received request.');

  const {NAME} = process.env;
  if (!NAME) {
    // Plain error logs do not appear in Stackdriver Error Reporting.
    console.error('Environment validation failed.');
    console.error(new Error('Missing required server parameter'));
    return res.status(500).send('Internal Server Error');
  }
  res.send(`Hello ${NAME}!`);
});
const port = parseInt(process.env.PORT) || 8080;
app.listen(port, () => {
  console.log(`hello: listening on port ${port}`);
});

Python

import json
import os

from flask import Flask


app = Flask(__name__)


@app.route("/", methods=["GET"])
def index():
    """Example route for testing local troubleshooting.

    This route may raise an HTTP 5XX error due to missing environment variable.
    """
    print("hello: received request.")

    NAME = os.getenv("NAME")

    if not NAME:
        print("Environment validation failed.")
        raise Exception("Missing required service parameter.")

    return f"Hello {NAME}"


if __name__ == "__main__":
    PORT = int(os.getenv("PORT")) if os.getenv("PORT") else 8080

    # This is used when running locally. Gunicorn is used to run the
    # application on Cloud Run. See entrypoint in Dockerfile.
    app.run(host="127.0.0.1", port=PORT, debug=True)

Vai


// Sample hello demonstrates a difficult to troubleshoot service.
package main

import (
	"fmt"
	"log"
	"net/http"
	"os"
)

func main() {
	log.Print("hello: service started")

	http.HandleFunc("/", helloHandler)


	port := os.Getenv("PORT")
	if port == "" {
		port = "8080"
		log.Printf("Defaulting to port %s", port)
	}

	log.Printf("Listening on port %s", port)
	log.Fatal(http.ListenAndServe(fmt.Sprintf(":%s", port), nil))
}

func helloHandler(w http.ResponseWriter, r *http.Request) {
	log.Print("hello: received request")

	name := os.Getenv("NAME")
	if name == "" {
		log.Printf("Missing required server parameter")
		// The panic stack trace appears in Cloud Error Reporting.
		panic("Missing required server parameter")
	}

	fmt.Fprintf(w, "Hello %s!\n", name)
}

Java

import static spark.Spark.get;
import static spark.Spark.port;

import org.slf4j.Logger;
import org.slf4j.LoggerFactory;

public class App {

  private static final Logger logger = LoggerFactory.getLogger(App.class);

  public static void main(String[] args) {
    int port = Integer.parseInt(System.getenv().getOrDefault("PORT", "8080"));
    port(port);

    get(
        "/",
        (req, res) -> {
          logger.info("Hello: received request.");
          String name = System.getenv("NAME");
          if (name == null) {
            // Standard error logs do not appear in Stackdriver Error Reporting.
            System.err.println("Environment validation failed.");
            String msg = "Missing required server parameter";
            logger.error(msg, new Exception(msg));
            res.status(500);
            return "Internal Server Error";
          }
          res.status(200);
          return String.format("Hello %s!", name);
        });
  }
}

Crea un Dockerfile per definire l'immagine container utilizzata per il deployment del servizio:

Node.js


# Use the official lightweight Node.js image.
# https://hub.docker.com/_/node
FROM node:20-slim
# Create and change to the app directory.
WORKDIR /usr/src/app

# Copy application dependency manifests to the container image.
# A wildcard is used to ensure copying both package.json AND package-lock.json (when available).
# Copying this first prevents re-running npm install on every code change.
COPY package*.json ./

# Install dependencies.
# if you need a deterministic and repeatable build create a
# package-lock.json file and use npm ci:
# RUN npm ci --omit=dev
# if you need to include development dependencies during development
# of your application, use:
# RUN npm install --dev

RUN npm install --omit=dev

# Copy local code to the container image.
COPY . ./

# Run the web service on container startup.
CMD [ "npm", "start" ]

Python


# Use the official Python image.
# https://hub.docker.com/_/python
FROM python:3.11

# Allow statements and log messages to immediately appear in the Cloud Run logs
ENV PYTHONUNBUFFERED True

# Copy application dependency manifests to the container image.
# Copying this separately prevents re-running pip install on every code change.
COPY requirements.txt ./

# Install production dependencies.
RUN pip install -r requirements.txt

# Copy local code to the container image.
ENV APP_HOME /app
WORKDIR $APP_HOME
COPY . ./

# Run the web service on container startup.
# Use gunicorn webserver with one worker process and 8 threads.
# For environments with multiple CPU cores, increase the number of workers
# to be equal to the cores available.
# Timeout is set to 0 to disable the timeouts of the workers to allow Cloud Run to handle instance scaling.
CMD exec gunicorn --bind :$PORT --workers 1 --threads 8 --timeout 0 main:app

Vai


# Use the offical golang image to create a binary.
# This is based on Debian and sets the GOPATH to /go.
# https://hub.docker.com/_/golang
FROM golang:1.21-bookworm as builder

# Create and change to the app directory.
WORKDIR /app

# Retrieve application dependencies.
# This allows the container build to reuse cached dependencies.
# Expecting to copy go.mod and if present go.sum.
COPY go.* ./
RUN go mod download

# Copy local code to the container image.
COPY . ./

# Build the binary.
RUN go build -v -o server

# Use the official Debian slim image for a lean production container.
# https://hub.docker.com/_/debian
# https://docs.docker.com/develop/develop-images/multistage-build/#use-multi-stage-builds
FROM debian:bookworm-slim
RUN set -x && apt-get update && DEBIAN_FRONTEND=noninteractive apt-get install -y \
    ca-certificates && \
    rm -rf /var/lib/apt/lists/*

# Copy the binary to the production image from the builder stage.
COPY --from=builder /app/server /server

# Run the web service on container startup.
CMD ["/server"]

Java

Questo esempio utilizza Jib per creare utilizzando strumenti Java comuni. Jib ottimizza le build dei container senza dover disporre di un Dockerfile o di Docker. Scopri di più sulla creazione di container Java con Jib.

<plugin>
  <groupId>com.google.cloud.tools</groupId>
  <artifactId>jib-maven-plugin</artifactId>
  <version>3.4.0</version>
  <configuration>
    <to>
      <image>gcr.io/PROJECT_ID/hello-service</image>
    </to>
  </configuration>
</plugin>

Spedizione del codice

Il codice di spedizione prevede tre passaggi: la creazione di un'immagine container con Cloud Build, caricando l'immagine container in Container Registry il deployment dell'immagine container in Knative serving.

Per spedire il codice:

Crea il contenitore e pubblicalo su Container Registry:
Node.js
```
gcloud builds submit --tag gcr.io/PROJECT_ID/hello-service
```
Dove PROJECT_ID è l'ID progetto Google Cloud. Puoi controllare il tuo ID progetto corrente con gcloud config get-value project.

Se l'operazione riesce, dovresti vedere il messaggio SUCCESS contenente l'ID, la creazione data e ora e nome dell'immagine. L'immagine è archiviata in Container Registry e può essere se lo desideri,
Python
```
gcloud builds submit --tag gcr.io/PROJECT_ID/hello-service
```
dove PROJECT_ID è l'ID progetto Google Cloud. Puoi controllare ID progetto attuale con gcloud config get-value project.

Se l'operazione riesce, dovresti vedere il messaggio SUCCESS contenente l'ID, la creazione data e ora e nome dell'immagine. L'immagine è archiviata in Container Registry e, se lo desideri, può essere riutilizzata.
Vai
```
gcloud builds submit --tag gcr.io/PROJECT_ID/hello-service
```
Dove PROJECT_ID è l'ID progetto Google Cloud. Puoi controllare il tuo ID progetto corrente con gcloud config get-value project.

Se l'operazione riesce, dovresti vedere il messaggio SUCCESS contenente l'ID, la creazione data e ora e nome dell'immagine. L'immagine è archiviata in Container Registry e, se lo desideri, può essere riutilizzata.
Java
```
mvn compile jib:build -Dimage=gcr.io/PROJECT_ID/hello-service
```
Dove PROJECT_ID è l'ID progetto Google Cloud. Puoi controllare ID progetto attuale con gcloud config get-value project.

In caso di esito positivo, dovresti visualizzare il messaggio BUILD SUCCESS. L'immagine è archiviata in Container Registry e, se lo desideri, può essere riutilizzata.
Esegui questo comando per eseguire il deployment della tua app:
```
gcloud run deploy hello-service --image gcr.io/PROJECT_ID/hello-service
```
Sostituisci PROJECT_ID con l'ID del tuo progetto Google Cloud. hello-service è sia il nome dell'immagine container sia il nome del servizio Knative serving. Tieni presente che l'immagine del contenitore viene dispiattata nel servizio e nel cluster che hai configurato in precedenza in Configurazione di gcloud

Attendi il completamento del deployment: l'operazione può richiedere circa mezzo minuto. Se l'operazione riesce, la riga di comando visualizza l'URL del servizio.

Prova

Prova il servizio per verificare di averlo eseguito correttamente. Le richieste devono non riuscire con un errore HTTP 500 o 503 (membri della classe Errori del server 5xx). Il tutorial illustra la risoluzione dei problemi relativi a questa risposta di errore.

Se il cluster è configurato con un routing dominio predefinito, ignora i passaggi precedenti e copia l'URL nel tuo browser web.

Se non utilizzi i certificati TLS automatici e mappatura dei domini, non ti viene fornito URL raggiungibile per il tuo servizio.

Utilizza invece l'URL fornito e l'indirizzo IP del gateway di ingresso del servizio per creare un comando curl che possa inviare richieste al servizio:

Per ottenere l'IP esterno per il bilanciatore del carico, esegui questo comando:
```
kubectl get svc istio-ingressgateway -n ASM-INGRESS-NAMESPACE
```
Sostituisci ASM-INGRESS-NAMESPACE con lo spazio dei nomi in cui Si trova il traffico in entrata di Cloud Service Mesh. Specifica istio-system se ha installato Cloud Service Mesh utilizzando la configurazione predefinita.

L'output risultante è simile al seguente:
```
NAME                   TYPE           CLUSTER-IP     EXTERNAL-IP  PORT(S)
istio-ingressgateway   LoadBalancer   XX.XX.XXX.XX   pending      80:32380/TCP,443:32390/TCP,32400:32400/TCP
```
dove il valore EXTERNAL-IP è il tuo indirizzo IP esterno del bilanciatore del carico di Google Cloud.
Esegui un comando curl utilizzando questo indirizzo GATEWAY_IP nell'URL.
```
 curl -G -H "Host: SERVICE-DOMAIN" https://EXTERNAL-IP/
```
Sostituisci SERVICE-DOMAIN con il dominio assegnato predefinito del tuo completamente gestito di Google Cloud. Puoi ottenerlo prendendo l'URL predefinito e rimuovendo il protocollo http://.
Visualizza il messaggio di errore HTTP 500 o HTTP 503.

Indagine sul problema

Visualizza che l'errore HTTP 5xx riscontrato sopra in Provare è stato rilevato come errore di runtime in produzione. Questo tutorial illustra una processo formale per gestirlo. Sebbene i processi di risoluzione degli errori di produzione variano notevolmente, questo tutorial presenta una sequenza particolare di passaggi per mostrare l'applicazione di strumenti e tecniche utili.

Per esaminare questo problema, dovrai svolgere le seguenti fasi:

Raccogliere maggiori dettagli sull’errore segnalato per supportare ulteriori indagini e impostare una strategia di mitigazione.
Riduci l'impatto sugli utenti decidendo di applicare una correzione o di eseguire il rollback a una versione nota come sana.
Riproduci l'errore per confermare che sono stati raccolti i dettagli corretti e che l'errore non è un glitch una tantum
Esegui un'analisi delle cause principali del bug per trovare il codice, la configurazione o il processo che ha creato questo errore

All'inizio dell'indagine hai un URL, un timestamp e il messaggio "Errore interno del server".

Raccolta di ulteriori dettagli

Raccogliere ulteriori informazioni sul problema per capire cosa è successo e determinare i passaggi successivi.

Utilizza gli strumenti disponibili per raccogliere ulteriori dettagli:

Visualizza i log per maggiori dettagli.
Usa Cloud Logging per rivedere la sequenza di operazioni che portano problema, inclusi i messaggi di errore.

Esegui il rollback a una versione integro

Se hai una revisione che è stata funziona, puoi eseguire il rollback del servizio per utilizzare la revisione. Ad esempio: non potrai eseguire un rollback sul nuovo Servizio hello-service di cui hai eseguito il deployment in questo perché contiene una sola revisione.

Per individuare una revisione e eseguire il rollback del servizio:

Riproduzione dell'errore in corso...

Utilizzando i dettagli ottenuti in precedenza, conferma si verifica sempre in condizioni di test.

Invia la stessa richiesta HTTP riprovando e controlla se vengono segnalati lo stesso errore con i relativi dettagli. I dettagli dell'errore possono richiedere del tempo che vengano mostrati.

Poiché il servizio di esempio in questo tutorial è di sola lettura e non attiva effetti collaterali complicati, la riproduzione di errori in produzione è sicura. Tuttavia, per molti servizi reali non è così: potrebbe essere necessario riprodurre gli errori in un ambiente di test o limitare questo passaggio all'indagine locale.

La riproduzione dell'errore stabilisce il contesto per ulteriori lavori. Ad esempio: Se gli sviluppatori non riescono a riprodurre l'errore, potrebbero essere necessarie ulteriori indagini strumentazione aggiuntiva del servizio.

Esecuzione dell'analisi delle cause principali

L'analisi della causa principale è un passaggio importante per la risoluzione dei problemi in modo da risolvere il problema anziché un sintomo.

In precedenza in questo tutorial, hai riprodotto il problema su Knative serving, confermando che il problema è attivo quando il servizio è ospitato su Knative serving. Ora riproduci il problema localmente per determinare se è isolato nel codice o se si verifica solo nell'hosting di produzione.

Se non hai utilizzato Docker CLI localmente con Container Registry, autenticalo con gcloud:
```
gcloud auth configure-docker
```
Per gli approcci alternativi, vedi Metodi di autenticazione di Container Registry.
Se il nome dell'immagine container utilizzato più di recente non è disponibile, il servizio contiene le informazioni sull'immagine container di cui è stato eseguito il deployment più recente:
```
gcloud run services describe hello-service
```
Trova il nome dell'immagine container all'interno dell'oggetto spec. Un comando più mirato può recuperarlo direttamente:
```
gcloud run services describe hello-service \
   --format="value(spec.template.spec.containers.image)"
```
Questo comando rivela il nome di un'immagine container come gcr.io/PROJECT_ID/hello-service.
Estrai l'immagine container da Container Registry nel tuo ambiente. Questo passaggio potrebbe richiedere diversi minuti durante il download dell'immagine container:
```
docker pull gcr.io/PROJECT_ID/hello-service
```
Gli aggiornamenti successivi all'immagine del contenitore che riutilizzano questo nome possono essere recuperati con lo stesso comando. Se salti questo passaggio, utilizza il comando docker run riportato di seguito esegue il pull di un'immagine container se non è presente sulla macchina locale.
Eseguilo localmente per verificare che il problema non sia univoco di Knative serving:
```
PORT=8080 && docker run --rm -e PORT=$PORT -p 9000:$PORT \
   gcr.io/PROJECT_ID/hello-service
```
Se analizziamo gli elementi del comando riportato sopra,
- La variabile di ambiente PORT viene utilizzata dal servizio per determinare la per rimanere in ascolto all'interno del container.
- Il comando run avvia il container, utilizzando come impostazione predefinita il punto di ingresso definito nel Dockerfile o in un'immagine container padre.
- Il flag --rm elimina l'istanza del contenitore all'uscita.
- Il flag -e assegna un valore a una variabile di ambiente. -e PORT=$PORT propaga la variabile PORT dal sistema locale al contenitore con lo stesso nome.
- Il flag -p pubblica il container come servizio disponibile su localhost sulla porta 9000. Le richieste a localhost:9000 verranno indirizzate al sulla porta 8080. Ciò significa che l'output del servizio relativo alla porta numero in uso non corrisponderà alla modalità di accesso al servizio.
- L'ultimo argomento gcr.io/PROJECT_ID/hello-service è un percorso del repository che rimanda alla versione più recente dell'immagine del contenitore. Se non è disponibile localmente, Docker tenta di recuperare l'immagine da un registro remoto.
Nel browser, apri http://localhost:9000. Controlla l'output del terminale per che corrispondono a quelli di Google Cloud Observability.

Se il problema non è riproducibile localmente, potrebbe essere univoco Ambiente Knative serving. Esamina il Guida alla risoluzione dei problemi relativi a Knative serving per aree specifiche da esaminare.

In questo caso l'errore viene riprodotto localmente.

Ora che l'errore è confermato doppiamente come persistente e causato dal servizio anziché sulla piattaforma di hosting, è il momento di esaminare il codice in modo più approfondito.

Ai fini di questo tutorial, è possibile assumere che il codice all'interno del contenitore e il codice nel sistema locale siano identici.

Node.js

Individua l'origine del messaggio di errore nel file index.js intorno alla riga numero chiamato nell'analisi dello stack mostrata nei log:

const {NAME} = process.env;
if (!NAME) {
  // Plain error logs do not appear in Stackdriver Error Reporting.
  console.error('Environment validation failed.');
  console.error(new Error('Missing required server parameter'));
  return res.status(500).send('Internal Server Error');
}

Python

Individua l'origine del messaggio di errore nel file main.py intorno al numero di riga indicato nella traccia dello stack mostrata nei log:

NAME = os.getenv("NAME")

if not NAME:
    print("Environment validation failed.")
    raise Exception("Missing required service parameter.")

Vai

Individua l'origine del messaggio di errore nel file main.go intorno al numero di riga indicato nella traccia dello stack mostrata nei log:

name := os.Getenv("NAME")
if name == "" {
	log.Printf("Missing required server parameter")
	// The panic stack trace appears in Cloud Error Reporting.
	panic("Missing required server parameter")
}

Java

Individua l'origine del messaggio di errore nel file App.java, intorno al numero di riga indicato nell'analisi dello stack mostrata nei log:

String name = System.getenv("NAME");
if (name == null) {
  // Standard error logs do not appear in Stackdriver Error Reporting.
  System.err.println("Environment validation failed.");
  String msg = "Missing required server parameter";
  logger.error(msg, new Exception(msg));
  res.status(500);
  return "Internal Server Error";
}

Esaminando questo codice, quando la variabile di ambiente NAME non è impostata vengono eseguite le seguenti azioni:

Viene registrato un errore in Google Cloud Observability
Viene inviata una risposta di errore HTTP

Il problema è causato da una variabile mancante, ma la causa principale è più specifica: la modifica del codice che aggiunge la dipendenza obbligatoria da una variabile di ambiente non includeva modifiche correlate agli script di deployment e alla documentazione dei requisiti di runtime.

Risolvere la causa principale

Ora che abbiamo raccolto il codice e identificato la potenziale causa principale, possiamo adottare le misure del caso per risolvere il problema.

Verifica se il servizio funziona localmente con l'ambiente NAME disponibile:
1. Esegui il container in locale con la variabile di ambiente aggiunta:
```
PORT=8080 && docker run --rm -e PORT=$PORT -p 9000:$PORT \
 -e NAME="Local World!" \
 gcr.io/PROJECT_ID/hello-service
```
2. Apri il browser e vai all'indirizzo http://localhost:9000
3. Vedi "Hello Local World!" appaiono sulla pagina
Modifica l'ambiente di servizio Knative serving in esecuzione in modo da includere questo elemento variabile:
1. Esegui il comando di aggiornamento dei servizi con il parametro --update-env-vars per aggiungere una variabile di ambiente:
```
gcloud run services update hello-service \
  --update-env-vars NAME=Override
```
2. Attendi qualche secondo mentre Knative serving crea una nuova revisione in base alla revisione precedente con la nuova variabile di ambiente aggiunta.
Verifica che il servizio sia stato risolto:
1. Vai nel browser all'URL del servizio Knative serving.
2. Nella pagina viene visualizzato il messaggio "Hello Override!".
3. Verifica che non vengano visualizzati messaggi o errori imprevisti in Cloud Logging.

Migliorare la velocità di risoluzione dei problemi futuri

In questo problema di produzione di esempio, l'errore era correlato alla configurazione operativa. Esistono modifiche al codice che ridurranno al minimo l'impatto di questo problema in futuro.

Migliora il log degli errori in modo da includere dettagli più specifici.
Anziché restituire un errore, il servizio deve eseguire il fallback a un valore predefinito sicuro. Se l'utilizzo di un valore predefinito rappresenta un cambiamento alla funzionalità normale, utilizza un avviso a scopo di monitoraggio.

Vediamo come rimuovere la variabile di ambiente NAME come dipendenza obbligatoria.

Rimuovi il codice di gestione NAME esistente:

Node.js

const {NAME} = process.env;
if (!NAME) {
  // Plain error logs do not appear in Stackdriver Error Reporting.
  console.error('Environment validation failed.');
  console.error(new Error('Missing required server parameter'));
  return res.status(500).send('Internal Server Error');
}

Python

NAME = os.getenv("NAME")

if not NAME:
    print("Environment validation failed.")
    raise Exception("Missing required service parameter.")

Vai

name := os.Getenv("NAME")
if name == "" {
	log.Printf("Missing required server parameter")
	// The panic stack trace appears in Cloud Error Reporting.
	panic("Missing required server parameter")
}

Java

String name = System.getenv("NAME");
if (name == null) {
  // Standard error logs do not appear in Stackdriver Error Reporting.
  System.err.println("Environment validation failed.");
  String msg = "Missing required server parameter";
  logger.error(msg, new Exception(msg));
  res.status(500);
  return "Internal Server Error";
}

Aggiungi un nuovo codice che imposti un valore di riserva:

Node.js

const NAME = process.env.NAME || 'World';
if (!process.env.NAME) {
  console.log(
    JSON.stringify({
      severity: 'WARNING',
      message: `NAME not set, default to '${NAME}'`,
    })
  );
}

Python

NAME = os.getenv("NAME")

if not NAME:
    NAME = "World"
    error_message = {
        "severity": "WARNING",
        "message": f"NAME not set, default to {NAME}",
    }
    print(json.dumps(error_message))

Vai

name := os.Getenv("NAME")
if name == "" {
	name = "World"
	log.Printf("warning: NAME not set, default to %s", name)
}

Java

String name = System.getenv().getOrDefault("NAME", "World");
if (System.getenv("NAME") == null) {
  logger.warn(String.format("NAME not set, default to %s", name));
}

Esegui il test a livello locale ricostruendo ed eseguendo il container nei casi di configurazione interessati:
Node.js
```
docker build --tag gcr.io/PROJECT_ID/hello-service .
```
Python
```
docker build --tag gcr.io/PROJECT_ID/hello-service .
```
Vai
```
docker build --tag gcr.io/PROJECT_ID/hello-service .
```
Java
```
mvn compile jib:build
```
Verifica che la variabile di ambiente NAME continui a funzionare:
```
PORT=8080 && docker run --rm -e $PORT -p 9000:$PORT \
 -e NAME="Robust World" \
 gcr.io/PROJECT_ID/hello-service
```
Verifica che il servizio funzioni senza la variabile NAME:
```
PORT=8080 && docker run --rm -e $PORT -p 9000:$PORT \
 gcr.io/PROJECT_ID/hello-service
```
Se il servizio non restituisce alcun risultato, conferma la rimozione del codice nel nel primo passaggio non ha rimosso le righe aggiuntive, come quelle utilizzate per scrivere la risposta.
Per eseguire il deployment, consulta la sezione Deployment del codice.

Ogni deployment in un servizio crea una nuova revisione e avvia automaticamente il servizio quando è pronto.

Per cancellare le variabili di ambiente impostate in precedenza:

gcloud run services update hello-service --clear-env-vars

Aggiungi la nuova funzionalità per il valore predefinito alla copertura dei test automatici per il servizio.

Trovare altri problemi nei log

Potresti visualizzare altri problemi nel visualizzatore log per questo servizio. Ad esempio, una chiamata di sistema non supportata viene visualizzata nei log come "Limitazione della sandbox del contenitore".

Ad esempio, i servizi Node.js a volte generano questo messaggio di log:

Container Sandbox Limitation: Unsupported syscall statx(0xffffff9c,0x3e1ba8e86d88,0x0,0xfff,0x3e1ba8e86970,0x3e1ba8e86a90). Please, refer to https://gvisor.dev/c/linux/amd64/statx for more information.

In questo caso, la mancanza di assistenza non influisce sul servizio di esempio hello-service.

Esegui la pulizia

Puoi eliminare le risorse create per questo tutorial per evitare di sostenere costi.

Eliminazione delle risorse dei tutorial

Elimina il servizio Knative serving di cui hai eseguito il deployment in questo tutorial:
```
gcloud run services delete SERVICE-NAME
```
Dove SERVICE-NAME è il nome del servizio che hai scelto.

Puoi anche eliminare i servizi Knative serving dalla Console Google Cloud:

Vai a Knative serving

Rimuovi le configurazioni predefinite di gcloud che hai aggiunto durante la configurazione del tutorial:

 gcloud config unset run/platform
 gcloud config unset run/cluster
 gcloud config unset run/cluster_location

Rimuovi la configurazione del progetto:
```
 gcloud config unset project
```
Elimina le altre risorse Google Cloud create in questo tutorial:
- Elimina l'immagine container denominata gcr.io/<var>PROJECT_ID</var>/hello-service da Container Registry.
- Se hai creato un cluster per questo tutorial, elimina il cluster.

Passaggi successivi

Scopri di più su come utilizzare Cloud Logging per ottenere informazioni sul comportamento in produzione.
Scopri di più sulla risoluzione dei problemi di Knative serving.
Esplora architetture di riferimento, diagrammi e best practice su Google Cloud. Consulta il nostro Cloud Architecture Center.