מדדים מצביעים על חריגת זמן אחזור, יומנים מתעדים שגיאה, אבל חיבורם לתמונה אחת נכשל. אנו נתקלים לעיתים קרובות במצב זה: RPS עלה, האחוזון ה-99 ירד ל-800 אלפיות השנייה, והגורם הוא בקשה אחת שנוגעת ב-10 מיקרוסרוויסים. ללא tracing, מציאת נקודה זו היא מחט בערמת שחת. Grafana Tempo הוא מנוע tracing מבוזר שמשתלב בצורה חלקה עם Prometheus ו-Loki בממשק Grafana אחיד. אנו מציעים פתרון מפתח: מביקורת instrumentation ועד הגדרת correlation והדרכת צוות. בקשו ביקורת על המערכת שלכם—קבלו תוכנית יישום תוך יום אחד. צרו קשר כדי לדון בפרטים.
כיצד להגדיר את Grafana Tempo ל-Tracing מבוזר?
Tempo אינו בונה אינדקסים על תוכן ה-trace. הוא מאחסן נתונים ישירות באחסון אובייקטים (S3, GCS), ומבצע אינדקס רק על Trace ID. זה מניב חיסכון קיצוני בעלויות אחסון—עד 70% בהשוואה ל-Jaeger, הדורש Elasticsearch או Cassandra. בפועל, Tempo עולה פחות משמעותית: אחסון של 1 TB של traces ב-S3 עולה פי כמה פחות. עבור פרויקט עם 20 מיקרוסרוויסים ועומס של 5000 spans בשנייה, החיסכון באחסון עולה על $2000 בחודש. החיסרון: חיפוש לפי מאפיינים ללא שפת שאילתות ייעודית אינו אפשרי. עם זאת, זרימת העבודה "נמצאה חריגה במדדים → ניווט ל-trace ספציפי" מכסה 90% מתרחישי האבחון. לחיפוש אד-הוק, השתמשו ב-TraceQL, הזמין מאז Tempo 2.0.
Tempo מול Jaeger: עלות אחסון
| קריטריון | Jaeger (עם Elasticsearch) | Tempo (S3) |
|---|---|---|
| עלות אחסון (1 TB לחודש) | גבוהה | נמוכה (חיסכון של עד 90%) |
| אינדוקס | מלא על כל המאפיינים | רק Trace ID |
| חיפוש מאפיינים | כן | באמצעות TraceQL או correlation |
| שמירה | מוגבלת לגודל האשכול | כמעט בלתי מוגבלת |
החיסכון נובע מהשמטת האינדקס היקר. אנו משתמשים ב-tail sampling ב-OpenTelemetry Collector כדי לסנן רעש: כל השגיאות והבקשות האיטיות נשמרות, האחרות בהסתברות של 10%. זה מקטין את נפח הנתונים המאוחסן בחצי מבלי לאבד ערך אבחוני.
השוואת שיטות דגימה
| פרמטר | Head-based sampling | Tail sampling |
|---|---|---|
| החלטת דגימה | בצד היישום (לפני שליחה) | ב-Collector (לאחר איסוף כל ה-spans) |
| בקרת שגיאות | לא ניתן להבטיח שכל השגיאות נשמרות | מדיניות אפשרית (כל השגיאות נשמרות) |
| משאבים | עומס נמוך על Collector | דורש OTLP receiver ו-buffering |
| גמישות | הסתברות קבועה | מדיניות מרובה (latency, status_code) |
לסביבות production, אנו ממליצים על tail sampling—הוא מספק שלמות מקסימלית של traces קריטיים.
Instrumentation של יישומים עם OpenTelemetry
Tempo מקבל traces דרך OTLP (מומלץ), Jaeger או Zipkin. דוגמה ל-instrumentation בפייתון:
from opentelemetry import trace
from opentelemetry.exporter.otlp.proto.grpc.trace_exporter import OTLPSpanExporter
from opentelemetry.sdk.trace import TracerProvider
from opentelemetry.sdk.trace.export import BatchSpanProcessor
provider = TracerProvider()
exporter = OTLPSpanExporter(endpoint="http://otel-collector:4317", insecure=True)
provider.add_span_processor(BatchSpanProcessor(exporter))
trace.set_tracer_provider(provider)
tracer = trace.get_tracer(__name__)
with tracer.start_as_current_span("process_order") as span:
span.set_attribute("order.id", order_id)
result = process(order_id)ה-traces נשלחים ל-OpenTelemetry Collector, שמבצע דגימה ומעביר ל-Tempo. אנו ממליצים להשתמש ב-OpenTelemetry כסטנדרט ל-instrumentation.
OpenTelemetry Collector: מרכזייה מרכזית
---
receivers:
otlp:
protocols:
grpc:
endpoint: 0.0.0.0:4317
http:
endpoint: 0.0.0.0:4318
jaeger:
protocols:
grpc:
endpoint: 0.0.0.0:14250
processors:
batch:
timeout: 5s
send_batch_size: 1024
tail_sampling:
decision_wait: 10s
policies:
- name: errors-policy
type: status_code
status_code: {status_codes: [ERROR]}
- name: slow-policy
type: latency
latency: {threshold_ms: 1000}
- name: probabilistic
type: probabilistic
probabilistic: {sampling_percentage: 10}
exporters:
otlp/tempo:
endpoint: http://tempo:4317
tls:
insecure: true
service:
pipelines:
traces:
receivers: [otlp, jaeger]
processors: [batch, tail_sampling]
exporters: [otlp/tempo]
פריסת Tempo
פריסת Tempo ב-Docker Compose
---
services:
tempo:
image: grafana/tempo:2.4.0
command: ["-config.file=/etc/tempo.yaml"]
volumes:
- ./tempo.yaml:/etc/tempo.yaml
- tempo-data:/tmp/tempo
ports:
- "3200:3200"
- "4317:4317"
------
server:
http_listen_port: 3200
distributor:
receivers:
otlp:
protocols:
grpc:
http:
storage:
trace:
backend: local # для разработки; в production: s3
local:
path: /tmp/tempo/blocks
compactor:
compaction:
block_retention: 336h
metrics_generator:
registry:
external_labels:
source: tempo
cluster: docker-compose
storage:
path: /tmp/tempo/generator/wal
remote_write:
- url: http://prometheus:9090/api/v1/write
send_exemplars: true
metrics_generator יוצר אוטומטית מדדים של Prometheus מתוך traces—service graphs ו-span metrics. זה מבטל את הצורך ב-instrumentation ידני של בקשות HTTP.
שילוב Grafana Tempo עם Prometheus ו-Loki
הגדירו את מקור הנתונים ב-Grafana: הגדירו סוג Tempo, כתובת URL http://tempo:3200, וב-jsonData הפעילו tracesToLogsV2 (UID של מקור הנתונים Loki) ו-serviceMap (UID של Prometheus). לאחר מכן, ב-Explore, לחיצה על מדד חושפת כפתור "הצג traces קשורים", ומתוך trace ניתן לנווט ליומנים.
TraceQL: חיפוש Traces לפי מאפיינים
TraceQL היא שפת שאילתות עבור Tempo, דומה ל-PromQL. דוגמאות: from opentelemetry import trace from opentelemetry.exporter.otlp.proto.grpc.trace_exporter import OTLPSpanExporter from opentelemetry.sdk.trace import TracerProvider from opentelemetry.sdk.trace.export import BatchSpanProcessor provider = TracerProvider() exporter = OTLPSpanExporter(endpoint="http://otel-collector:4317", insecure=True) provider.add_span_processor(BatchSpanProcessor(exporter)) trace.set_tracer_provider(provider) tracer = trace.get_tracer(__name__) with tracer.start_as_current_span("process_order") as span: span.set_attribute("order.id", order_id) result = process(order_id) receivers: otlp: protocols: grpc: endpoint: 0.0.0.0:4317 http: endpoint: 0.0.0.0:4318 jaeger: protocols: grpc: endpoint: 0.0.0.0:14250 processors: batch: timeout: 5s send_batch_size: 1024 tail_sampling: decision_wait: 10s policies: - name: errors-policy type: status_code status_code: {status_codes: [ERROR]} - name: slow-policy type: latency latency: {threshold_ms: 1000} - name: probabilistic type: probabilistic probabilistic: {sampling_percentage: 10} exporters: otlp/tempo: endpoint: http://tempo:4317 tls: insecure: true service: pipelines: traces: receivers: [otlp, jaeger] processors: [batch, tail_sampling] exporters: [otlp/tempo]
services: tempo: image: grafana/tempo:2.4.0 command: ["-config.file=/etc/tempo.yaml"] volumes: - ./tempo.yaml:/etc/tempo.yaml - tempo-data:/tmp/tempo ports: - "3200:3200" - "4317:4317"
TraceQL פותר את המגבלה המרכזית של Tempo—כעת ניתן לחפש traces לא רק לפי ID אלא גם לפי מאפיינים שרירותיים. התיעוד הרשמי של TraceQL מכיל תיאור מלא של התחביר.
כיצד ליישם Tracing מבוזר עם Grafana Tempo?
- ביקורת instrumentation: בדקו אם קיימים OTel SDK, Jaeger, Zipkin. בחרו אסטרטגיית דגימה.
- פריסת Tempo + Collector: פרסו בסביבתכם, הגדירו אחסון אובייקטים (S3, GCS).
- הגדירו מקור נתונים ב-Grafana: הגדירו correlations עם Prometheus ו-Loki.
- הפעילו metrics_generator: קבלו מדדים אוטומטיים ו-service graphs.
- תיעוד והדרכה: ספקו הוראות להוספת tracing לשירותים חדשים.
מה כוללת העבודה
- פריסת Tempo ו-Collector עם תצורת דגימה אופטימלית.
- שילוב עם מחסנית הניטור הקיימת (Prometheus, Loki).
- הגדרת התראות המבוססות על traces (לדוגמה, ירידת SLO).
- תיעוד והדרכה מעשית לצוות.
- אחריות ל-correlation נכון בין מדדים, traces ויומנים.
לוח זמנים: 2 עד 5 ימים בהתאם למורכבות התשתית. אנו צוות עם ניסיון של 5+ שנים ב-observability, שיישם tracing מבוזר על למעלה מ-30 פרויקטים. נבחן את הפרויקט שלכם תוך יום עסקים אחד. קבלו ייעוץ כדי לדון בפרטים. צרו קשר, ונמצא את הפתרון האופטימלי.