امنیت، هویت، استقرار و تاب‌آوری · فصل ۵ — Telemetry، SLO و Incident Response · 101
OpenTelemetry: Trace, Metric, Log Correlation
می‌تواند سرویس را اجرا کند اما lifecycle، health، rollout، observability و recovery را به‌صورت سیستماتیک مدیریت نمی‌کند. موضوع جاری: «OpenTelemetry: Trace, Metric, Log Correlation». می‌تواند برای «OpenTelemetry: Trace, Metric, Log Correlation» run/release model و signals/recovery checks لازم را برای یک سرویس محدود طراحی کند.
خلاصهٔ درس
می‌تواند سرویس را اجرا کند اما lifecycle، health، rollout، observability و recovery را به‌صورت سیستماتیک مدیریت نمی‌کند. موضوع جاری: «OpenTelemetry: Trace, Metric, Log Correlation».
می‌تواند برای «OpenTelemetry: Trace, Metric, Log Correlation» run/release model و signals/recovery checks لازم را برای یک سرویس محدود طراحی کند.
خروجی این درس
می‌تواند برای «OpenTelemetry: Trace, Metric, Log Correlation» run/release model و signals/recovery checks لازم را برای یک سرویس محدود طراحی کند.
پیش‌نیازها
1. مسئله: سه سیگنال داشتن با قابلیت تشخیص یکی نیست
ممکن است یک سرویس trace، metric و log تولید کند و همچنان نتوانیم بگوییم کدام مشاهده‌ها واقعاً به یک request یا failure path تعلق دارند. وجود سه نمودار یا سه stream فقط نشان می‌دهد داده‌هایی تولید شده‌اند؛ correlation به هویت مشترک، context و رابطه قابل‌اثبات نیاز دارد.
خروجی مالک این درس Telemetry Correlation Evidence Record v1 است. این رکورد باید direct evidence، inference، missing context و unknownها را جدا نگه دارد. هدف، «بیشتر telemetry تولید کردن» نیست؛ هدف، ساختن یک زنجیره تشخیص محدود و قابل‌ردگیری است.
2. OpenTelemetry چه چیزی است و چه چیزی نیست
OpenTelemetry یک framework و toolkit متن‌باز و vendor-neutral برای instrument، generate، collect و export کردن telemetry مانند traces، metrics و logs است. خود OTel backend ذخیره‌سازی یا visualization نیست و سبز بودن pipeline هم کامل‌بودن instrumentation را ثابت نمی‌کند.
پس در این درس، وجود Collector یا exporter فقط یک لایه از زنجیره است. سؤال اصلی این است که آیا داده‌های مشاهده‌شده identity و context کافی برای پاسخ به سؤال تشخیصی ما دارند یا نه.
3. سه signal نقش یکسان ندارند
Trace معمولاً ساختار اجرا و رابطه parent/child را نشان می‌دهد؛ log جزئیات رویداد یا پیام را در یک نقطه از اجرا ثبت می‌کند؛ metric رفتار را به‌شکل aggregate یا اندازه‌گیری در طول زمان خلاصه می‌کند. این سه signal مکمل‌اند، اما قابل‌جایگزینی کامل نیستند.
یک log پرجزئیات ممکن است topology توزیع‌شده را نداشته باشد. یک metric aggregate ممکن است anomaly را نشان دهد ولی request دقیق را معرفی نکند. یک trace ممکن است مسیر را نشان دهد اما متن خطای application در log باشد.
4. Resource identity قبل از correlation
OpenTelemetry برای telemetry یک Resource context دارد؛ برای مثال service.name و در بعضی deploymentها service.instance.id می‌توانند منشأ observation را روشن کنند. یک نام سرویس مشترک به‌تنهایی ثابت نمی‌کند دو observation از یک instance یا deployment واحد آمده‌اند.
در artifact، هویت resource را مستقل ثبت کن. اگر شناسه‌ای وجود ندارد یا با signal دیگر ناسازگار است، آن را OPEN یا gap نگه دار و با شباهت نام آن را پر نکن.
5. Trace topology: Trace ID کافی نیست
در distributed tracing باید parentage را هم ببینیم. اگر Service A spanی ایجاد کند و Service B span بعدی همان Trace ID را داشته باشد و Parent Span ID آن به span upstream اشاره کند، یک رابطه مستقیم و قابل‌بررسی داریم.
اگر downstream با Trace ID جدید ظاهر شود یا parentage گم شود، صرف نزدیک‌بودن زمان‌ها رابطه را برنمی‌گرداند. این همان جایی است که propagation gap باید صریح ثبت شود.
6. Context propagation مرز سرویس‌ها را وصل می‌کند
Context propagation اطلاعات لازم برای حفظ رابطه execution را از یک process یا service به دیگری منتقل می‌کند. در HTTP معمولاً trace context در carrier منتقل و سمت دریافت extract می‌شود؛ instrumentation اغلب این کار را خودکار می‌کند، اما شکست propagation همچنان ممکن است رخ دهد.
در Lab یکی از edgeها عمداً context را از دست می‌دهد. پاسخ صحیح، ساختن رابطه فرضی نیست؛ باید آن edge را unproven نگه داشت و حداقل instrumentation repair را مشخص کرد.
7. Log correlation با TraceId و SpanId
در مدل log OpenTelemetry، TraceId و SpanId می‌توانند در LogRecord قرار گیرند. وقتی این شناسه‌ها با span موجود هم‌خوان باشند، log می‌تواند مستقیماً به execution context آن span متصل شود.
اما یک log که فقط در همان ثانیه رخ داده است correlation مستقیم ندارد. timestamp برای جست‌وجو مفید است، نه برای اثبات causality. در fixture، یک log عمداً از نظر زمان نزدیک اما بدون context است.
8. Metric correlation و exemplar
Metric معمولاً aggregate است. OpenTelemetry exemplar را برای نگه‌داشتن یک measurement نمونه همراه با context تعریف می‌کند؛ exemplar می‌تواند trace_id و span_id داشته باشد و یک پل مشخص از metric به trace بسازد.
نبود exemplar به معنی بی‌ارزش بودن metric نیست، ولی یعنی از همان metric aggregate نمی‌توانیم یک request دقیق را با قطعیت تعیین کنیم. artifact باید aggregate evidence را از trace-linked evidence جدا کند.
9. Full key reasoning: Span ID تنها کافی نیست
برای correlation امن، partial key را با کلید کامل اشتباه نکن. ممکن است دو trace متفاوت به‌طور مصنوعی span ID مشابه داشته باشند. اگر log فقط span ID مشابه دارد ولی Trace ID متفاوت است، باید آن link را رد کنیم.
این failure probe عمداً در Lab وجود دارد تا نشان دهد shortcutهایی مانند «span_id match شد، پس همان request است» قابل‌اعتماد نیستند.
10. Pipeline health با telemetry completeness فرق دارد
Collector می‌تواند receive/process/export را بدون error گزارش کند، در حالی که یک library اصلاً instrument نشده، یک route context را propagate نمی‌کند، یا یک signal برای بخشی از سیستم تولید نمی‌شود. سلامت pipeline فقط درباره مسیری است که telemetry واقعاً وارد آن شده است.
بنابراین pipeline healthy را به application fully observable تبدیل نکن. اگر یک signal برای edge مهم غایب است، gap باید در record باقی بماند.
11. Cardinality و attribute را با evidence نیازسنجی کن
اضافه‌کردن attributeهای بسیار متنوع می‌تواند query و correlation را آسان به نظر برساند، اما هزینه، حجم، privacy و cardinality را تغییر می‌دهد. هر attribute باید برای سؤال تشخیصی مشخص و bounded باشد.
برای identity از semantic fieldهای مناسب استفاده کن و از قرار دادن secrets، credential یا اطلاعات حساس در telemetry خودداری کن. این درس هیچ داده واقعی کاربر را وارد fixture نمی‌کند.
12. Telemetry Correlation Evidence Record v1
رکورد شامل این ستون‌هاست: observation، signal type، resource/service identity، Trace ID، Span ID، parent relation، log context link، metric/exemplar link، direct correlation، inference، missing context، instrumentation gap، unknowns و diagnostic decision.
این قالب یک synthesis آموزشی MAKNOW است، نه فرم اجباری OpenTelemetry. ارزش آن این است که observation و inference را کنار هم اما جدا ثبت می‌کند و اجازه نمی‌دهد gapها به‌صورت ضمنی حذف شوند.
13. Lab: هشت fixture و negative probe
Lab کاملاً local و synthetic است. هشت fixture شامل مسیر سالم، propagation شکسته، log نزدیک بدون context، resource mismatch، metric بدون exemplar، partial-key collision، signal ناقص و transfer با topology جدید هستند.
در هر fixture هشت بُعد مستقل را طبقه‌بندی می‌کنی. hidden oracle رابطه‌ها را می‌سنجد، نه متن حفظ‌شده. هیچ endpoint خارجی، backend زنده یا credential لازم نیست.
14. Transfer و معیار پذیرش
در transfer، نام سرویس‌ها، instanceها، trace topology و edge خراب تغییر می‌کنند. شناسه‌های کیس اول قابل‌کپی نیستند. باید از fixture دوم، topology و direct links را دوباره استخراج کنی.
PASS زمانی است که parentage بدون edge ساختگی بازسازی شود، log فقط با context معتبر link شود، exemplar و aggregate تفکیک شوند، resource mismatch پنهان نشود و instrumentation gap به‌صورت محدود و قابل‌اقدام ثبت شود.
15. منابع، freshness و مرز ادعا
مستندات رسمی OpenTelemetry همچنان OTel را framework مستقل از vendor برای traces، metrics و logs معرفی می‌کنند. راهنمای context propagation توضیح می‌دهد context چگونه correlation را بین processها و serviceها ممکن می‌کند. specification لاگ، TraceId و SpanId را برای correlation تعریف می‌کند و specification متریک، exemplar را به‌عنوان measurement دارای context و پل احتمالی metric-to-trace توضیح می‌دهد.
این منابع در 2026-09-19 بازبینی شدند و تا 2026-10-17 باید دوباره بررسی شوند. از این منابع هیچ ادعای «observability کامل» یا backend خاص نتیجه‌گیری نمی‌شود؛ هر link فاقد context باید OPEN بماند.
ارزیابی
پاسخ‌نامه‌ی این درس در بسته‌ی آموزش وجود ندارد؛ خودت جواب بده و صادقانه علامت بزن. «نیاز به مرور» درس را به صف تکرار می‌فرستد.
OPS-008-S1 retrieval
Draw the supplied trace/span topology and identify any edge whose parentage is not directly supported.
OPS-008-S2 application
Classify each log as directly correlated, context-free, or rejected because trace/span identity does not match.
OPS-008-S3 diagnosis
Explain when a metric exemplar links an aggregate observation to a trace and when the aggregate remains unlinked.
OPS-008-S4 decision
Diagnose one orphaned telemetry path and name the minimum instrumentation repair while leaving unsupported links OPEN.
OPS-008-S5 transfer
Rebuild correlation for a changed two-service topology with different resource identities and a different broken propagation edge.
ملاک‌های ارزیابی (rubric)
| Dimension | Critical | Sufficient evidence |
|---|---|---|
| Context topology | Yes | Trace/span parentage and propagation continuity are reconstructed without invented edges. |
| Cross-signal correlation | Yes | Logs and metric exemplars are linked only through explicit context/evidence. |
| Instrumentation-gap diagnosis | Yes | Missing propagation, resource identity, signal coverage, or attribution remains explicit rather than inferred away. |
| Transfer topology | Yes | Changed service/resource topology is solved independently without copying identifiers or diagnosis. |
Failure: timestamp-only causality, span-ID-only matching, treating aggregate metrics as request-specific without a link, or treating pipeline health as proof of complete instrumentation.
منابع و تازگی
مطالعهٔ موارد (case studies)
تصاویر درس
فایل‌های آزمایشگاه
Everything is local and synthetic. No account, network target, credential, customer data, production telemetry system, or live backend is used.
For each case, produce eight states: signal_identity_state, resource_identity_state, trace_topology_state, propagation_state, log_correlation_state, metric_exemplar_state, instrumentation_gap_state, and diagnostic_decision.
Rules:
- Use the complete trace/span context; do not correlate by timestamp or Span ID alone.
- Preserve parent/child topology. A new Trace ID or missing parent leaves the edge unproven.
- Treat resource identity as separate evidence, even when trace context matches.
- Link a log directly only when its TraceId/SpanId match an observed span.
- Distinguish aggregate metrics from exemplar-linked observations.
- A healthy collector does not prove missing application telemetry exists.
- Keep every unsupported path as an explicit instrumentation gap.
- Rebuild the transfer topology from its own identifiers.
رسانه و اسلایدهای درس
فایل‌های آموزشی (دانلود)