رفتن به محتوا
بایت

00001001

هرچه بگندد نمکش می‌زنند، وای به روزی که بگندد نمک

چرا مانیتورینگ هم باید مانیتور شود و چطور زیرساخت پایش چندلایه طراحی کنیم

۴ دقیقه مطالعه

در دنیای زیرساخت نرم‌افزاری، واژه‌هایی مانند و ، دیگر فقط شعارهای مهندسی نیستند؛ بلکه شرط زنده ماندن یک سامانه در محیط‌های واقعی‌اند. همۀ ما می‌دانیم که اگر بخواهیم سیستم‌هایمان بدون وقفه کار کنند، باید ابزارهایی برای مانیتور کردن آن‌ها داشته باشیم، اما کم‌تر پیش می‌آید کسی از خودش بپرسد: «اگر خود سیستم مانیتورینگ از کار بیفتد، چه خواهد شد؟»

این‌جاست که معنای دقیق آن ضرب‌المثل قدیمی به چشم می‌آید: «هرچه بگندد نمکش می‌زنند، وای به روزی که بگندد نمک!»

گام نخست: جداسازی زیرساخت مانیتورینگ از زیرساخت اصلی

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

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

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

این لایۀ ثانویه ممکن است چیزی به‌سادگی یک Blackbox Exporter، یک VPS با اسکریپت‌های ping و health check یا حتی یک سرویس خارجی مانند UptimeRobot باشد که فقط بررسی می‌کند آیا اندپوینت‌های حیاتی پرومتئوس، گرافانا یا مدیریت‌کنندۀ هشدار در دسترس هستند یا نه. اگر این سرویس‌ها پاسخ‌گو نباشند، این سامانۀ کوچک باید بتواند از مسیرهای جایگزین مثل پیامک، تماس تلفنی یا ایمیل از سرور خارجی هشدار ارسال کند.

به بیان دیگر، سیستم مانیتورینگ هم باید مانیتور شود.

این همان اصل ساده‌ای است که در بسیاری از طراحی‌ها نادیده گرفته می‌شود؛ اما در لحظۀ بحران، مرز بین آگاهی و نابینایی کامل است.

معماری پیشنهادی برای مانیتورینگ چند‌لایه

یک طراحی بهینه برای مانیتورینگ پایدار می‌تواند سه لایه داشته باشد.

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

این سه‌لایه بودن باعث می‌شود حتی در بدترین سناریوها، همیشه یک نقطۀ دید خارجی باقی بماند که بتواند تشخیص دهد چه چیزی از کار افتاده و تیم فنی را مطلع سازد.

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

به زبان ساده، در دنیای فناوری هم مانند زندگی، همیشه باید به این فکر کرد که اگر روزی «نمک» بگندد چه باید کرد.

سیستم مانیتورینگ ما همان نمک است؛ حافظ سلامت بقیه. و اگر خودش از کار بیفتد، دیگر هیچ سازوکاری برای فهمیدن خرابی‌ها باقی نمی‌ماند. پس بیایید همان‌قدر که برای نظارت بر دیگران تلاش می‌کنیم، برای نظارت بر «ناظر» نیز تدبیر بیندیشیم، چرا که در مهندسی زیرساخت، هیچ چیز خطرناک‌تر از دیده‌بانی نیست که کسی حواسش به او نیست.

مطالب مرتبط