סקירה כללית של הטמעת מדדים ב-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 פועל רק כשמשתמשים ב-OpenTelemetry Collector מגרסה 0.140.0 ואילך.

שמות של מדדים ותוויות ב-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 הזה כדי למחוק את כל המדדים מסוג INT64 מהיקף המדדים.target_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 דגימות לשנייה. אפשר לבקש להגדיל את המכסה.

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