Questa pagina è stata tradotta dall'API Cloud Translation.

Tutorial: risoluzione dei problemi locali di un servizio Cloud Run

Questo tutorial mostra come uno sviluppatore di servizi può risolvere i problemi relativi a un guasto Servizio Cloud Run che utilizza gli strumenti di Google Cloud Observability per il rilevamento e e un flusso di lavoro di sviluppo.

Questo "case study" dettagliato complementare alla guida alla risoluzione dei problemi utilizza un progetto di esempio che genera errori di runtime durante il deployment, che puoi risolvere per trovare e correggere il problema.

Obiettivi

Scrivi, crea ed esegui il deployment di un servizio in Cloud Run
Utilizzare Error Reporting e Cloud Logging per identificare un errore
Recupera l'immagine container da Container Registry per un'analisi delle cause principali
Correggi il servizio "produzione", quindi miglioralo per ridurre 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

Sign in to your Google Cloud account. If you're new to Google Cloud, create an account to evaluate how our products perform in real-world scenarios. New customers also get $300 in free credits to run, test, and deploy workloads.

In the Google Cloud console, on the project selector page, select or create a Google Cloud project.

Go to project selector

Make sure that billing is enabled for your Google Cloud project.

In the Google Cloud console, on the project selector page, select or create a Google Cloud project.

Go to project selector

Make sure that billing is enabled for your Google Cloud project.

Abilita l'API Cloud Run Admin
Installa e inizializza l'interfaccia a riga di comando gcloud.
Aggiorna i componenti:
```
gcloud components update
```
Segui le istruzioni per installare Docker in locale

Ruoli obbligatori

Per ottenere le autorizzazioni necessarie per completare il tutorial: chiedi all'amministratore di concederti i seguenti ruoli IAM sul tuo progetto:

Editor Cloud Build (roles/cloudbuild.builds.editor)
Amministratore Cloud Run (roles/run.admin)
Visualizzatore Error Reporting (roles/errorreporting.viewer)
Funzione di accesso alla visualizzazione dei log (roles/logging.viewAccessor)
Amministratore IAM del progetto (roles/resourcemanager.projectIamAdmin)
Utente account di servizio (roles/iam.serviceAccountUser)
Consumer Service Usage (roles/serviceusage.serviceUsageConsumer)
Amministratore archiviazione (roles/storage.admin)

Per saperne di più sulla concessione dei ruoli, consulta Gestire l'accesso a progetti, cartelle e organizzazioni.

Potresti anche riuscire a ottenere le autorizzazioni richieste tramite la ruoli o altri ruoli predefiniti ruoli.

Configurare i valori predefiniti di gcloud

Per configurare gcloud con i valori predefiniti per il servizio Cloud Run:

Imposta il progetto predefinito:
```
gcloud config set project PROJECT_ID
```
Sostituisci PROJECT_ID con il nome del progetto per cui hai creato questo tutorial.
Configura gcloud per la regione scelta:
```
gcloud config set run/region REGION
```
Sostituisci REGION con la regione di Cloud Run supportata che preferisci.

Località Cloud Run

Cloud Run è un servizio a livello di regione, il che significa che l'infrastruttura che esegue i tuoi servizi Cloud Run si trova in una regione specifica ed è gestita da Google in modo da essere disponibile in modo ridondante in tutte le zone all'interno della regione.

La soddisfazione dei requisiti di latenza, disponibilità o durabilità è uno dei fattori principali per la selezione della regione in cui vengono eseguiti i servizi Cloud Run. In genere puoi selezionare la regione più vicina ai tuoi utenti, ma devi prendere in considerazione la posizione degli altri prodotti Google Cloud utilizzati dal servizio Cloud Run. L'utilizzo combinato dei prodotti Google Cloud in più località può influire sulla latenza e sul costo del servizio.

Cloud Run è disponibile nelle regioni seguenti:

Soggetto ai prezzi di Livello 1

asia-east1 (Taiwan)
asia-northeast1 (Tokyo)
asia-northeast2 (Osaka)
europe-north1 (Finlandia) A basse emissioni di CO₂
europe-southwest1 (Madrid) A basse emissioni di CO₂
europe-west1 (Belgio) Bassi livelli di CO₂
europe-west4 (Paesi Bassi) Bassi livelli di CO₂
europe-west8 (Milano)
europe-west9 (Parigi) Bassi livelli di CO₂
me-west1 (Tel Aviv)
us-central1 (Iowa) A basse emissioni di CO₂
us-east1 (Carolina del Sud)
us-east4 (Virginia del Nord)
us-east5 (Columbus)
us-south1 (Dallas) A basse emissioni di CO₂
us-west1 (Oregon) Bassi livelli di CO₂

Soggetto ai prezzi di Livello 2

africa-south1 (Johannesburg)
asia-east2 (Hong Kong)
asia-northeast3 (Seul, Corea del Sud)
asia-southeast1 (Singapore)
asia-southeast2 (Giacarta)
asia-south1 (Mumbai, India)
asia-south2 (Delhi, India)
australia-southeast1 (Sydney)
australia-southeast2 (Melbourne)
europe-central2 (Varsavia, Polonia)
europe-west10 (Berlino) A basse emissioni di CO₂
europe-west12 (Torino)
europe-west2 (Londra, Regno Unito) Bassi livelli di CO₂
europe-west3 (Francoforte, Germania) A basse emissioni di CO₂
europe-west6 (Zurigo, Svizzera) Bassi livelli di CO₂
me-central1 (Doha)
me-central2 (Dammam)
northamerica-northeast1 (Montreal) Bassi livelli di CO₂
northamerica-northeast2 (Toronto) A basse emissioni di CO₂
southamerica-east1 (San Paolo, Brasile) A basse emissioni di CO₂
southamerica-west1 (Santiago, Cile) A basse emissioni di CO₂
us-west2 (Los Angeles)
us-west3 (Salt Lake City)
us-west4 (Las Vegas)

Se hai già creato un servizio Cloud Run, puoi visualizzare la regione nella dashboard di Cloud Run nella console Google Cloud.

Assemblaggio del codice

Crea passo dopo passo un nuovo servizio di messaggistica di Cloud Run. Ti ricordiamo che questo servizio crea un errore di runtime per risoluzione dei problemi dell'allenamento.

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 nuova directory hello-service:
```
mkdir hello-service
cd hello-service
```
Crea un nuovo progetto Node.js generando 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-broken",
  "description": "Broken Cloud Run service for troubleshooting practice",
  "version": "1.0.0",
  "private": true,
  "main": "index.js",
  "scripts": {
    "start": "node index.js",
    "test": "echo \"Error: no test specified\" && exit 0",
    "system-test": "NAME=Cloud c8 mocha -p -j 2 test/system.test.js --timeout=360000 --exit"
  },
  "engines": {
    "node": ">=16.0.0"
  },
  "author": "Google LLC",
  "license": "Apache-2.0",
  "dependencies": {
    "express": "^4.17.1"
  },
  "devDependencies": {
    "c8": "^10.0.0",
    "google-auth-library": "^9.0.0",
    "got": "^11.5.0",
    "mocha": "^10.0.0"
  }
}

Se continui a sviluppare questo servizio oltre il tutorial immediato, ti consigliamo di compilare la descrizione, l'autore e valutare 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 nuova directory hello-service:
```
mkdir hello-service
cd hello-service
```
Crea un progetto Go inizializzando un nuovo modulo Go:
```
go mod init example.com/hello-service
```

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

Java

Crea un nuovo progetto Maven:

mvn archetype:generate \
  -DgroupId=com.example.cloudrun \
  -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 della build 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 di container senza la necessità di un Dockerfile o di avere Docker installato. 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>

Invio 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 Cloud Run.

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 ID progetto attuale con gcloud config get-value project.

In caso di esito positivo, dovresti visualizzare un messaggio di successo contenente l'ID, l'ora di creazione e il 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.

In caso di esito positivo, dovresti visualizzare un messaggio di successo contenente l'ID, l'ora di creazione e il nome dell'immagine. L'immagine è archiviata in Container Registry e può essere se lo desideri,
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.

In caso di esito positivo, dovresti visualizzare un messaggio di successo contenente l'ID, l'ora di creazione e il nome dell'immagine. L'immagine è archiviata in Container Registry e, se lo desideri, può essere riutilizzata.
Java
1. Utilizza l'assistente per le credenziali gcloud per autorizzare Docker a eseguire il push nel tuo Container Registry.
  gcloud auth configure-docker
2. Utilizza il plug-in Maven Jib per creare il container ed eseguirlo in Container Registry.
  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.

Se l'operazione riesce, dovresti visualizzare il messaggio BUILD SUCCESS. L'immagine è archiviata in in Container Registry e può essere riutilizzato, se necessario.
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 Cloud Run. Tieni presente che l'immagine del contenitore viene dispiattata nel servizio e nella regione che hai configurato in precedenza in Configurazione di gcloud.

Rispondi y, "Sì", alla richiesta consenti non autenticati. Per ulteriori dettagli sull'autenticazione basata su IAM, consulta la pagina Gestire l'accesso.

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 implementato 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.

Al servizio viene assegnato automaticamente un URL navigabile.

Accedi a questo URL con il tuo browser web:
1. Apri un browser web
2. Trova l'output dell'URL del servizio con il comando di deployment precedente.
  
  Se il comando di deployment non ha fornito un URL, si è verificato un problema. Esamina il messaggio di errore e agisci di conseguenza, se non esistono indicazioni strategiche è presente, consulta la guida alla risoluzione dei problemi ed eventualmente riprovare.
3. Accedi all'URL copiandolo nella barra degli indirizzi del browser e premendo INVIO.
Visualizza l'errore HTTP 500 o HTTP 503.

Se ricevi un errore HTTP 403, è possibile che tu abbia rifiutato allow unauthenticated invocations al prompt di deployment. Per risolvere il problema, concedi l'accesso non autenticato al servizio:
```
gcloud run services add-iam-policy-binding hello-service \
  --member="allUsers" \
  --role="roles/run.invoker"
```

Per ulteriori informazioni, consulta Consentire l'accesso pubblico (non autenticato).

Indagine sul problema

Verifica che l'errore HTTP 5xx riscontrato in Prova è stato riscontrato come un errore di runtime di produzione. Questo tutorial illustra una processo formale per gestirlo. Sebbene le procedure di risoluzione degli errori di produzione varieggino notevolmente, questo tutorial presenta una sequenza specifica 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.
Allevia l'impatto degli utenti decidendo se eseguire una correzione o eseguire il rollback a una versione integro nota.
Riproduci l'errore per confermare che sono stati raccolti i dettagli corretti e che l'errore non è un glitch una tantum
Esegui un'analisi della causa principale del bug per trovare il codice, la configurazione processo che ha creato l'errore

All'inizio dell'indagine sono disponibili un URL, un timestamp e il messaggio "Internal Server Error".

Raccolta di ulteriori dettagli

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

Utilizza gli strumenti di Google Cloud Observability disponibili per raccogliere ulteriori dettagli:

Utilizza la console Error Reporting, che fornisce una dashboard con dettagli e monitoraggio della ricorrenza per gli errori con un'analisi dello stack riconosciuta.

Vai alla console di Error Reporting

Elenco degli errori registrati. Gli errori vengono raggruppati per messaggio tra revisioni, servizi e piattaforme.
Fai clic sull'errore per visualizzare i dettagli della traccia dello stack, tenendo presente le chiamate di funzione eseguite poco prima dell'errore.

"Esempio di traccia dello stack" nella pagina dei dettagli dell'errore mostra una singola istanza dell'errore. Puoi esaminare ogni singola istanza.
Utilizza Cloud Logging per esaminare la sequenza di operazioni che ha causato il problema, inclusi i messaggi di errore non inclusi nella console Error Reporting a causa della mancanza di una traccia dello stack degli errori riconosciuta:

Vai alla console Cloud Logging

Seleziona Revisione Cloud Run > hello-service dal primo elenco a discesa. In questo modo le voci di log verranno filtrate in base a quelle generate dal servizio.

Scopri di più sulla visualizzazione dei log in Cloud Run

Esegui il rollback a una versione integro

Se si tratta di un servizio consolidato che funziona, ci sarà una precedente del servizio in Cloud Run. Questo tutorial utilizza un nuovo servizio senza versioni precedenti, quindi non puoi eseguire un rollback.

Tuttavia, se hai un servizio con versioni precedenti a cui puoi eseguire il rollback, segui la sezione Visualizzazione dei dettagli della revisione per estrarre il nome del contenitore e i dettagli di configurazione necessari per creare un nuovo deployment funzionante del servizio.

Riproduzione dell'errore in corso...

Utilizzando i dettagli ottenuti in precedenza, verifica che il problema si verifichi in modo coerente nelle condizioni di test.

Invia la stessa richiesta HTTP provando di nuovo e controlla se vengono segnalati gli stessi errori e dettagli. Potrebbe essere necessario del tempo prima che vengano visualizzati i dettagli dell'errore.

Poiché il servizio di esempio in questo tutorial è di sola lettura e non attiva alcuno complicando gli effetti collaterali, la riproduzione degli errori in produzione è sicura. Tuttavia, per molti servizi reali, non sarà così: potresti dover riprodurre gli errori in un ambiente di test o limitare questo passaggio alle indagini locali.

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 in Cloud Run che conferma che il problema è attivo quando il servizio è ospitato su in Cloud Run. Ora riproduci il problema localmente per determinare se è isolato nel codice o se si verifica solo nell'hosting di produzione.

Se non hai utilizzato l'interfaccia a riga di comando Docker in locale con Container Registry, esegui l'autenticazione con gcloud:
```
gcloud auth configure-docker
```
Per approcci alternativi, consulta Metodi di autenticazione di Container Registry.
Se il nome dell'immagine container utilizzata più di recente non è disponibile, la descrizione del servizio contiene le informazioni sull'immagine container di cui è stato eseguito il deployment più di recente:
```
gcloud run services describe hello-service
```
Trova il nome dell'immagine del contenitore 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 mostra il nome di un'immagine container, ad esempio 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.
Esegui in locale per verificare che il problema non sia univoco di Cloud Run:
```
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 porta su cui eseguire l'ascolto all'interno del contenitore.
- 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 di container 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 instradate al container sulla porta 8080. Ciò significa che l'output del servizio relativo al numero di porta in uso non corrisponderà al modo in cui si accede al servizio.
- L'argomento finale gcr.io/PROJECT_ID/hello-service è l'immagine container tag, un'etichetta leggibile per l'immagine container l'identificatore hash sha256. Se non è disponibile localmente, Docker tenta di recuperare l'immagine da un registry remoto.
Nel browser, apri http://localhost:9000. Controlla l'output del terminale per messaggi di errore che corrispondono a quelli su {ops_name}}.

Se il problema non è riproducibile localmente, potrebbe essere specifico per l'ambiente Cloud Run. Esamina il Guida alla risoluzione dei problemi di Cloud Run per aree specifiche da esaminare.

In questo caso l'errore viene riprodotto localmente.

Ora che l'errore è stato confermato come persistente e causato dal codice del servizio anziché dalla piattaforma di hosting, è il momento di esaminare più da vicino il codice.

Ai fini di questo tutorial, è consigliabile presupporre il codice all'interno del container e il codice nel sistema locale è identico.

Riesamina l'analisi dello stack del report sugli errori ed esegui un controllo incrociato con il codice per trovare sulle specifiche linee in errore.

Node.js

Individua l'origine del messaggio di errore nel file index.js intorno al numero di riga indicato nella traccia 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 alla riga numero chiamato nell'analisi 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 alla riga numero chiamato nell'analisi 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";
}

Durante l'esame di questo codice, vengono eseguite le seguenti azioni quando l'ambiente NAME non è impostata:

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 al codice che aggiungeva la dipendenza rigida su una variabile di ambiente che includa le modifiche correlate agli script di deployment e alla documentazione sui requisiti di runtime.

Correzione della causa principale

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

Controlla se il servizio funziona localmente con l'ambiente NAME disponibile in uso:
1. Esegui il contenitore localmente 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. Vai all'indirizzo http://localhost:9000 nel browser.
3. Visualizza "Hello Local World!" nella pagina
Modifica l'ambiente del servizio Cloud Run in esecuzione per includere questa variabile:
1. Esegui il comando services update per aggiungere una variabile di ambiente:
```
gcloud run services update hello-service \
  --set-env-vars NAME=Override
```
2. Attendi qualche secondo mentre Cloud Run 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 Cloud Run.
2. Vedi "Hello Override!" vengono visualizzate nella pagina.
3. Verifica che non vengano visualizzati messaggi o errori imprevisti in Cloud Logging o Error Reporting.

Migliorare la velocità di risoluzione dei problemi futuri

In questo problema di produzione di esempio, l'errore era correlato alle operazioni configurazione. Alcune modifiche al codice ridurranno al minimo l'impatto di questa problema in futuro.

Migliora il log degli errori in modo da includere dettagli più specifici.
Invece di restituire un errore, fai in modo che il servizio torni a un'impostazione predefinita sicura. 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 test in locale ricreando ed eseguendo il container tramite di configurazione:

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=$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=$PORT -p 9000:$PORT \
 gcr.io/PROJECT_ID/hello-service

Se il servizio non restituisce un risultato, verifica che la rimozione del codice nel primo passaggio non abbia rimosso righe aggiuntive, ad esempio 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.

Individuazione di altri problemi nei log

Potresti notare 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, a volte i servizi Node.js 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.

Risoluzione dei problemi di Terraform

Per domande o risoluzione dei problemi relativi a Terraform, consulta la risoluzione dei problemi di convalida delle norme di Terraform o contatta l'assistenza Terraform.

Esegui la pulizia

Se hai creato un nuovo progetto per questo tutorial, elimina il progetto. Se hai utilizzato un progetto esistente e vuoi conservarlo senza le modifiche aggiunte in questo tutorial, elimina le risorse create per il tutorial.

Elimina il progetto

Il modo più semplice per eliminare la fatturazione creato per il tutorial.

Per eliminare il progetto:

Attenzione: l'eliminazione di un progetto ha i seguenti effetti:

L'intero contenuto del progetto viene eliminato. Se hai utilizzato un progetto esistente per le attività descritte in questo documento, quando lo elimini elimini anche tutto il lavoro svolto nel progetto.
Gli ID progetto personalizzati non sono più disponibili. Quando hai creato questo progetto, potresti aver creato un ID progetto personalizzato che vuoi utilizzare in futuro. Per conservare gli URL che utilizzano l'ID progetto, ad esempio un appspot.com URL, elimina le risorse selezionate all'interno del progetto anziché eliminare l'intero progetto.

Se intendi esplorare più architetture, tutorial o guide rapide, il riuso dei progetti può aiutarti a non superare i limiti di quota.

In the Google Cloud console, go to the Manage resources page.
Go to Manage resources
In the project list, select the project that you want to delete, and then click Delete.
In the dialog, type the project ID, and then click Shut down to delete the project.

Eliminazione delle risorse dei tutorial

Elimina il servizio Cloud Run 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 Cloud Run dalla console Google Cloud.
Rimuovi la configurazione predefinita della regione gcloud che hai aggiunto durante il tutorial configurazione:
```
 gcloud config unset run/region
```
Rimuovi la configurazione del progetto:
```
 gcloud config unset project
```
Elimina altre risorse Google Cloud create in questo tutorial:
- Elimina l'immagine container denominata gcr.io/<var>PROJECT_ID</var>/hello-service da Container Registry.

Passaggi successivi

Scopri di più su come utilizzare Cloud Logging ed Error Reporting. per ottenere insight sul comportamento di produzione.
Per ulteriori informazioni sulla risoluzione dei problemi di Cloud Run, consulta la guida alla risoluzione dei problemi.
Esplora architetture di riferimento, diagrammi e best practice su Google Cloud. Consulta il nostro Cloud Architecture Center.