راهنمای جامع پایش سرور: چه چیزی را، هر چند وقت و با چه آستانه‌ای

بیشتر سرورهایی که دیده‌ام از کار افتاده‌اند، بی‌خبر از کار نیفتاده‌اند. دیسک D سه هفته بود که هر روز یک درصد پرتر می‌شد. سرویس SQL Server دو شب پیش یک بار متوقف شده و خودش دوباره بالا آمده بود. لاگ امنیتی پر از ورود ناموفق از یک آی‌پی خارجی بود. همهٔ این نشانه‌ها آنجا بودند؛ فقط کسی نگاه نمی‌کرد. پایش سرور یعنی همین نگاه کردن، ولی به‌جای آدم، با ماشین، و فقط وقتی آدم را صدا کند که واقعاً لازم است.

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

پایش سرور به سه سؤال جواب می‌دهد

وقتی با تیم‌های IT دربارهٔ پایش حرف می‌زنم، اغلب فهرستی از سنجه‌ها می‌آورند: CPU، رم، دیسک. این فهرست غلط نیست، ولی ناقص است. سامانهٔ پایش خوب باید در هر لحظه به سه سؤال جواب بدهد:

1. آیا سرور زنده است و کارش را می‌کند؟ روشن بودن کافی نیست. سروری که پینگ جواب می‌دهد ولی سرویس IIS آن متوقف است، برای کاربر مرده است.
2. آیا منابعش رو به تمام شدن است؟ دیسک، رم، CPU، شبکه. این سؤال دربارهٔ «الان» نیست؛ دربارهٔ روند است. دیسکی که امروز ۸۰٪ است و هفته‌ای ۲٪ پر می‌شود، ده هفته وقت دارد. دیسکی که ۸۰٪ است و ساعتی ۵٪ پر می‌شود، چهار ساعت.
3. آیا وضعیتش امن و درست است؟ آپدیت‌ها نصب شده‌اند؟ آنتی‌ویروس روشن است و امضایش تازه است؟ فایروال فعال است؟ کسی دارد رمز حدس می‌زند؟ ادمین تازه‌ای اضافه شده؟

بیشتر ابزارهای قدیمی پایش روی دو سؤال اول متمرکز بودند و سؤال سوم را به ابزارهای امنیتی جدا سپردند. در شرکت‌های بزرگ با تیم SOC این تقسیم کار معنا دارد. ولی در شرکتی با دو نفر IT و بیست سرور، همان دو نفر باید جواب هر سه سؤال را بدانند، و اگر هر سؤال یک ابزار و یک داشبورد جدا داشته باشد، عملاً سؤال سوم بی‌جواب می‌ماند.

لایه‌های پایش: دقیقاً چه چیزی را بپاییم

من پایش یک سرور را در پنج لایه می‌بینم. هر لایه سؤال‌های خودش را دارد و اگر یکی را جا بیندازید، دقیقاً همان‌جا غافلگیر می‌شوید.

دسترس‌پذیری

ساده‌ترین لایه و در عین حال لایه‌ای که بیشترین اشتباه را در آن می‌بینم. پینگ کردن سرور از یک ماشین دیگر فقط می‌گوید کارت شبکه و پشتهٔ TCP/IP جواب می‌دهند. سروری که روی صفحهٔ آبی گیر کرده گاهی هنوز پینگ جواب می‌دهد، و سروری که فایروالش ICMP را می‌بندد سالم است ولی «پایین» دیده می‌شود. روش مطمئن‌تر این است که خود سرور به‌طور منظم بگوید «زنده‌ام» (heartbeat) و نبودِ این پیام هشدار بسازد. دربارهٔ این الگو پایین‌تر بیشتر می‌گویم.

uptime هم ارزش نگاه کردن دارد: اگر uptime سرور ناگهان به چند دقیقه برگشت و کسی ریبوتی برنامه‌ریزی نکرده بود، باید دنبال علت بگردید. در ویندوز رویدادهای 41 (Kernel-Power) و 6008 (خاموشی غیرمنتظره) در لاگ System سرنخ می‌دهند؛ در لینوکس journalctl --list-boots و last -x reboot.

منابع

اینجا جزئیات مهم است. «مصرف دیسک» به‌تنهایی کافی نیست؛ باید هر درایو جدا پایش شود، چون C پر می‌شود در حالی که میانگین همهٔ درایوها ۴۰٪ است. در لینوکس علاوه بر فضا، inode هم باید پایش شود: دیسکی که ۳۰٪ پر است ولی inodeهایش تمام شده، دیگر فایل جدید نمی‌سازد و پیغام خطایش «No space left on device» است که همه را گمراه می‌کند. برای رم، در لینوکس به ستون available در خروجی free -m نگاه کنید، نه free؛ کش فایل‌سیستم رم «مصرف‌شده» نیست.

# Windows (PowerShell 5.1): free space per volume
Get-Volume | Where-Object DriveLetter |
  Select-Object DriveLetter, FileSystemLabel,
    @{n='SizeGB';e={[math]::Round($_.Size/1GB,1)}},
    @{n='FreePct';e={[math]::Round(100*$_.SizeRemaining/$_.Size,1)}}

# Linux: space and inodes per filesystem
df -hT -x tmpfs -x devtmpfs
df -i -x tmpfs -x devtmpfs

سرویس‌ها

سرور برای یک کار وجود دارد: میزبانی SQL Server، IIS، فایل‌سرور، Active Directory، اپلیکیشن داخلی. سرویسی که آن کار را انجام می‌دهد باید با نام پایش شود. علاوه بر آن، یک چک عمومی مفید است: «سرویس‌هایی که نوع راه‌اندازی‌شان Automatic است ولی الان متوقف‌اند». این چک بسیاری از مشکلات را بدون اینکه از قبل بدانید کدام سرویس مهم است پیدا می‌کند. فقط باید چند سرویس معروف را که عادتاً متوقف می‌مانند (مثل sppsvc یا gupdate) استثنا کنید.

# Windows: automatic services that are not running
Get-CimInstance Win32_Service -Filter "StartMode='Auto' AND State<>'Running'" |
  Select-Object Name, DisplayName, State, ExitCode

# Linux: failed systemd units
systemctl --failed --no-legend

سلامت و پیکربندی

این لایه کم‌تر از بقیه دیده می‌شود چون هیچ‌کدامش «همین الان» سرور را نمی‌خواباند. آپدیت امنیتی‌ای که سه ماه نصب نشده، گواهی‌ای که دوازده روز دیگر منقضی می‌شود، دیسک فیزیکی‌ای که سلامتش از Healthy به Warning رفته، ساعتی که پنج دقیقه عقب است و دیر یا زود احراز هویت Kerberos را می‌شکند. همه بمب ساعتی‌اند. خبر خوب این است که چک کردنشان ارزان است و روزی چند بار کافی است.

امنیت

حداقل پایش امنیتی که برای هر سرور توصیه می‌کنم: ورود ناموفق (در ویندوز رویداد 4625، در لینوکس «Failed password» در لاگ sshd) با آی‌پی مبدأ، اضافه شدن عضو به گروه Administrators (رویداد 4732) یا sudo، ساخت حساب جدید (4720)، پاک شدن لاگ امنیتی (1102) و نصب سرویس جدید (7045 در لاگ System). این پنج مورد چیزی نیستند که هر روز اتفاق بیفتند، و وقتی اتفاق می‌افتند یا کار خودتان است یا کار کسی که باید فوراً از وجودش باخبر شوید.

هر چند وقت یک بار اندازه بگیریم

بسامد نمونه‌برداری مصالحه‌ای است بین دقت و هزینه. اگر CPU را هر پنج دقیقه یک بار بخوانید، جهش‌های سی‌ثانیه‌ای را هرگز نمی‌بینید؛ اگر هر ثانیه بخوانید، حجم داده و بار روی سرور بی‌دلیل بالا می‌رود. تجربهٔ من این است که چیزهای سریع‌التغییر را باید زیاد خواند و چیزهای کندتغییر را کم:

یک نکتهٔ ظریف: بسامد نمونه‌برداری با بسامد ارسال یکی نیست. سنسوری که هر ۱۵ ثانیه سنجه می‌خواند می‌تواند هر ۳۰ ثانیه دو نمونه را با هم بفرستد. آنچه برای تشخیص قطعی اهمیت دارد فاصلهٔ ارسال است؛ آنچه برای دقت نمودار اهمیت دارد فاصلهٔ نمونه‌برداری.

آستانه‌ها: از کجا شروع کنیم

بزرگ‌ترین دلیلی که سامانه‌های پایش کنار گذاشته می‌شوند آستانهٔ بد است. آستانه‌ای که هر روز ده بار بی‌دلیل زنگ بزند، در هفتهٔ سوم نادیده گرفته می‌شود و روزی که واقعاً مشکل هست، همان هم نادیده گرفته می‌شود. دو قاعده را از اول رعایت کنید:

• مدت را در آستانه بگذارید. «CPU بالای ۹۵٪» آستانه نیست؛ «CPU بالای ۹۵٪ به مدت ۱۰ دقیقه» آستانه است. CPU سرور سالم هنگام بکاپ شبانه یا اسکن آنتی‌ویروس چند دقیقه صددرصد می‌شود و این مشکل نیست.
• دو سطح بگذارید. سطح هشدار برای «باید این هفته نگاه کنم» و سطح بحرانی برای «باید همین الان کاری کنم». فقط سطح بحرانی باید کسی را از خواب بیدار کند.

جدول زیر نقطهٔ شروعی است که برای بیشتر سرورهای عمومی جواب داده است. این‌ها عدد جادویی نیستند؛ بعد از دو سه هفته با نگاه به نمودارهای خودتان تنظیمشان کنید.

دربارهٔ دیسک یک توصیهٔ اضافه دارم: درصد روی درایوهای بزرگ گمراه‌کننده است. ۹۵٪ از یک درایو ۴ ترابایتی یعنی ۲۰۰ گیگابایت جای خالی که ممکن است برای ماه‌ها کافی باشد؛ ۹۵٪ از درایو C شصت گیگابایتی یعنی سه گیگابایت که با یک آپدیت تجمعی ویندوز تمام می‌شود. اگر ابزارتان اجازه می‌دهد، برای درایوهای بزرگ آستانه را بالاتر بگذارید یا روی گیگابایت آزاد هشدار بدهید.

وقتی سرور ساکت می‌شود

هر سامانهٔ پایشی باید به این سؤال جواب داشته باشد: اگر خود سرور یا سنسور روی آن بمیرد، چه کسی خبردار می‌شود؟ جوابش الگویی است به نام heartbeat یا dead man’s switch: سرور منظم گزارش می‌فرستد و سامانهٔ مرکزی اگر برای مدت مشخصی گزارشی نگرفت، خودش هشدار «قطعی» می‌سازد. این هشدار از همهٔ هشدارهای دیگر مهم‌تر است، چون وقتی سرور قطع است، هیچ هشدار دیگری از آن نمی‌رسد.

دو نکته در عمل مهم است. اول، وقتی سرور قطع است، هشدارهای مبتنی بر سنجه‌اش نباید باز یا بسته شوند؛ آخرین مقدار CPU که سه ساعت پیش رسیده، الان معنایی ندارد. اگر سامانه آن هشدار را «برطرف‌شده» حساب کند، اطلاعات غلط می‌دهد. دوم، قطعی شبکهٔ کوتاه نباید هشدار بسازد؛ پنجرهٔ دو تا پنج دقیقه‌ای معمولاً تعادل خوبی است.

agent یا بدون agent

برای جمع کردن این داده‌ها دو راه کلی هست. در روش بدون agent، یک سرور مرکزی از راه دور با پروتکل‌هایی مثل SNMP، WMI یا SSH سراغ هر سرور می‌رود و داده می‌پرسد. در روش agent، یک برنامهٔ کوچک روی هر سرور نصب می‌شود و داده را خودش می‌فرستد.

روش بدون agent برای تجهیزات شبکه (سوییچ، روتر، UPS) که نمی‌شود رویشان نرم‌افزار نصب کرد تنها راه است. ولی برای سرورها، معمولاً یعنی باز کردن پورت ورودی (WMI و WinRM و SSH) روی هر سرور و نگه داشتن یک حساب با دسترسی بالا روی سرور مرکزی که به همه‌جا دسترسی دارد؛ یعنی دقیقاً همان چیزی که مهاجم دنبالش است. agentی که فقط ارتباط خروجی برقرار می‌کند این مشکل را ندارد و به داده‌هایی هم دسترسی دارد که از راه دور سخت به دست می‌آیند (مثل رویدادهای امنیتی با جزئیات کامل). هزینه‌اش نصب و به‌روز نگه داشتن agent است. این مقایسه را در مقاله‌ای جدا مفصل باز کرده‌ام.

موجودی و تغییرات: پایشی که کمتر کسی انجام می‌دهد

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

در گزارش‌های حادثه‌های باج‌افزاری که خوانده‌ام، الگوی تکراری این است که مهاجم چند روز پیش از رمزگذاری ابزارهایی نصب می‌کند: AnyDesk برای دسترسی پایدار، Advanced IP Scanner برای شناسایی شبکه، rclone برای بیرون بردن داده. هر کدام از این‌ها در فهرست نرم‌افزارها یا سرویس‌ها ردپا می‌گذارد. مقایسهٔ موجودی امروز با دیروز ساده‌ترین راه دیدن این ردپاست.

# Windows: listening ports with owning process
Get-NetTCPConnection -State Listen |
  Select-Object LocalAddress, LocalPort,
    @{n='Process';e={(Get-Process -Id $_.OwningProcess).ProcessName}} |
  Sort-Object LocalPort

# Windows: members of the local Administrators group
Get-LocalGroupMember -Group Administrators

# Linux: listening sockets and sudo group members
ss -tulpn
getent group sudo wheel

نگه‌داری داده و نمودار بلندمدت

داده‌ای که یک هفته بعد پاک شود، فقط به سؤال «الان چه خبر است» جواب می‌دهد. سؤال‌های مهم‌تر بلندمدت‌اند: «مصرف رم این سرور در شش ماه گذشته چقدر رشد کرده؟»، «از وقتی آن نسخهٔ جدید اپلیکیشن را نصب کردیم، CPU بالاتر رفته؟»، «دیسک با این روند کِی پر می‌شود؟». الگوی رایج و معقول این است که دادهٔ خام را چند روز نگه دارید، میانگین چنددقیقه‌ای را چند ماه، و میانگین ساعتی را بیش از یک سال. نمودار یک‌ساله به نقطه‌های پانزده‌ثانیه‌ای نیاز ندارد.

یک اشتباه رایج: فقط میانگین را نگه داشتن. میانگین ساعتی CPU که ۴۰٪ است ممکن است شامل ده دقیقهٔ صددرصد باشد. اگر می‌توانید، کنار میانگین، بیشینه را هم در هر بازه نگه دارید.

هشدار: پایش بدون اطلاع‌رسانی نصفه است

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

• یک مشکل، یک هشدار. اگر دیسک ۹۶٪ است و هر دقیقه دوباره بررسی می‌شود، شصت پیام در ساعت نباید بیاید. هشدار باز می‌ماند و تکرارش شمرده می‌شود.
• کانال متناسب با شدت. بحرانی‌ها از کانالی که حتماً دیده می‌شود (در ایران، عملاً پیامک)؛ بقیه در داشبورد یا سامانه‌های تیکت.
• ساعت سکوت برای غیربحرانی‌ها. هشدار «آپدیت معوق» ساعت سه صبح نباید کسی را بیدار کند.
• ارجاع. اگر نفر اول در زمان معقولی هشدار بحرانی را تأیید نکرد، نفر دوم باید خبردار شود.
• حالت نگهداری. وقتی عمداً سرور را ریبوت می‌کنید یا ارتقا می‌دهید، هشدارها ثبت شوند ولی کسی را صدا نکنند.

ابزارها: چه چیزهایی در دسترس است

برای پایش سرور ابزار کم نیست و هر کدام نقطهٔ قوت خودش را دارد. منصفانه بگویم:

اگر تیمی دارید که وقت راه‌اندازی و نگه‌داری Zabbix یا Prometheus را دارد، این‌ها ابزارهای خوبی‌اند. ServerMug را برای وضعیتی ساختیم که این وقت نیست: سنسوری که با یک دستور نصب می‌شود، هر سه سؤال بالا (زنده بودن، منابع، امنیت) را با چک‌های آماده جواب می‌دهد و هشدار را با پیامک می‌فرستد. فهرست کامل آنچه می‌سنجد در مرجع چک‌ها، سنجه‌ها و رویدادها آمده است.

اشتباه‌های رایجی که بارها دیده‌ام

آخرین مورد را جدی بگیرید. در شبکه‌ای که پنج سال است کار می‌کند، اغلب سه چهار سرور هست که «موقت» راه‌اندازی شده‌اند و هیچ‌کس یادش نیست. اگر دامین دارید، پخش سنسور با Group Policy این مشکل را از ریشه حل می‌کند: هر سرور تازه که به دامین بپیوندد، خودش پایش می‌شود. روش این کار را در نصب روی همهٔ سرورهای دامین با GPO نوشته‌ام.

نقشهٔ یک هفته‌ای برای شروع

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

1. روز اول: فهرست سرورها. همهٔ سرورها، نقششان، سیستم‌عاملشان و مسئولشان را در یک جدول بنویسید. همین کار ساده معمولاً یکی دو سرور فراموش‌شده پیدا می‌کند. اگر Windows Server 2012 یا قدیمی‌تر در فهرست هست، علامتش بزنید؛ پشتیبانی امنیتی‌اش تمام شده و بیشتر ابزارهای جدید هم دیگر رویش اجرا نمی‌شوند.
2. روز دوم: نصب پایش روی همه. نه فقط سرورهای «مهم». سرور کم‌اهمیتی که بی‌پایش مانده، بهترین جای پای مهاجم است. دستورهای نصب ویندوز و لینوکس در نصب سنسور روی ویندوز سرور و نصب روی لینوکس آمده است.
3. روز سوم: هشدارهای بحرانی. فقط این‌ها: قطعی سرور، دیسک بالای ۹۵٪، سرویس اصلی متوقف، و رویدادهای امنیتی جدی. همه با پیامک.
4. روز چهارم: سرویس‌های تحت نظر. برای هر سرور، سرویس یا سرویس‌هایی که سرور برایشان وجود دارد را مشخص کنید.
5. روز پنجم: مخاطبان و ساعت سکوت. چه کسی چه چیزی را می‌گیرد؟ نفر دوم کیست؟
6. هفتهٔ دوم و سوم: تنظیم. هر هشداری که بی‌دلیل آمد، آستانه یا مدتش را اصلاح کنید یا خاموشش کنید. هر مشکلی که بی‌هشدار رخ داد، برایش قانون بسازید. شیوهٔ تعریف این قانون‌ها در قانون‌های هشدار توضیح داده شده است.

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

منابع و مطالعهٔ بیشتر

• پایش سیستم‌های توزیع‌شده، کتاب SRE گوگل — چهار سیگنال طلایی و اصولی دربارهٔ هشدار که برای پایش سرور هم صدق می‌کند.
• روش USE از برندن گرگ — چارچوبی ساده برای بررسی هر منبع از سه جهت: مصرف، اشباع و خطا.
• NIST SP 800-137: پایش مستمر امنیت اطلاعات — نگاه سازمانی به اینکه پایش امنیتی چطور باید برنامه‌ریزی و اجرا شود.
• پایش و مدیریت وضعیت و کارایی سیستم در RHEL 9 — مستندات رسمی Red Hat دربارهٔ ابزارهای پایش منابع در لینوکس.