‫Google משתמשת בטכנולוגיית AI כדי לתרגם תוכן לשפה המועדפת עליך. בתרגומים כאלו עשויות להיות שגיאות.

פריסת Managed OpenTelemetry ל-GKE

טייס אוטומטי רגילה

במאמר הזה מוסבר איך להגדיר את Managed OpenTelemetry ל-GKE כדי לשלוח מעקבים, מדדים ויומנים של OpenTelemetry Protocol (OTLP) ל-Google Cloud Observability מאפליקציות שפועלות ב-GKE.

מידע נוסף על אופן הפעולה של Managed OpenTelemetry for GKE זמין במאמר Managed OpenTelemetry for GKE.

אתם יכולים להשתמש ב-Managed OpenTelemetry ל-GKE כדי:

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

אם אתם צריכים סינון ואמצעי בקרה ברמת ה-collector, השתמשו ב-Google-Built OpenTelemetry Collector במקום במוצר המנוהל הזה.

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

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

התקינו את ה-CLI של Google Cloud.

הערה: אם התקנתם את ה-CLI של gcloud, השתמשו בפקודה gcloud components update כדי לבדוק אם הגרסה העדכנית מותקנת.

אם אתם משתמשים בספק זהויות חיצוני (IdP), קודם אתם צריכים להיכנס ל-CLI של gcloud באמצעות המאגר המאוחד לניהול זהויות.

כדי לאתחל את ה-CLI של gcloud, הריצו את הפקודה הבאה:

gcloud init

יוצרים או בוחרים Google Cloud פרויקט.

התפקידים שנדרשים כדי לבחור או ליצור פרויקט

Select a project: כדי לבחור פרויקט לא צריך תפקיד IAM ספציפי – אפשר לבחור כל פרויקט שקיבלתם בו תפקיד.
יצירת פרויקט: כדי ליצור פרויקט, צריך את התפקיד Project Creator (roles/resourcemanager.projectCreator), שכולל את ההרשאה resourcemanager.projects.create. איך מקצים תפקידים

יוצרים Google Cloud פרויקט:
```
gcloud projects create PROJECT_ID
```
מחליפים את PROJECT_ID בשם של פרויקט Google Cloud שיוצרים.
בוחרים את הפרויקט שיצרתם: Google Cloud
```
gcloud config set project PROJECT_ID
```
מחליפים את PROJECT_ID בשם הפרויקט ב- Google Cloud .

מוודאים שיש את ההרשאות הנדרשות כדי להשלים את ההדרכה.

מוודאים שהחיוב מופעל בפרויקט Google Cloud .

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

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

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

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

התקינו את ה-CLI של Google Cloud.

הערה: אם התקנתם את ה-CLI של gcloud, השתמשו בפקודה gcloud components update כדי לבדוק אם הגרסה העדכנית מותקנת.

אם אתם משתמשים בספק זהויות חיצוני (IdP), קודם אתם צריכים להיכנס ל-CLI של gcloud באמצעות המאגר המאוחד לניהול זהויות.

כדי לאתחל את ה-CLI של gcloud, הריצו את הפקודה הבאה:

gcloud init

יוצרים או בוחרים Google Cloud פרויקט.

התפקידים שנדרשים כדי לבחור או ליצור פרויקט

Select a project: כדי לבחור פרויקט לא צריך תפקיד IAM ספציפי – אפשר לבחור כל פרויקט שקיבלתם בו תפקיד.
יצירת פרויקט: כדי ליצור פרויקט, צריך את התפקיד Project Creator (roles/resourcemanager.projectCreator), שכולל את ההרשאה resourcemanager.projects.create. איך מקצים תפקידים

יוצרים Google Cloud פרויקט:
```
gcloud projects create PROJECT_ID
```
מחליפים את PROJECT_ID בשם של פרויקט Google Cloud שיוצרים.
בוחרים את הפרויקט שיצרתם: Google Cloud
```
gcloud config set project PROJECT_ID
```
מחליפים את PROJECT_ID בשם הפרויקט ב- Google Cloud .

מוודאים שיש את ההרשאות הנדרשות כדי להשלים את ההדרכה.

מוודאים שהחיוב מופעל בפרויקט Google Cloud .

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

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

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

דרישות

כדי להשתמש ב-Managed OpenTelemetry ל-GKE, אתם צריכים לעמוד בדרישות הבאות:

ב-cluster צריכה להיות גרסה ‎1.34.1-gke.2178000 ואילך של GKE.
‫ה-CLI של gcloud מופעל בגרסה 576.0.0 ואילך.
אם אתם משתמשים ב-Terraform כדי להקצות את תשתית GKE, אתם צריכים להשתמש ב-terraform-provider-google-beta provider בגרסה v7.17.0 ואילך.

התפקידים הנדרשים

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

אדמין של אשכול Kubernetes Engine (roles/container.clusterAdmin)
צפייה ב-Monitoring (roles/monitoring.viewer)
כלי הצפייה ביומנים (roles/logging.viewer)
משתמש Cloud Trace (roles/cloudtrace.user)

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

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

עלויות

במאמר בנושא חיוב אפשר לקרוא פרטים על העלויות שקשורות לשימוש ב-Managed OpenTelemetry for GKE.

הפעלת OpenTelemetry מנוהל ל-GKE באשכול

כדי להגדיר את Managed OpenTelemetry ל-GKE, צריך לבצע את הפעולות הבאות:

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

כשמפעילים את Managed OpenTelemetry ב-GKE, האובייקטים הבאים נפרסים באשכול:

פריסה של GKE Managed OpenTelemetry Collector שפרוסה במרחב השמות gke-managed-otel. נקודת הקצה (endpoint) ב-HTTP של OpenTelemetry collector שמנוהל באשכול, ליומנים, למדדים ולמעקבים, היא: http://opentelemetry-collector.gke-managed-otel.svc.cluster.local:4318.
הגדרה של משאב בהתאמה אישית, instrumentations.telemetry.googleapis.com, שבה אפשר להשתמש כדי להגדיר באופן אוטומטי את עומסי העבודה.

לפרטים נוספים על משאבים בהתאמה אישית, אפשר לעיין במאמר משאבים בהתאמה אישית במסמכי Kubernetes.

הפעלה באשכול חדש

כדי להפעיל את Managed OpenTelemetry for GKE באשכול חדש, פועלים לפי השלבים הבאים:

gcloud

באשכול Autopilot, משתמשים בפקודה הבאה:

gcloud container clusters create-auto CLUSTER_NAME \
  --project=PROJECT_ID \
  --managed-otel-scope=COLLECTION_AND_INSTRUMENTATION_COMPONENTS \
  --location=LOCATION \
  --cluster-version=VERSION

מחליפים את מה שכתוב בשדות הבאים:

‫CLUSTER_NAME: שם האשכול.
‫PROJECT_ID: מזהה הפרויקט ב- Google Cloud .
‫LOCATION: האזור או התחום.
‫VERSION: הגרסה, שצריכה להיות 1.34.1-gke.2178000 ומעלה.

עבור אשכול Standard, השתמש בפקודה הבאה:

gcloud container clusters create CLUSTER_NAME \
  --project=PROJECT_ID \
  --managed-otel-scope=COLLECTION_AND_INSTRUMENTATION_COMPONENTS \
  --location=LOCATION \
  --cluster-version=VERSION

מחליפים את מה שכתוב בשדות הבאים:

‫CLUSTER_NAME: שם האשכול.
‫PROJECT_ID: מזהה הפרויקט ב- Google Cloud .
‫LOCATION: האזור או התחום.
‫VERSION: הגרסה, שצריכה להיות 1.34.1-gke.2178000 ואילך.

המסוף

כדי להגדיר את התכונה באשכול Autopilot:
1. נכנסים לדף Create an Autopilot cluster במסוף Google Cloud .
  כניסה לדף Create an Autopilot cluster
2. בחלונית הניווט, לוחצים על הגדרות מתקדמות.
3. בקטע Operations (פעולות), בוחרים באפשרות Enable managed OpenTelemetry (הפעלת OpenTelemetry מנוהל).
4. לוחצים על יצירה.
במקרה של אשכול רגיל:
1. נכנסים לדף Create a Kubernetes cluster במסוף Google Cloud .
  יצירת אשכול Kubernetes
2. בחלונית הניווט, לוחצים על הגדרות מתקדמות.
3. בשורה Managed OpenTelemetry, לוחצים על Edit configuration.
4. בוחרים באפשרות Enable managed OpenTelemetry.
5. לוחצים על Save.
6. לוחצים על יצירה.

Terraform

כדי להפעיל את Managed OpenTelemetry for GKE באשכול חדש באמצעות Terraform, אפשר להיעזר בדוגמה הבאה:

terraform {
  required_providers {
    google-beta = {
      source  = "hashicorp/google-beta"
      version = ">= 7.17.0"
    }
  }
}

resource "google_container_cluster" "default" {
  name     = "gke-standard-regional-with-managed-otel"
  provider = google-beta
  location = "us-west1"

  initial_node_count = 1
  release_channel {
    channel = "RAPID" # The default rapid version already has the feature available.
  }

  managed_opentelemetry_config {
    scope = "COLLECTION_AND_INSTRUMENTATION_COMPONENTS"
  }
}

מידע נוסף על שימוש ב-Terraform זמין במאמר תמיכה ב-Terraform ב-GKE.

הפעלה באשכול קיים

כדי להפעיל את Managed OpenTelemetry for GKE באשכול קיים, פועלים לפי השלבים הבאים:

gcloud

מוודאים שגרסת האשכול היא 1.34.1-gke.2178000 ואילך. לפרטים על שדרוג אשכול קיים, אפשר לעיין במאמרים בנושא שדרוגים של אשכולות רגילים ושדרוגים של אשכולות במצב Autopilot.
מפעילים את Managed OpenTelemetry ל-GKE באמצעות הפקודה הבאה:
```
gcloud container clusters update CLUSTER_NAME \
  --project=PROJECT_ID \
  --managed-otel-scope=COLLECTION_AND_INSTRUMENTATION_COMPONENTS \
  --location=LOCATION
```
מחליפים את מה שכתוב בשדות הבאים:
- ‫CLUSTER_NAME: שם האשכול.
- ‫PROJECT_ID: מזהה הפרויקט ב- Google Cloud .
- ‫LOCATION: האזור או התחום.

המסוף

מוודאים שגרסת האשכול היא 1.34.1-gke.2178000 ואילך. לפרטים על שדרוג אשכול קיים, אפשר לעיין במאמרים בנושא שדרוגים של אשכולות רגילים ושדרוגים של אשכולות במצב Autopilot.
נכנסים לדף Kubernetes clusters במסוף Google Cloud :

מעבר אל Kubernetes clusters
לוחצים על שם האשכול.
ברשימה Features, מאתרים את האפשרות Managed OpenTelemetry. אם האפשרות מופיעה כהשבתה, לוחצים על סמל העריכה עריכה ואז על הפעלה של OpenTelemetry מנוהל.
לוחצים על שמירת השינויים.

Terraform

כדי להפעיל את Managed OpenTelemetry ל-GKE באשכול קיים, מוסיפים את הבלוק managed_opentelemetry_config למשאב google_container_cluster הקיים, כמו בדוגמה הבאה:

terraform {
  required_providers {
    google-beta = {
      source  = "hashicorp/google-beta"
      version = ">= 7.17.0"
    }
  }
}

resource "google_container_cluster" "default" {
  name     = "gke-standard-regional-with-managed-otel"
  provider = google-beta
  location = "us-west1"

  initial_node_count = 1
  release_channel {
    channel = "RAPID" # The default rapid version already has the feature available.
  }

  managed_opentelemetry_config {
    scope = "COLLECTION_AND_INSTRUMENTATION_COMPONENTS"
  }
}

מידע נוסף על שימוש ב-Terraform זמין במאמר תמיכה ב-Terraform ב-GKE.

הגדרת האפליקציה לשימוש ב-Managed OpenTelemetry collector

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

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

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

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

הגדרת תצורה אוטומטית

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

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

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

כדי להגדיר את המשאב המותאם אישית Instrumentation:
1. שומרים את קובץ המניפסט Instrumentation הבא בקובץ בשם otlp-auto-config-namespace.yaml:
```
apiVersion: telemetry.googleapis.com/v1alpha1
kind: Instrumentation
metadata:
  namespace: NAMESPACE
  name: NAME
spec:
  selector:
    matchLabels:
      KEY: VALUE
  autoInstrumentationConfig:
    configInjection:
      enabled: true
  otelSDKConfig:
    tracer_provider:
      sampler:
        parent_based:
          root:
            trace_id_ratio_based:
              ratio: "TRACE_RATIO"
    meter_provider:
      readers:
      - periodic:
          interval: METRICS_INTERVAL
```
  מחליפים את מה שכתוב בשדות הבאים:
  - ‫NAMESPACE: מרחב השמות שמכיל את ה-Pods שרוצים להגדיר להם אינסטרומנטציה אוטומטית. משתמשים ב-default כדי לטרגט את מרחב השמות שמוגדר כברירת מחדל.
  - ‫NAME: השם של קובץ המניפסט. בדוגמה הזו, השם הוא otlp-auto-config-namespace.yaml.
  - (אופציונלי) התווית שמצורפת ל-Pods לטירגוט. אם מציינים בורר ריק ({}), כל ה-Pods במרחב השמות מטורגטים.
    - ‫KEY: המפתח של התווית.
    - ‫VALUE: הערך של התווית.
  - ‫TRACE_RATIO: היחס של נתוני המעקב שצריך לאסוף. אם לא מצוין ערך, ברירת המחדל היא 1.0. למידע נוסף, קראו את המאמר שינוי תדירות הדגימה של המעקב.
  - ‫METRICS_INTERVAL: משך הזמן, באלפיות השנייה, של נתוני המעקב שייאספו. ערך ברירת המחדל הוא 30000. הערך צריך להיות לא שלילי, עם מינימום של 5,000 אלפיות שנייה, מקסימום של 300,000 אלפיות שנייה ומכפלה של 5,000 אלפיות שנייה. פרטים נוספים זמינים במאמר בנושא שינוי מרווח הזמן של ייצוא המדדים.
2. אם רוצים לשנות את ההגדרות, אפשר לעיין בקטע הבא כדי לשנות את ההגדרות האישיות.
3. מריצים את הפקודה הבאה כדי להחיל את ההגדרה:
```
kubectl apply -f otlp-auto-config-namespace.yaml
```
כדי להוסיף את משתני הסביבה באופן אוטומטי, צריך לפרוס את האפליקציה במרחב השמות באשכול שההגדרה חלה עליו.
- כדי להחיל את ההגדרות על עומס עבודה שעדיין לא פועל במרחב השמות, פורסים את עומס העבודה באמצעות הפקודה הבאה:
```
kubectl apply -f DEPLOYMENT_NAME -n NAMESPACE
```
  מחליפים את מה שכתוב בשדות הבאים:
  - ‫DEPLOYMENT_NAME: שם הפריסה.
  - ‫NAMESPACE: מרחב השמות.
- כדי להחיל את ההגדרה על עומס עבודה שכבר פועל במרחב השמות, פורסים מחדש את עומס העבודה באמצעות הפקודה הבאה:
```
kubectl rollout restart deployment DEPLOYMENT_NAME -n NAMESPACE
```
  מחליפים את מה שכתוב בשדות הבאים:
  - ‫DEPLOYMENT_NAME: שם הפריסה.
  - ‫NAMESPACE: מרחב השמות.

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

כשעומס עבודה מוגדר עם משתני הסביבה האלה ופועל באשכול שבו נפרס האוסף המנוהל, במהלך הפעלת עומס העבודה הוא שולח אותות OpenTelemetry לאוסף המנוהל. אתם יכולים לראות את האותות האלה ב-Google Cloud Observability.

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

שינוי ההגדרות

כדי לשנות את ההגדרה, צריך לבצע את הפעולות הבאות:

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

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

שינוי הכמות או התדירות של איסוף הנתונים

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

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

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

שינוי שיעור הדגימה של העקבות

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

ההתנהגות שמוגדרת כברירת מחדל ב-OpenTelemetry SDK היא always_on, ששווה ליחס של 1.

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

    tracer_provider:
      sampler:
        parent_based:
          root:
            trace_id_ratio_based:
              ratio: "0.25"

שינוי מרווח הזמן לייצוא המדדים

מרווח הייצוא של המדדים קובע את רמת הפירוט של הנתונים שמוצגים בתרשימים ב-Cloud Monitoring.

הדוגמה הבאה ממחישה את ההגדרה של מרווח הזמן לייצוא המדדים. בדוגמה הזו, מרווח הייצוא הוא 30,000 אלפיות השנייה.

מרווח הזמן לייצוא מדדים משמש לציון מרווח העיכוב בין תחילת שני ייצואים עוקבים של מדדים מ-OpenTelemetry SDK.

הערך של מרווח הזמן הזה צריך להיות לא שלילי, עם מינימום של 5,000 אלפיות השנייה, מקסימום של 300,000 אלפיות השנייה וריבוי של 5,000 אלפיות השנייה. הערך מצוין באלפיות השנייה.

meter_provider:
  readers:
  - periodic:
      interval: 30000

בוחרים את סוגי האותות שרוצים לאסוף

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

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

הדוגמה הבאה היא קובץ מניפסט של Instrumentation שמוגדר לאיסוף של נתוני מעקב בלבד. איסוף היומנים והמדדים מושבת כי meter_provider ו-logger_provider מוגדרים כ-null.

apiVersion: telemetry.googleapis.com/v1alpha1
kind: Instrumentation
metadata:
  namespace: default
  name: otlp-auto-config-disable-metrics-logs
spec:
  selector:
    matchLabels: # Update the labels to match your workloads
      app: telemetrygen-app
  autoInstrumentationConfig:
    configInjection:
      enabled: true
  otelSDKConfig:
    meter_provider: null
    logger_provider: null

איסוף נתונים של פרומפטים מולטי-מודאליים ותשובות

אפשר להגדיר את Managed OpenTelemetry for GKE כדי לאסוף נתונים של פרומפטים מולטי-מודאליים ותגובות.

הפונקציונליות הזו זמינה לסוכני LangGraph ReAct ולסוכני AI גנרטיבי שנוצרו באמצעות המסגרת של הערכה לפיתוח סוכנים (ADK).

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

אתם יכולים להשתמש במוצרים כמו Model Armor ו-Sensitive Data Protection כדי לנהל מידע אישי רגיש שעשוי להופיע בהנחיות ובתשובות.

כדי להגדיר את Managed OpenTelemetry for GKE לאיסוף נתונים של הנחיות ותשובות מולטי-מודאליות, צריך לבצע את הפעולות הבאות:

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

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

מגדירים את השדה promptsResponses.uploadBasePath במשאב המותאם אישית Instrumentation, למשל:

apiVersion: telemetry.googleapis.com/v1alpha1
kind: Instrumentation
metadata:
  namespace: default
  name: prompts-responses
spec:
  selector: {}
  promptsResponses:
    uploadBasePath: gs://BUCKET_NAME

מחליפים את BUCKET_NAME בשם של הקטגוריה ב-Cloud Storage.

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

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

השבתת ההגדרה האוטומטית של עומסי עבודה

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

kubectl delete instrumentations.telemetry.googleapis.com INSTRUMENTATION_NAME -n NAMESPACE

מחליפים את מה שכתוב בשדות הבאים:

‫INSTRUMENTATION_NAME: השם של Instrumentation המשאב המותאם אישית.
‫NAMESPACE: מרחב השמות שמכיל את ה-Pods שבהם רוצים להשבית את ההגדרה האוטומטית.

כדי להשבית באופן זמני את ההחדרה האוטומטית של משתני סביבה, תוך שמירה על הגדרת המכשיר האוטומטי לשימוש עתידי, מגדירים את autoInstrumentationConfig.configInjection.enabled ל-false ומחילים את המשאב המותאם אישית המעודכן.

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

apiVersion: telemetry.googleapis.com/v1alpha1
kind: Instrumentation
metadata:
  namespace: default
  name: otlp-auto-config-example
spec:
  selector:
    matchLabels: # Update the labels to match your workloads
      app: telemetrygen-app
  autoInstrumentationConfig:
    configInjection:
      enabled: false # disable environment variables config injection
  otelSDKConfig:
  ... # preserve OpenTelemetry configuration for future use

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

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

kubectl rollout restart deployment DEPLOYMENT_NAME -n NAMESPACE

מחליפים את מה שכתוב בשדות הבאים:

‫DEPLOYMENT_NAME: שם הפריסה.
‫NAMESPACE: מרחב השמות.

הצגת נתוני הטלמטריה

כשעומס עבודה מוגדר פועל ב-GKE שבו מופעל Managed OpenTelemetry for GKE, האותות של OpenTelemetry נשלחים אל Google Cloud Observability.

במאמרים הבאים מוסבר איך לצפות בנתונים ב-Google Cloud Observability:

יצירת טלמטריה לדוגמה

בקטע הזה מוסבר איך פורסים אפליקציה לדוגמה ומפנים את האפליקציה הזו לנקודת הקצה (endpoint) של OTLP של Managed OpenTelemetry Collector. אחר כך תוכלו לראות את נתוני הטלמטריה ב Google Cloud.

אפליקציית הדוגמה היא גנרטור קטן שמייצא עקבות, יומנים ומדדים אל נקודת הקצה של HTTP של OpenTelemetry Collector שמנוהל בתוך האשכול. נקודת הקצה של OTLP נמצאת בתוך הקוד של האפליקציה, ומפנה אל http://opentelemetry-collector.gke-managed-otel.svc.cluster.local:4318.

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

כדי לפרוס את האפליקציה לדוגמה:

מתחברים לאשכול שבו הפעלתם את Managed OpenTelemetry. הוראות מפורטות מופיעות במאמר הגדרת אשכול ברירת מחדל לפקודות kubectl.
מריצים את הפקודה הבאה:
```
kubectl apply -f https://raw.githubusercontent.com/GoogleCloudPlatform/otlp-k8s-ingest/main/sample/gke-app.yaml
```
אחרי כמה דקות, נתוני הטלמטריה שנוצרו על ידי האפליקציה מתחילים לזרום דרך ה-collector אל הקצה העורפי של Google Cloud לכל אות.
1. כדי לוודא שהטלמטריה נאספת, אפשר לעיין ביומנים, במדדים ובנתוני המעקב מאפליקציית ההדגמה במסוף Google Cloud :
2. כדי לראות את המדדים:
  1. במסוף Google Cloud , עוברים לדף Metrics Explorer:
    
    לדף Metrics Explorer
  2. מריצים את שאילתת PromQL הבאה ב-Metrics Explorer:
```
sum(avg_over_time({"__name__"="gen","namespace"="opentelemetry-demo","job"="telemetrygen"}[1h]))
```
3. כדי לראות את העקבות:
  1. נכנסים לדף Trace Explorer במסוף Google Cloud .
    
    כניסה לדף Trace Explorer
  2. סינון של טווחים של מעקב לפי שם הטווח ששווה ל-lets-go.
4. כדי לראות את היומנים:
  1. נכנסים לדף Logs Explorer במסוף Google Cloud .
    
    כניסה לדף Logs Explorer
  2. מריצים את השאילתה הבאה:
```
resource.type="k8s_pod"
resource.labels.namespace_name="opentelemetry-demo"
```

השבתה של OpenTelemetry מנוהל ל-GKE

אתם יכולים להשבית את Managed OpenTelemetry for GKE באשכול. כשמשביתים את אוסף הנתונים, אוסף הנתונים המנוהל של OpenTelemetry מוסר מהאשכול ולא נאספים נתוני טלמטריה חדשים.

כדי להשבית את Managed OpenTelemetry for GKE, פועלים לפי השלבים הבאים.

gcloud

כדי להשבית את Managed OpenTelemetry for GKE באשכול, מריצים את הפקודה הבאה של gcloud:

  gcloud container clusters update CLUSTER_NAME \
  --project=PROJECT_ID \
  --managed-otel-scope=NONE \
  --location=LOCATION

מחליפים את מה שכתוב בשדות הבאים:

‫CLUSTER_NAME: שם האשכול.
‫PROJECT_ID: מזהה הפרויקט ב- Google Cloud .
‫LOCATION: האזור או התחום.

המסוף

במסוף, עוברים לרשימת האשכולות:

כניסה לאשכולות של Kubernetes
בוחרים את האשכול שרוצים להשבית בו את Managed OpenTelemetry Collector.
בקטע Cluster details, לצד Managed OpenTelemetry, לוחצים על סמל העריכה.
כדי להשבית את התכונה, מבטלים את הסימון בתיבה.

Terraform

כדי להשבית את Managed OpenTelemetry ל-GKE, מעדכנים את הבלוק managed_opentelemetry_config במשאב google_container_cluster כדי להגדיר את ההיקף ל-NONE.

מעדכנים את קובץ התצורה של Terraform:

resource "google_container_cluster" "default" {
  provider = google-beta
  name     = "CLUSTER_NAME"
  location = "LOCATION"
  project  = "PROJECT_ID"

  # ... other configuration ...

  managed_opentelemetry_config {
    scope = "NONE"
  }
}

מחילים את ההגדרות של Terraform:
```
terraform apply
```

מחליפים את מה שכתוב בשדות הבאים:

‫CLUSTER_NAME: שם האשכול.
‫LOCATION: האזור או התחום.
‫PROJECT_ID: מזהה הפרויקט ב- Google Cloud .

כשמשביתים את Managed OpenTelemetry for GKE, ההגדרה של המשאב המותאם אישית Instrumentation והמשאבים המותאמים אישית Instrumentation לא מוסרים מהאשכול. אם תפעילו מחדש את OpenTelemetry המנוהל, הוא ישתמש בהגדרות שנשמרו במשאבים המותאמים אישית של Instrumentation.

אם יש לכם נתוני טלמטריה שכבר נאספו על ידי Managed OpenTelemetry ל-GKE, השבתת האוסף לא תשפיע על הנתונים האלה. הנתונים הקיימים עדיין מאוחסנים ב-Google Cloud Observability, ולא נאספים נתוני טלמטריה חדשים.

פתרון בעיות

עומסי עבודה (workloads) עם הרשאות מיוחדות של שותפי Autopilot

אם תנסו להשתמש בהגדרה אוטומטית עם עומס עבודה מורשה של שותף Autopilot, יכול להיות שה-Pod של עומס העבודה יידחה.

אי אפשר להחדיר הגדרות של OpenTelemetry לעומסי עבודה עם הרשאות משותפי GKE Autopilot. אם תטרגטו עומסי עבודה כאלה באמצעות משאב מותאם אישית של Instrumentation כדי להפעיל הזרקה של משתני סביבה של OpenTelemetry, יכול להיות שעומס העבודה לא יתאים לרשימת ההיתרים של עומסי עבודה עם הרשאות ב-Autopilot. כלומר, Pod עם הזרקת הגדרות יידחה על ידי GKE Autopilot.

יומנים, מדדים או עקבות לא מוצגים במסוף Google Cloud

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

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

מוודאים שכל ממשקי ה-API הנדרשים מופעלים בפרויקט.
מוודאים שInstrumentation המשאב המותאם אישית מוגדר בצורה נכונה, עם מרחב שמות שתואם למרחב השמות שבו עומס העבודה פועל, ושהבורר תואם לתווית של עומס העבודה.
בודקים את ה-Pod של עומס העבודה כדי לראות אם משתני הסביבה מוזרקים בצורה נכונה.
בודקים את יומני הקונטיינר של OpenTelemetry Collector כדי לראות אם יש שגיאות ב-Collector. כדי לעשות זאת, מריצים את הפקודה הבאה:
```
kubectl logs -n gke-managed-otel -l app=opentelemetry-collector -c opentelemetry-collector
```

השבתה של אות טלמטריה לא עובדת

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

כשמחילים את המשאב המותאם אישית, משתמשים בהחלה בצד השרת בפקודה kubectl apply כשמעדכנים את המשאב המותאם אישית Instrumentation.

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

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

המשתנים מוזרקים לקונטיינרים של פודים של עומסי עבודה , ולא לעומס העבודה. בודקים את ה-Pods, ולא את האובייקטים של הבעלים כמו ReplicaSets או Deployments.

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

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

kubectl get pods -n default -l app=telemetrygen-app -o yaml

בודקים את spec.containers[*].env של ה-Pods.
מוודאים שיש אובייקט Instrumentation באותו מרחב שמות, ובודקים שהוא מטרגט את ה-Pod ושהתכונה config injection מופעלת. כדי לעשות זאת, מריצים את הפקודה הבאה:
```
kubectl get instrumentations.telemetry.googleapis.com -n default -o yaml
```

המשתנים מוזרקים לקונטיינרים רק כשיוצרים Pods, כי Kubernetes API לא מאפשר לשנות את רוב השדות במפרט של Pod קיים, כמו משתני סביבה. כדי שההגדרה תיכנס לתוקף בעומסי עבודה שנוצרו לפני שיצרתם את האובייקט Instrumentation, צריך להפעיל מחדש את עומס העבודה. לדוגמה, לפריסה בשם telemetry-gen-app, מריצים את הפקודה הבאה:

kubectl rollout restart deployment -n default telemetry-gen-app

כמות מוגזמת של נתוני מעקב ב-Cloud Trace

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

לדוגמה, מוסיפים את השורה הבאה לאובייקט Instrumentation:

spec:
  otelSDKConfig:
    tracer_provider:
      sampler:
        parent_based:
          root:
            trace_id_ratio_based:
              ratio: "0.01"

התנהגות ברירת המחדל של OpenTelemetry SDK היא מעקב מסוג always_on, ששווה ליחס של 1.

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

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

אם אתם רואים הגדרה שגויה של ה-Pod, ודאו שה-Pod מטורגט בצורה נכונה על ידי האובייקט Instrumentation, ושאין כמה אובייקטים מסוג Instrumentation שמטרגטים את אותו Pod:

kubectl get instrumentations --all-namespaces \
-o custom-columns=NAMESPACE:.metadata.namespace,NAME:.metadata.name,SELECTOR:.spec.selector

kubectl get pod -n ${NAMESPACE:?} ${POD_NAME:?} --show-labels

הערה: סלקטור ריק מטַרגט את כל ה-Pods במרחב השמות שלו.

אם כמה מכשירים מכוונים לאותו Pod כשהוא נוצר, המכשיר שעודכן אחרון נכנס לתוקף.

הפקודה `kubectl logs` לא מחזירה פלט

כשיומנים מועברים בסטרימינג ישירות מאפליקציה אל OpenTelemetry collector, היומנים מדלגים על נתיב הרישום ביומן הרגיל של זמן הריצה של הקונטיינר. זהו התרחיש הנפוץ כשמשתמשים ב-OpenTelemetry ליומנים. כברירת מחדל, הכלי לייצוא שולח את היומנים לנקודת הקצה otlp במקום לזרמי הנתונים stdout ו-stderr.

במקרה כזה, הפקודה kubectl logs לא תציג פלט עבור האפליקציה הזו, כי היומנים לא נכתבים לזרמי stdout או stderr כדי שזמן הריצה של הקונטיינר יתעד אותם. במקום זאת, פלט הרישום זמין ב-Cloud Logging.

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

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

למידע נוסף על אופן הפעולה של Managed OpenTelemetry ל-GKE, קראו את המאמר Managed OpenTelemetry ל-GKE.
אם אתם רוצים לפרוס בעצמכם חלופה ל-Managed OpenTelemetry ל-GKE, קראו את המאמר Google-Built OpenTelemetry Collector.

פריסת Managed OpenTelemetry ל-GKE קל לארגן דפים בעזרת אוספים אפשר לשמור ולסווג תוכן על סמך ההעדפות שלך.

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

דרישות

התפקידים הנדרשים

עלויות

הפעלת OpenTelemetry מנוהל ל-GKE באשכול

הפעלה באשכול חדש

gcloud

המסוף

Terraform

הפעלה באשכול קיים

gcloud

המסוף

Terraform

הגדרת האפליקציה לשימוש ב-Managed OpenTelemetry collector

הגדרת תצורה אוטומטית

שינוי ההגדרות

שינוי הכמות או התדירות של איסוף הנתונים

שינוי שיעור הדגימה של העקבות

שינוי מרווח הזמן לייצוא המדדים

בוחרים את סוגי האותות שרוצים לאסוף

איסוף נתונים של פרומפטים מולטי-מודאליים ותשובות

השבתת ההגדרה האוטומטית של עומסי עבודה

הצגת נתוני הטלמטריה

יצירת טלמטריה לדוגמה

השבתה של OpenTelemetry מנוהל ל-GKE

gcloud

המסוף

Terraform

פתרון בעיות

עומסי עבודה (workloads) עם הרשאות מיוחדות של שותפי Autopilot

יומנים, מדדים או עקבות לא מוצגים במסוף Google Cloud

השבתה של אות טלמטריה לא עובדת

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

כמות מוגזמת של נתוני מעקב ב-Cloud Trace

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

הפקודה kubectl logs לא מחזירה פלט

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

פריסת Managed OpenTelemetry ל-GKE

הפקודה `kubectl logs` לא מחזירה פלט