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

פריסת Managed OpenTelemetry ל-GKE

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

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

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

אפשר להשתמש ב-Managed OpenTelemetry for GKE כדי:

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

אם אתם צריכים סינון ובקרה ברמת האוסף, השתמשו ב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, טלמטריה (OTLP), Cloud Logging,‏ Cloud Monitoring ו-Cloud Trace:

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

כדי להפעיל ממשקי API, צריך את תפקיד ה-IAM 'אדמין של שימוש בשירות' (roles/serviceusage.serviceUsageAdmin), שכולל את ההרשאה serviceusage.services.enable. איך מקצים תפקידים

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, טלמטריה (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 ואילך.
ה-CLI של gcloud מופעל בגרסה 551.0.0 ואילך.
אם אתם משתמשים ב-Terraform כדי להקצות את תשתית GKE, אתם צריכים להשתמש בספק terraform-provider-google-beta בגרסה 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, צריך לבצע את הפעולות הבאות:

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

כשמפעילים את 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 beta 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 ואילך.

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

gcloud beta 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. לוחצים על Save.
במקרה של אשכול רגיל:
1. נכנסים לדף Create a Kubernetes cluster במסוף Google Cloud .
  מעבר אל יצירת אשכול Kubernetes
2. בחלונית הניווט, לוחצים על תכונות.
3. בקטע Operations (פעולות), בוחרים באפשרות Enable managed OpenTelemetry (הפעלת OpenTelemetry מנוהל).
4. לוחצים על Save.

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 beta 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.
במסוף Google Cloud , עוברים לדף Kubernetes clusters:

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

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

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

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

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

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

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

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

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

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

מתחברים לאשכול שבו הפעלתם את Managed OpenTelemetry. הוראות מופיעות במאמר הגדרת אשכול ברירת מחדל לפקודות kubectl.
מריצים את הפקודה הבאה:
```
kubectl apply -f https://raw.githubusercontent.com/GoogleCloudPlatform/otlp-k8s-ingest/main/sample/gke-app.yaml
```
אחרי כמה דקות, נתוני הטלמטריה שנוצרו על ידי האפליקציה מתחילים לזרום דרך האוסף אל קצה העורפי של 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 beta container clusters update CLUSTER_NAME \
  --project=PROJECT_ID \
  --managed-otel-scope=NONE \
  --location=LOCATION

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

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

המסוף

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

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

פתרון בעיות

עומסי עבודה עם הרשאות מיוחדות של שותפים ב-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 custom resource, חשוב להחיל את המשאב המותאם אישית ולפרוס מחדש את עומסי העבודה.

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

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

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

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

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

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

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

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

המשתנים מוזרקים למאגרי התגים רק כשנוצרים אובייקטים מסוג Pod, כי 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, צריך לבדוק שאובייקט Instrumentation מטַרגט את ה-Pod בצורה נכונה, ואין כמה אובייקטים של 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.

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

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

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

פרטים על אופן הפעולה של Managed OpenTelemetry for GKE זמינים במאמר Managed OpenTelemetry for GKE.
אם אתם מחפשים חלופה להטמעה עצמית של Managed OpenTelemetry for GKE, תוכלו לעיין במאמר בנושא Google-Built OpenTelemetry Collector.

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

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

דרישות

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

עלויות

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

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

gcloud

המסוף

Terraform

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

gcloud

המסוף

Terraform

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

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

שינוי ההגדרה

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

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

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

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

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

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

צפייה בטלמטריה

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

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

gcloud

המסוף

Terraform

פתרון בעיות

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

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

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

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

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

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

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

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

פריסת Managed OpenTelemetry ל-GKE

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