Monitoring & Observability
مانیتورینگ و Observability
سامانهای که همهچیز را هشدار میدهد، معادل سامانهای است که هیچچیز را هشدار نمیدهد.
معرفی تخصصی
مانیتورینگ و Observability در عمل چه کاری انجام میدهد
تفاوت سازمانی که زیرساختش را میبیند با سازمانی که نمیبیند، در لحظهٔ خرابی معلوم نمیشود؛ چند ساعت پیش از آن معلوم میشود. بیشتر قطعیهای پرهزینه نشانههای قبلی داشتهاند: دیسکی که آرام پر شده، سرویسی که نرخ خطایش بالا رفته، لینکی که مرتب بالا و پایین شده است.
پایش یعنی این نشانهها دیده شوند و به دست کسی برسند که میتواند کاری بکند. این دو شرط با هم لازماند؛ داشبوردی که کسی نگاهش نمیکند و هشداری که همه یاد گرفتهاند نادیده بگیرند، هر دو بیاثرند.
به همین دلیل طراحی ما از آستانهها شروع میشود، نه از ابزار: چه چیزی واقعاً غیرعادی است، چه کسی باید بداند، و چه اقدامی از او انتظار میرود.
مسئله
چه مشکلی را حل میکند
دو حالت افراطی رایج است. در یکی هیچ پایشی وجود ندارد و خرابی را کاربر گزارش میکند. در دیگری ابزار پایش نصب شده اما با تنظیمات پیشفرض، و آنقدر هشدار بیاهمیت تولید میکند که تیم فنی اعلانها را خاموش کرده است.
حالت دوم خطرناکتر است، چون سازمان تصور میکند پوشش دارد در حالی که عملاً ندارد.
- اطلاع از خرابی تنها پس از تماس کاربران
- هشدارهای پرتعداد و بیاهمیت که به بیتوجهی تیم فنی منجر شده است
- نبود دید روی روند مصرف و ظرفیت برای برنامهریزی آینده
- لاگهایی که نگهداری نمیشوند و پس از حادثه قابل بررسی نیستند
- پایش محدود به سرورها، بدون پوشش تجهیزات شبکه و سرویسهای حیاتی
- نبود تعریف روشن از اینکه هر هشدار به چه کسی میرسد و چه اقدامی لازم دارد
کاربرد سازمانی
کجا به این خدمت نیاز پیدا میشود
پایش سلامت زیرساخت
اندازهگیری وضعیت سرورها، ذخیرهسازی، تجهیزات شبکه و تغذیه، با آستانهٔ متناسب با هر کدام.
پایش در دسترس بودن سرویس
بررسی اینکه سرویس از دید کاربر کار میکند، نه صرفاً اینکه فرایندش در حال اجراست.
برنامهریزی ظرفیت
تحلیل روند مصرف برای پیشبینی زمان رسیدن به سقف و برنامهریزی ارتقا پیش از فشار.
بررسی پس از حادثه
نگهداشت شاخص و لاگ برای بازسازی زنجیرهٔ رویدادها و یافتن علت ریشهای.
معماری پیشنهادی
ساختاری که پیشنهاد میکنیم
سامانهٔ پایش در چهار لایه ساخته میشود؛ لایهٔ چهارم همان جایی است که بیشتر پیادهسازیها متوقف میمانند و به همین دلیل بیاثر میشوند.
برای دیدن کامل نمودار، آن را به چپ و راست بکشید.
- جمعآوریبرداشت شاخص از سرورها، ماشینهای مجازی، تجهیزات شبکه و سرویسها، با بازهٔ متناسب با سرعت تغییر هر شاخص.
- انباره و نگهداشتذخیرهٔ شاخصها و لاگ با سیاست نگهداشت مشخص، بهگونهای که بررسی پس از حادثه ممکن باشد.
- تحلیل و آستانهتعریف آستانه بر پایهٔ رفتار عادی هر سرویس، نه یک عدد عمومی برای همه.
- هشدار و مسیر اقدامتعیین اینکه هر هشدار به چه کسی میرسد، از چه مسیری، و چه اقدامی از او انتظار میرود.
قابلیتها
اجزا و قابلیتهای فنی
تعریف شاخصهای معنادار
انتخاب آنچه واقعاً وضعیت سرویس را نشان میدهد، بهجای جمعآوری هر چیز قابل اندازهگیری.
آستانهگذاری بر پایهٔ رفتار واقعی
تعیین آستانه پس از مشاهدهٔ رفتار عادی سرویس در یک بازهٔ کامل، شامل ساعات اوج.
کاهش نویز هشدار
گروهبندی هشدارهای وابسته و حذف موارد تکراری، تا هر اعلان واقعاً قابل اقدام باشد.
داشبورد وضعیت
نمای کلی قابل فهم برای تیم فنی و نمای خلاصه برای مدیریت، با سطح جزئیات متفاوت.
نگهداشت و جستوجوی لاگ
تجمیع لاگ سرویسهای کلیدی با امکان جستوجو، برای بررسی پس از حادثه.
گزارش روند و ظرفیت
گزارش دورهای از روند مصرف و نقاط نزدیک به سقف ظرفیت، بهعنوان ورودی تصمیمهای خرید.
مزیتها
چه چیزی در عملیات روزمره تغییر میکند
اطلاع پیش از کاربر
تیم فنی پیش از رسیدن مشکل به کاربر خبردار میشود.
هشدار قابل اعتماد
وقتی اعلان کم و معنادار باشد، جدی گرفته میشود.
تصمیم بر پایهٔ داده
ارتقای ظرفیت از روند مصرف میآید، نه از حدس.
بررسی ممکن پس از حادثه
با نگهداشت شاخص و لاگ، میتوان گفت چه شد؛ نه اینکه حدس زد.
سناریوهای استفاده
سه وضعیت پرتکرار و پاسخ ما به آنها
این سناریوها الگوی طراحیاند، نه شرح پروژههای انجامشده؛ برای هر سازمان با اندازهگیری وضعیت واقعی بازنویسی میشوند.
- وضعیت
سازمانی که ابزار پایش نصب کرده اما بهدلیل حجم بالای هشدارهای بیاهمیت، اعلانها خاموش شده است.
رویکردبازبینی کامل آستانهها بر پایهٔ رفتار واقعی هر سرویس، گروهبندی هشدارهای وابسته و تعریف مسیر اقدام برای هر اعلان.
نتیجهٔ مورد انتظارتعداد هشدارها بهشدت کاهش و اعتبارشان بازمیگردد؛ اعلان دوباره معنا پیدا میکند.
- وضعیت
توقفهای مقطعی یک سامانه که هر بار بهصورت موردی حل شده و علت ریشهای آن مشخص نیست.
رویکردفعالسازی نگهداشت شاخص و لاگ، و بررسی همزمانی رویدادها در بازهٔ وقوع توقفها.
نتیجهٔ مورد انتظارالگوی تکرارشونده شناسایی و علت در لایهٔ درست برطرف میشود، بهجای رفع موقت هر بار.
مراحل اجرا
از ارزیابی تا بهرهبرداری
تعیین دامنه و شاخصها
مشخص کردن سرویسهای تحت پایش و شاخصهایی که وضعیت هر کدام را واقعاً نشان میدهند.
پیادهسازی جمعآوری
برپایی بستر پایش، اتصال منابع داده و تعریف سیاست نگهداشت.
آستانهگذاری و هشدار
مشاهدهٔ رفتار عادی، تعریف آستانه و تنظیم مسیر اطلاعرسانی برای هر دسته رویداد.
تحویل و تنظیم مستمر
تحویل داشبوردها و مستندات، و بازبینی دورهای آستانهها بر اساس تغییرات زیرساخت.
فناوریها
سکوها و فناوریهای مرتبط
فهرست فناوریهایی که در این حوزه با آنها کار میکنیم. انتخاب نهایی در مرحلهٔ طراحی و بر پایهٔ وضعیت موجود سازمان انجام میشود.
- Zabbix
- Prometheus + Grafana
- SNMP
- Netdata
- Loki / Elasticsearch
- Uptime Monitoring
پرسشهای متداول — مانیتورینگ و Observability
پایش چه چیزهایی را باید پوشش دهد؟
در حداقل کاربردی: منابع سرورها، فضای دیسک، سلامت ذخیرهساز، وضعیت تجهیزات شبکه، در دسترس بودن سرویسهای کلیدی و موفقیت اجرای بکاپ. دامنهٔ دقیق بر اساس سرویسهای حیاتی سازمان شما تعیین میشود.
تفاوت مانیتورینگ با Observability چیست؟
مانیتورینگ به پرسشهای از پیش تعریفشده پاسخ میدهد: آیا این سرویس بالاست، آیا دیسک پر شده. Observability یعنی دادهای که نگه میدارید اجازه دهد پرسشهای تازه هم پاسخ بگیرند؛ مثل اینکه چرا دیروز ساعت ده کندی رخ داد. دومی نیازمند نگهداشت شاخص و لاگ با جزئیات کافی است.
آیا پایش بار اضافه روی سرورها ایجاد میکند؟
سربار جمعآوری شاخص در حالت متعارف ناچیز است. آنچه میتواند اثر بگذارد، بازهٔ برداشت بیش از حد کوتاه یا جمعآوری دادههای غیرضروری است؛ به همین دلیل بازهٔ هر شاخص متناسب با سرعت تغییر آن تعیین میشود.
هشدارها به چه صورت به ما میرسند؟
مسیر اطلاعرسانی بر اساس ساختار تیم شما و شدت رویداد تعریف میشود. نکتهٔ مهم این است که برای هر دسته هشدار مشخص باشد چه کسی مسئول است و چه اقدامی انتظار میرود؛ وگرنه اعلان به نویز تبدیل میشود.
خدمات مرتبط
دربارهٔ مانیتورینگ و Observability در سازمان خود صحبت کنیم
در جلسهٔ تخصصی، وضعیت فعلی، محدودیتها و اهداف قابل اندازهگیری شما بررسی میشود و تصویر روشنی از معماری پیشنهادی و مراحل اجرا ارائه میگردد.