Google uses AI technology to translate content into your preferred language. AI translations can contain errors.

יצירת פרופיל של אפליקציות Node.js

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

סוגי פרופילים ל-Node.js:

Heap
זמן בפועל

גרסאות שפה נתמכות של Node.js:

‫Node.js מגרסה 14 ואילך
מדיניות ההפצה של Node.js מפורטת בלוח הזמנים של ההפצה.

גרסאות נתמכות של סוכן הפרופילים:

הגרסה העדכנית ביותר של הסוכן נתמכת. באופן כללי, אין תמיכה בגרסאות בנות יותר משנה. מומלץ להשתמש בגרסה העדכנית ביותר של הסוכן.

מערכות הפעלה נתמכות:

Linux. יש תמיכה בפרופילים של אפליקציות Node.js עבור ליבות Linux שספריית ה-C הרגילה שלהן מיושמת באמצעות glibc או באמצעות musl. למידע על הגדרות שספציפיות לליבות של Linux Alpine, אפשר לעיין במאמר הפעלה ב-Linux Alpine.

סביבות נתמכות:

Compute Engine
Google Kubernetes Engine (GKE)
סביבה גמישה של App Engine
סביבה רגילה של App Engine
מחוץ ל- Google Cloud (מידע על דרישות ההגדרה הנוספות זמין במאמר יצירת פרופילים של אפליקציות שפועלות מחוץ ל- Google Cloud).

הפעלת Profiler API

לפני שמשתמשים בסוכן הפרופילים, צריך לוודא שממשק ה-Profiler API הבסיסי מופעל. אתם יכולים לבדוק את הסטטוס של ה-API ולהפעיל אותו אם צריך באמצעות Google Cloud CLI או Google Cloud המסוף:

‫CLI של gcloud

אם עדיין לא התקנתם את Google Cloud CLI בתחנת העבודה, תוכלו לעיין במסמכי Google Cloud CLI.

מריצים את הפקודה הבאה:

gcloud services enable cloudprofiler.googleapis.com

מידע נוסף זמין במאמר gcloud services.

מסוף Google Cloud

מפעילים את Cloud Profiler API.
תפקידים שנדרשים להפעלת ממשקי API
כדי להפעיל ממשקי API, צריך את תפקיד ה-IAM 'אדמין של Service Usage' (roles/serviceusage.serviceUsageAdmin), שכולל את ההרשאה serviceusage.services.enable. איך מקצים תפקידים
להפעלת ה-API
אם מוצג הכיתוב API enabled, סימן שממשק ה-API כבר מופעל. אם לא, לוחצים על הכפתור הפעלה.

הקצאת תפקיד IAM לחשבון שירות

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

אם אתם מבצעים אחת מהפעולות הבאות, אתם צריכים להקצות לחשבון השירות את תפקיד ה-IAM‏ Cloud Profiler Agent (roles/cloudprofiler.agent):

אתם משתמשים בחשבון השירות שמוגדר כברירת מחדל, אבל שיניתם את הרשאות התפקיד שלו.
אתם משתמשים בחשבון שירות שנוצר על ידי משתמש.
אם אתם משתמשים ב-Workload Identity, צריך להקצות את התפקיד Cloud Profiler Agent לחשבון השירות של Kubernetes.

אפשר להקצות תפקיד IAM לחשבון שירות באמצעות מסוףGoogle Cloud או Google Cloud CLI. לדוגמה, אפשר להשתמש בפקודה gcloud projects add-iam-policy-binding:

gcloud projects add-iam-policy-binding GCP_PROJECT_ID \
    --member serviceAccount:MY_SVC_ACCT_ID@GCP_PROJECT_ID.iam.gserviceaccount.com \
    --role roles/cloudprofiler.agent

לפני שמשתמשים בפקודה הקודמת, מחליפים את הערכים הבאים:

‫GCP_PROJECT_ID: מזהה הפרויקט.
‫MY_SVC_ACCT_ID: השם של חשבון השירות.

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

שימוש ב-Cloud Profiler

בכל הסביבות הנתמכות, כדי להשתמש ב-Profiler צריך להתקין את החבילה @google-cloud/profiler, להוסיף הצהרה require לאפליקציה ואז לפרוס את האפליקציה בדרך הרגילה.

לפני שמתקינים את `@google-cloud/profiler`

החבילה @google-cloud/profiler תלויה במודול מובנה. קבצים בינאריים מוכנים מראש למודול המובנה הזה זמינים ל-Linux ול-Alpine Linux ל-Node 14 ו-16. לא נדרשות תלותיות נוספות. ‫@google-cloud/profiler משתמש ב-node-pre-gyp כדי לקבוע איזה קובץ בינארי מוכן מראש להתקין.

כשמשתמשים ב-@google-cloud/profiler בסביבות אחרות שאין בהן קבצים בינאריים מוכנים מראש, נעשה שימוש במודול node-gyp כדי ליצור קבצים בינאריים. מידע על יחסי התלות שנדרשים כדי ליצור קבצים בינאריים באמצעות node-gyp זמין במסמכי ההתקנה של node-gyp.

התקנה

כדי להתקין את הגרסה האחרונה של Cloud Profiler:

    npm install @google-cloud/profiler

אם אתם משתמשים גם בסוכן Trace, כשאתם משנים את האפליקציה, אתם צריכים לייבא את חבילת Profiler אחרי חבילת הסוכן Trace ‏ (@google-cloud/trace-agent).

Compute Engine

ב-Compute Engine, מבצעים את הפעולות הבאות:

מתקינים את הגרסה העדכנית של Cloud Profiler:
```
npm install @google-cloud/profiler
```
משנים את הקוד של האפליקציה require כדי ליצור אובייקט serviceContext שמוקצה לו service השם של השירות שיוצר את הפרופיל. אופציונלי: אפשר להקצות ל-version את גרסת השירות שמוגדרת בפרופיל. מידע נוסף על אפשרויות ההגדרה האלה זמין במאמר ארגומנטים של שם השירות והגרסה:
```
require('@google-cloud/profiler').start({
  serviceContext: {
    service: 'your-service',
    version: '1.0.0',
  },
});
```

GKE

ב-GKE, מבצעים את הפעולות הבאות:

משנים את קובץ ה-Dockerfile כדי להתקין את חבילת Profiler:
```
FROM node:10
...
RUN npm install @google-cloud/profiler
```
משנים את הקוד של האפליקציה require כדי ליצור אובייקט serviceContext שמוקצה לו service השם של השירות שיוצר את הפרופיל. אופציונלי: אפשר להקצות ל-version את גרסת השירות שמוגדרת בפרופיל. מידע נוסף על אפשרויות ההגדרה האלה זמין במאמר ארגומנטים של שם השירות והגרסה:
```
require('@google-cloud/profiler').start({
  serviceContext: {
    service: 'your-service',
    version: '1.0.0',
  },
});
```

App Engine

בסביבה הגמישה של App Engine ובסביבה הרגילה של App Engine, הקוד require דומה לקוד הבא:

require('@google-cloud/profiler').start();

ב-App Engine, הפרמטרים service ו-version נגזרים מהסביבה, כך שלא צריך לציין אותם. לכן, אין צורך ליצור אובייקט serviceContext.

מנתח נתונים

אחרי ש-Profiler אוסף נתונים, אפשר להציג ולנתח את הנתונים האלה באמצעות הממשק של Profiler.

נכנסים לדף Profiler במסוף Google Cloud :

עוברים אל Profiler

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

ארגומנטים של שם השירות והגרסה

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

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

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

אם משתמשים בשמות שירות שונים עבור העותקים, השירות ינותח בתדירות גבוהה מהנדרש, עם תקורה גבוהה יותר בהתאם.

כשבוחרים שם שירות:

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

^[a-z0-9]([-a-z0-9_.]{0,253}[a-z0-9])?$

הנחיה טובה היא להשתמש במחרוזת סטטית כמו imageproc-service בתור שם השירות.

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

הערך של הארגומנט service-version הוא מחרוזת חופשית, אבל הערכים של הארגומנט הזה בדרך כלל נראים כמו מספרי גרסאות, למשל, 1.0.0 או 2.1.2.

רישום ביומן של סוכנים

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

‫0: משבית את כל הרישום ביומן של הסוכן.
‫1: מפעיל רישום ביומן של שגיאות.
‫2: מפעיל רישום של אזהרות ביומן (ברירת מחדל).
‫3: מפעיל רישום ביומן של מידע.
‫4: הפעלת רישום ניפוי הבאגים ביומן.

מגדירים את הערך logLevel באותו אובייקט שמספק את הקשר של השירות:

require('@google-cloud/profiler').start({
    serviceContext: { ... }
    logLevel:       3
});

הפעלה עם Linux Alpine

סוכן פרופילים של Node.js ל-Linux Alpine נתמך רק בהגדרות של Google Kubernetes Engine.

שגיאת בנייה

אם מריצים את הפקודה npm install וה-build נכשל עם השגיאה הבאה, סימן שבקובץ ה-Dockerfile חסרים כמה יחסי תלות של build:

ERR! stack Error: not found: make

כדי לפתור את הבעיה, מוסיפים את ההצהרה הבאה לשלב הבנייה של Dockerfile:

RUN apk add python3 g++ make

שגיאת אימות

אם אתם משתמשים בתמונות Docker שפועלות עם Linux Alpine (כמו golang:alpine או רק alpine), יכול להיות שתופיע שגיאת האימות הבאה:

connection error: desc = "transport: authentication handshake failed: x509: failed to load system roots and no roots provided"

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

השגיאה מציינת שבתמונות Docker עם Linux Alpine לא מותקנים אישורי ה-SSL של הבסיס כברירת מחדל. האישורים האלה נחוצים כדי שהסוכן ליצירת פרופילים יוכל לתקשר עם ה-API של הכלי ליצירת פרופילים. כדי לפתור את השגיאה, מוסיפים את הפקודה apk הבאה לקובץ Dockerfile:

FROM alpine
...
RUN apk add --no-cache ca-certificates

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

בעיות מוכרות

הסוכן ליצירת פרופילים עבור Node.js מפריע ליציאה הרגילה מהתוכנית. יכול להיות שיחלפו עד שעה עד שהתוכנית תצא אחרי שכל המשימות בתוכנית יסתיימו. כשמבצעים SIGINT, למשל באמצעות Ctrl-C, התהליך מסתיים בצורה תקינה.