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 for GKE כולל שני רכיבים:

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

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

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

הוראות לשימוש ב-Managed OpenTelemetry for GKE מופיעות במאמר פריסת Managed OpenTelemetry for GKE.

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

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

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

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

אוסף מנוהל

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

נקודת הקצה של האוסף המנוהל היא: http://opentelemetry-collector.gke-managed-otel.svc.cluster.local:4318.

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

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

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

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

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

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

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

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

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

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

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

במאמר שינוי ההגדרות מוסבר איך משתמשים במשאב בהתאמה אישית Instrumentation.

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

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

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

משתני סביבה

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

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

אלה משתני הסביבה שאפשר להחדיר אוטומטית למאגרי מידע:

  • נקודת הקצה (endpoint) של OpenTelemetry exporter.
    • ‫OTEL_EXPORTER_OTLP_ENDPOINT: כתובת URL בסיסית של נקודת קצה לכל סוג של אות. נקודת הקצה הזו תמיד מצביעה על נקודת הקצה (endpoint) של HTTP של OpenTelemetry Collector לניהול בתוך האשכול עבור יומנים, מדדים ועקבות. נקודת הקצה היא: http://opentelemetry-collector.gke-managed-otel.svc.cluster.local:4318.
  • הגדרת יחס הדגימה של המעקב.
    • ‫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.
  • זיהוי של קבוצות Pod של hostNetwork לצורך שיוך המטא-נתונים באמצעות מעבד המאפיינים של Kubernetes של 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.

הגדרה ידנית

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

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

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

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

עומסי עבודה נתמכים הם עומסי עבודה שמשתמשים ב-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 ל-Prometheus, ראו תמחור של Google Cloud Observability.

מכסות

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

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