پایش SQL Server: چه چیزی را ببینیم و کجا هشدار بدهیم

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

این مقاله دربارهٔ حالت سوم است: کم، دقیق، و قابل اعتماد.

قاعدهٔ اول: هر هشدار باید یک کار مشخص داشته باشد

پیش از گذاشتن هر هشدار، این را از خودتان بپرسید: «اگر این هشدار ساعت ۳ بامداد بیاید، دقیقاً چه کار می‌کنم؟» اگر جواب «صبح نگاه می‌کنم» است، این هشدار نیست، یک گزارش است و جایش داشبورد است نه پیامک. اگر جواب «هیچی، همین‌طوریه» است، آستانه‌تان غلط است.

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

چهار چیزی که بی‌بحث باید پایش شوند

۱. در دسترس بودن، و سکوتِ خودِ پایش

«آیا وصل می‌شوم» ساده‌ترین بررسی است و مهم‌ترین. ولی یک نکتهٔ کم‌تر دیده‌شده دارد: اگر ابزار پایش خودش خاموش شود، هیچ هشداری نمی‌آید و سکوت شبیه سلامت است. این خرابی را خودم یک بار زندگی کرده‌ام: بعد از ری‌استارت سرور، سرویس پایش دو دقیقه زودتر از SQL Server بالا آمد، به دیتابیسِ نیامده خورد، مرد، و ۱۸ ساعت هیچ‌کس نفهمید — چون خبر نیامدن، خبر خوب به نظر می‌رسید.

راه‌حل: نبض. پایش باید در فاصله‌های منظم «من زنده‌ام» ثبت کند و اگر این ثبت قطع شد، از جای دیگری هشدار برود.

۲. فضای دیسک — با روند، نه فقط لحظه

«۱۰ گیگ آزاد است» به‌تنهایی معنا ندارد. اگر روزی ۱ گیگ مصرف می‌شود، ده روز وقت دارید؛ اگر روزی ۵ گیگ، دو روز. عددی که به کار می‌آید روزِ پر شدن است، و برای محاسبه‌اش به تاریخچه نیاز دارید.

پر شدن دیسک برای دیتابیس یعنی توقف نوشتن — یعنی از دید کاربر، سرویس خوابیده.

۳. لاگ ترنزکشن: درصد پر بودن، و مهم‌تر، علت

اینجا نکته‌ای است که خودم اشتباه پیاده کردم و بابتش پیامک خوردم. اولین نسخهٔ قاعدهٔ «لاگ پر است» را روی درصد پر بودن گذاشتم. نتیجه: tempdb که لاگش طبیعتاً مثل ارّه بالا و پایین می‌رود، در ۷۲ ساعت ۱۵۰ پیامک فرستاد — و بدتر، خبرِ «حل شد» هم پیامک داشت، پس هر نوسان دو پیامک بود.

معیار درست «پر بودن» نیست، «نمی‌تواند بازیافت شود» است:

SELECT name, log_reuse_wait_desc
FROM   sys.databases
WHERE  log_reuse_wait_desc <> N'NOTHING';

لاگی که ۹۰٪ پر است ولی log_reuse_wait_desc = NOTHING دارد، در checkpoint بعدی آزاد می‌شود و مشکلی نیست. لاگی که ۶۰٪ پر است ولی روی LOG_BACKUP یا ACTIVE_TRANSACTION یا REPLICATION ایستاده، دارد به سمت خرابی می‌رود. درصد، علامت است؛ علت، آن ستون است.

۴. بکاپ: سن آخرین بکاپ موفق

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

SELECT d.name,
       last_full = MAX(CASE WHEN b.type = 'D' THEN b.backup_finish_date END),
       last_diff = MAX(CASE WHEN b.type = 'I' THEN b.backup_finish_date END),
       last_log  = MAX(CASE WHEN b.type = 'L' THEN b.backup_finish_date END)
FROM   sys.databases d
LEFT JOIN msdb.dbo.backupset b ON b.database_name = d.name
WHERE  d.database_id > 4
GROUP  BY d.name
ORDER  BY last_full;

دیتابیسی که در ستون last_full مقدار NULL دارد، هرگز بکاپ نداشته. این کوئری را روی سرور مشتری اجرا کنید؛ تقریباً همیشه دست‌کم یک سطر NULL پیدا می‌شود که هیچ‌کس نمی‌دانست.

چیزهایی که خوب است ببینید ولی لازم نیست پیامک کنند

• CPU. ۹۰٪ در ساعت گزارش‌گیری ماهانه طبیعی است. CPU به‌تنهایی سیگنال بدی است؛ ترکیبش با انتظارها معنا دارد.
• طول عمر صفحه‌ها (PLE). عدد مطلقش افسانه است؛ افتادن ناگهانی‌اش سیگنال است.
• مسدودسازی. چند ثانیه قفل عادی است؛ زنجیرهٔ قفلی که چند دقیقه می‌ماند نه.
• ورودهای ناموفق. یکی دوتا یعنی کسی رمز را غلط زده؛ صدتا در دقیقه یعنی چیز دیگری در جریان است.

چطور هشدار را قابل‌تحمل کنیم

این بخش تفاوت بین «پایش داریم» و «پایش کار می‌کند» است. چهار مکانیزمی که در عمل لازم‌اند:

• شناسهٔ یکتا برای هر مشکل. «لاگ دیتابیس Sales پر است» باید یک هشدار باز باشد که تا حل شدن زنده می‌ماند، نه یک هشدار تازه در هر دور بررسی. بی این، یک مشکل ساعتی ۶۰ پیام می‌شود.
• دورهٔ سکوت و نردبان. بار اول به مسئول کشیک، اگر تأیید نشد بعد از n دقیقه به نفر بعد. تکرار بی‌پایان به همه، همان سیلی است که باعث بی‌اعتنایی می‌شود.
• سقف مستقل. بالای همهٔ منطق‌ها، یک سقف روزانه بگذارید؛ و بخشی از آن را برای هشدارهای بحرانی رزرو کنید، وگرنه سی هشدار کم‌اهمیت سقف را می‌خورند و هشدار واقعی نیمه‌شب هرگز نمی‌رسد.
• خبر حل شدن، فقط برای بحرانی‌ها. «حل شد» آرام‌بخش است ولی حجم پیام را دو برابر می‌کند. برای مشکل نوسانی، خودش به سیل تبدیل می‌شود.

یک هشدار خوب چه شکلی است؟

این بد است:

Alert: Database log usage > 90% on SRV-DB01

این خوب است:

[بحرانی] لاگ ترنزکشن Sales ۹۲٪ پر است. علت: بکاپ لاگ ۴ ساعت عقب افتاده. فضای آزاد درایو L: ۳٫۱ گیگ.

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

چک‌لیست راه‌اندازی

1. وصل شدن به هر نمونه + نبض خودِ پایش.
2. فضای آزاد هر درایو، همراه با تخمین روز پر شدن.
3. log_reuse_wait_desc غیر از NOTHING — با tempdb مستثنا.
4. سن آخرین فول و آخرین بکاپ لاگ، به ازای هر دیتابیس.
5. خطاهای سنگین در ERRORLOG (خرابی صفحه، ورود ناموفق انبوه، قطع شدن).
6. زنجیرهٔ قفل طولانی‌تر از چند دقیقه.
7. و بالای همه: شناسهٔ یکتا، دورهٔ سکوت، نردبان و سقف روزانه.

هر کدام از این‌ها را می‌توانید با اسکریپت و جاب خودتان بسازید و بعضی تیم‌ها همین کار را می‌کنند. آنچه معمولاً ساخته نمی‌شود، همان بند آخر است — چرخهٔ عمر هشدار — و دقیقاً همان بندی است که تعیین می‌کند شش ماه بعد کسی به این پیام‌ها نگاه می‌کند یا نه. DBMug برای همین ساخته شد: خود قاعده‌ها ساده‌اند؛ چیزی که وقت می‌برد، قابل‌تحمل کردن هشدارهاست.