הגדרת מעקב ב-Cloud Trace

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

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

מתי להוסיף לאפליקציה כלים למדידת ביצועים

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

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

איך להוסיף כלים לאפליקציות

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

  • מומלץ: להשתמש ב-OpenTelemetry, להגדיר את האפליקציה עם מייצא OTLP ששולח נתוני מעקב לאספן, ולהגדיר את האספן כך שישלח נתוני מעקב לפרויקט ב- Google Cloud באמצעות Telemetry (OTLP) API. איך בוחרים גישה למדידת ביצועים

  • משתמשים ב-OpenTelemetry ומגדירים את האפליקציה עם מייצא OTLP ששולח את נתוני המעקב לפרויקט ב- Google Cloud באמצעות Telemetry API.

  • אם אתם כותבים אפליקציות שפועלות ב-Compute Engine, אתם יכולים להשתמש בסוכן התפעול ובמקלט של פרוטוקול OpenTelemetry‏ (OTLP) כדי לאסוף נתוני מעקב ומדדים מהאפליקציה. גם סוכן תפעול יכול לאסוף יומנים, אבל לא באמצעות OTLP. למידע נוסף, קראו את המאמרים שימוש ב-Ops Agent וב-OTLP וסקירה כללית על Ops Agent.

  • להפעיל ישירות את Telemetry API או את Cloud Trace API.

  • באפליקציות Spring Boot, מגדירים אותן כך שיעבירו את נתוני המעקב שהן אוספות אל Cloud Trace. למידע נוסף על התהליך, קראו את המאמר Spring Cloud for Google Cloud: Cloud Trace.

  • משתמשים בספריות הלקוח של Cloud Trace או ב-Cloud Trace exporter ל-OpenTelemetry.

דוגמאות לאינסטרומנטציה

הדוגמאות למדידת ביצועים שאנחנו מספקים משתמשות ב-OpenTelemetry:

יצירת טווחים בהתאמה אישית

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

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

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

אילוץ דגימת מעקב

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

  • האפליקציות שלכם: אתם קובעים איך לוגיקת המדידה תתייחס לדגל sampled. לדוגמה, כשמשתמשים ב-OpenTelemetry, אפשר להשתמש בדוגם ParentBased כדי לוודא שדגל הדגימה של ההורה נשמר.

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

התאמה בין מדדים ועקבות באמצעות דוגמאות

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

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

הגדרת הפרויקט והפלטפורמה

בקטע הזה מוסבר אילו ממשקי API ותפקידים של ניהול זהויות והרשאות גישה (IAM) נדרשים, ואיך להגדיר את פרטי הכניסה לאימות בפלטפורמה.

הפעלת ממשקי ה-API

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

מפעילים את Telemetry API ואת Cloud Trace API, אם הם עדיין לא מופעלים.

התפקידים שנדרשים כדי להפעיל ממשקי API

כדי להפעיל ממשקי API, צריך את ההרשאה serviceusage.services.enable. אם יצרתם את הפרויקט, סביר להניח שכבר יש לכם את ההרשאה הזו דרך התפקיד "בעלים" (roles/owner). אחרת, תוכלו לקבל את ההרשאה הזו דרך התפקיד "אדמין בממשק 'שימוש בשירות'" (roles/serviceusage.serviceUsageAdmin). איך מקצים תפקידים

הפעלת ממשקי ה-API

מתן תפקידים ב-IAM

תפקידי ה-IAM הנדרשים תלויים בשאלה אם אתם צופים בנתוני המעקב במסוף Google Cloud או כותבים נתוני מעקב בפרויקט:

  • כדי לקבל את ההרשאות שנדרשות לצפייה בנתוני המעקב באמצעות מסוף Google Cloud , צריך לבקש מהאדמין להקצות לכם את התפקיד משתמש ב-Cloud Trace ‏ (roles/cloudtrace.user) ב-IAM בפרויקט.

  • כדי לקבל את ההרשאות שנדרשות לכתיבת נתוני מעקב באמצעות Cloud Trace API, בקשו מהאדמין להקצות לכם את התפקיד סוכן Cloud Trace (roles/cloudtrace.agent) ב-IAM בפרויקט.

  • כדי לקבל את ההרשאות שנדרשות לכתיבת נתוני מעקב באמצעות Telemetry API, צריך לבקש מהאדמין להקצות לכם את התפקיד Cloud Telemetry Writer (roles/telemetry.writer) ב-IAM בפרויקט.

אמת

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

ריצה ב- Google Cloud

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

מוודאים שבפלטפורמה של Google Cloud מופעל היקף הגישה ל-Cloud Trace API. בהגדרות הבאות, הגדרות ברירת המחדל של היקף הגישה כוללות את היקף הגישה ל-Cloud Trace API:

אם אתם משתמשים בהיקפי גישה בהתאמה אישית, אתם צריכים לוודא שהיקף הגישה של Cloud Trace API מופעל. לדוגמה, אם אתם משתמשים ב-Google Cloud CLI כדי ליצור אשכול GKE ומציינים את הדגל --scopes, ודאו שההיקף כולל את trace.append. הפקודה הבאה מדגימה את הגדרת הדגל --scopes:

gcloud container clusters create example-cluster-name --scopes=https://www.googleapis.com/auth/trace.append

הפעלה מקומית ובמקומות אחרים

אם האפליקציה פועלת מחוץ ל- Google Cloud, צריך לספק לספריית הלקוח פרטי כניסה לאימות. צריך להקצות לחשבון השירות את התפקיד "סוכן Cloud Trace" ‏(roles/cloudtrace.agent). מידע נוסף על תפקידים זמין במאמר בקרת גישה באמצעות IAM.

ספריות הלקוח שלGoogle Cloud משתמשות ב-Application Default Credentials ‏ (ADC) כדי למצוא את פרטי הכניסה של האפליקציה. אפשר לספק את פרטי הכניסה האלה באחת משלוש דרכים:

  • מריצים את gcloud auth application-default login

  • ממקמים את קובץ המפתח של חשבון השירות בנתיב ברירת המחדל של מערכת ההפעלה. ברשימה הבאה מפורטים נתיבי ברירת המחדל ל-Windows ול-Linux:

    • ב-Windows:‏ %APPDATA%/gcloud/application_default_credentials.json‎

    • ‫Linux: ‏ $HOME/.config/gcloud/application_default_credentials.json

  • מגדירים את משתנה הסביבה GOOGLE_APPLICATION_CREDENTIALS לנתיב של חשבון השירות:

    ‫Linux/macOS

        export GOOGLE_APPLICATION_CREDENTIALS=path-to-your-service-accounts-private-key

    Windows

        set GOOGLE_APPLICATION_CREDENTIALS=path-to-your-service-accounts-private-key

    PowerShell:

        $env:GOOGLE_APPLICATION_CREDENTIALS="path-to-your-service-accounts-private-key"

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