OpenTelemetry: תקן אחיד ל-Traces, Metrics ו-Logs בלי נעילה לספק

מאת צוות מדיה דיל · 02.09.2026 · טכנולוגיה · 6 דק׳

SDK מול Collector, Trace Context Propagation בין שירותים, Head מול Tail Sampling, Exemplars, ולמה OpenTelemetry פותר בעיית Vendor Lock-In אמיתית.

כשמערכת בנויה מעשרות מיקרו-שירותים, השאלה "למה הבקשה הזו לקחה 4 שניות" הופכת בלתי אפשרת לענות עליה בלי לוגים ו-Dashboards נפרדים לכל שירות שאף אחד לא מצליח לחבר יחד. OpenTelemetry (OTel) נוצר בדיוק בשביל זה — תקן פתוח ואחיד לאיסוף Traces, Metrics ו-Logs, בלי תלות בספק Observability ספציפי.

שלושת העמודים: Traces, Metrics, Logs

Metrics הם מספרים מצטברים לאורך זמן (קצב בקשות, אחוזון Latency) — טובים לזיהוי "שיש בעיה" ולהתראות. Logs הם רשומות טקסטואליות של אירועים בודדים — טובים לחקירת "מה קרה בדיוק". Traces עוקבים אחרי בקשה בודדת לאורך כל השירותים שהיא עברה — טובים ל"איפה בדיוק בשרשרת הזמן אבד". OTel מטרתו לתקנן את שלושתם תחת פורמט נתונים אחד, כך שהם יכולים להתחבר זה לזה, לא לחיות בשלושה כלים נפרדים.

SDK מול Collector: איפה עובד מה

ה-SDK רץ בתוך קוד האפליקציה ואוסף נתונים (Instrumentation). ה-Collector הוא תהליך נפרד (לרוב Sidecar או שירות משותף) שמקבל את הנתונים מכל השירותים, מעבד אותם (סינון, Batching, העשרה), ומייצא אותם ליעד — Jaeger, Prometheus, Datadog, או כל Backend אחר. ההפרדה הזו קריטית: היא מאפשרת להחליף Backend Observability בלי לגעת בקוד האפליקציה בכלל, רק בקונפיגורציה של ה-Collector.

Trace Context Propagation: איך העקבה עוברת בין שירותים

כדי ש-Trace יעקוב אחרי בקשה שעוברת בין כמה שירותים, כל שירות חייב להעביר הלאה מזהה משותף — תקן W3C traceparent מגדיר כותרת HTTP סטנדרטית שמכילה trace-id ו-span-id, כך שכל שירות שמקבל בקשה יודע לאיזה Trace קיים הוא שייך ולא מתחיל אחד חדש. בלי Propagation נכון בין שירותים, מקבלים Traces מקוטעים שלא מספרים סיפור שלם.

Sampling: לא כל בקשה שווה תיעוד מלא

תיעוד Trace מלא לכל בקשה במערכת בעומס גבוה יקר מדי — גם באחסון וגם ב-Overhead ריצה. Head-Based Sampling מחליט האם לתעד Trace ברגע הכניסה (למשל 10% אקראי). Tail-Based Sampling מחליט רק בסיום, אחרי שרואים את כל ה-Trace — מה שמאפשר לשמור תמיד Traces עם שגיאה או Latency חריג, גם אם רוב התעבורה הרגילה נדגמת בשיעור נמוך בהרבה.

Auto-Instrumentation מול ידני

OTel מספק ספריות Auto-Instrumentation שמזריקות איסוף נתונים אוטומטי לספריות נפוצות (HTTP Clients, ORMs) בלי לגעת בקוד — נקודת התחלה מהירה שמכסה רוב המקרים. לביקורת עסקית עמוקה יותר (למשל "כמה זמן לקח שלב אימות ספציפי בתוך פונקציה") נדרש Instrumentation ידני עם Spans מותאמים — השילוב בין השניים נותן כיסוי טוב בלי לכתוב הכל ידנית.

Exemplars: הגשר בין Metrics ל-Traces

אחד היתרונות המעשיים של OTel כתקן אחוד הוא Exemplars — קישור ישיר מנקודת דגימה במטריקה (למשל spike ב-p99 Latency) ל-Trace ID קונקרטי שהיה חלק מהדגימה הזו. זה חוסך את השלב הידני המתסכל של "לראות שיש בעיה בגרף, ואז לנסות לנחש איזה Trace מסביר אותה" — קליק אחד מהגרף מוביל ישירות ל-Trace הרלוונטי.

Collector Pipeline: Receivers, Processors, Exporters

ה-Collector בנוי מצינור מודולרי: Receivers קולטים נתונים (מפורמטים שונים, כולל לא-OTel כמו Prometheus), Processors מעבדים אותם (Batching, הסרת שדות רגישים, הוספת תגיות), ו-Exporters שולחים אותם ליעד הסופי. תצורה גמישה זו מאפשרת, למשל, לסנן PII לפני שהוא בכלל עוזב את הרשת הפנימית — נקודת בקרה קריטית לפני שנתונים מגיעים לספק חיצוני.

Vendor-Neutral: הערך שקל לפספס

הערך האמיתי של OTel הוא לא רק טכני אלא אסטרטגי — כי ה-Instrumentation בקוד לא תלוי ב-API קנייני של ספק APM ספציפי, מעבר מ-Datadog ל-Grafana או ל-Backend פנימי הופך לשינוי קונפיגורציה ב-Collector במקום שכתוב Instrumentation מלא. זו בדיוק אותה בעיה שנדונה במדריך על Vendor Lock-In, ו-OTel הוא אחד הכלים הבודדים שפותר אותה באמת בתחום ה-Observability. שילוב עם Circuit Breakers ועם נתוני Service Mesh נותן תמונה מלאה — לא רק שקרה כשל, אלא איפה בדיוק בשרשרת הקריאות הוא התרחש.

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

תגיות: OpenTelemetry · Observability · Distributed Tracing · Metrics · DevOps

← חזרה לבלוג · צור קשר