فصل پنجم: مشاهده‌پذیری و مقاومت

لاگ متمرکز و همبستگی درخواست‌ها

مشکل لاگ‌های پراکنده

در یک مونولیت، وقتی خطایی رخ می‌دهد، کافی است یک فایل لاگ را باز کنید. اما در میکروسرویس، لاگ هر سرویس روی کانتینر یا سرور خودش ذخیره می‌شود؛ اگر یک درخواست کاربر از پنج سرویس عبور کرده باشد، دنبال کردن مسیر آن درخواست در پنج فایل لاگ جداگانه عملاً غیرممکن است.

راه‌حل اول، لاگ متمرکز است: همه‌ی سرویس‌ها لاگ خود را به یک سیستم مرکزی مثل ELK Stack (Elasticsearch, Logstash, Kibana) یا Loki ارسال می‌کنند تا بتوان همه‌ی لاگ‌ها را در یک رابط واحد جست‌وجو کرد.

Correlation ID: نخ اتصال‌دهنده

راه‌حل دوم و حیاتی‌تر، Correlation ID است: یک شناسه‌ی یکتا که در ابتدای ورود درخواست به سیستم (معمولاً در Gateway) تولید می‌شود و در تمام فراخوانی‌های بین سرویس‌ها، در یک هدر HTTP منتقل می‌شود:

import uuid
import logging

correlation_id = request.headers.get("X-Correlation-ID", str(uuid.uuid4()))
logging.info("processing order", extra={"correlation_id": correlation_id})

با این شناسه، می‌توان در سیستم لاگ متمرکز، فیلتر کرد و تمام لاگ‌های مربوط به یک درخواست خاص را در همه‌ی سرویس‌ها، به‌ترتیب زمانی، پیدا کرد. بدون Correlation ID، دیباگ کردن مشکلات در سیستم توزیع‌شده شبیه پیدا کردن سوزن در انبار کاه است؛ با آن، مسیر کامل یک درخواست به‌راحتی قابل بازسازی است.

برای ذخیره‌ی پیشرفت و شرکت در آزمون، وارد شوید — رایگان است.