סקירה כללית של Google-Built OpenTelemetry Collector

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

‫OpenTelemetry Collector של Google הוא גרסת קוד פתוח של OpenTelemetry Collector, שנבנתה מרכיבי upstream באמצעות שרשרת אספקה מאובטחת בתשתית של Google. ‫OpenTelemetry, שהוא חלק מ-Cloud Native Computing Foundation, מספק ממשקי API, ספריות וערכות SDK בקוד פתוח לאיסוף של עקבות מבוזרים, מדדים ויומנים לצורך מעקב אחר אפליקציות.

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

החל מגרסה 0.134.0, ‏ Google-Built OpenTelemetry Collector מבוסס על התקן Supply-chain Levels for Software Artifacts‏ (SLSA) ברמה 3. הקוד של כלי האיסוף והתלות שלו נסרקים באופן רציף כדי לזהות נקודות חולשה. מידע נוסף זמין במאמר בנושא תכונות אבטחה.

שימוש ב-OpenTelemetry Collector שנוצר על ידי Google

אתם יכולים להשתמש ב-Collector שנוצר על ידי Google כדי לאסוף נתוני טלמטריה מהאפליקציות שלכם שפועלות ב-Kubernetes (כולל Google Kubernetes Engine‏ (GKE)), במערכת הפעלה שמותאמת לקונטיינרים, בקונטיינרים עצמאיים או ישירות בסביבת מארח (כולל Compute Engine). במסמכים שבקטע הזה מוסבר איך להגדיר ולפרוס את כלי האיסוף שנוצר על ידי Google בסביבות הבאות:

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

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

תיאור של OpenTelemetry Collector מבית Google

‫OpenTelemetry Collector מבית Google מבוסס על רכיבים וכלים של OpenTelemetry, אבל הוא נוצר ומאוחזר באופן מלא מתשתית של Google לבנייה, בדיקה ושחרור (Artifact Registry). ה-Collector שפותח על ידי Google תואם ל-OpenTelemetry Collector שנבנה ממאגר המידע שלמעלה. הוא גם מתארח כקובץ אימג' של Docker לפריסה גמישה בכל מערכת מבוססת-קונטיינרים, כולל Kubernetes ו-GKE.

הכלי Collector שפותח על ידי Google מספק חבילה שאוצרה על ידי Google עם הרכיבים שרוב המשתמשים יצטרכו כדי ליהנות מחוויית שימוש עשירה ב- Google Cloud. אתם לא צריכים לבחור רכיבים וליצור אוסף נתונים משלכם באופן ידני. באמצעות כלי האיסוף ש-Google יצרה, אתם יכולים:

  • אוספים מטא-נתונים של Google Cloud משאבים כדי שתוכלו ליצור קורלציה בין נתוני ביצועי האפליקציה לבין נתוני טלמטריה של התשתית.
  • אפשר להשתמש בייצואנים כדי להעביר נתוני טלמטריה אל Google Cloud Observability או אל קצה העורפי שתבחרו, כולל קצוות עורפיים שתומכים באופן מובנה ב-OpenTelemetry.
  • לפשט את תהליך ההצטרפות באמצעות הגדרות מומלצות ושיטות מומלצות לניטור עצמי, כולל בדיקות תקינות ועיבוד ברצף (batch processing).
  • אפשר להשתמש בקובץ אימג' של Docker שמתארח ב-Cloud Build כדי לפרוס את התוסף בצורה גמישה בכל מערכת מבוססת-קונטיינרים, כולל Kubernetes ו-GKE.

שיטות מומלצות

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

שימוש בתוסף לבדיקת תקינות

התוסף לבדיקת תקינות מאפשר להשתמש בכתובת URL מסוג HTTP שאפשר לבדוק כדי לבדוק את הסטטוס של OpenTelemetry Collector. השימוש בתוסף הזה מספק את היתרונות הבאים:

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

ב-Kubernetes וב-GKE, תוסף בדיקת התקינות תואם לבדיקות התקינות (liveness) ולבדיקות המוכנות (readiness) של Kubernetes. מידע על הגדרת הבדיקות האלה זמין במאמר שיטות מומלצות ל-Kubernetes: הגדרת בדיקות תקינות באמצעות בדיקות מוכנות ובדיקות פעילות.

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

שימוש בכלי לעיבוד קבוצתי

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

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

שימוש בספק googlesecretmanager

ספק googlesecretmanager מאפשר לכם לאחסן מידע רגיש שנדרש לקובצי הגדרה ב-Secret Manager, שירות שנועד במיוחד לאחסון, לגישה ולניהול של נתונים רגישים בצורה מאובטחת. השימוש בספק googlesecretmanager מציע את היתרונות הבאים:

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

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

נתוני גרסה

הגרסה של Google-Built OpenTelemetry Collector מסונכרנת עם הגרסה של OpenTelemetry Collector. הגרסה הנוכחית היא v0.143.0. קובץ האימג' של Docker התואם, שמאוחסן ב-Artifact Registry, הוא us-docker.pkg.dev/cloud-ops-agents-artifacts/google-cloud-opentelemetry-collector/otelcol-google:0.143.0. בכל גרסה חדשה, השינויים שהכי רלוונטיים Google Cloud למשתמשים מופיעים בדף הזה.

תכונות אבטחה

החל מגרסה 0.134.0, Google-Built OpenTelemetry Collector מציע קובצי אימג' של Docker שנבנו בהתאם לתקן Supply-chain Levels for Software Artifacts (SLSA) level 3, וכוללים את תכונות האבטחה הבאות:

  • גרסה מאובטחת: צינור ה-CI/CD של OpenTelemetry Collector שנוצר על ידי Google יוצר אישורים לכל גרסה של קובץ אימג' של קונטיינר. האישורים האלה כוללים אישור סיכום אימות (VSA), שמצורף כנכס לכל מהדורה ב-GitHub.

  • סריקה ותיקון של נקודות חולשה: אנחנו סורקים באופן רציף את Google-Built OpenTelemetry Collector כדי לזהות נקודות חולשה, ומשתדלים לפעול בהתאם להסכמי רמת השירות (SLO) של FedRamp לתיקון נקודות חולשה. אנחנו נותנים עדיפות לאבטחת המשתמשים, ולכן אנחנו בונים מחדש את הכלי לאיסוף נתונים באופן קבוע עם תלות מעודכנת בחבילות. צינור ה-CI/CD שלנו מתוכנן לשילוב מהיר של תיקוני אבטחה קריטיים ועדכוני תלות. המחויבות הזו מצמצמת את החשיפה לנקודות חולשה ידועות, ומספקת לכם מוצר מאובטח ועדכני באופן רציף.

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

יכולת תמיכה

לכל הבעיות בצד הלקוח ב-Google-Built OpenTelemetry Collector, כולל בקשות להוספת תכונות, דיווחים על באגים ושאלות כלליות, אפשר לפתוח issue במאגר GitHub המתאים. ‫Google עוקבת אחרי המאגרים האלה, ומטפלת בבעיות על בסיס האפשרות הטובה ביותר.

  • מאגר חבילות של OpenTelemetry Collector שנוצר על ידי Google, לבעיות שקשורות לנושאים הבאים:

    • אריזה
    • פריסה ב- Google Cloud
    • אימות בתוך Google Cloud
    • בקשות להוספה של רכיבי OpenTelemetry חדשים

  • מאגר OpenTelemetry Collector Contrib, לבעיות שקשורות לנושאים הבאים:

    • רכיבי OpenTelemetry ספציפיים ל-Google, לדוגמה:
      • googlecloudexporter
      • googlemanagedprometheusexporter
      • googleclientauthextension
      • resourcedetectionprocessor
    • רכיבי OpenTelemetry שלא ספציפיים ל-Google ומנוהלים על ידי קהילת המקור

אם נתקלתם בבעיות שקשורות לשימוש ב-Google Cloud Observability API ובשירותים של Google-Built OpenTelemetry Collector, כמו שגיאות שרת או מכסות, אתם יכולים לפנות אל Cloud Customer Care.

תמחור

אין עלות על פריסה ושימוש ב-OpenTelemetry Collector שנוצר על ידי Google.

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

התנסות בהדגמה של OpenTelemetry

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

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

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

הדמו של OpenTelemetry דורש אשכול Kubernetes עם הגדרה של איחוד שירותי אימות הזהות של עומסי עבודה. מידע על הגדרת Workload Identity Federation עבור הדמו של OpenTelemetry זמין במאמר דרישות מוקדמות ל-Workload Identity.

עדכון ההדגמה לשימוש ב-Collector שנוצר על ידי Google

כברירת מחדל, ההדגמה של OpenTelemetry משתמשת ב-OpenTelemetry Collector במעלה הזרם. כדי להשתמש ב-Google-Built OpenTelemetry Collector במקום זאת, מבצעים את הפעולות הבאות:

  1. משכפלים את מאגר ההדגמה של OpenTelemetry:

    git clone https://github.com/GoogleCloudPlatform/opentelemetry-demo.git

  2. עוברים לספרייה kubernetes.

    cd kubernetes

  3. עורכים את הקובץ opentelemetry-demo.yaml כדי להחליף את השורה של תמונת הכלי לאיסוף נתונים שבה רוצים להשתמש. השורה אמורה להיראות כך, אבל יכול להיות שהגרסה תהיה שונה:

    image: "otel/opentelemetry-collector-contrib:0.108.0"

    מחליפים את הערך של השדה image: בערך us-docker.pkg.dev/cloud-ops-agents-artifacts/google-cloud-opentelemetry-collector/otelcol-google:0.143.0, כך שהשורה תיראה כמו השורה הבאה, ואז שומרים את הקובץ:

    image: "us-docker.pkg.dev/cloud-ops-agents-artifacts/google-cloud-opentelemetry-collector/otelcol-google:0.143.0"

פריסת ההדגמה

מבצעים פריסה של ההדגמה על ידי החלת הקובץ המעודכן opentelemetry-demo.yaml:

kubectl apply --namespace otel-demo -f opentelemetry-demo.yaml

התחברות להדגמה

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

kubectl port-forward --n otel-demo svc/opentelemetry-demo-frontendproxy 8080:8080

אחרי כן תוכלו להשתמש בדפדפן כדי להתחבר להדגמה בכתובת localhost:8080.

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

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

הצגת המדדים

‫Google-Built OpenTelemetry Collector אוסף מדדי Prometheus שאפשר לראות באמצעות Metrics Explorer. המדדים שנאספים תלויים באינסטרומנטציה של האפליקציה, למרות שכלי האיסוף ש-Google בנתה גם כותב כמה מדדים עצמיים.

כדי לראות את המדדים שנאספים על ידי Google-Built OpenTelemetry Collector:

  1. במסוף Google Cloud , עוברים לדף  Metrics explorer:

    כניסה אל Metrics Explorer

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

  2. בסרגל הכלים של מסוף Google Cloud , בוחרים את Google Cloud הפרויקט. בהגדרות של App Hub, בוחרים את פרויקט המארח של App Hub או את פרויקט הניהול של התיקייה לניהול אפליקציות.
  3. ברכיב Metric, מרחיבים את התפריט Select a metric, כותבים Prometheus Target בשורת הסינון ומשתמשים בתפריטי המשנה כדי לבחור סוג ספציפי של משאב ומדד:
    1. בתפריט Active resources בוחרים באפשרות Prometheus Target.
    2. כדי לבחור מדד, משתמשים בתפריטים Active metric categories ו-Active metrics. למדדים שנאספים על ידי Google-Built OpenTelemetry Collector יש את הקידומת prometheus.googleapis.com.
    3. לוחצים על אישור.

  4. כדי להוסיף מסננים שמסירים סדרות זמן מתוצאות השאילתה, משתמשים ברכיב Filter.

  5. מגדירים את אופן התצוגה של הנתונים.

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

    כשמודדים ערכים מסוג integer או double, כמו במדדים מסוג counter, הכלי Metrics Explorer מסכם באופן אוטומטי את כל סדרות הזמנים. כדי לשנות את ההתנהגות הזו, מגדירים את התפריט הראשון של הרשומה Aggregation (צבירה) לערך None (ללא).

    מידע נוסף על הגדרת תרשים זמין במאמר איך בוחרים מדדים כשמשתמשים ב-Metrics Explorer.

הצגת העקבות

כדי לראות את נתוני העקבות:

  1. נכנסים לדף Trace explorer במסוף Google Cloud :

    כניסה אל Trace explorer

    אפשר גם להשתמש בסרגל החיפוש כדי למצוא את הדף הזה.

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

  4. בתרשים גאנט בחלונית Trace details, בוחרים טווח.

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

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

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

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

הצגת רישומי היומן

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

  1. במסוף Google Cloud , נכנסים לדף Logs Explorer:

    כניסה אל Logs Explorer

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

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

  3. לוחצים על Traces ברשומה ביומן עם הודעת מעקב, ואז בוחרים באפשרות View trace details.

    נפתחת חלונית Trace details ומוצג בה ה-Trace שנבחר.

מידע נוסף על השימוש ב-Logs Explorer זמין במאמר הצגת יומנים באמצעות Logs Explorer.