איסוף מדדים ועקבות של OpenTelemetry Protocol‏ (OTLP)

במאמר הזה מוסבר איך להשתמש בסוכן תפעול ובמקלט OpenTelemetry Protocol ‏(OTLP) כדי לאסוף מדדים ועקבות שהוגדרו על ידי המשתמשים מאפליקציות שמוטמעות באמצעות OpenTelemetry ופועלות ב-Compute Engine.

המסמך הזה מחולק לנושאים הבאים:

סקירה כללית שמתארת את תרחישי השימוש ב-OTLP receiver.
דרישות מוקדמות לשימוש ב-OTLP receiver.
הגדרת הסוכן לשימוש במקלט OTLP.
שימוש ברכיב המקבל כדי לאסוף מדדים. בקטע הזה מוסבר איך לשלוח שאילתות על מדדי OpenTelemetry ב-Cloud Monitoring.
שימוש במקלט כדי לאסוף עקבות. בקטע הזה מוסבר איך לתת לחשבון שירות הרשאה לכתוב נתונים ל-Cloud Trace.

סקירה כללית על השימוש ב-OTLP receiver

בעזרת רכיב ה-OTLP receiver של סוכן תפעול, אפשר:

כדי להוסיף לאפליקציה מכשור, אפשר להשתמש באחת מגרסאות ה-SDK הספציפיות לשפה של OpenTelemetry. מידע על השפות הנתמכות מופיע במאמר OpenTelemetry Instrumentation. השילוב של ערכות OpenTelemetry SDK ו-סוכן תפעול מאפשר לכם לבצע את הפעולות הבאות:
- אוספים מדדי OTLP מהאפליקציה ושולחים אותם לניתוח ב-Cloud Monitoring.
- אוספים טווחים של OTLP – נתוני מעקב – מהאפליקציה ואז שולחים את הטווחים האלה ל-Cloud Trace לצורך ניתוח.
איסוף עקבות מאפליקציות של צד שלישי שיש להן תמיכה מובנית ב-OTLP או בפלאגינים עם תמיכה כזו, כמו אפליקציות Nginx. ה-OTLP receiver בסוכן תפעול יכול לאסוף את העקבות האלה. לדוגמה, אפשר לעיין במאמר בנושא מודול OpenTelemetry nginx.
משתמשים במכשור מותאם אישית של OpenTelemetry.
משתמשים באינסטרומנטציה אוטומטית של OpenTelemetry.

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

יתרונות

לפני שהתוסף OTLP ל-Ops Agent היה זמין, הדרכים העיקריות להטמעת אינסטרומנטציה באפליקציות כדי לאסוף מדדים ועקבות שהוגדרו על ידי המשתמשים כללו את האפשרויות הבאות:

שימוש בספריות לקוח שמטמיעות את Monitoring API או את Trace API.
שימוש בספריות הישנות יותר של OpenCensus.

לשימוש ב-OpenTelemetry עם מקלט OTLP יש כמה יתרונות בהשוואה לשיטות האלה, כולל:

‫OpenTelemetry הוא התחליף ל-OpenCensus. פרויקט OpenCensus עובר לארכיון. מידע נוסף זמין במאמר מה זה OpenTelemetry?.
ההטמעה נשלטת ברמת הסוכן, כך שלא צריך לפרוס מחדש את האפליקציות אם יש שינויים בהגדרות הסוכן.
אין צורך להגדיר פרטי כניסה באפליקציות שלכם. כל ההרשאות מנוהלות ברמת הסוכן. Google Cloud
קוד האפליקציה שלך לא מכיל קוד ספציפי לניטור Google Cloudאו למעקב. לא חייבים להשתמש ישירות ב-Monitoring API או ב-Trace API.
האפליקציה שלכם דוחפת נתונים אל Ops Agent, ואם האפליקציה קורסת, הנתונים שנאספו על ידי Ops Agent לא אובדים.

מגבלות

מאזין OTLP שנחשף על ידי מקלט סוכן תפעול תומך בתעבורת gRPC. פרוטוקול HTTP, שמשמש בעיקר לקוחות JavaScript, לא נתמך. מידע נוסף על פרוטוקול OpenTelemetry זמין במאמר פרטי הפרוטוקול.

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

דרישות מוקדמות

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

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

הגדרת סוכן התפעול

כדי להגדיר את סוכן התפעול לשימוש ב-OTLP receiver:

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

בקטעים הבאים מפורט כל שלב.

שינוי קובץ הגדרות המשתמש של סוכן תפעול

מוסיפים את רכיבי ההגדרה של מקלט OTLP לקובץ הגדרת המשתמש של סוכן תפעול:

ב-Linux: /etc/google-cloud-ops-agent/config.yaml
ב-Windows: ‏ C:\Program Files\Google\Cloud Operations\Ops Agent\config\config.yaml

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

מקלט OTLP מציג את קטע ההגדרות combined של סוכן התפעול. כדי להשתמש ב-receiver, צריך להגדיר שירותים למדדים ולעקבות, גם אם לא משתמשים בשניהם.

בקטעים הבאים מוסבר איך מגדירים את מקלט OTLP.

הוספת הקטע `combined` receiver

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

ההגדרה המינימלית של combined ל-OTLP נראית כך:

combined:
  receivers:
    otlp:
      type: otlp

למקלט otlp יש את אפשרויות ההגדרה הבאות:

‫type: חובה. חייב להיות otlp
‫grpc_endpoint: אופציונלי. נקודת הקצה של gRPC שבה רשימת המקבלים של OTLP מאזינה. ברירת המחדל היא 0.0.0.0:4317.
‫metrics_mode: אופציונלי. ברירת המחדל היא googlemanagedprometheus, כלומר המקלט שולח מדדי OTLP כמדדים בפורמט Prometheus באמצעות Prometheus API, שמשמש גם את שירות מנוהל ל-Prometheus.

כדי לשלוח את המדדים כמדדים מותאמים אישית של Cloud Monitoring באמצעות Monitoring API, צריך להגדיר את האפשרות metrics_mode לערך googlecloudmonitoring.

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

הוספת צינורות OTLP לשירותים

רכיב ה-OTLP receiver יכול לאסוף מדדים ונתוני מעקב, ולכן צריך להגדיר שירות למדדים ושירות לנתוני מעקב. אם אתם לא מתכוונים לאסוף מדדים או עקבות, אתם יכולים ליצור שירותים ריקים. אם כבר יש לכם שירותים עם צינורות אחרים, אתם יכולים להוסיף להם את צינור OTLP.

בתרשים הבא מוצגים השירותים metrics ו-traces עם רכיב ה-OTLP receiver שכלול בצינורות:

combined:
  receivers:
    otlp:
      type: otlp
metrics:
  service:
    pipelines:
      otlp:
        receivers: [otlp]
traces:
  service:
    pipelines:
      otlp:
        receivers: [otlp]

אם אתם לא רוצים להשתמש בשירות metrics או בשירות traces לאיסוף נתונים ב-OTLP, אל תכללו את מקלט ה-OTLP בצינור הנתונים של השירות. השירות חייב להתקיים, גם אם אין לו צינורות. אם האפליקציה שולחת נתונים מסוג מסוים ואין צינור נתונים תואם שכולל את הרכיב receiver, סוכן תפעול משליך את הנתונים.

הפעלה מחדש של סוכן התפעול

כדי להחיל את שינויי ההגדרות, צריך להפעיל מחדש את סוכן התפעול.

Linux

כדי להפעיל מחדש את הסוכן, מריצים את הפקודה הבאה במופע:
```
sudo systemctl restart google-cloud-ops-agent
```
כדי לוודא שהסוכן הופעל מחדש, מריצים את הפקודה הבאה ומוודאים שהרכיבים Metrics Agent ו-Logging Agent הופעלו:
```
sudo systemctl status "google-cloud-ops-agent*"
```

Windows

מתחברים למופע באמצעות RDP או כלי דומה ומתחברים ל-Windows.
פותחים טרמינל ב-PowerShell עם הרשאות אדמין על ידי לחיצה ימנית על סמל PowerShell ובחירה באפשרות הפעלה כמנהל מערכת.
כדי להפעיל מחדש את הסוכן, מריצים את פקודת PowerShell הבאה:
```
Restart-Service google-cloud-ops-agent -Force
```
כדי לוודא שהסוכן הופעל מחדש, מריצים את הפקודה הבאה ומוודאים שהרכיבים Metrics Agent ו-Logging Agent הופעלו:
```
Get-Service google-cloud-ops-agent*
```

איסוף מדדים של OTLP

כשמשתמשים ב-OTLP receiver כדי לאסוף מדדים מהאפליקציות של OpenTelemetry, הבחירה העיקרית בהגדרות של ה-receiver היא ה-API שרוצים להשתמש בו כדי להעביר את המדדים.

כדי לבחור באפשרות הזו, צריך לשנות את האפשרות metrics_mode בהגדרה של מקבל otlp או להשתמש בערך ברירת המחדל. הבחירה משפיעה על האופן שבו המדדים של OTLP מוזנים ל-Cloud Monitoring ועל האופן שבו הנתונים האלה נמדדים למטרות חיוב.

הבחירה באפשרות metrics_mode לא משפיעה על היכולת שלכם ליצור תרשימים, לוחות בקרה ומדיניות התראות ב-Monitoring.

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

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

פורמטים של נתונים שנכנסים למערכת עבור מדדים של OTLP

רכיב ה-OTLP receiver מספק את האפשרות metrics_mode, שבה מציינים את ה-API שמשמש להעברה של נתוני המדדים. כברירת מחדל, המקבל משתמש ב-Prometheus API. ערך ברירת המחדל של האפשרות metrics_mode הוא googlemanagedprometheus. המדדים מוזנים באמצעות אותו API שבו נעשה שימוש בשירות המנוהל ל-Prometheus.

אפשר להגדיר את המקלט כך שישלח את נתוני המדדים אל Cloud Monitoring API. כדי לשלוח נתונים ל-Monitoring API, צריך להגדיר את הערך של האפשרות metrics_mode ל-googlecloudmonitoring, כמו בדוגמה הבאה:

combined:
  receivers:
    otlp:
      type: otlp
      metrics_mode: googlecloudmonitoring

פורמט ההטמעה שבו אתם משתמשים קובע איך מדדי OTLP ממופים ל-Cloud Monitoring. אפשר ליצור תרשימים, לוחות בקרה ומדיניות התראות ב-Monitoring למדדים בכל אחד מפורמטי המדדים, אבל צריך להתייחס למדדים בצורה שונה בשאילתות.

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

בקטעים הבאים מתוארים התמחור, ההבדלים המבניים בין מדד שנקלט על ידי Prometheus API לבין אותו מדד שנקלט על ידי Monitoring API, ואיך מתייחסים למדדים בשאילתות.

תמחור ומכסה

פורמט ההטמעה שבו אתם משתמשים קובע איך יחויבו מדדי OTLP:

‫Prometheus API: כשמשתמשים ב-Prometheus API כדי להטמיע את מדדי האפליקציה, הנתונים כפופים לתמחור מבוסס-דגימה, כאילו המדדים הגיעו באמצעות שירות מנוהל ל-Prometheus.
Monitoring API: כשמשתמשים ב-Monitoring API כדי להטמיע את המדדים של האפליקציה, הנתונים כפופים לתמחור לפי נפח, כמו נתונים משילובים אחרים עם סוכן תפעול.

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

במחירון של Google Cloud Observability תוכלו לעיין ברשימת המחירים העדכניים.

מבנה המדד

ב-Cloud Monitoring, פורמט נתוני המדדים מתואר באמצעות סכימה שנקראת תיאור מדד. תיאור המדד כולל את שם המדד, סוג הנתונים של ערכי המדד, הקשר בין כל ערך לערכים הקודמים ותוויות שמשויכות לערכים. אם מגדירים את מקלט ה-OTLP להטמעת מדדים באמצעות Prometheus API, תיאור המדד שנוצר שונה מתיאור המדד שנוצר כשמשתמשים ב-Monitoring API.

‫Prometheus API: כשמשתמשים ב-Prometheus API כדי להטמיע את המדדים של האפליקציה, כל מדד עובר טרנספורמציה באמצעות OpenTelemetry-to-Prometheus transformation הסטנדרטית וממופה לסוג של משאב במעקב ב-Cloud Monitoring.

השינויים שכלולים בהמרה:
- לשם המדד ב-OTLP מתווספת הקידומת prometheus.googleapis.com/.
- כל התווים שאינם אלפאנומריים, כמו נקודות (.), בשם המדד של OTLP מוחלפים בקווים תחתונים (_).
- שם המדד ב-OTLP מסתיים במחרוזת שמציינת את סוג המדד, כמו /gauge או /counter.
התוויות הבאות, שאוכלסו בערכים מתוך משאב OTLP, מתווספות למדד:
- ‫instance_name: הערך של מאפיין המשאב host.name.
- ‫machine_type: הערך של מאפיין המשאב host.type.
המשאב במעקב שתועד עם מדידות המדדים הוא מסוג prometheus_target. סדרת הזמן של Prometheus שנוצרת כוללת את התוויות הבאות של המשאב prometheus_target, שאוכלסו בערכים מהמשאב OTLP:
- ‫location: הערך של מאפיין המשאב cloud.availability_zone.
- ‫namespace: הערך של מאפיין המשאב host.id.
סוג המשאב prometheus_target כולל גם את התוויות האלה:
- ‫project_id: המזהה של הפרויקט, כמו my-project, שבו פועל סוכן התפעול. Google Cloud
- ‫cluster: הערך הוא תמיד __gce__ כשסוכן התפעול אוסף מדדים.

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

‫Monitoring API: כשמשתמשים ב-Monitoring API כדי להטמיע את המדדים של האפליקציה, כל מדד מטופל באופן הבא:

שם המדד של OTLP מתחיל בקידומת המחרוזת workload.googleapis.com/, אלא אם שם המדד של OTLP כבר מכיל את המחרוזת הזו או דומיין מדד תקין אחר, כמו custom.googleapis.com. מומלץ להשתמש בדומיין 'עומס עבודה'.
המשאב במעקב שנרשם עם המדדים הוא סוג המכונה הווירטואלית של Compute Engine‏ gce_instance.

בדוגמאות הבאות מוצגים מתארי המדדים של צמד מדדים של OpenTelemetry. המדדים נוצרים על ידי אפליקציה שמשתמשת בספריית המדדים של Go OpenTelemetry. בכרטיסייה Prometheus API מוצג תיאור המדד שנוצר כשמקלט OTLP משתמש במצב ברירת המחדל של מדדי Prometheus. בכרטיסייה Monitoring API מוצג תיאור המדד שנוצר כשמקלט OTLP משתמש במצב המדד googlecloudmonitoring.

לא חל שינוי באפליקציה שיוצרת את המדד. השינוי היחיד הוא מצב המדד שבו נעשה שימוש על ידי מקלט OTLP.

האפליקציה יוצרת מדד מסוג OTLP gauge, ‏ otlp.test.gauge, שמתעד ערכים של נקודה צפה (floating-point) בגודל 64 ביט. בכרטיסיות הבאות מוצג תיאור המדד שנוצר על ידי כל API להעברת נתונים:

Prometheus API

{
  "name": "projects/PROJECT_ID/metricDescriptors/prometheus.googleapis.com/otlp_test_gauge/gauge",
  "labels": [
    {
      "key": "instance_name"
    },
    {
      "key": "machine_type"
    }
  ],
  "metricKind": "GAUGE",
  "valueType": "DOUBLE",
  "type": "prometheus.googleapis.com/otlp_test_gauge/gauge",
  "monitoredResourceTypes": [
    "prometheus_target"
  ]
}

Monitoring API

{
  "name": "projects/PROJECT_ID/metricDescriptors/workload.googleapis.com/otlp.test.gauge",
  "labels": [
    {
      "key": "instrumentation_source"
    }
  ],
  "metricKind": "GAUGE",
  "valueType": "DOUBLE",
  "type": "workload.googleapis.com/otlp.test.gauge",
  "monitoredResourceTypes": [
    "gce_instance",
    ...many other types deleted...
  ]
}

האפליקציה יוצרת מדד נגדי OTLP, ‏ otlp.test.cumulative, שתועדים בו ערכי נקודה צפה של 64 ביט שעולים. בכרטיסיות הבאות מוצג תיאור המדד שנוצר על ידי כל API להעברת נתונים:

Prometheus API

{
  "name": "projects/PROJECT_ID/metricDescriptors/prometheus.googleapis.com/otlp_test_cumulative/counter",
  "labels": [
    {
      "key": "instance_name"
    },
    {
      "key": "machine_type"
    }
  ],
  "metricKind": "CUMULATIVE",
  "valueType": "DOUBLE",
  "type": "prometheus.googleapis.com/otlp_test_cumulative/counter",
  "monitoredResourceTypes": [
    "prometheus_target"
  ]
}

Monitoring API

{
  "name": "projects/PROJECT_ID/metricDescriptors/workload.googleapis.com/otlp.test.cumulative",
  "labels": [
    {
      "key": "instrumentation_source"
    }
  ],
  "metricKind": "CUMULATIVE",
  "valueType": "DOUBLE",
  "type": "workload.googleapis.com/otlp.test.cumulative",
  "monitoredResourceTypes": [
    "gce_instance",
    ...many other types deleted...
  ]
}

בטבלה הבאה מפורטים כמה מההבדלים בפורמט שנובעים מממשקי ה-API שמשמשים להעברת מדדים בפורמט OTLP:

	Prometheus API	Monitoring API
דומיין המדד	`prometheus.googleapis.com`	`workload.googleapis.com`
שם המדד ב-OTLP	שונה במהלך הטמעת הנתונים	השימוש בהם נעשה כמו שהם
משאב במעקב	`prometheus_target`	`gce_instance`

פורמטים של נתונים ושאילתות

מצב המדדים שבו נעשה שימוש ב-OTLP receiver משפיע על האופן שבו מבצעים שאילתות על המדדים שמתקבלים ב-Cloud Monitoring כשיוצרים תרשימים, מרכזי בקרה ומדיניות התראות.

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

אלה הכלים שנתמכים ב-Cloud Monitoring לשליחת שאילתות לגבי נתוני מדדים:

ממשק ליצירת שאילתות שמוטמע בכלים כמו Metrics Explorer, הממשק ליצירת לוחות בקרה והממשק להגדרת מדיניות התראות.
שפת השאילתות של Prometheus‏ (PromQL): שפת השאילתות מבוססת-הטקסט שבה נעשה שימוש ב-Prometheus בקוד פתוח.

למידע על שליחת שאילתות למדדי OTLP באמצעות הכלים האלה, אפשר לעיין במאמרים הבאים:

שאילתת מדדי OTLP שנקלטים באמצעות Prometheus API
שאילתת מדדי OTLP שהועברו באמצעות Monitoring API

שליחת שאילתות על מדדי OTLP שהועברו באמצעות Prometheus API

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

השאילתות מבוססות על מדדי OTLP שמתוארים במבנה המדדים:

‫otlp.test.gauge: מדד OTLP מסוג gauge שמתעד ערכים של נקודה צפה (floating-point) בגודל 64 ביט.
‫otlp.test.cumlative: מדד OTLP מסוג counter שמתעד ערכי נקודה צפה של 64 ביט שעולים.

המדדים האלה מוזנים ל-Cloud Monitoring עם סוגי המדדים הבאים, שמשמשים כשמות:

prometheus.googleapis.com/otlp_test_gauge/gauge
prometheus.googleapis.com/otlp_test_cumulative/counter

מדדים שמועברים באמצעות Prometheus API נכתבים לפי סוג המשאב המנוטר prometheus_target.

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

הממשק של הכלי ליצירת שאילתות

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

אם מזינים 'prometheus' בשדה החיפוש, התוצאות כוללות את המשאב המנוטר prometheus_target, שמוצג לפי השם לתצוגה 'Prometheus Target', ואת קבוצת המדדים שנכתבים למשאב. המדדים מסווגים לפי שם. שני המדדים לדוגמה מופיעים בקטגוריה Otlp. אפשר לבחור באפשרות Prometheus/otlp_test_cumulative/counter או באפשרות Prometheus/otlp_test_gauge/gauge.

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

בצילום המסך הבא אפשר לראות את התוצאה של שאילתה לגבי המדד prometheus.googleapis.com/otlp_test_gauge/gauge:

תרשים ב-Metrics Explorer שמבוסס על Builder ומציג את מדד המדד OTLP שנבלע באמצעות Prometheus API.

בצילום המסך הבא אפשר לראות את התוצאה של שאילתה לגבי המדד prometheus.googleapis.com/otlp_test_cumulative/counter:

תרשים ב-Metrics Explorer שמבוסס על Builder למדד OTLP counter שנבלע באמצעות Prometheus API.

PromQL

כשמשתמשים ב-PromQL כדי לשלוח שאילתות על נתוני מדדים שנקלטו באמצעות Prometheus API, צריך לציין רק את הצורה המעודכנת של שם המדד המקורי ב-OTLP. אין צורך לציין את המחרוזת prometheus.googleapis.com/ עם הקידומת או את הסוג עם הסיומת.

אם אפשר לכתוב את המדד רק מול סוג אחד של משאב במעקב, לא צריך לציין את המשאב. כפי שמתואר במבנה המדדים, מדדי OTLP שנקלטים באמצעות Prometheus API נכתבים רק מול סוג המשאב המפוקח prometheus_target. שאילתות PromQL פשוטות למדדים לדוגמה נראות כך:

otlp_test_gauge
otlp_test_cumulative

מידע נוסף על שימוש ב-PromQL ב-Cloud Monitoring כדי לשלוח שאילתות על מדדים שנקלטים באמצעות Prometheus API זמין במאמר נתונים של השירות המנוהל של Google Cloud ל-Prometheus ב-Cloud Monitoring. מידע על שפת PromQL זמין במאמר בנושא שליחת שאילתות ל-Prometheus.

בצילום המסך הבא אפשר לראות את התוצאה של שאילתה לגבי המדד prometheus.googleapis.com/otlp_test_gauge/gauge:

תרשים ב-Metrics Explorer של PromQL למדד המדד OTLP שנאסף באמצעות Prometheus API.

בצילום המסך הבא אפשר לראות את התוצאה של שאילתה לגבי המדד prometheus.googleapis.com/otlp_test_cumulative/counter:

תרשים ב-Metrics Explorer של PromQL למדד הדלפק OTLP שנקלט באמצעות Prometheus API.

שליחת שאילתות על מדדי OTLP שנקלטים באמצעות Monitoring API

בקטע הזה מוסבר איך לשלוח שאילתות על מדדי OTLP שנקלטים באמצעות Monitoring API. כדי לבחור את Cloud Monitoring API, מגדירים את השדה metrics_mode של מקלט OTLP לערך googlecloudmonitoring.

השאילתות מבוססות על מדדי OTLP שמתוארים במבנה המדדים:

‫otlp.test.gauge: מדד OTLP מסוג gauge שמתעד ערכים של נקודה צפה (floating-point) בגודל 64 ביט.
‫otlp.test.cumlative: מדד OTLP מסוג counter שמתעד ערכי נקודה צפה של 64 ביט שעולים.

המדדים האלה מוזנים ל-Cloud Monitoring עם סוגי המדדים הבאים, שמשמשים כשמות:

workload.googleapis.com/otlp.test.gauge
workload.googleapis.com/otlp.test.cumulative

מדדים שמועברים באמצעות Monitoring API נכתבים מול סוג המשאב במעקב gce_instance.

הממשק של הכלי ליצירת שאילתות

אם מזינים 'gce_instance' בשדה החיפוש, בתוצאות מוצג סוג המשאב לפי השם המוצג שלו, 'VM Instance', וקבוצת המדדים שנכתבים למשאב. המדדים מסווגים לפי שם. שני המדדים לדוגמה מופיעים בקטגוריה Otlp. אפשר לבחור באפשרות Workload/otlp_test_cumulative או Workload/otlp_test_gauge.

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

בצילום המסך הבא אפשר לראות את התוצאה של שאילתה לגבי המדד workload.googleapis.com/otlp.test.gauge:

תרשים ב-Metrics Explorer שמבוסס על Builder למדד OTLP gauge שנבלע באמצעות Monitoring API.

בצילום המסך הבא אפשר לראות את התוצאה של שאילתה לגבי המדד workload.googleapis.com/otlp.test.cumulative:

תרשים ב-Metrics Explorer שמבוסס על כלי ה-Builder למדד ה-counter של OTLP שנקלט באמצעות Monitoring API.

PromQL

כשמשתמשים ב-PromQL כדי לשלוח שאילתות על נתונים של מדדים שנקלטו באמצעות Monitoring API, צריך למפות את שם המדד למוסכמות של PromQL. כללי המיפוי הבסיסיים כוללים את הפעולות הבאות:

מחליפים את / הראשון ב-:.
מחליפים את כל התווים המיוחדים האחרים (כולל . ותווים אחרים של / ) ב-_.

מידע נוסף על כללי המיפוי זמין במאמר מיפוי מדדים של Cloud Monitoring ל-PromQL.

סוגי המדדים של Monitoring בדוגמאות ממופים ל-PromQL באופן הבא:

workload_googleapis_com:otlp_test_gauge
workload_googleapis_com:otlp_test_cumulative

אם אפשר לכתוב את המדד רק מול סוג אחד של משאב במעקב, לא צריך לציין את המשאב. המדדים לדוגמה נכתבים ביחס לסוג המשאב המנוטר gce_instance, אבל כמו שמתואר במאמר מבנה המדדים, ‏gce_instance הוא רק אחד מסוגי המדדים האפשריים. לכן, שאילתות PromQL עבור המדדים האלה חייבות לכלול מסנן לסוג המשאב gce_instance. כדי לכלול את המסנן, מוסיפים את המחרוזת הבאה לסוף השמות של המדדים הממופים: {monitored_resource="gce_instance"}

מידע נוסף על השימוש ב-PromQL ב-Cloud Monitoring זמין במאמר PromQL ב-Cloud Monitoring. מידע על שפת PromQL זמין במאמר שליחת שאילתות ל-Prometheus.

שאילתות PromQL פשוטות למדדים לדוגמה נראות כך:

workload_googleapis_com:otlp_test_gauge{monitored_resource="gce_instance"}
workload_googleapis_com:otlp_test_cumulative{monitored_resource="gce_instance"}

בצילום המסך הבא אפשר לראות את התוצאה של שאילתה לגבי המדד workload.googleapis.com/otlp.test.gauge:

תרשים ב-Metrics Explorer של מדד מדד OTLP שנבלע באמצעות Monitoring API.

בצילום המסך הבא אפשר לראות את התוצאה של שאילתה לגבי המדד workload.googleapis.com/otlp.test.cumulative:

תרשים ב-Metrics Explorer של מדד מונה OTLP שנקלט באמצעות Monitoring API.

הצגת דפוסי שימוש וביצועים ואבחון במדדים ב-Cloud Monitoring

בדף Metrics Management ב-Cloud Monitoring יש מידע שיכול לעזור לכם לשלוט בסכום שאתם מוציאים על מדדים שניתנים לחיוב, בלי לפגוע ביכולת הצפייה. בדף Metrics Management מופיע המידע הבא:

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

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

כדי להציג את הדף ניהול מדדים:

נכנסים לדף Metrics management במסוף Google Cloud :
כניסה אל ניהול מדדים

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

מידע נוסף על הדף ניהול מדדים זמין במאמר איך רואים ומנהלים את השימוש במדדים.

איסוף עקבות OTLP

אם הגדרתם את Ops Agent לאיסוף עקבות, אבל לא קיבלתם עקבות ב-Cloud Trace כשאתם מריצים את האפליקציה, יכול להיות שתצטרכו להעניק תפקיד נוסף לחשבון השירות של Compute Engine שבו הסוכן משתמש. כברירת מחדל, חשבון השירות מקבל את התפקידים שנדרשים לכתיבת מדדים ויומנים, אבל לא לכתיבת עקבות.

בקטעים הבאים מוסבר איך להעניק לחשבון השירות את ההרשאה הנדרשת ל-Cloud Trace.

קובעים את התפקידים שניתנו לחשבון השירות

כדי לראות את התפקידים שניתנו לחשבון שירות, מריצים את הפקודה הבאה gcloud projects get-iam-policy:

gcloud projects get-iam-policy PROJECT_ID --format="table(bindings.role)" --flatten="bindings[].members" --filter="bindings.members:SERVICE_ACCT_NAME@PROJECT_ID.iam.gserviceaccount.com"

יכול להיות שיוצג פלט כמו זה:

ROLE
roles/logging.logWriter
roles/monitoring.metricWriter

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

הקצאת התפקיד Cloud Trace לחשבון השירות

בחשבון שירות, התפקיד המתאים בדרך כלל הוא Cloud Trace Agent‏, roles/cloudtrace.agent. כדי להקצות את התפקיד הזה לחשבון השירות, מריצים את הפקודה הבאה gcloud projects add-iam-policy-binding:

gcloud projects add-iam-policy-binding PROJECT_ID --member "serviceAccount:SERVICE_ACCT_NAME@PROJECT_ID.iam.gserviceaccount.com" --role="roles/cloudtrace.agent"

לאחר מכן, מריצים את הפקודה gcloud projects get-iam-policy כדי לוודא שהשינוי בוצע:

gcloud projects get-iam-policy PROJECT_ID --format="table(bindings.role)" --flatten="bindings[].members" --filter="bindings.members:SERVICE_ACCT_NAME@PROJECT_ID.iam.gserviceaccount.com"

הפלט כולל עכשיו את roles/cloudtrace.agent:

ROLE
roles/cloudtrace.agent
roles/logging.logWriter
roles/monitoring.metricWriter

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

אחרי שמאשרים לחשבון השירות שבו משתמש סוכן התפעול לכתוב נתונים ל-Cloud Trace, כשמריצים את האפליקציה שמבוססת על OpenTelemetry, העקבות מופיעים ב-Cloud Trace.

השבתת מקלט OTLP

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

כדי להשבית את איסוף המדדים או העקבות, מבצעים אחד מהשינויים הבאים בקובץ תצורת המשתמש, config.yaml:
- מסירים את צינור הנתונים של otlp מהשירות metrics.
- מסירים את צינור הנתונים של otlp מהשירות traces.
מפעילים מחדש את סוכן התפעול.

כדי להשבית את האיסוף של מדדים ועקבות OTLP על ידי סוכן תפעול, פועלים לפי השלבים הבאים:

מסירים את הגדרת ה-OTLP מקובץ התצורה של המשתמש:
- למחוק את כל הקטע combined, כולל הנמען otlp.
- מסירים את צינור הנתונים של otlp מהשירות metrics.
- מחיקת השירות traces כולו.
מפעילים מחדש את סוכן התפעול.

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

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

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

איסוף מדדים ועקבות של OpenTelemetry Protocol‏ (OTLP) קל לארגן דפים בעזרת אוספים אפשר לשמור ולסווג תוכן על סמך ההעדפות שלך.

סקירה כללית על השימוש ב-OTLP receiver

יתרונות

מגבלות

דרישות מוקדמות

הגדרת סוכן התפעול

שינוי קובץ הגדרות המשתמש של סוכן תפעול

הוספת הקטע combined receiver

הוספת צינורות OTLP לשירותים

הפעלה מחדש של סוכן התפעול

Linux

Windows

איסוף מדדים של OTLP

פורמטים של נתונים שנכנסים למערכת עבור מדדים של OTLP

תמחור ומכסה

מבנה המדד

Prometheus API

Monitoring API

Prometheus API

Monitoring API

פורמטים של נתונים ושאילתות

שליחת שאילתות על מדדי OTLP שהועברו באמצעות Prometheus API

הממשק של הכלי ליצירת שאילתות

PromQL

שליחת שאילתות על מדדי OTLP שנקלטים באמצעות Monitoring API

הממשק של הכלי ליצירת שאילתות

PromQL

הצגת דפוסי שימוש וביצועים ואבחון במדדים ב-Cloud Monitoring

איסוף עקבות OTLP

קובעים את התפקידים שניתנו לחשבון השירות

הקצאת התפקיד Cloud Trace לחשבון השירות

השבתת מקלט OTLP

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

איסוף מדדים ועקבות של OpenTelemetry Protocol‏ (OTLP)

הוספת הקטע `combined` receiver