Observability چیست؟ مانیتورینگ لحظه‌ای سایت با Metric، Log و Trace

مانیتورینگ لحظه‌ای یعنی بتوانید پیش از حدس‌زدن پاسخ دهید: کدام کاربر، کدام مسیر، از چه نسخه‌ای و در کدام وابستگی کند یا خطادار شده است؟ یک نمودار CPU یا پیام «سایت بالا است» برای این کار کافی نیست. سامانه باید Metric، Log و Trace را با زمینه مشترک جمع کند، اثر را با SLO بسنجد و فقط وقتی اقدام انسانی لازم است هشدار دهد.

این مقاله بر Observability یا مشاهده‌پذیری داخل سامانه تمرکز دارد. اگر هدف شما این است که از بیرون بفهمید دامنه، گواهی یا صفحه Down شده، راهنمای مانیتورینگ آپتایم و Synthetic Check را بخوانید. بهترین معماری هر دو دید را کنار هم دارد.

Observability چیست؟

مشاهده‌پذیری توان درک وضعیت داخلی سامانه از خروجی‌هایی است که منتشر می‌کند. Monitoring معمولاً سؤال‌های ازپیش‌تعریف‌شده را جواب می‌دهد—مثلاً نرخ خطا از حد گذشته؟ Observability باید امکان پرسیدن سؤال تازه هنگام رخداد ناشناخته را نیز بدهد—مثلاً چرا فقط کاربران یک نسخه موبایل در پرداخت با latency بالا روبه‌رو هستند؟

راهنمای OpenTelemetry این توان را به Instrumentation وابسته می‌داند: برنامه باید Signalهایی مانند Trace، Metric و Log تولید کند تا تیم بدون افزودن فوری کد جدید بتواند رخداد را بررسی کند.

مانیتورینگ لحظه‌ای با «Real-time» تبلیغاتی فرق دارد

هیچ زنجیره Telemetry کاملاً بی‌تأخیر نیست. داده جمع، Buffer، پردازش، منتقل و Index می‌شود. سؤال درست این است: «تأخیر End-to-End داده و هشدار برای این SLO چقدر است و آیا در بازه واکنش موردنیاز قرار دارد؟»

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

چهار Signal اصلی: Metric، Log، Trace و Profile

Metric

اندازه‌گیری عددی در طول زمان است: نرخ درخواست، خطا، latency، CPU، طول صف یا تعداد پرداخت موفق. Metric برای Trend، Dashboard و Alert مناسب است، اما معمولاً جزئیات یک درخواست خاص را ندارد.

Log

رکورد یک Event است: شروع Deploy، خطای اعتبارسنجی، Timeout درگاه یا تغییر تنظیم. Log ساختاریافته با فیلدهای ثابت—زمان، سرویس، محیط، نسخه، severity، request_id و trace_id—از متن آزاد قابل‌جست‌وجوتر است.

Trace

مسیر یک درخواست را میان سرویس‌ها به Span تقسیم می‌کند. Trace نشان می‌دهد تأخیر در CDN، API، دیتابیس، Queue یا سرویس پرداخت رخ داده و کدام عملیات والد/فرزند بوده است. برای سامانه توزیع‌شده، Propagation درست Context حیاتی است.

Profile

مصرف CPU، حافظه و Stackهای کد را در سطح تابع نشان می‌دهد و برای مسئله‌ای مفید است که Metric آن را آشکار کرده اما Trace علت اجرای پرهزینه را دقیق نمی‌کند. Profiling پیوسته باید با سربار و حریم خصوصی کنترل شود.

مستندات جاری Signalهای OpenTelemetry از Trace، Metric، Log و Baggage پشتیبانی می‌کند و Profiles را نیز در مسیر توسعه استاندارد معرفی کرده است.

سه دید مکمل: Black-box، White-box و RUM

هرکدام Blind Spot دارد. Synthetic ممکن است داده یا دستگاه واقعی را نبیند؛ White-box ممکن است با خاموشی کامل همراه سیستم از دسترس خارج شود؛ RUM بدون ترافیک داده ندارد و با Ad blocker یا رضایت کاربر محدود می‌شود. ترکیب آن‌ها تصویر قابل‌اعتمادتر می‌سازد.

چه چیزهایی را اندازه بگیریم؟ چهار Golden Signal

کتاب Site Reliability Engineering گوگل چهار Signal را برای سرویس آنلاین برجسته می‌کند:

• Latency: زمان پاسخ؛ پاسخ موفق و ناموفق را جدا و Distribution/Percentile را ببینید.
• Traffic: میزان تقاضا مانند درخواست بر ثانیه، Session یا تراکنش.
• Errors: خطای صریح، پاسخ اشتباه و درخواست کندتر از SLO.
• Saturation: نزدیکی به سقف منابع مانند CPU، حافظه، Connection Pool یا Queue.

میانگین latency می‌تواند تعداد کمی درخواست بسیار کند را پنهان کند. صدک ۵۰، ۹۵ و ۹۹ و تفکیک endpoint/منطقه/نسخه به تصمیم بهتر کمک می‌کند—بدون آنکه Labelهای کنترل‌نشده هزینه و Cardinality را منفجر کنند.

RED و USE؛ دو روش برای پوشش بهتر

RED برای سرویس درخواست‌محور

• Rate: نرخ درخواست؛
• Errors: نرخ/نسبت خطا؛
• Duration: توزیع مدت پاسخ.

برای API، وب و Worker مصرف‌کننده پیام مناسب است.

USE برای منابع

• Utilization: میزان استفاده؛
• Saturation: صف یا تقاضای منتظر؛
• Errors: خطاهای منبع.

برای CPU، دیسک، شبکه و Poolها مفید است. RED درد کاربر را نزدیک‌تر و USE علت ظرفیت را بهتر نشان می‌دهد؛ یکی جای دیگری را نمی‌گیرد.

SLI و SLO را از مسیر کاربر بسازید

برای «سایت» یک SLO کلی تعریف نکنید اگر رفتار صفحه مقاله، Login و پرداخت متفاوت است. نمونه:

Error Budget فاصله میان هدف SLO و ۱۰۰٪ است. مصرف سریع Budget نشانه‌ای عملی برای کاهش ریسک انتشار یا تمرکز روی پایداری است؛ نه بهانه‌ای برای مخفی‌کردن خطا با تغییر تعریف.

معماری زنجیره Observability

1. Instrumentation: کد، Runtime، وب‌سرور و دیتابیس Signal تولید می‌کنند.
2. Collection: Agent/Collector داده را دریافت می‌کند.
3. Processing: Batch، Filter، Redaction، Sampling و Enrichment اعمال می‌شود.
4. Export: داده به یک یا چند Backend ارسال می‌شود.
5. Storage: Metric، Log و Trace بر اساس Retention و Index نگه‌داری می‌شوند.
6. Query/Dashboard: تیم به SLO، Release و Dependency نگاه می‌کند.
7. Alert/Incident: شرط قابل‌اقدام به On-call و Runbook متصل می‌شود.

Collector را نقطه شکست تازه نسازید: Buffer، Queue، محدودیت حافظه، Backpressure و Drop counter خود آن باید مانیتور شود. اگر Telemetry هنگام بحران حذف شود، ارزشش دقیقاً در مهم‌ترین لحظه از بین می‌رود.

OpenTelemetry چه مسئله‌ای را حل می‌کند؟

OpenTelemetry API، SDK، Semantic Convention و Collector برای تولید و انتقال Telemetry استاندارد ارائه می‌دهد. هدف، کاهش وابستگی Instrumentation به یک Backend خاص است؛ به این معنا نیست که مهاجرت بین فروشندگان کاملاً بدون کار خواهد بود. Query language، Dashboard، Alert و هزینه ذخیره‌سازی همچنان متفاوت‌اند.

برای شروع:

• Automatic Instrumentation را برای HTTP، Runtime و دیتابیس فعال کنید.
• نام سرویس، Environment و نسخه Deploy را استاندارد کنید.
• Trace Context را در HTTP، Queue و Job منتقل کنید.
• Span سفارشی فقط برای عملیات مهم کسب‌وکار اضافه کنید.
• Attribute حساس یا پرکاردینال را پیش از Export حذف کنید.
• نرخ Drop و Export failure را مانیتور کنید.

Cardinality؛ هزینه پنهان Metric

هر ترکیب Label یک Time Series جدا می‌سازد. اگر user_id، URL خام با شناسه، IP یا request_id را Label متریک کنید، تعداد Series می‌تواند به‌سرعت رشد و Query/Storage را گران کند. این داده‌ها معمولاً جای‌شان در Log یا Trace است.

Labelهای مناسب تعداد محدودی مقدار قابل‌کنترل دارند: سرویس، محیط، منطقه، وضعیت، روش HTTP و Route الگو. به‌جای /orders/12345 از /orders/:id استفاده کنید.

Logging ساختاریافته بدون نشت داده

Log باید برای عملیات مفید و از نظر امنیتی حداقلی باشد:

• Timestamp با Zone/UTC روشن و همگام‌سازی ساعت؛
• Severity استاندارد و Message کوتاه؛
• service، environment، version، host/region؛
• request_id و trace_id برای Correlation؛
• کد خطای پایدار و فیلدهای زمینه محدود؛
• عدم ثبت رمز، توکن، Cookie، CVV، بدنه کامل پرداخت یا داده شخصی غیرضروری.

Redaction را نزدیک منبع و دوباره در Collector اعمال کنید. دسترسی به Log، Retention و Export باید Audit شود. Observability جایگزین SIEM یا کنترل‌های امنیت برنامه نیست؛ برای پیشگیری از حملات رایج، راهنمای مقابله با SQL Injection و XSS را ببینید.

Tracing و Sampling

ذخیره صددرصد Trace در ترافیک بالا معمولاً ضروری یا اقتصادی نیست. روش‌ها:

• Head Sampling: تصمیم در ابتدای Trace؛ سبک‌تر اما ممکن است خطای نادر را از دست بدهد.
• Tail Sampling: تصمیم پس از مشاهده Spanها؛ حفظ Trace کند/خطادار بهتر، ولی Collector و Buffer بیشتری می‌خواهد.
• Rule-based: نگهداری همه خطاها، endpoint حیاتی یا نسخه تازه و نمونه کمتر از ترافیک عادی.

Sampling باید در گزارش نرخ خطا و SLO لحاظ شود. Metricهای شمارنده را از Trace نمونه‌برداری‌شده مشتق نکنید مگر روش آماری را دقیق می‌دانید.

هشدار: از درد کاربر به علت برسید

Alert Page باید urgent، مهم، واقعی و قابل‌اقدام باشد. راهنمای Prometheus توصیه می‌کند Alert روی symptom نزدیک به کاربر—مانند نرخ خطا و latency بالای لایه سرویس—باشد و Dashboard برای یافتن علت استفاده شود.

برای شرایط ناپایدار از مدت for، Grouping و Inhibition استفاده کنید. یک خرابی دیتابیس نباید برای هر API یک Page جدا بسازد. در مقابل، هشدار نباید آن‌قدر تأخیر داشته باشد که Budget تمام شود.

Dashboard خوب برای چه مخاطبی است؟

نمای کسب‌وکار و SLO

دسترس‌پذیری، تراکنش موفق، Error Budget، بازار متاثر و روند هفتگی/ماهانه. برای مدیر، صدها Metric زیرساخت کمکی نمی‌کند.

نمای عملیات

Golden Signals، Deploy marker، منطقه، نسخه، Dependency و ظرفیت. باید در چند دقیقه دامنه اثر را روشن کند.

نمای تشخیص

Query عمیق Log/Trace/Profile و Drill-down بر Route، Error code و Dependency. این صفحه برای Incident و مهندس سرویس است.

Dashboard را همراه تغییر معماری و سرویس‌ها بازبینی کنید. نمودار بدون مالک و تصمیم مشخص، هزینه نگهداری است.

RUM برای تجربه واقعی کاربر

RUM داده مرورگر واقعی را درباره Core Web Vitals، Navigation، خطای JavaScript، دستگاه و شبکه جمع می‌کند. آن را با ملاحظات رضایت و حریم خصوصی پیاده کنید. Session replay یا ضبط ورودی بدون Masking می‌تواند داده حساس را افشا کند.

برای ایران، تفکیک اپراتور، شهر/منطقه در حد مجاز، دستگاه و نسخه مرورگر ارزشمند است. میانگین جهانی ممکن است اختلال یک اپراتور را پنهان کند. از IDهای ناشناس و Retention محدود استفاده کنید.

مثال: Observability فروشگاه ایرانی

یک مسیر خرید را از مرورگر تا پرداخت دنبال کنید:

1. RUM زمان تعامل و خطای JavaScript صفحه محصول را ثبت می‌کند.
2. Trace درخواست افزودن به سبد را با API، Redis و دیتابیس مرتبط می‌کند.
3. Metric نرخ خطا و latency را بر Route و نسخه Deploy نشان می‌دهد.
4. Log ساختاریافته کد خطا و شناسه سفارش غیرحساس را ثبت می‌کند.
5. Span پرداخت زمان تماس با PSP و Retry را جدا نشان می‌دهد.
6. Metric کسب‌وکار نتیجه نهایی موفق/ناموفق/نامشخص را می‌شمارد.
7. Alert بر کاهش موفقیت پرداخت یا Burn Rate SLO فعال می‌شود.

اگر فقط CPU سرور را ببینید، خطای منطقی «پرداخت ثبت شد ولی سفارش نهایی نشد» ممکن است پنهان بماند. KPI فنی و کسب‌وکار باید با Correlation مناسب کنار هم باشند.

Observability در وردپرس و سایت کوچک

برای شروع لازم نیست سامانه پیچیده بسازید:

• Uptime بیرونی برای صفحه اصلی، Login و endpoint سلامت؛
• لاگ PHP/وب‌سرور ساختاریافته با Rotation و دسترسی محدود؛
• متریک نرخ درخواست، 4xx/5xx، TTFB، PHP workers و Query کند؛
• APM روی درصد کنترل‌شده برای Transactionهای مهم؛
• RUM/Core Web Vitals برای کاربران واقعی؛
• Deploy marker و نسخه افزونه/پوسته در رخدادها؛
• هشدار ساده روی خطا و latency کاربرمحور.

هدف، پاسخ سریع به سؤال است نه نصب بیشترین Agent. هر Signal باید مالک، Retention و تصمیمی که پشتیبانی می‌کند داشته باشد.

خرید SaaS یا ساخت Self-hosted؟

PoC را با حجم واقعی انجام دهید. هزینه فقط ingest نیست: cardinality، retention، egress، query، seat، archive و بازگردانی داده نیز اثر دارند.

نقشه اجرای ۳۰روزه

هفته ۱: مسیر و SLO

سه مسیر حیاتی، SLI، مالک و Error Budget را تعریف کنید. Uptime بیرونی و Alert پایه را فعال کنید.

هفته ۲: Metric و Log

Golden Signals، نسخه Deploy، Log ساختاریافته و Correlation ID را اضافه کنید. داده حساس و Cardinality را بازبینی کنید.

هفته ۳: Trace و RUM

یک مسیر پرتأثیر را End-to-End Trace و RUM را برای صفحات نماینده فعال کنید. Sampling و Retention را با هزینه بسنجید.

هفته ۴: Incident و تمرین

Dashboard، Alert، On-call و Runbook را متصل کنید. یک failure کنترل‌شده یا Game Day اجرا و Gapها را به Backlog ببرید. ارتباط این کار با CI/CD را در راهنمای Pipeline و انتشار امن ببینید.

چک‌لیست مانیتورینگ لحظه‌ای

• مسیرهای حیاتی و SLI/SLO کاربرمحور داریم.
• Black-box، White-box و RUM نقش روشن دارند.
• Metric، Log و Trace با service/version/trace_id مرتبط می‌شوند.
• Golden Signals و KPI کسب‌وکار کنار هم دیده می‌شوند.
• Label پرکاردینال و داده حساس حذف شده است.
• Sampling، Retention و هزینه مستندند.
• Alertهای Page کم، فوری و قابل‌اقدام‌اند.
• Dashboard به مخاطب و تصمیم مشخص متصل است.
• Collector، Pipeline و مسیر اعلان خود مانیتور می‌شوند.
• Deploy marker و Rollback در Timeline رخداد وجود دارد.
• Runbook، On-call، Status Page و Postmortem تمرین می‌شوند.
• انباشت مشکل‌های Observability به دفتر بدهی فنی وارد می‌شود.

سؤالات متداول Observability

تفاوت Monitoring و Observability چیست؟

Monitoring معمولاً شرایط شناخته‌شده را می‌سنجد و هشدار می‌دهد. Observability با Telemetry کافی امکان بررسی سؤال‌های تازه و علت رخدادهای ناشناخته را فراهم می‌کند. در عمل به هر دو نیاز دارید.

Metric، Log یا Trace؛ از کدام شروع کنیم؟

برای سرویس کوچک، Uptime بیرونی، Golden Metrics و Log ساختاریافته شروع خوبی است. سپس برای مسیرهای پیچیده یا توزیع‌شده Trace و RUM را اضافه کنید. انتخاب به سؤال عملی وابسته است.

آیا OpenTelemetry خودش ابزار مانیتورینگ است؟

OpenTelemetry استاندارد و ابزار تولید/جمع‌آوری/انتقال Telemetry است؛ Backend ذخیره‌سازی، Query، Dashboard و Incident را به‌تنهایی جایگزین نمی‌کند.

چرا هزینه Observability زیاد می‌شود؟

حجم Log، Labelهای پرکاردینال، Trace بدون Sampling، Retention بلند و Query پرهزینه عامل‌های رایج‌اند. داده را بر اساس تصمیم، امنیت و ارزش نگه‌داری کنید.

چه هشدارهایی باید On-call را بیدار کنند؟

فقط رخداد فوری، مهم، واقعی و قابل‌اقدام با اثر کاربر—مانند Burn Rate بالای SLO یا اختلال پرداخت. علت‌های تشخیصی و ظرفیت آینده معمولاً Ticket یا Dashboard هستند.

جمع‌بندی

مشاهده‌پذیری با خرید Dashboard ایجاد نمی‌شود. باید مسیر کاربر و SLO را تعریف کنید، Signalها را با Context مشترک بسازید، هزینه و حریم خصوصی را کنترل کنید و Alert را به Runbook و مالک وصل سازید. نتیجه خوب، کاهش زمان حدس‌زدن و تصمیم دقیق‌تر هنگام تغییر و Incident است.

برای طراحی SLI/SLO، انتخاب پشته Telemetry یا کاهش نویز هشدارها، در فرم مشاوره مایندیو معماری سرویس، حجم ترافیک و نمونه رخداد را ارسال کنید.