سرور روشن است؛ سرویس واقعاً کار می‌کند؟

منبع مفهومی: Monitoring Distributed Systems — Google SRE. طرح پایش و مثال زیر، پیشنهاد مستقل برای یک محیط کوچک است.

ممکن است سرور به ping پاسخ دهد اما کاربر نتواند یک گزارش را باز کند. این تناقض نیست؛ ما دو چیز متفاوت را اندازه گرفته‌ایم. از نظر من، پایش باید دست‌کم یک پاسخ روشن به این سؤال بدهد: «کار اصلی کاربر هنوز انجام می‌شود؟»

سلامت را لایه‌به‌لایه تعریف کنیم

هیچ‌کدام به‌تنهایی سلامت تمام سیستم را تضمین نمی‌کند. حتی یک پاسخ موفق HTTP ممکن است فقط صفحه خطای خوش‌ظاهر برنامه باشد؛ محتوای موردانتظار و زمان پاسخ را هم تعریف کنید.

با یک سناریوی کوچک شروع کنیم

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

اگر برنامه مسیر آمادگی جدا دارد، وابستگی‌های ضروری آن را هم بسنجید. بااین‌حال وابسته‌کردن بررسی زنده‌بودن فرایند به همه سرویس‌های بیرونی ممکن است هنگام خرابی یک وابستگی، راه‌اندازی‌های مجدد بی‌فایده ایجاد کند. تصمیم «آماده پذیرش درخواست است؟» با تصمیم «فرایند باید دوباره اجرا شود؟» یکسان نیست.

هشدار باید مقصد و اقدام داشته باشد

• چه کاری برای کاربر ناموفق شده است؟
• خرابی از چه زمانی و از کدام محل بررسی دیده می‌شود؟
• مسئول پاسخ‌گویی کیست و اولین بررسی پیشنهادی چیست؟

پیشنهاد من این است که ابتدا یک هشدار مفید بسازیم و بعد تعداد نمودارها را بیشتر کنیم. داشبوردی که همه چراغ‌هایش سبز است ولی کاربر ناراضی است، احتمالاً سؤال اشتباه را پایش می‌کند.

مطالعه مرتبط: قالب مستند سرویس.