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

פריסת Managed OpenTelemetry ל-GKE

Autopilot Standard

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

למידע נוסף על אופן הפעולה של Managed OpenTelemetry ל-GKE, קראו את המאמר Managed OpenTelemetry ל-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 .

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

בחירת פרויקט: כדי לבחור פרויקט לא נדרש תפקיד IAM ספציפי – אתם יכולים לבחור כל פרויקט שקיבלתם בו תפקיד.
יצירת פרויקט: כדי ליצור פרויקט, צריך את התפקיד "יצירת פרויקטים" (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). אחרת, תוכלו לקבל את ההרשאה הזו דרך התפקיד "אדמין בממשק 'שימוש בשירות'" (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 .

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

בחירת פרויקט: כדי לבחור פרויקט לא נדרש תפקיד IAM ספציפי – אתם יכולים לבחור כל פרויקט שקיבלתם בו תפקיד.
יצירת פרויקט: כדי ליצור פרויקט, צריך את התפקיד "יצירת פרויקטים" (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, צריך לעמוד בדרישות הבאות:

באשכול צריכה להיות גרסת GKE‏ 1.34.1-gke.2178000 ואילך. כדי להגדיר את פרוטוקול הייצוא של OTLP כ-gRPC במשאב המותאם אישית של הכלים, צריך להשתמש בגרסה 1.37.1-gke.1697000 או בגרסה חדשה יותר של GKE.
‫ה-CLI של gcloud מופעל בגרסה 576.0.0 ואילך.
אם אתם משתמשים ב-Terraform כדי להקצות את התשתית של GKE, אתם צריכים להשתמש ב-terraform-provider-google בגרסה v8.8.0 ואילך.

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

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

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

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

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

עלויות

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

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

כדי להגדיר את Managed OpenTelemetry ל-GKE:

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

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

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

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

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

כדי להפעיל את Managed OpenTelemetry ל-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: הגרסה של GKE. בקטע דרישות מפורטת הגרסה המינימלית שבה אפשר להשתמש.

באשכול 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: הגרסה של GKE. בקטע דרישות מפורטת הגרסה המינימלית שבה אפשר להשתמש.

המסוף

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

Terraform

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

terraform {
  required_providers {
    google = {
      source  = "hashicorp/google"
      version = ">= 8.8.0"
    }
  }
}

resource "google_container_cluster" "default" {
  name     = "gke-standard-regional-with-managed-otel"
  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 ל-GKE באשכול קיים:

gcloud

מוודאים שגרסת האשכול עומדת בדרישות. במאמרים שדרוג אשכולות רגילים ושדרוג אשכולות 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: האזור או התחום.

המסוף

מוודאים שגרסת האשכול עומדת בדרישות. במאמרים שדרוג אשכולות רגילים ושדרוג אשכולות Autopilot מוסבר איך משדרגים אשכול קיים.
במסוף Google Cloud , נכנסים לדף Kubernetes clusters:

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

Terraform

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

terraform {
  required_providers {
    google = {
      source  = "hashicorp/google"
      version = ">= 8.8.0"
    }
  }
}

resource "google_container_cluster" "default" {
  name     = "gke-standard-regional-with-managed-otel"
  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 מקבל אותות מהאפליקציות שפועלות באשכול שבו הוא מופעל. האותות מהאפליקציה כוללים מעקבים, מדדים ויומנים.

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

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

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

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

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

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

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

כדי להגדיר את המשאב המותאם אישית של Instrumentation:
1. שומרים את מניפסט הכלים הבא בקובץ בשם 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: השם של אובייקט ה-Instrumentation בקובץ המניפסט.
  - (אופציונלי) התווית שמצורפת לפודים לטירגוט. אם מציינים בורר ריק ({}), כל ה-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 מגדיר באופן אוטומטי את כל עומסי העבודה כשהם נפרסים באשכול. עומסי העבודה מנוהלים על ידי הזרקת משתני סביבה לפודים שבהם עומסי העבודה פועלים.

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

למידע נוסף על הצגת האותות, ראו הצגת נתוני טלמטריה. לדוגמה, ראו יצירת נתוני טלמטריה לדוגמה.

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

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

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

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

הגדרת פרוטוקול הייצוא של OTLP (‏HTTP או gRPC)

כברירת מחדל, ההגדרה האוטומטית מגדירה עומסי עבודה לייצוא נתוני טלמטריה באמצעות HTTP. ב-GKE מגרסה 1.37.1-gke.1697000 ואילך, אפשר להגדיר את המשאב המותאם אישית של Instrumentation לייצא נתוני טלמטריה באמצעות HTTP או gRPC.

משאב מותאם אישית של Instrumentation תומך רק בפרוטוקול אחד לכל הספקים. כדי להשתמש ב-gRPC, מגדירים את המייצא ל-otlp_grpc: {} לכל ספק שבו משתמשים, ומגדירים את כל הספקים שלא בשימוש ל-null. לדוגמה, כדי להשבית את המדדים, משתמשים ב-meter_provider: null.

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

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"
      processors:
      - batch:
          exporter:
            otlp_grpc: {}
    meter_provider:
      readers:
      - periodic:
          interval: METRICS_INTERVAL
          exporter:
            otlp_grpc: {}
    logger_provider:
      processors:
      - batch:
          exporter:
            otlp_grpc: {}

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

‫NAMESPACE: מרחב השמות שמכיל את ה-Pods שרוצים להגדיר להם אינסטרומנטציה אוטומטית. כדי לטרגט את מרחב השמות שמוגדר כברירת מחדל, משתמשים ב-default.
‫NAME: השם של אובייקט ה-Instrumentation בקובץ המניפסט.
(אופציונלי) התווית שמצורפת לפודים לטירגוט. אם מציינים בורר ריק ({}), כל ה-Pods במרחב השמות מטורגטים.
- ‫KEY: המפתח של התווית.
- ‫VALUE: הערך של התווית.
‫TRACE_RATIO: היחס של נתוני המעקב שצריך לאסוף. אם לא מצוין ערך, ברירת המחדל היא 1.0. למידע נוסף, ראו שינוי תדירות הדגימה של המעקב.
METRICS_INTERVAL: המרווח, באלפיות שנייה, של נתוני המעקב שצריך לאסוף. ערך ברירת המחדל הוא 30000. הערך חייב להיות חיובי, לפחות 5,000 אלפיות השנייה, עד 300,000 אלפיות השנייה ובכפולות של 5,000 אלפיות השנייה. לפרטים נוספים, קראו את המאמר שינוי מרווח הזמן לייצוא המדדים.

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

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

כדי לשנות את התדירות שבה נתוני המעקב נשלחים ל-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

איסוף נתונים של הנחיות ותשובות מולטי-מודאליות

בגרסה 1.35.2-gke.1210000 ואילך של אשכול GKE, אתם יכולים להגדיר את Managed OpenTelemetry ל-GKE כדי לאסוף נתונים של הנחיות ותשובות מולטי-מודאליות.

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

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

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

כדי להגדיר את Managed OpenTelemetry ל-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 ומפעילים מחדש את עומסי העבודה, משתני הסביבה שמגדירים את ההנחיות והתשובות מוזרקים לקונטיינרים של עומסי העבודה.

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

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

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

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, ראו:

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

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

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

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

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

מתחברים לאשכול שבו הפעלתם את 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"
```

השבתת Managed OpenTelemetry ל-GKE

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

כדי להשבית את 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.
בקטע Cluster details, לצד Managed OpenTelemetry, לוחצים על סמל העריכה.
כדי להשבית את התכונה, מבטלים את הסימון בתיבה.

Terraform

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

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

resource "google_container_cluster" "default" {
  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 ב-GKE, לא מסירים מהאשכול את Instrumentation CustomResourceDefinition ואת המשאבים המותאמים אישית של Instrumentation שיצרתם.

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

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

פתרון בעיות

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

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

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

היומנים, המדדים או המעקבים לא מופיעים במסוף Google Cloud

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

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

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

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

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

כשמחילים את המשאב בהתאמה אישית, משתמשים ב-Server-Side Apply בפקודה kubectl apply כשמעדכנים את המשאב בהתאמה אישית של Instrumentation.

במאמר בחירת סוגי האותות לאיסוף מוסבר איך להשבית אות טלמטריה.

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

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

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

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

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

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

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

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

דרישות

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

עלויות

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

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

gcloud

המסוף

Terraform

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

gcloud

המסוף

Terraform

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

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

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

הגדרת פרוטוקול הייצוא של OTLP (‏HTTP או gRPC)

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

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

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

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

איסוף נתונים של הנחיות ותשובות מולטי-מודאליות

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

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

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

השבתת Managed OpenTelemetry ל-GKE

gcloud

המסוף

Terraform

פתרון בעיות

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

היומנים, המדדים או המעקבים לא מופיעים במסוף Google Cloud

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

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

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

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

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

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

פריסת Managed OpenTelemetry ל-GKE

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