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

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

בעזרת Google-Built OpenTelemetry Collector אתם יכולים לשלוח נתוני מעקב, מדדים ויומנים של OTLP מקושרים אל Google Cloud Observability ורכיבי backend אחרים מאפליקציות שכוללות ערכות OpenTelemetry SDK. ה-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)‎ ברמה 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.

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

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

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

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

שימוש בספק googlesecretmanager

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

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

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

נתוני גרסה

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

אמצעי האבטחה

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

  • פיתוח מאובטח: צינור עיבוד הנתונים של 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 Observability מפורטות העלויות שקשורות להטמעת נתוני מעקב, יומנים ומדדים של השירות המנוהל של Google Cloud ל-Prometheus.

הדגמה של OpenTelemetry

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

הקטע הזה הוא אופציונלי. אם אתם מוכנים לשלב את 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.164.0, כך שהשורה תיראה כמו בדוגמה הבאה, ואז שומרים את הקובץ:

    image: "us-docker.pkg.dev/cloud-ops-agents-artifacts/google-cloud-opentelemetry-collector/otelcol-google:0.164.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. המדדים שנאספים תלויים במכשור של האפליקציה, אבל ה-Collector שנוצר על ידי Google כותב גם כמה מדדים עצמיים.

כדי לראות את המדדים שנאספו על ידי Google-Built OpenTelemetry Collector:
  1. נכנסים לדף  Metrics explorer במסוף Google Cloud :

    כניסה לדף 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, קראו את המאמר הצגת יומנים באמצעות Logs Explorer.