Managed OpenTelemetry for GKE

במאמר הזה מוסבר על Managed OpenTelemetry ל-Google Kubernetes Engine ‏ (GKE), שמאפשר לשלוח עקבות, מדדים ויומנים של OpenTelemetry Protocol (OTLP) ל-Google Cloud Observability מאפליקציות שפועלות ב-GKE. ‫Managed OpenTelemetry הוא הפתרון המנוהל היחיד של Google Cloud לאיסוף נתוני מעקב ב-GKE.

כדי להשתמש ב-Managed OpenTelemetry ל-Google Kubernetes Engine (GKE), צריך להגדיר באפליקציות כלים ליצירת אותות באמצעות פרוטוקול OpenTelemetry. לפרטים נוספים, קראו את המאמר עומסי עבודה נתמכים.

ל-Managed OpenTelemetry ל-GKE יש שני רכיבים:

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

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

    אתם יכולים להשתמש במשאב המותאם אישית של Instrumentation לעומסי עבודה שמשתמשים ב-SDK של OpenTelemetry ומוגדרים עם משתני סביבה סטנדרטיים של OpenTelemetry. המשאב המותאם אישית instrumentations.telemetry.googleapis.com של Instrumentation הוא משאב שונה מהמשאב Instrumentation של מפעיל OpenTelemetry.

במאמר פריסת Managed OpenTelemetry ל-GKE מוסבר איך משתמשים ב-Managed OpenTelemetry ל-GKE.

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

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

איך פועל Managed OpenTelemetry ל-GKE

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

אוסף מנוהל

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

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

  • כתובת ה-URL של http://opentelemetry-collector.gke-managed-otel.svc.cluster.local:4318 לנקודת הקצה (endpoint) של HTTP.
  • כתובת ה-URL של http://opentelemetry-collector.gke-managed-otel.svc.cluster.local:4317 לנקודת הקצה (endpoint) של gRPC.

האוסף המנוהל שולח את הנתונים שנאספו אל Google Cloud Observability. לאחר מכן הנתונים זמינים בשירותים הבאים:

אפשר להפעיל את ה-collector המנוהל באשכול GKE באמצעות המסוף או ה-CLI של gcloud. הוראות מפורטות זמינות במאמר הפעלת Managed OpenTelemetry ל-GKE באשכול.

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

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

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

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

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

במאמר הגדרת האפליקציה לשימוש ב-Managed OpenTelemetry Collector מוסבר איך להגדיר את האפליקציה באמצעות ההגדרה האוטומטית.

המשאב המותאם אישית של Instrumentation

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

  • מציינים אם להחדיר את משתני הסביבה לקונטיינרים של Pods נבחרים או של כל ה-Pods במרחב שמות.
  • לשלוט בסוג הנתונים שנאספים (יומנים, מדדים ומעקבים).
  • לשלוט בתדירות שבה נתוני המדדים נשלחים לאוסף המנוהל.
  • שליטה בתדירות הדגימה של נתוני המעקב.
  • שליטה בפרוטוקול התעבורה של OTLP (‏HTTP או gRPC) שמשמש לייצוא נתוני הטלמטריה לאוסף המנוהל.

למידע נוסף על השימוש במשאב המותאם אישית של Instrumentation, ראו שינוי ההגדרות.

הזרקה אוטומטית של משתני סביבה

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

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

משתני סביבה

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

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

אלה משתני הסביבה שאפשר להוסיף באופן אוטומטי למאגרי תגים:

  • נקודת הקצה והפרוטוקול של כלי הייצוא של OpenTelemetry.
    • ‫OTEL_EXPORTER_OTLP_ENDPOINT: כתובת URL בסיסית של נקודת קצה לכל סוג של אות. בהתאם למייצא שהוגדר במשאב המותאם אישית של הכלים, הערך של משתנה הסביבה הזה הוא נקודת הקצה (endpoint) של HTTP של אוסף OpenTelemetry המנוהל באשכול (http://opentelemetry-collector.gke-managed-otel.svc.cluster.local:4318, ברירת המחדל) או נקודת הקצה של gRPC‏ (http://opentelemetry-collector.gke-managed-otel.svc.cluster.local:4317).
    • ‫OTEL_EXPORTER_OTLP_PROTOCOL: מציין את פרוטוקול התעבורה של OTLP שמשמש את המייצא של ה-SDK. הערך של משתנה הסביבה הזה הוא אחד מהערכים הבאים, בהתאם לפרוטוקול התעבורה של OTLP שבו אתם משתמשים:
      • ‫grpc אם משתמשים בפרוטוקול התעבורה otlp_grpc.
      • ‫http/protobuf אם לא מציינים פרוטוקול תעבורה או אם משתמשים בפרוטוקול התעבורה otlp_http.
  • הגדרת יחס הדגימה של המעקב.
    • ‫OTEL_TRACES_SAMPLER: מגדיר את הדוגם שמשמש לדגימת נתוני מעקב על ידי ה-SDK לאחת מהאפשרויות הבאות:
      • parentbased_traceidratio כשדגימת המעקב מוגדרת במשאב בהתאמה אישית.
      • ‫parentbased_always_on הוא ערך ברירת המחדל של משתנה הסביבה הזה. הוא משמש אם משתנה הסביבה הזה לא מוגדר או שהוא null במשאב המותאם אישית.
    • ‫OTEL_TRACES_SAMPLER_ARG: מציין את יחס הדגימה של המעקב (בין 0.0 ל-1.0). אם לא מגדירים את המאפיין במשאב המותאם אישית, המערכת משתמשת בערך 1.0.
  • מרווח הזמן בין ההתחלה של שני ייצואים עוקבים של מדדים.
    • ‫OTEL_METRIC_EXPORT_INTERVAL: מרווח הזמן (באלפיות השנייה) בין ההתחלה של שני ניסיונות ייצוא (מינימום: 5,000, מקסימום: 300,000, ברירת מחדל: 30,000).
  • השבתת הייצוא של נתוני טלמטריה ב-OTLP לפי סוג האות. מייצאי האותות מושבתים כש-tracer_provider,‏ meter_provider או logger_provider מוגדרים ל-null במשאב המותאם אישית של Instrumentation.
    • ‫OTEL_TRACES_EXPORTER: משבית את הייצוא של נתוני המעקב כשהערך הוא none. ערך ברירת המחדל: otlp.
    • ‫OTEL_METRICS_EXPORTER: משבית את הייצוא של המדדים כשהוא מוגדר לערך none. ערך ברירת המחדל: otlp.
    • ‫OTEL_LOGS_EXPORTER: משבית את ייצוא היומנים כשהערך הוא none. ערך ברירת המחדל: otlp.
  • זיהוי של Pods מסוג hostNetwork כדי לשייך את המטא-נתונים באמצעות Kubernetes Attributes Processor של OpenTelemetry Collector.
    • K8S_POD_UID: מזהה ה-Pod של hostNetwork Pod לאכלוס ההגדרה k8s.pod.uid במשתנה הסביבה OTEL_RESOURCE_ATTRIBUTES.
    • ‫OTEL_RESOURCE_ATTRIBUTES: הערך כולל את k8s.pod.uid=$(K8S_POD_UID) כדי לאפשר למעבד המאפיינים של Kubernetes לשייך מטא-נתונים, כמו k8s.namespace.name,‏ k8s.deployment.name ו-k8s.node.name, לפודים של hostNetwork. השיוך של מטא-נתונים ו-hostNetwork Pods מאפשר להוסיף את המטא-נתונים שחולצו לטווחים, למדדים וליומנים כמאפייני משאבים.
  • הנחיות ותשובות.
    • ‫OTEL_INSTRUMENTATION_GENAI_UPLOAD_FORMAT='jsonl': הוראה ל-OpenTelemetry לעצב אובייקטים של Cloud Storage כשורות JSON. למשתנה הסביבה הזה יש ערך קבוע: jsonl.
    • ‫OTEL_INSTRUMENTATION_GENAI_COMPLETION_HOOK='upload': הוראה ל-OpenTelemetry להעלות נתוני הנחיות ותשובות במקום להטמיע את התוכן הזה בטווחים של המעקב. הרשומות ביומן כוללות הפניות לאובייקטים שהועלו. למשתנה הסביבה הזה יש ערך קבוע: upload.
    • ‫OTEL_SEMCONV_STABILITY_OPT_IN='gen_ai_latest_experimental': הוראה ל-OpenTelemetry להשתמש במוסכמות הסמנטיות העדכניות ביותר ל-AI גנרטיבי. למשתנה הסביבה הזה יש ערך קבוע: gen_ai_latest_experimental.
    • ‫OTEL_INSTRUMENTATION_GENAI_UPLOAD_BASE_PATH: ציון הנתיב לאובייקטים. לדוגמה, gs://STORAGE_BUCKET_NAME/PATH.

הגדרה ידנית

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

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

לפרטים על הגדרה אוטומטית, ראו הגדרה אוטומטית.

עומסי עבודה נתמכים

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

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

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

אי אפשר להוסיף הגדרות של OpenTelemetry לעומסי עבודה עם הרשאות משותפי GKE Autopilot.

חיוב

כששולחים נתוני טלמטריה אל Google Cloud, החיוב מתבצע לפי נפח הטמעת הנתונים. החיוב על מדדים מתבצע לפי התמחור של השירות המנוהל של Google Cloud ל-Prometheus, החיוב על יומנים מתבצע לפי התמחור של Cloud Logging והחיוב על נתוני מעקב מתבצע לפי התמחור של Cloud Trace.

במאמר התמחור של Google Cloud Observability מפורט מידע על העלויות שקשורות להטמעת נתוני מעקב, יומנים ומדדים של השירות המנוהל של Google Cloud ל-Prometheus.

מכסות

כשמשתמשים ב-Managed OpenTelemetry ל-GKE, חלות המכסות של שירותי Google Cloud Observability. פרטים נוספים זמינים במאמרים הבאים:

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