در معماری microservice، یک درخواست کاربر ممکن است از API Gateway به ده سرویس، دو صف، یک cache و یک دیتابیس برود. وقتی latency بالا می‌رود یا error می‌آید، log خام و metric میانگین کافی نیست — باید مسیر دقیق همان درخواست را ببینید.

Jaeger برای همین ساخته شد:

open source, distributed tracing platform — Monitor and troubleshoot workflows in complex distributed systems.

یعنی متصل کردن نقطه‌ها بین سرویس‌های پراکنده: پیدا کردن bottleneck، ریشهٔ خطا، و وابستگی سرویس‌ها — با مقیاس ابری و بدون قفل vendor.

CNCF Graduated — یکی از اولین پروژه‌های graduated بنیاد. خاستگاه: Uber (اهدا به CNCF). لایسنس: Apache 2.0. سایت: jaegertracing.io · Docs: docs · Repo: github.com/jaegertracing/jaeger

مشکل: بدون Trace، Blind Debugging

بدون tracing:
  Service A ──?──► B ──?──► C
  metric: p99 بالا — کجا؟
  log: خطای timeout در C — چرا A کند بود؟

با Jaeger:
  Trace ID = abc123
  A (12ms) → B (80ms) → C (410ms) ← bottleneck
  هر span: tags، logs، status، parent/child

Tracing جایگزین log یا metric نیست — ستون سوم observability کنار آن‌هاست. برای log یکپارچه ببینید: Fluentd. برای mesh و proxy: Istio و Envoy.

Jaeger چیست؟

طبق جاegertracing.io و Features:

• پلتفرم distributed tracing برای مانیتور و عیب‌یابی workflowهای توزیع‌شده
• طراحی‌شده برای high scalability (مثلاً استقرار Uber: میلیاردها span در روز)
• Cloud Native: image کانتینر، binary، Operator و Helm برای Kubernetes
• دریافت داده با OTLP (پروتکل استاندارد OpenTelemetry) به‌علاوه پروتکل‌های legacy Jaeger و Zipkin
• UI مدرن (React) برای جستجوی trace، timeline، dependency graph و SPM
• Sampling سر/دم برای کنترل سربار و هزینهٔ storage

مفاهیم پایه

مدل داده در UI همچنان نزدیک OpenTracing است (DAG با span references، نه فقط درخت ساده)، در حالی که ingestion مدرن روی OTLP متمرکز است.

تاریخچهٔ کوتاه: از OpenTracing تا Jaeger v2

پیام جامعه امروز: instrument کنید با OpenTelemetry SDK؛ backend می‌تواند Jaeger باشد. exporterهای بومی Jaeger در SDKها به‌تدریج به نفع OTLP کنار می‌روند.

معماری Jaeger v2

Jaeger v2 یک binary انعطاف‌پذیر است که با config به نقش‌های مختلف درمی‌آید:

Apps (OTel SDK / Zipkin / legacy Jaeger)
        │  OTLP :4317/:4318  (یا Zipkin :9411)
        ▼
┌───────────────────┐     اختیاری      ┌─────────────┐
│ Jaeger collector  │ ───────────────► │    Kafka    │
│  (+ processors)   │                  └──────┬──────┘
└─────────┬─────────┘                         │
          │ direct                            ▼
          │                          ┌─────────────┐
          ▼                          │  ingester   │
┌───────────────────┐                └──────┬──────┘
│ Storage backend   │ ◄─────────────────────┘
│ ES / Cassandra /  │
│ OpenSearch /      │
│ ClickHouse /      │
│ Badger / memory   │
└─────────┬─────────┘
          ▼
┌───────────────────┐
│ query + Jaeger UI │  :16686
└───────────────────┘

دو الگوی استقرار مقیاس‌پذیر

1. Direct-to-storage — collector مستقیم به DB می‌نویسد. ساده؛ storage باید peak را تحمل کند.
2. Via Kafka — collector به Kafka export می‌کند؛ ingester می‌خواند و به storage می‌نویسد. بافر پایدار در برابر spike و outage کوتاه storage.

all-in-one چه وقت؟

جزئیات: Architecture.

Jaeger روی OpenTelemetry Collector

Jaeger v2 عملاً یک توزیع سفارشی از OpenTelemetry Collector است با:

• کامپوننت‌های upstream (OTLP receiver، batch، attributes، …)
• contrib (Kafka، tail sampling، …)
• کامپوننت‌های خود Jaeger: Storage Extension/Exporter، Query Extension، Adaptive Sampling، Remote Sampling

می‌توانید با OpenTelemetry Collector Builder (ocb) توزیع سفارشی بسازید.

Receivers مهم

Processors و قابلیت‌های pipeline

• Batch — کارایی نوشتن
• Memory Limiter — back-pressure زیر فشار
• Attributes / Filter — غنی‌سازی، redact دادهٔ حساس، کاهش volume (Filter می‌تواند trace را بشکند — با احتیاط)
• Tail Sampling — تصمیم بعد از دیدن کل trace (مثلاً نگه داشتن فقط errorها)

OTel Collector جلوتر از Jaeger؟

اجباری نیست — خود Jaeger همان نقش collector را دارد. اگر قبلاً OTel Collector برای metrics/logs دارید، می‌تواند sidecar، DaemonSet یا remote cluster جلوی Jaeger باشد برای enrichment (نام Pod، namespace) یا sharding / tail sampling متمرکز.

Storage backends

چرا ClickHouse مهم شد؟

حجم span نیمه‌ساخت‌یافته بالاست؛ نیاز به جستجو روی service، operation، tag، duration و trace ID دارید. گزارش‌های جامعه (از جمله CNCF blog و پست Introducing Native ClickHouse Support):

• ingestion بالای ۵۰k spans/sec در بنچمارک تک‌نود
• فشرده‌سازی حدود ۸.۶× روی جدول spans
• بازیابی trace حدود ~۱۰۰ ms؛ بسیاری از searchها زیر ۵۰ ms

اسکیما برای مدل OTel در v2 بازطراحی شده: جدول spans با ستون‌های Nested، مرتب‌سازی برای search، Bloom filter روی trace_id، و materialized view برای بهینه‌سازی FindTraceIDs.

Sampling: کنترل هزینه و سربار

بدون sampling، هر درخواست = هزینهٔ storage و CPU روی مسیر hot.

Remote Sampling از طریق extension در Jaeger (و سازگاری با OTel Collector) سرو می‌شود. جزئیات در Sampling docs.

UI، Dependency Graph و SPM

Jaeger UI (:16686)

• جستجو بر اساس service، operation، tags، مدت، بازهٔ زمانی
• waterfall / timeline برای ده‌ها هزار span (بهبودهای v1.0+؛ آزمایش با ~۸۰٬۰۰۰ span گزارش شده)
• contextual logs روی span

دو نوع گراف وابستگی

System Architecture می‌تواند از memory ساخته شود یا با jobهای Spark/Flink روی storage توزیع‌شده.

Service Performance Monitoring (SPM)

از spanها metricهای تجمیعی (latency، error rate، throughput) می‌سازد و به‌صورت time series نشان می‌دهد — پلی بین tracing و «مانیتورینگ عملکرد سرویس» بدون اینکه جایگزین Prometheus کامل شود. اجزای backend معمولاً Prometheus metrics و log ساخت‌یافته (zap) هم expose می‌کنند.

سازگاری با Zipkin

اگر instrumentation قدیمی Zipkin دارید، لازم نیست همه را یک‌شبه عوض کنید. Jaeger spanهای Zipkin (Thrift، JSON v1/v2، Protobuf روی HTTP، پورت رایج :9411) را می‌پذیرد. مسیر پیشنهادی بلندمدت: مهاجرت به OpenTelemetry و OTLP.

شروع سریع

all-in-one با Docker

طبق Getting Started (نسخه را با آخرین release عوض کنید):

docker run --rm --name jaeger \
  -p 16686:16686 \
  -p 4317:4317 \
  -p 4318:4318 \
  -p 5778:5778 \
  -p 9411:9411 \
  cr.jaegertracing.io/jaegertracing/jaeger:2.20.0

• UI: http://localhost:16686
• OTLP gRPC: 4317 · OTLP HTTP: 4318
• Zipkin: 9411 · Remote sampling: 5778

با config سفارشی:

docker run --rm --name jaeger \
  -p 16686:16686 -p 4317:4317 -p 4318:4318 \
  -v /path/to/config.yaml:/jaeger/config.yaml \
  cr.jaegertracing.io/jaegertracing/jaeger:2.20.0 \
  --config /jaeger/config.yaml

HotROD — دموی رسمی

HotROD (Rides on Demand) چند microservice دارد و برای یادگیری latency، concurrency، baggage و instrumentation OTel عالی است:

export JAEGER_VERSION=2.20.0   # آخرین نسخهٔ پایدار
git clone https://github.com/jaegertracing/jaeger.git jaeger
cd jaeger/examples/hotrod
docker compose up

App: http://localhost:8080 · Jaeger UI معمولاً کنار همان compose بالا می‌آید.

ارسال span با OTLP (مفهومی)

# مثال مفهومی — endpoint OTLP HTTP به all-in-one
export OTEL_EXPORTER_OTLP_ENDPOINT=http://localhost:4318
export OTEL_SERVICE_NAME=checkout-api
# سپس اپ را با OpenTelemetry SDK / auto-instrumentation اجرا کنید

در Kubernetes معمولاً:

1. Operator یا Helm chart Jaeger
2. Instrumentation با OTel Operator / sidecars / SDK
3. Service mesh (Istio، Linkerd) برای spanهای شبکه بدون تغییر همهٔ کد

مقایسه: Jaeger در برابر گزینه‌های رایج

انتخاب سریع:

• می‌خواهید UI و جستجوی standalone قوی + CNCF → Jaeger
• قبلاً همه چیز داخل Grafana stack و object storage ارزان → Tempo را هم ارزیابی کنید
• فقط migration کوتاه از Zipkin → Jaeger به‌عنوان drop-in backend خوب است

عملیات روزمره

برای شبکه و observability مبتنی بر eBPF کنار tracing: Cilium. برای runtime security: Falco.

یکپارچگی با استک P30Light

الگوی رایج production:

Apps / Mesh ──OTLP──► OTel Collector (enrich) ──► Jaeger collector
                                              └──► (اختیاری) metrics/logs backends
Jaeger storage ◄── collector / Kafka+ingester
UI / SPM ◄── query

خلاصه

قدم بعدی

1. all-in-one را با Docker بالا بیاورید و UI را روی :16686 باز کنید.
2. HotROD را با docker compose اجرا کنید و یک latency cascade را در waterfall ببینید.
3. یک سرویس واقعی را با OTel SDK به 4317/4318 وصل کنید.
4. برای staging، collector/query جدا + Elasticsearch یا ClickHouse انتخاب کنید.
5. sampling (adaptive یا tail) را قبل از production کامل روشن کنید.
6. با mesh یا Fluentd، سه ستون metrics / logs / traces را هم‌تراز کنید.

منابع

• Jaeger — سایت رسمی
• Architecture
• Features
• Getting Started
• Sampling
• GitHub — jaegertracing/jaeger
• Native ClickHouse support (blog)
• CNCF — ClickHouse backend benchmarks
• OpenTelemetry

منتشر شده در P30Light — بخش زیرساخت و سرور