סקירה כללית של הטמעת מדדים ב-OTLP

במסמך הזה מוסבר איך להשתמש ב-OpenTelemetry Collector עם otlphttp exporter ועם Telemetry (OTLP) API,‏ telemetry.googleapis.com שמטמיע את OpenTelemetry Line Protocol. השילוב של כלי הייצוא otlphttp ו-Telemetry API מאפשר לכם להטמיע מדדי OTLP ב-Cloud Monitoring.

נקודת הקצה של OTLP תומכת בכל הפרוטוקולים של OTLP, כולל http/protobuf, http/json ו-grpc. מידע נוסף מופיע במאמר בנושא תמיכה בפרוטוקולים.

אפשר גם לשלוח מדדים ישירות אל Telemetry API מאפליקציות שמשתמשות בערכות SDK. מידע נוסף זמין במאמר שימוש ב-SDK לשליחת מדדים מאפליקציות.

אם אתם משתמשים ב-Google Kubernetes Engine, אתם יכולים לפעול לפי ההוראות במאמר Managed OpenTelemetry for GKE במקום לפרוס ולהגדיר באופן ידני OpenTelemetry Collector שמשתמש ב-Telemetry API.

פרוטוקול OTLP למדדים של Prometheus פועל רק כשמשתמשים בגרסה 0.140.0 או בגרסה חדשה יותר של OpenTelemetry Collector.

שמות של מדדים ותוויות ב-Telemetry API

בקטע הזה מוסבר על מוסכמות ודרישות למתן שמות למדדים שמועברים ל-Cloud Monitoring באמצעות Telemetry API:

  • שמות של מדדים ומפתחות של תוויות לא תומכים ב-UTF-8 מלא.

    • שמות של מדדים שלא תואמים לביטוי הרגולרי [a-zA-Z][a-zA-Z0-9_:./-]* יידחו. התווים המיוחדים היחידים שמותרים בשמות של מדדים הם התווים שבקבוצה _:./-.
    • נקודות נתונים שמכילות מאפיינים (כלומר, מפתחות של תוויות) שלא תואמים לביטוי הרגולרי [a-zA-Z_][a-zA-Z0-9_.]* יידחו. התווים המיוחדים היחידים שמותרים במפתחות של תוויות הם אלה שבקבוצה _.. מותר להשתמש בכל התווים המיוחדים בערכי התוויות.

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

  • חשוב: כשמבצעים שאילתות על שמות של מדדים ומפתחות של תוויות עם תווים מיוחדים שאינם נקודתיים (:) או קו תחתון (_), צריך להוסיף אותם בסוגריים מסולסלים ({}) ובמירכאות ("), בהתאם למפרט UTF-8 של PromQL. לדוגמה, השאילתות הבאות הן שאילתות תקינות:

    • {"my.metric.name"}
    • {"my.metric.name", "label.key.KEY"="value"}

מדדים של Telemetry API ו-Cloud Monitoring

בקטע הזה מוסבר איך מדדים שמוזנים באמצעות Telemetry API ו-otlphttp exporter פועלים עם Cloud Monitoring:

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

  • שמירה על התווית le כשמריצים שאילתה על היסטוגרמות אקספוננציאליות עלולה להחזיר תוצאות לא צפויות. צפוי שהשאילתות הטיפוסיות יותר histogram_quantile(.99, sum by (le) (metric)) יפעלו.

  • יכול להיות שבנסיבות מסוימות, כמו דלתאות דלילות מאוד, לא תתבצע שאילתה תקינה של מדדי הדלתא.

תמיכה בפרוטוקול

נקודת הקצה של OTLP תומכת בכל הפרוטוקולים של OTLP, כולל http/protobuf, http/json ו-grpc. כשמייצאים מ-OpenTelemetry Collector, אפשר להשתמש בכל אחד מהפרוטוקולים. עם זאת, ברוב כלי הייצוא של SDK אין תמיכה ברענון דינמי של טוקנים, ולכן אנחנו ממליצים להשתמש רק בכלי הייצוא gRPC OTLP, ולא בכלי הייצוא HTTP, כשמייצאים ישירות מ-SDK. מידע נוסף זמין במאמר שימוש ב-SDK לשליחת מדדים מאפליקציות.

חיוב

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

מגבלות ומכסות

הטמעה של מדדים באמצעות Telemetry API כפופה למגבלות המדדים של Telemetry API.

בנוסף, חלות מכסות ומגבלות של מדדים סטנדרטיים ב-Cloud Monitoring ובשירות המנוהל של Google Cloud ל-Prometheus. לדוגמה, למדדים לא יכולות להיות יותר מ-200 תוויות.

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

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