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

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

בעזרת Google-Built OpenTelemetry Collector אתם יכולים לשלוח נתוני מעקב, מדדים ויומנים של OTLP שתואמים ל-Google Cloud Observability ולרכיבי backend אחרים מאפליקציות שמשתמשות ב-OpenTelemetry SDKs. ה-Collector גם מתעד מטא-נתונים של משאבי 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) level 3. הקוד של ה-collector והתלויות שלו נסרקים כל הזמן כדי לאתר נקודות חולשה. מידע נוסף זמין במאמר אמצעי אבטחה.

שימוש ב-OpenTelemetry Collector שפותח על ידי Google

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

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

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

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

תיאור של Google-Built OpenTelemetry Collector

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

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

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

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

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

שימוש ב-OTLP gRPC exporter

משתמשים ב-OTLP gRPC כדי להתחבר ל-Telemetry (OTLP) API, ‏telemetry.googleapis.com. ‫Telemetry API מקבל את כל נתוני הטלמטריה – יומנים, מדדים ומעקבים – בפורמט OTLP שלא תלוי בספק. שליחת נתוני טלמטריה ל-Telemetry API פירושה שהנתונים שזורמים מ-OpenTelemetry Collector נשמרים ברמת הדיוק המקסימלית באחסון של Google Cloud .

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

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

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

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

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

שימוש במעבד האצווה

מעבד עיבוד ברצף אוסף נתוני מעקב, מדדים או יומנים ומקבץ אותם לקבוצות (batches) כדי לשלוח אותם. היתרונות של שימוש במעבד האצווה:

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

שימוש בספק googlesecretmanager

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

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

למידע על השימוש בספק הזה, ראו ניהול סודות בהגדרות של Collector.

נתוני גרסה

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

אמצעי האבטחה

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

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

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

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

תמיכה

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

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

    • אריזה
    • פריסה ב- Google Cloud
    • אימות בתוך Google Cloud
    • בקשות להוספת רכיבי OpenTelemetry חדשים
  • מאגר OpenTelemetry Collector Contrib, לבעיות שקשורות לנושאים הבאים:

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

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

תמחור

אין חיוב על פריסה ושימוש ב-Google-Built OpenTelemetry Collector.

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

הדגמה של OpenTelemetry

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

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

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

כדי להשתמש בהדגמה של OpenTelemetry, צריך אשכול Kubernetes שמוגדר בו איחוד שירותי אימות הזהות של עומסי עבודה. במאמר שימוש באיחוד זהויות של עומסי עבודה ל-GKE מוסבר איך מגדירים את איחוד הזהויות של עומסי העבודה באשכול.

עדכון ההדגמה לשימוש ב-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 כדי להחליף את השורה של קובץ האימג' של Collector שבו רוצים להשתמש. השורה נראית כך, אבל יכול להיות שהגרסה תהיה שונה:

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

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

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

פריסת ההדגמה

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

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

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

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

הצגת המעקבים

כדי להציג את נתוני המעקב:

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

    כניסה לדף Trace Explorer

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

  2. בסרגל הכלים של מסוף Google Cloud , בוחרים את הפרויקט ב- Google Cloud . בהגדרות של App Hub, בוחרים את הפרויקט המארח או את פרויקט הניהול של App Hub.
  3. בקטע של הטבלה בדף, בוחרים שורה.
  4. בתרשים הגאנט שבחלונית Trace details, בוחרים span.

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

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

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

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

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

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

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

    נכנסים לדף Logs Explorer.

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

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

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

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

למידע נוסף על השימוש ב-Logs Explorer, קראו את המאמר הצגת יומנים באמצעות הכלי "מציג היומנים".