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

כדי שקוד האפליקציה לא יהיה תלוי בספק בזמן איסוף ושליחת נתוני הטלמטריה אל Google Cloud, אתם יכולים להשתמש בדוגמאות לאינסטרומנטציה מבוססת-אוסף של OpenTelemetry ב-Go, ב-Java, ב-Node.js וב-Python.

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

איך פועלות הדגימות

הדוגמאות ל-Go, ל-Java, ל-Node.js ול-Python משתמשות בפרוטוקול OpenTelemetry כדי לאסוף נתוני מעקב ומדדים. הדוגמאות מגדירות מסגרת רישום ביומן לכתיבת יומנים מובְנים, ומגדירות את ה-collector של OpenTelemetry לקריאה מהסטרים stdout של האפליקציה. המלצות לגבי מסגרות מפורטות במאמר בחירת גישה למדידה.

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

אתם יכולים להריץ את הדוגמאות ב-Cloud Shell, במשאבי Google Cloudאו בסביבת פיתוח מקומית.

ירידה לפרטים

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

הדוגמאות מראות איך:

1. מגדירים את OpenTelemetry לאיסוף מדדים ומעקבים באמצעות OpenTelemetry collector.

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

2. להגדיר מסגרת רישום ביומן כדי לכתוב יומנים מובְנים.

   מומלץ שהאפליקציות שלכם יכתבו יומנים מובְנים, שבהם המטען הייעודי של היומן מוגדר כאובייקט JSON. ביומנים האלה, אתם יכולים ליצור שאילתות שמחפשות נתיבי JSON ספציפיים, ולהוסיף לאינדקס שדות ספציפיים במטען הייעודי (payload) של היומן.

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

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

3. מגדירים את קובצי Docker. כל הדוגמאות מכילות את קובצי ה-YAML הבאים:

   • ‫docker-compose.yaml: מגדיר את השירותים לאפליקציה, את OpenTelemetry collector ואת מחולל העומס. לדוגמה, השירות של OpenTelemetry Collector,‏ otelcol, מציין קובץ אימג', אמצעי אחסון ומשתני סביבה. נקודת הקצה של OpenTelemetry Collector מוגדרת על ידי משתנה הסביבה OTEL_EXPORTER_OTLP_ENDPOINT, שמצוין בשירות app.

   • ‫otel-collector-config.yaml: מגדירה את ה-collector של OpenTelemetry:

     • בדוגמאות נעשה שימוש במקלט otlp לנתוני מדדים ומעקב, ובמקלט filelog לנתוני יומנים.

     • בדוגמאות נעשה שימוש ב-exporter של otlphttp לנתוני יומנים, מדדים ומעקב.

       הייצוא של otlphttp שולח נתונים לפרויקט באמצעות Telemetry API, שתומך ב-OTLP.

   • ‫docker-compose.creds.yaml: הקובץ הזה טוען באופן אופציונלי קובץ של פרטי כניסה של Google Cloudבקונטיינר otelcol. אתם צריכים את הקובץ הזה כשאתם מריצים דוגמה במכונה מקומית שבה Application Default Credentials (‏ADC) זמינים רק כקובץ.

ההרשאות הנדרשות

• כדי לקבל את ההרשאות שדרושות בשביל שאפליקציות לדוגמה יכתבו נתוני יומנים, מדדים ומעקב, אתם צריכים לבקש מהאדמין לתת לכם את התפקידים הבאים ב-IAM:

  • כתיבה ביומן (roles/logging.logWriter) בפרויקט
  • כתיבת מדדי מעקב (roles/monitoring.metricWriter) בפרויקט
  • כתיבת נתוני מעקב של Cloud Telemetry (roles/telemetry.tracesWriter) בפרויקט
  • Service Usage Consumer (roles/serviceusage.serviceUsageConsumer) בפרויקט המכסה

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

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

• כדי לקבל את ההרשאות שדרושות לצפייה בנתוני היומנים, המדדים והמעקב, בקשו מהאדמין להקצות לכם את תפקידי ה-IAM הבאים בפרויקט:

  • צפייה ביומנים (roles/logging.viewer)
  • צפייה במעקב (roles/monitoring.viewer)
  • Cloud Trace User (roles/cloudtrace.user)

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

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

ממשקי ה-API הנדרשים

מפעילים את ממשקי ה-API של Cloud Logging,‏ Cloud Monitoring,‏ Cloud Trace ו-Telemetry, אם הם עדיין לא מופעלים:

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

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

gcloud services enable logging.googleapis.com monitoring.googleapis.com cloudtrace.googleapis.com telemetry.googleapis.com

גישות חלופיות למדידה

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

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

  אם הסביבה שלכם תומכת בשימוש ב-OpenTelemetry Collector, מומלץ להשתמש בו כדי לייצא את נתוני הטלמטריה. אם אתם לא יכולים להשתמש ב-collector, אתם צריכים להשתמש ב-exporter בתהליך ששולח את הנתונים ישירות לפרויקט ב- Google Cloud .

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

• שימוש בסוכן תפעול ובפרוטוקול OpenTelemetry‏ (OTLP): איך מגדירים את סוכן תפעול ומקלט OTLP כדי לאסוף מדדים ועקבות מאפליקציה.

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

למידע נוסף על אוספים, ראו OpenTelemetry Collector שנוצר על ידי Google.

דוגמאות לשימוש בייצוא מבוסס-אוסף.

• דוגמה ב-Go
• דוגמה ב-Java
• דוגמה ל-Node.js
• דוגמה ב-Python