پایش چه چیزی را باید اندازه بگیرد؟

تفاوت پایش منابع و پایش سرویس

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

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

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

برای هر سرویس، سه چیز تعریف کنید

طراحی پایش را از ابزار شروع نکنید؛ از این جدول شروع کنید. برای هر سرویس مهم سازمان، سه ستون پر می‌شود:

سنجهٔ سلامت

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

آستانه

از چه عددی به بعد باید هشدار داد؟ آستانه باید از دادهٔ واقعی چند هفته بیاید، نه از حس. آستانه‌ای که روی عدد گرد و دلبخواهی تنظیم شود، یا هیچ‌وقت فعال نمی‌شود یا هر روز فعال می‌شود.

مسئول

هشدار به چه کسی می‌رسد و او چه کاری باید بکند؟ هشداری که به صندوق مشترکی می‌رود که کسی مسئول آن نیست، هشدار نیست؛ ثبت رخداد است.

لایه‌بندی پایش

سنجهٔ سرویس می‌گوید چیزی خراب است؛ برای فهمیدن علت، به لایه‌های زیرین هم نیاز دارید. طرح مؤثر هر سه لایه را دارد و آن‌ها را به هم مرتبط می‌کند:

• لایهٔ سرویس: آزمون کارکرد از دید کاربر — این لایه هشدار می‌دهد.
• لایهٔ میزبان و منابع: پردازنده، حافظه، دیسک، صف ورودی‌خروجی — این لایه علت را روشن می‌کند.
• لایهٔ مسیر و وابستگی: دسترس‌پذیری شبکه، سرویس‌های پیش‌نیاز، نام‌گذاری — این لایه تفکیک می‌کند که مشکل از سرویس است یا از مسیر رسیدن به آن.

بدون لایهٔ سوم، بیشترین زمان عیب‌یابی صرف پاسخ به یک پرسش می‌شود: مشکل از سرویس است یا از شبکه؟ داشتن دادهٔ هم‌زمان از مسیر، این پرسش را در چند ثانیه حل می‌کند.

سیاههٔ متمرکز، و چیزی که به آن اضافه می‌شود

پایش به شما می‌گوید چیزی خراب شد. سیاههٔ رخداد به شما می‌گوید چه اتفاقی افتاد. اگر سیاهه‌ها روی ده سامانهٔ مختلف پراکنده باشند، بررسی یک رویداد به ورود پی‌درپی به ده جا تبدیل می‌شود — و در زمان فشار، این کار انجام نمی‌شود.

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

ترتیب این دو مهم است: تحلیل همبستگی روی سیاههٔ پراکنده کار نمی‌کند. ابتدا تمرکز، سپس تحلیل.

شاخص سلامت خودِ پایش

سامانهٔ پایش هم به سنجه نیاز دارد. دو عدد بیشترین اطلاع را می‌دهند: نسبت هشدارهایی که به اقدام منتهی شده‌اند، و تعداد رویدادهایی که کاربر پیش از سامانهٔ پایش خبر داده است.

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