مشاهده‌پذیری (Observability) چیست؟ تفاوت مانیتورینگ و مشاهده‌پذیری.

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

نکته‌های کلیدی

• مانیتورینگ شرایط شناخته‌شده رو چک می‌کنه و هشدار می‌ده؛ مشاهده‌پذیری اجازه می‌ده از یه سیستم در حال اجرا سؤال‌های جدید بپرسید.
• سه سیگنال اصلی متریک، لاگ و trace هستن و هر کدوم به سؤال‌های متفاوتی جواب می‌دن.
• مشاهده‌پذیری خوب به شناسه‌ها و زمینه‌ی یکسان در هر سه وابسته است.
• مانیتورینگ بیرونی آپتایم ضروری می‌مونه: همون چیزی رو می‌بینه که کاربر می‌بینه، حتی وقتی تله‌متری داخلی خرابه.
• کوچیک شروع کنید: چند متریک معنادار، لاگ ساخت‌یافته و شناسه‌ی درخواست راه زیادی می‌برن.

مانیتورینگ در برابر مشاهده‌پذیری

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

سه سیگنال

متریک

عددها در طول زمان: نرخ درخواست، نرخ خطا، صدک‌های تأخیر، CPU، طول صف. ذخیره‌ی متریک ارزونه و کوئریش سریع، برای همین ستون فقرات هشدار و داشبوردهاست. محدودیتش جزئیاته: متریک می‌گه نرخ خطا بالا رفت، نه اینکه کدوم مشتری یا کدوم مسیر کد درگیر بود.

لاگ

ثبت رویدادهای تکی با زمینه. توضیح می‌ده در یه درخواست یا کار مشخص چه اتفاقی افتاد. لاگ ساخت‌یافته اون‌ها رو به‌جای grep کردن، قابل کوئری می‌کنه.

Trace

یه trace یه درخواست رو در همه‌ی سرویس‌هایی که بهشون سر می‌زنه دنبال می‌کنه و هر مرحله (یه «span») رو با زمانش ثبت می‌کنه. traceها در سیستم‌های توزیع‌شده به سؤال‌های «زمان کجا رفت؟» و «کدوم تماس پایین‌دستی شکست خورد؟» جواب می‌دن. Tracing توزیع‌شده رو ببینید.

چی این‌ها رو به هم وصل می‌کنه؟

سیگنال‌ها وقتی قدرتمند می‌شن که بتونید بینشون جابه‌جا بشید:

• از یه هشدار روی یه متریک (بالا رفتن نرخ خطای پرداخت)،
• به traceهای درخواست‌های پرداخت ناموفق،
• به لاگ‌های دقیقاً همون درخواستی که شکست خورد، از روی trace ID.

این کار زمینه‌ی مشترک لازم داره: اسم سرویس‌ها و برچسب‌های محیط یکسان و یه شناسه‌ی trace یا درخواست در هر خط لاگ. OpenTelemetry به روش رایج و مستقل از فروشنده برای تولید هر سه تبدیل شده.

جای مانیتورینگ آپتایم کجاست؟

تله‌متری داخلی یه نقطه‌ی کور داره: فقط چیزی رو می‌تونه توصیف کنه که به سیستم شما می‌رسه. اگه DNS خراب باشه، گواهی منقضی شده باشه، لودبالانسر قطع باشه یا مسیر شبکه بین کاربرها و دیتاسنتر شما شکست بخوره، متریک‌هاتون ممکنه کاملاً آروم به نظر برسن؛ چون اصلاً ترافیکی نمی‌رسه.

چک‌های بیرونی این شکاف رو پر می‌کنن:

• چک‌های سایت و API از چند شهر تأیید می‌کنن کاربرها بهتون می‌رسن.
• چک‌های SSL، دامنه و DNS خرابی‌های بیرون از سرورهاتون رو پیدا می‌کنن.
• چک‌های Heartbeat تأیید می‌کنن کارهای پس‌زمینه واقعاً انجام می‌شن.

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

شروع بدون یه پروژه‌ی بزرگ

1. برای هر سرویس چهار سیگنال طلایی انتخاب کنید: ترافیک، خطا، تأخیر و اشباع.
2. لاگ‌ها رو ساخت‌یافته و با شناسه‌ی درخواست بنویسید.
3. tracing رو به شلوغ‌ترین مسیر درخواست اضافه کنید، نه همه‌جا یکجا.
4. روی هر چیزی که کاربر باهاش سروکار داره مانیتورینگ بیرونی آپتایم بذارید.
5. هر رخداد رو مرور کنید: کدوم سیگنال علت رو سریع‌تر نشون می‌داد؟ بعدی همون رو اضافه کنید.

پرسش‌های پرتکرار

• مشاهده‌پذیری فقط برای میکروسرویس‌هاست؟

  +

  نه، ولی اونجا بیشترین سود رو داره. یه برنامه‌ی تکی روی یه سرور با متریک و لاگ خوب راه زیادی می‌ره؛ tracing وقتی ضروری می‌شه که درخواست‌ها از چند سرویس رد بشن.

• مشاهده‌پذیری جای مانیتورینگ رو می‌گیره؟

  +

  نه. هنوز روی شرایط شناخته‌شده هشدار لازم دارید. مشاهده‌پذیری بررسی همون هشدارها (و غافلگیری‌ها) رو سریع‌تر می‌کنه.

• کاردینالیتی بالا چیه و چرا مهمه؟

  +

  یعنی یه فیلد مقدارهای متمایز زیادی داره، مثل شناسه‌ی کاربر. چنین فیلدهایی در لاگ و trace بی‌نهایت ارزشمندن، ولی می‌تونن سیستم‌های متریک رو گرون یا کند کنن؛ پس اون‌ها رو از برچسب‌های متریک بیرون نگه دارید.