פתרון בעיות מקומי

במדריך הזה מוסבר איך לפתור בעיות בשירות Knative Serving באמצעות כלי Stackdriver לגילוי, ואיך להשתמש בתהליך עבודה מקומי לפיתוח לצורך בדיקה.

המדריך המפורט הזה הוא 'מחקר מקרה' שנועד להשלים את מדריך פתרון הבעיות. הוא כולל פרויקט לדוגמה שגורם לשגיאות בזמן הריצה כשפורסים אותו. המדריך מסביר איך לפתור את הבעיה.

מטרות

  • כתיבה, פיתוח ופריסה של שירות למילוי בקשות מסוג Knative
  • שימוש ב-Cloud Logging כדי לזהות שגיאה
  • אחזור קובץ אימג' של קונטיינר מ-Container Registry לצורך ניתוח של שורש הבעיה
  • לתקן את שירות ה'ייצור', ואז לשפר את השירות כדי לצמצם בעיות עתידיות

עלויות

במסמך הזה משתמשים ברכיבים הבאים של Google Cloud, והשימוש בהם כרוך בתשלום:

כדי ליצור הערכת עלויות בהתאם לשימוש החזוי, אפשר להשתמש במחשבון התמחור.

יכול להיות שמשתמשים חדשים ב- Google Cloud זכאים לתקופת ניסיון בחינם.

לפני שמתחילים

הרכבת הקוד

בונים שירות חדש של Knative serving greeter שלב אחר שלב. לתזכורת, השירות הזה יוצר שגיאת זמן ריצה בכוונה לצורך תרגיל פתרון הבעיות.

  1. כדי ליצור פרויקט חדש:

    Node.js

    יוצרים פרויקט Node.js על ידי הגדרת חבילת השירות, התלויות הראשוניות וכמה פעולות נפוצות.

    1. יוצרים ספרייה בשם hello-service:

      mkdir hello-service
cd hello-service

    2. יוצרים קובץ package.json:

      npm init --yes
npm install express@4

    3. פותחים את הקובץ החדש package.json בכלי העריכה ומגדירים סקריפט start להרצת node index.js. בסיום, הקובץ ייראה כך:

      {
  "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"
  }
}

    אם אתם מתכוונים להמשיך לפתח את השירות הזה מעבר להדרכה המיידית, כדאי למלא את התיאור, את שם המחבר ולבדוק את הרישיון. פרטים נוספים זמינים במסמכי התיעוד בנושא package.json.

    Python

    1. יצירת ספרייה חדשה ב-hello-service:

      mkdir hello-service
cd hello-service

    2. יוצרים קובץ requirements.txt ומעתיקים אליו את התלות: 

      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==23.0.0
Werkzeug==3.0.3

    Go

    1. יוצרים ספרייה בשם hello-service:

      mkdir hello-service
cd hello-service

    2. יוצרים פרויקט Go על ידי הפעלה של מודול Go חדש:

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

    אפשר לעדכן את השם הספציפי איך שרוצים: צריך לעדכן את השם אם הקוד מתפרסם במאגר קוד שאפשר לגשת אליו דרך האינטרנט.

    Java

    1. יוצרים פרויקט Maven:

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

    2. מעתיקים את יחסי התלות לרשימת יחסי התלות pom.xml (בין רכיבי <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>

    3. מעתיקים את הגדרת ה-build אל pom.xml (מתחת לרכיבי <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>

  2. יוצרים שירות HTTP לטיפול בבקשות נכנסות:

    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)

    Go 

    
// 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);
        });
  }
}

  3. יוצרים Dockerfile כדי להגדיר את קובץ האימג' של הקונטיינר שמשמש לפריסת השירות:

    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

    Go 

    
# Use the official Go image to create a binary.
# This is based on Debian and sets the GOPATH to /go.
# https://hub.docker.com/_/golang
FROM golang:1.24-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

    בדוגמה הזו נעשה שימוש ב-Jib כדי ליצור תמונות Docker באמצעות כלים נפוצים של Java. ‫Jib מבצע אופטימיזציה של בניית קונטיינרים בלי צורך ב-קובץ Docker או בהתקנה של Docker.

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

שליחת הקוד

תהליך העברת הקוד כולל שלושה שלבים: יצירת קובץ אימג' של קונטיינר באמצעות Cloud Build, העלאת קובץ האימג' של הקונטיינר ל-Container Registry ופריסת קובץ האימג' של הקונטיינר ל-Knative serving.

כדי לשלוח את הקוד:

  1. יוצרים את הקונטיינר ומפרסמים אותו ב-Container Registry:

    Node.js 

    gcloud builds submit --tag gcr.io/PROJECT_ID/hello-service

    כאשר PROJECT_ID הוא מזהה הפרויקט. Google Cloud אפשר לבדוק את מזהה הפרויקט הנוכחי באמצעות gcloud config get-value project.

    בסיום מוצלח, אמורה להופיע הודעת SUCCESS (הצלחה) עם המזהה, זמן היצירה ושם התמונה. התמונה מאוחסנת ב-Container Registry ואפשר לעשות בה שימוש חוזר אם רוצים.

    Python 

    gcloud builds submit --tag gcr.io/PROJECT_ID/hello-service

    כאשר PROJECT_ID הוא מזהה הפרויקט. Google Cloud אפשר לבדוק את מזהה הפרויקט הנוכחי באמצעות gcloud config get-value project.

    בסיום מוצלח, אמורה להופיע הודעת SUCCESS (הצלחה) עם המזהה, זמן היצירה ושם התמונה. התמונה מאוחסנת ב-Container Registry ואפשר לעשות בה שימוש חוזר אם רוצים.

    Go 

    gcloud builds submit --tag gcr.io/PROJECT_ID/hello-service

    כאשר PROJECT_ID הוא מזהה הפרויקט. Google Cloud אפשר לבדוק את מזהה הפרויקט הנוכחי באמצעות gcloud config get-value project.

    בסיום מוצלח, אמורה להופיע הודעת SUCCESS (הצלחה) עם המזהה, זמן היצירה ושם התמונה. התמונה מאוחסנת ב-Container Registry ואפשר לעשות בה שימוש חוזר אם רוצים.

    Java 

    mvn compile jib:build -Dimage=gcr.io/PROJECT_ID/hello-service

    כאשר PROJECT_ID הוא מזהה הפרויקט. Google Cloud אפשר לבדוק את מזהה הפרויקט הנוכחי באמצעות gcloud config get-value project.

    אם הפעולה תצליח, תוצג ההודעה BUILD SUCCESS. התמונה מאוחסנת ב-Container Registry ואפשר להשתמש בה שוב אם רוצים.

  2. מריצים את הפקודה הבאה כדי לפרוס את האפליקציה:

    gcloud run deploy hello-service --image gcr.io/PROJECT_ID/hello-service

    מחליפים את PROJECT_ID במזהה הפרויקט ב- Google Cloud . ‫hello-service הוא גם השם של קובץ אימג' של קונטיינר וגם השם של שירות Knative Serving. שימו לב שקובץ אימג' של קונטיינר נפרס בשירות ובאשכול שהגדרתם קודם בקטע הגדרת gcloud.

    מחכים עד שהפריסה תושלם. התהליך עשוי להימשך כחצי דקה. אם הפעולה בוצעה ללא שגיאות, כתובת ה-URL של השירות תוצג בשורת הפקודה.

אני רוצה לנסות

כדאי לנסות את השירות כדי לוודא שהפריסה בוצעה בהצלחה. הבקשות צריכות להיכשל עם שגיאת HTTP 500 או 503 (שגיאות ששייכות לסיווג 5xx שגיאות בחיבור לשרת). במדריך מוסבר איך לפתור את הבעיה שמופיעה בתגובת השגיאה הזו.

אם האשכול שלכם מוגדר עם דומיין ברירת מחדל שניתן לניתוב, אפשר לדלג על השלבים שלמעלה ולהעתיק את כתובת ה-URL לדפדפן האינטרנט.

אם לא משתמשים באישורי TLS אוטומטיים ובמיפוי דומיינים, לא מקבלים כתובת URL שניתן לנווט אליה בשביל השירות.

במקום זאת, משתמשים בכתובת ה-URL שסופקה ובכתובת ה-IP של שער הכניסה (ingress) של השירות כדי ליצור פקודת curl שיכולה לשלוח בקשות לשירות:

  1. כדי לקבל את כתובת ה-IP החיצונית של מאזן העומסים, מריצים את הפקודה הבאה:

    kubectl get svc istio-ingressgateway -n ASM-INGRESS-NAMESPACE

    מחליפים את ASM-INGRESS-NAMESPACE במרחב השמות שבו נמצאת הכניסה של Cloud Service Mesh. מציינים istio-system אם התקנתם את Cloud Service Mesh באמצעות הגדרת ברירת המחדל שלו.

    הפלט שיתקבל ייראה כך:

    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

    כאשר הערך EXTERNAL-IP הוא כתובת ה-IP החיצונית של מאזן העומסים.

  2. מריצים פקודה curl באמצעות הכתובת GATEWAY_IP הזו בכתובת ה-URL.

     curl -G -H "Host: SERVICE-DOMAIN" https://EXTERNAL-IP/

    מחליפים את SERVICE-DOMAIN בדומיין שמוקצה כברירת מחדל לשירות. כדי למצוא את כתובת ה-URL הזו, לוקחים את כתובת ה-URL שמוגדרת כברירת מחדל ומסירים את הפרוטוקול http://.

  3. ראו את הודעת השגיאה HTTP 500 או HTTP 503.

בדיקת הבעיה

תארו לעצמכם ששגיאת HTTP 5xx שנתקלתם בה למעלה בקטע Trying it out התרחשה כשגיאת זמן ריצה בייצור. במדריך הזה מוסבר על תהליך רשמי לטיפול בבעיה. תהליכי פתרון שגיאות בהפקה משתנים מאוד, אבל במדריך הזה מוצגת רצף מסוים של שלבים כדי להראות את השימוש בכלים ובטכניקות שימושיים.

כדי לחקור את הבעיה הזו, תצטרכו לעבור את השלבים הבאים:

  • כדאי לאסוף פרטים נוספים על השגיאה שדווחה כדי לתמוך בחקירה נוספת ולהגדיר אסטרטגיית צמצום סיכונים.
  • כדי להקטין את ההשפעה על המשתמשים, אפשר להחליט להמשיך בתיקון או לחזור לגרסה תקינה מוכרת.
  • לשחזר את השגיאה כדי לוודא שהפרטים הנכונים נאספו ושהשגיאה היא לא תקלה חד-פעמית
  • מבצעים ניתוח של שורש הבעיה כדי למצוא את הקוד, ההגדרה או התהליך שיצרו את השגיאה הזו.

בתחילת הבדיקה יש לכם כתובת URL, חותמת זמן וההודעה "שגיאת שרת פנימית".

איסוף פרטים נוספים

כדאי לאסוף מידע נוסף על הבעיה כדי להבין מה קרה ולקבוע מה השלבים הבאים.

משתמשים בכלים הזמינים כדי לאסוף פרטים נוספים:

  1. פרטים נוספים זמינים ביומנים.

  2. אפשר להשתמש ב-Cloud Logging כדי לבדוק את רצף הפעולות שהובילו לבעיה, כולל הודעות השגיאה.

חזרה לגרסה תקינה

אם יש לכם גרסה שאתם יודעים שהיא פועלת, אתם יכולים לבטל את השירות שלכם כדי להשתמש בגרסה הזו. לדוגמה, לא תוכלו לבצע חזרה לגרסה קודמת בשירות החדש hello-service שפרסתם במדריך הזה, כי הוא מכיל רק גרסה אחת.

כדי לאתר גרסה ולבטל את השינויים בשירות:

  1. הצגת רשימה של כל הגרסאות של השירות

  2. העברת כל התנועה לגרסה תקינה.

שחזור השגיאה

בעזרת הפרטים שקיבלתם קודם, ודאו שהבעיה מתרחשת באופן עקבי בתנאי בדיקה.

שולחים את אותה בקשת HTTP על ידי ניסיון חוזר, ובודקים אם מדווחים על אותה שגיאה ופרטים. יכול להיות שיעבור זמן מה עד שפרטי השגיאה יופיעו.

שירות הדוגמה במדריך הזה הוא לקריאה בלבד ולא מפעיל תופעות לוואי מסובכות, ולכן אפשר לשחזר שגיאות בסביבת הייצור בלי חשש. עם זאת, במקרים רבים של שירותים אמיתיים, זה לא יקרה: יכול להיות שתצטרכו לשחזר שגיאות בסביבת בדיקה או להגביל את השלב הזה לחקירה מקומית.

שחזור השגיאה יוצר את ההקשר להמשך העבודה. לדוגמה, אם המפתחים לא מצליחים לשחזר את השגיאה, יכול להיות שיידרש מחקר נוסף כדי להוסיף מכשור לשירות.

ביצוע ניתוח שורש הבעיה

ניתוח הגורם המרכזי הוא שלב חשוב בפתרון בעיות יעיל, כדי לוודא שאתם פותרים את הבעיה ולא רק את הסימפטום שלה.

במדריך הזה, שיחזרתם את הבעיה ב-Knative serving, מה שמאשר שהבעיה פעילה כשהשירות מתארח ב-Knative serving. עכשיו משחזרים את הבעיה באופן מקומי כדי לקבוע אם הבעיה מבודדת לקוד או אם היא מופיעה רק באירוח בייצור.

  1. אם לא השתמשתם ב-Docker CLI באופן מקומי עם Container Registry, צריך לאמת אותו באמצעות gcloud:

    gcloud auth configure-docker

    גישות חלופיות מפורטות במאמר שיטות אימות ב-Container Registry.

  2. אם השם של קובץ אימג' של קונטיינר שהשתמשתם בו לאחרונה לא זמין, בתיאור השירות מופיע המידע על קובץ אימג' של קונטיינר שהפריסה שלו בוצעה לאחרונה:

    gcloud run services describe hello-service

    מחפשים את שם קובץ האימג' של קונטיינר בתוך האובייקט spec. אפשר להשתמש בפקודה ממוקדת יותר כדי לאחזר אותו ישירות:

    gcloud run services describe hello-service \
   --format="value(spec.template.spec.containers.image)"

    הפקודה הזו חושפת את השם של קובץ אימג' של קונטיינר, כמו gcr.io/PROJECT_ID/hello-service.

  3. מושכים את קובץ אימג' של קונטיינר מ-Container Registry לסביבה שלכם. השלב הזה עשוי להימשך כמה דקות כי קובץ אימג' של קונטיינר יורד:

    docker pull gcr.io/PROJECT_ID/hello-service

    אפשר לאחזר עדכונים מאוחרים יותר של קובץ אימג' של קונטיינר שנעשה בהם שימוש חוזר בשם הזה באמצעות אותה פקודה. אם מדלגים על השלב הזה, הפקודה docker run שבהמשך שולפת קובץ אימג' של קונטיינר אם הוא לא קיים במחשב המקומי.

  4. מריצים באופן מקומי כדי לוודא שהבעיה לא ייחודית ל-Knative serving:

    PORT=8080 && docker run --rm -e PORT=$PORT -p 9000:$PORT \
   gcr.io/PROJECT_ID/hello-service

    פירוט הרכיבים של הפקודה שלמעלה:

    • משתנה הסביבה PORT משמש את השירות כדי לקבוע את היציאה להאזנה בתוך הקונטיינר.
    • הפקודה run מפעילה את הקונטיינר, ומשתמשת כברירת מחדל בפקודת נקודת הכניסה שמוגדרת בקובץ Docker או בקובץ אימג' של קונטיינר של אב.
    • הדגל --rm מוחק את מופע הקונטיינר ביציאה.
    • הדגל -e מקצה ערך למשתנה סביבה. ‫-e PORT=$PORT is propagating the PORT variable from the local system into the container with the same variable name.
    • הדגל -p מפרסם את מאגר התגים כשירות שזמין ב-localhost ביציאה 9000. בקשות אל localhost:9000 ינותבו אל הקונטיינר ביציאה 8080. המשמעות היא שהפלט מהשירות לגבי מספר היציאה שבשימוש לא יתאים לאופן הגישה לשירות.
    • הארגומנט האחרון gcr.io/PROJECT_ID/hello-service הוא נתיב למאגר שמצביע על הגרסה האחרונה של תמונת המאגר. אם התמונה לא זמינה באופן מקומי, Docker מנסה לאחזר אותה ממאגר מרוחק.

    פותחים את הכתובת http://localhost:9000 בדפדפן. בודקים את הפלט של הטרמינל כדי לראות אם יש הודעות שגיאה שדומות לאלה שמופיעות ב-Google Cloud Observability.

    אם הבעיה לא ניתנת לשחזור באופן מקומי, יכול להיות שהיא ייחודית לסביבת Knative serving. כדאי לעיין במדריך לפתרון בעיות ב-Knative Serving כדי לדעת אילו תחומים ספציפיים צריך לבדוק.

    במקרה כזה, השגיאה משוכפלת באופן מקומי.

עכשיו, אחרי שאישרנו פעמיים שהשגיאה נמשכת ושהיא נגרמת על ידי קוד השירות ולא על ידי פלטפורמת האירוח, הגיע הזמן לבדוק את הקוד מקרוב יותר.

לצורך המדריך הזה, אפשר להניח שהקוד בתוך מאגר התגים והקוד במערכת המקומית זהים.

Node.js

מחפשים את המקור של הודעת השגיאה בקובץ index.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

מחפשים את המקור של הודעת השגיאה בקובץ main.py סביב מספר השורה שמופיע בדוח קריסות שמוצג ברישומים: 
NAME = os.getenv("NAME")

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

Go

מחפשים את המקור של הודעת השגיאה בקובץ main.go סביב מספר השורה שמופיע בדוח קריסות שמוצג ברישומים:

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

מחפשים את המקור של הודעת השגיאה בקובץ App.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";
}

בבדיקה של הקוד הזה, הפעולות הבאות מתבצעות כשמשתנה הסביבה NAME לא מוגדר:

  • שגיאה נרשמת ביומן של Google Cloud Observability
  • נשלחת תגובת שגיאת HTTP

הבעיה נגרמת בגלל משתנה חסר, אבל סיבת השורש ספציפית יותר: שינוי הקוד שמוסיף את התלות הקשיחה במשתנה סביבה לא כולל שינויים קשורים בסקריפטים של הפריסה ובמסמכי הדרישות של זמן הריצה.

תיקון שורש הבעיה

אחרי שאספנו את הקוד וזיהינו את שורש הבעיה האפשרי, אפשר לנקוט צעדים לפתרון הבעיה.

  • בודקים אם השירות פועל באופן מקומי בסביבה NAME שזמינה במקום:

    1. מריצים את הקונטיינר באופן מקומי עם משתנה הסביבה שנוסף:

      PORT=8080 && docker run --rm -e PORT=$PORT -p 9000:$PORT \
 -e NAME="Local World!" \
 gcr.io/PROJECT_ID/hello-service

    2. בדפדפן, עוברים לכתובת http://localhost:9000

    3. הטקסט 'Hello Local World!‎' מופיע בדף

  • משנים את סביבת השירות הפועל של Knative serving כך שתכלול את המשתנה הזה:

    1. מריצים את פקודת העדכון של השירותים עם הפרמטר --update-env-vars כדי להוסיף משתנה סביבה:

      gcloud run services update hello-service \
  --update-env-vars NAME=Override

    2. מחכים כמה שניות בזמן ש-Knative serving יוצר גרסה חדשה על סמך הגרסה הקודמת עם משתנה הסביבה החדש שנוסף.

  • מוודאים שהשירות תוקן:

    1. בדפדפן, עוברים לכתובת ה-URL של שירות Knative.
    2. הטקסט 'Hello Override!‎' יופיע בדף.
    3. מוודאים שלא מופיעות הודעות או שגיאות לא צפויות ב-Cloud Logging.

שיפור מהירות פתרון הבעיות בעתיד

בדוגמה הזו של בעיה בסביבת הייצור, השגיאה הייתה קשורה להגדרות התפעוליות. יש שינויים בקוד שיצמצמו את ההשפעה של הבעיה הזו בעתיד.

  • שיפור יומן השגיאות כך שיכלול פרטים ספציפיים יותר.
  • במקום להחזיר שגיאה, השירות צריך לחזור לברירת מחדל בטוחה. אם שימוש בערך ברירת מחדל מייצג שינוי בפונקציונליות הרגילה, כדאי להשתמש בהודעת אזהרה למטרות מעקב.

נראה איך מסירים את משתנה הסביבה NAME כתלות מחייבת.

  1. מסירים את הקוד הקיים לטיפול ב-NAME:

    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.")

    Go 

    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";
}

  2. מוסיפים קוד חדש שמגדיר ערך ברירת מחדל:

    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))

    Go 

    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));
}

  3. כדי לבדוק באופן מקומי, צריך לבנות מחדש את הקונטיינר ולהפעיל אותו באמצעות תרחישי ההגדרות המושפעות:

    Node.js 

    docker build --tag gcr.io/PROJECT_ID/hello-service .

    Python 

    docker build --tag gcr.io/PROJECT_ID/hello-service .

    Go 

    docker build --tag gcr.io/PROJECT_ID/hello-service .

    Java 

    mvn compile jib:build

    מוודאים שמשתנה הסביבה NAME עדיין פועל:

    PORT=8080 && docker run --rm -e $PORT -p 9000:$PORT \
 -e NAME="Robust World" \
 gcr.io/PROJECT_ID/hello-service

    מוודאים שהשירות פועל ללא המשתנה NAME:

    PORT=8080 && docker run --rm -e $PORT -p 9000:$PORT \
 gcr.io/PROJECT_ID/hello-service

    אם השירות לא מחזיר תוצאה, צריך לוודא שהסרת הקוד בשלב הראשון לא הסירה שורות נוספות, כמו אלה שמשמשות לכתיבת התשובה.

  4. כדי להטמיע את הקוד, חוזרים לקטע הטמעת הקוד.

    כל פריסה לשירות יוצרת גרסה חדשה ומתחילה להציג תנועה באופן אוטומטי כשהיא מוכנה.

    כדי למחוק את משתני הסביבה שהוגדרו קודם:

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

מוסיפים את הפונקציונליות החדשה של ערך ברירת המחדל לכיסוי הבדיקות האוטומטיות של השירות.

חיפוש בעיות אחרות ביומנים

יכול להיות שיופיעו בעיות אחרות בכלי Log Viewer עבור השירות הזה. לדוגמה, קריאה למערכת שלא נתמכת תופיע ביומנים כ-"Container Sandbox Limitation" (מגבלה של ארגז חול של קונטיינר).

לדוגמה, לפעמים השירותים של Node.js יוצרים את הודעת היומן הבאה:

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.

במקרה הזה, חוסר התמיכה לא משפיע על שירות הדוגמה hello-service.

הסרת המשאבים

כדי להימנע מחיובים, אפשר למחוק את המשאבים שנוצרו במסגרת המדריך הזה.

מחיקת משאבי הדרכה

  1. מוחקים את שירות Knative serving שפרסתם במדריך הזה:

    gcloud run services delete SERVICE-NAME

    כאשר SERVICE-NAME הוא שם השירות שבחרתם.

    אפשר גם למחוק שירותי Knative serving מהמסוף:Google Cloud

    מעבר אל Knative serving

  2. מסירים את הגדרות ברירת המחדל של gcloud שהוספתם במהלך ההגדרה של המדריך:

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

  3. מסירים את הגדרות הפרויקט:

     gcloud config unset project

  4. מחיקה של משאבים אחרים Google Cloud שנוצרו במדריך הזה:

המאמרים הבאים