فرض کنید یک آزمون تنش (Stress Test) انجام داده‌اید و بر خلاف پیشبینی سامانه نتوانست بار هزار کاربر همزمان را تحمل کند. مشکل از کجاست؟ برای پیدا کردن مشکل از وارسی شرایط سامانه حین آزمون شروع می‌کنیم. مثلا به دنبال پاسخ این سوال می‌رویم: آیا پردازنده اشباع شده بود یا حافظه؟ برای پاسخ به این گونه سوالات و ریشه‌یابی علت شکست آزمون (Root Cause Analysis) باید حتما سنجه‌های مهم سامانه، حین آزمون پایش شود. برای بیان اهمیت این موضوع گوشه‌ای از کتاب خواندنی «مهندسی اتکاپذیری سامانه؛ چگونه گوگل سیستم‌های پروداکشن خود را اجرا می‌کند» را در ادامه آورده‌ام. هرچند این کتاب به مساله‌ی پایش حین اجرا به شکل عمومی پرداخته است، مطالب آن حین اجرای آزمون کارایی نیز به طریق اولی صادق است.
دلایل بسیاری وجود دارد که پایش سیستم را ایجاب می‌کند:
ما به سطوح مختلفی از هشدار احتیاج داریم. چیزی از کار افتاده است، یک نفر باید همین الان درستش کند! یا چیزی در حال خرابی است، یک نفر باید هر چه سریع‌تر به آن بپردازد.
داشبوردها ابزاری هستند که اطلاعات پایه‌ای را راجع به سرویس ما نمایش می‌دهند.
تاخیر ما همین الان بسیار زیاد شد؛ چه چیز دیگری در همین زمان رخ داده و ممکن است مربوط به آن باشد؟
با نگاهی که از مهندسان گوگل وام گرفتیم، اهمیت پایش سامانه تحت آزمون کارایی مشخص شد. حال اگر این پایش به شکل یکپارچه با راهکار آزمون کارایی باشد، چه بهتر! اما حتی اگر این امکان وجود نداشت، همچنان نباید از خیر راه‌اندازی یک راهکار پایش برای ثبت و دیداری‌سازی سنجه‌های کلیدی سامانه بگذریم وگرنه در تحلیل نتایج آزمون کارایی بینش کاملی از رفتار سامانه نخواهیم داشت.
