Monitoring و عملیات روزانه پشتیبان شبکه

در یک شرکت واقعی، Monitoring زمانی ارزش دارد که به سؤال‌های عملی پاسخ بدهد: آیا سرویس در دسترس است، آیا کیفیت آن قابل قبول است، آیا منابع در حال نزدیک شدن به مرز خطر هستند و آیا تغییری رخ داده که باید قبل از تبدیل شدن به Incident بررسی شود. اگر فقط صدها عدد جمع کنیم اما ندانیم کدام عدد برای تصمیم‌گیری مهم است، سیستم مانیتورینگ به انبار داده تبدیل می‌شود. ابتدا سرویس‌های حیاتی سازمان را بشناس؛ مثل اینترنت، Domain Controller، DNS، DHCP، File Server، SQL، VMware، Backup، Router و Switch. سپس برای هر سرویس مشخص کن سلامت آن از چه نشانه‌هایی فهمیده می‌شود. ممکن است یک Server روشن باشد اما سرویس SQL متوقف شده باشد، یا Ping پاسخ دهد ولی فضای Disk تقریباً تمام شده باشد. بنابراین Availability تنها یکی از ابعاد سلامت است. اشتباه رایج این است که همه چیز را فقط Up یا Down ببینیم یا هر عددی را Alert کنیم. Alert باید به اقدامی مشخص منجر شود، نه اینکه فقط Dashboard را قرمز کند. همچنین باید بین وضعیت لحظه‌ای، روند گذشته و ظرفیت آینده فرق بگذاری. مانیتورینگ حرفه‌ای باید هم وضعیت فعلی را نشان دهد، هم تغییرات گذشته را نگه دارد و هم در زمان مناسب هشدار قابل اقدام تولید کند. در این پک هر Metric را به یک سؤال عملی وصل می‌کنی تا Monitoring از همان ابتدا بخشی از عملیات روزانه و عیب‌یابی باشد، نه یک صفحه تزئینی.

Metric معمولاً یک مقدار عددی در طول زمان است؛ مثل CPU، فضای آزاد Disk، Latency یا Packet Loss. Log یک رکورد متنی یا ساختاری از رخدادهای سیستم است. Event یک اتفاق مشخص است، برای مثال تغییر وضعیت یک Trigger از OK به Problem. Alert پیام یا اقدامی است که از یک Event مهم ساخته می‌شود و Report خلاصه‌ای از داده‌ها در یک بازه زمانی است. در Zabbix، Item داده را جمع می‌کند، Trigger شرط Problem را می‌سنجد، Event از تغییر وضعیت ساخته می‌شود و Action می‌تواند Notification یا عملیات دیگری ایجاد کند. وقتی این زنجیره را بفهمی، دقیقاً می‌دانی هر تنظیم در کجای چرخه قرار دارد و برای عیب‌یابی از چه چیزی باید استفاده کنی. اگر مفاهیم را مخلوط کنی، طراحی ضعیف می‌شود؛ مثلاً ممکن است هر خط Log را Alert کنی و تیم را با پیام‌های بی‌ارزش خسته کنی، یا فقط CPU را جمع کنی ولی هیچ Trigger معناداری برای شرایط خطر نداشته باشی. Report هم نباید جای Alert فوری را بگیرد. در عملیات واقعی، Metric برای Trend و Threshold، Log برای جزئیات رخداد، Event برای ثبت تغییر وضعیت، Alert برای جلب توجه و Report برای مرور دوره‌ای استفاده می‌شود. این تفکیک ساده بعداً در طراحی Dashboard، Notification و Runbook بسیار مهم خواهد بود.

برای اینکه سلامت زیرساخت را فقط با یک عدد نسنجیم، چهار زاویه بسیار مفید هستند. Availability می‌گوید سرویس در دسترس است یا نه. Latency زمان پاسخ را نشان می‌دهد. Errors تعداد یا نرخ خطاها را مشخص می‌کند و Saturation نشان می‌دهد یک منبع تا چه اندازه به ظرفیت عملی خود نزدیک شده است. برای WAN می‌توان ICMP Availability، RTT، Packet Loss و Utilization را کنار هم دید. برای File Server می‌توان SMB Availability، Disk Latency، فضای آزاد و Errorهای مرتبط را بررسی کرد. در VMware وضعیت Host، Datastore و Guest باید هم‌زمان دیده شود و در Backup نتیجه Job، سن آخرین Restore Point و ظرفیت Repository اهمیت دارد. اگر فقط Up/Down را مانیتور کنی، بسیاری از مشکلات را دیر می‌بینی. از طرف دیگر، هر Spike کوتاه CPU هم Incident نیست. Metric باید با مدت زمان، Baseline و اثر سرویس تفسیر شود. عدد بدون Context به‌سادگی گمراه‌کننده است. این چهار دید کمک می‌کنند Dashboard را بر اساس سلامت واقعی سرویس بسازی. ممکن است Ping سبز باشد ولی Latency بالا، Error زیاد یا Capacity در آستانه اتمام باشد. چنین سیستمی از نظر کاربر سالم نیست و Monitoring باید آن را نشان دهد.

Baseline یعنی تصویری از رفتار معمول یک سیستم در شرایط عادی. بدون Baseline، Thresholdها اغلب از روی حدس انتخاب می‌شوند. برای نمونه 70 درصد CPU ممکن است برای یک Server در ساعات کاری طبیعی باشد و برای Server دیگری نشانه بار غیرعادی. همین موضوع برای Latency، Bandwidth، Disk I/O و Database Growth هم صدق می‌کند. برای ساخت Baseline باید داده کافی در روزهای کاری، ساعات اوج و در صورت نیاز آخر هفته جمع کنی و به Trend نگاه کنی، نه فقط یک Snapshot. Average به‌تنهایی همیشه کافی نیست؛ Peak، Maximum و الگوی زمانی هم مهم‌اند. بعد از افزایش کاربر، مهاجرت سرویس یا تغییر ظرفیت، Baseline قبلی باید دوباره ارزیابی شود. اشتباه رایج این است که Thresholdهای عمومی اینترنتی را بدون شناخت محیط کپی کنیم. عددی که برای یک دیتاسنتر مناسب است ممکن است برای شعبه کوچک معنا نداشته باشد. همچنین یک جهش کوتاه نباید به‌صورت خودکار به Incident پایدار تعبیر شود. Baseline پایه Alert Tuning و Capacity Planning است. وقتی رفتار عادی را بشناسی، می‌توانی انحراف واقعی را زودتر ببینی و تفاوت بین Growth طبیعی و رفتار غیرعادی را توضیح بدهی.

SLI شاخصی است که عملکرد واقعی یک سرویس را اندازه می‌گیرد؛ برای مثال درصد درخواست‌های موفق یا درصد زمان در دسترس بودن سرویس. SLO هدف داخلی یا عملیاتی برای آن شاخص است و SLA معمولاً یک تعهد رسمی یا قراردادی است که می‌تواند Availability، زمان پاسخ، ساعات پشتیبانی و پیامدهای عدم تحقق را تعریف کند. اگر می‌گویی یک سرویس 99.9 درصد Available بوده، باید مشخص کنی بازه اندازه‌گیری چه بوده، Down چگونه تعریف شده، Check از کجا انجام شده و Maintenance برنامه‌ریزی‌شده چگونه محاسبه شده است. این جزئیات روی تفسیر عدد و تصمیم مدیریتی اثر مستقیم دارند. گزارش Availability بدون تعریف دقیق می‌تواند گمراه‌کننده باشد. Ping موفق الزاماً به معنی سلامت Application نیست و Check داخلی ممکن است تجربه کاربر بیرونی را نشان ندهد. همچنین عدد خوب Availability ممکن است Latency یا Error Rate ضعیف را پنهان کند. برای پشتیبان شبکه مهم است که SLI را به Metric واقعی و قابل اندازه‌گیری وصل کند، SLO را با نیاز کسب‌وکار هماهنگ سازد و SLA را بدون تعریف مبهم گزارش نکند. این نگاه بعدها در گزارش‌های ماهانه و Escalation اهمیت زیادی دارد.

Threshold حدی است که بعد از عبور یک Metric از آن، وضعیت نیازمند توجه می‌شود؛ اما انتخاب آن نباید صرفاً بر اساس یک عدد عمومی مثل «CPU بالاتر از ۸۰٪» باشد. یک Threshold خوب باید با ماهیت سرویس، Baseline، مدت زمان عبور از حد و اثر واقعی روی کاربر ارتباط داشته باشد. برای نمونه استفاده CPU به مدت چند ثانیه در زمان اجرای یک Job می‌تواند کاملاً طبیعی باشد، اما همان مقدار اگر ده‌ها دقیقه ادامه پیدا کند و هم‌زمان Response Time افزایش یابد، معنی متفاوتی دارد. در Zabbix این منطق معمولاً با Trigger Expression پیاده می‌شود و می‌توان به‌جای آخرین مقدار، Average، Minimum، Maximum یا شرایط زمانی را در نظر گرفت. برای طراحی Threshold ابتدا Metric را به یک سرویس وصل کن و بپرس «اگر این مقدار تغییر کند چه چیزی خراب می‌شود؟». سپس Baseline را ببین، محدوده Warning و High را جدا کن و برای وضعیت‌هایی که نیاز به اقدام فوری ندارند Severity پایین‌تری در نظر بگیر. روی Disk Space بهتر است علاوه بر درصد فضای آزاد، نرخ رشد مصرف را هم ببینی؛ ۱۵٪ فضای آزاد روی یک Disk دو ترابایتی ممکن است فرصت کافی ایجاد کند، در حالی که همان درصد روی Volume کوچک و با رشد سریع می‌تواند فوری باشد. روی Interface شبکه نیز Utilization را همراه Errors و Discards تحلیل کن. اشتباه رایج این است که Threshold را برای همه Hostها یکسان تعریف کنیم، Trigger را با یک Spike کوتاه فعال کنیم یا برای هر Warning پیام فوری بفرستیم. این کار Alert Fatigue ایجاد می‌کند و باعث می‌شود هشدارهای واقعی در میان پیام‌های کم‌اهمیت دیده نشوند. همچنین Threshold نباید به‌گونه‌ای باشد که فقط پس از وقوع کامل خرابی واکنش نشان دهد؛ وقتی روندها زودتر دیده شوند، برای بسیاری از مشکلات قابل پیش‌بینی فرصت اقدام پیشگیرانه خواهی داشت. در محیط واقعی بهتر است Thresholdها دوره‌ای بازبینی شوند. بعد از تغییر ظرفیت، مهاجرت VM، اضافه شدن کاربران یا تغییر Backup Window، رفتار عادی سیستم ممکن است عوض شود. بنابراین Threshold یک تنظیم دائمی و فراموش‌شدنی نیست؛ بخشی از چرخه نگهداری Monitoring است و باید با داده‌های واقعی تنظیم و مستند شود.

Alert Fatigue زمانی رخ می‌دهد که تیم آن‌قدر پیام دریافت می‌کند که دیگر نمی‌تواند اهمیت هر پیام را سریع تشخیص دهد. Alert Storm شکل شدیدتری از همین مشکل است؛ یک خرابی ریشه‌ای مثل قطع Uplink ممکن است ده‌ها یا صدها Host پایین‌دستی را هم‌زمان Down نشان دهد و سیستم برای هرکدام هشدار جداگانه بسازد. در یک Monitoring حرفه‌ای هدف افزایش تعداد Alert نیست، بلکه تبدیل داده به تعداد محدودی رخداد قابل اقدام است. Zabbix برای این کار ابزارهایی مانند Trigger Dependency، Event Correlation، Tag و Action Condition دارد و در PRTG نیز Dependency و Notification Trigger به کنترل پیام‌ها کمک می‌کنند. برای کنترل نویز ابتدا وابستگی سرویس‌ها را بشناس. اگر Router یا Core Switch قطع شود، لازم نیست Down شدن تک‌تک Serverها و Printerهای پشت آن همان سطح از هشدار را ایجاد کند. Maintenance Window را برای تغییرات برنامه‌ریزی‌شده تعریف کن تا Patch یا Reboot عمدی با Incident اشتباه نشود. Severity را به معنی اثر واقعی تنظیم کن و Notification را به‌گونه‌ای بساز که Warningهای کم‌اهمیت وارد Dashboard شوند، اما Problemهای بحرانی به فرد مسئول برسند. Recovery Notification هم مهم است تا تیم بداند مشکل واقعاً برطرف شده است. دو خطای رایج دیگر، هشدار تکراری بدون Escalation Plan و ارسال همه پیام‌ها به همه افراد است. اگر یک Alert هر پنج دقیقه بدون تغییر وضعیت تکرار شود، خیلی زود نادیده گرفته می‌شود. اگر مسئولیت مشخص نباشد، ممکن است همه تصور کنند فرد دیگری پیگیری می‌کند. هر Notification باید Recipient، Severity، زمان انتظار، مرحله Escalation و شرایط پایان داشته باشد. قبل از فعال‌کردن پیامک یا پیام‌رسان برای صدها Trigger، چند روز Monitoring را در حالت مشاهده اجرا کن و ببین چه مقدار نویز تولید می‌شود. سپس Ruleها را اصلاح کن. کیفیت سیستم مانیتورینگ را می‌توان با نسبت Alertهای واقعاً قابل اقدام به کل Alertها سنجید؛ هر Alertی که بارها بی‌دلیل Ignore می‌شود، یک علامت برای بازطراحی Rule است.

Zabbix یک سامانه Monitoring متمرکز است که اجزای مختلفی برای جمع‌آوری، ذخیره، پردازش و نمایش داده دارد. Zabbix Server هسته اصلی پردازش است؛ Configuration را از Database می‌خواند، داده‌های دریافت‌شده را پردازش می‌کند و Triggerها و Actionها را اجرا می‌کند. Database تاریخچه، Trend و تنظیمات را نگه می‌دارد و Frontend رابط وب مدیریتی است. Zabbix Agent یا Agent 2 می‌تواند روی Windows و Linux نصب شود تا Metricهای داخل سیستم‌عامل را جمع کند. برای تجهیزات شبکه نیز SNMP، ICMP، Simple Check و روش‌های بدون Agent قابل استفاده هستند. Zabbix Proxy برای شعب یا شبکه‌های دوردست داده را محلی جمع و به Server مرکزی ارسال می‌کند. شناخت این اجزا برای عیب‌یابی حیاتی است. اگر Frontend باز نمی‌شود، الزاماً به معنی از کار افتادن جمع‌آوری داده نیست. اگر Database کند شود، History و Trigger Processing ممکن است تحت تأثیر قرار گیرد. اگر Agent پاسخ ندهد، فقط Itemهای وابسته به Agent مشکل خواهند داشت، در حالی که ICMP یا SNMP ممکن است همچنان کار کنند. این تفکیک باعث می‌شود هنگام خرابی خود Monitoring، مشکل را مرحله‌به‌مرحله پیدا کنی. در طراحی کوچک می‌توان Server، Frontend و Database را روی یک ماشین قرار داد، اما با بزرگ شدن تعداد Hostها، Itemها و History باید ظرفیت CPU، RAM، I/O و Database را جدی‌تر در نظر گرفت. Proxy نیز جای Server مرکزی را نمی‌گیرد؛ نقش آن جمع‌آوری توزیع‌شده و Buffer کردن داده در قطعی موقت ارتباط است. هر Proxy Database خودش را دارد و باید ظرفیت آن متناسب با حجم داده و مدت قطع احتمالی در نظر گرفته شود. قبل از نصب، روی کاغذ مشخص کن چه چیزهایی را Monitoring می‌کنی، چند Host و Item خواهی داشت، چه مدت History لازم است، چه شعبی داری و مسیر ارتباط آن‌ها چگونه است. معماری خوب از همان ابتدا از رشد بی‌برنامه Database، فشار بی‌مورد روی WAN و پیچیدگی بعدی جلوگیری می‌کند.

نصب Zabbix فقط اجرای چند Package نیست. پیش از نصب باید نسخه پشتیبانی‌شده سیستم‌عامل و Database، تعداد تقریبی Hostها، Itemها، نرخ دریافت داده و مدت نگهداری History و Trend را مشخص کنی. حجم Database عمدتاً با تعداد Itemها، Update Interval و Retention رشد می‌کند؛ بنابراین دو محیط با تعداد Host یکسان ممکن است نیاز کاملاً متفاوتی داشته باشند. برای مثال جمع‌آوری ده‌ها Metric هر ۳۰ ثانیه از صدها Host، با نگهداری طولانی History، I/O و Storage بیشتری نسبت به چند Check ساده پنج‌دقیقه‌ای مصرف می‌کند. در محیط آموزشی می‌توان Frontend، Server و Database را روی یک VM نصب کرد، اما حتی در Lab هم بهتر است Disk مربوط به Database را جداگانه Monitoring کنی و Backup داشته باشی. Time Synchronization روی Zabbix Server، Database و Hostهای تحت مانیتورینگ مهم است؛ Timestamp نادرست تحلیل Incident را دشوار می‌کند. DNS، Firewall، Portهای موردنیاز و دسترسی به Repositoryهای نصب هم باید قبل از شروع بررسی شوند. بعد از نصب صرفاً به باز شدن صفحه Login اکتفا نکن. وضعیت Zabbix Server، Database Connection، Queue، Internal Processها، Housekeeping و زمان پاسخ را بررسی کن. خود Monitoring Platform باید Monitoring شود. اگر Housekeeping یا Database درگیر باشد، ممکن است داده با تأخیر وارد شود و Dashboard ظاهراً سالم باشد اما تصمیم‌گیری بر اساس داده قدیمی انجام شود. برای Production نصب را مستند کن: Version، OS، DB Engine، Storage Layout، IP/DNS، Credential Ownership، Backup Plan، Update Method و محل فایل‌های Configuration. این مستند در Disaster Recovery و هنگام Upgrade ارزش زیادی دارد و جلوی وابستگی به حافظه یک نفر را می‌گیرد.

در Zabbix هر تجهیز یا سیستم معمولاً به‌صورت Host تعریف می‌شود. Host می‌تواند یک Windows Server، ESXi Host، MikroTik Router، Switch، UPS یا حتی یک سرویس منطقی باشد. Interface روش ارتباط را مشخص می‌کند؛ مانند Agent، SNMP، JMX یا IPMI. Host Group برای سازمان‌دهی، Permission و انتخاب گروهی استفاده می‌شود و Tag به Event و Trigger Context می‌دهد. اگر از روز اول نام‌گذاری و Grouping بی‌قاعده باشد، با بزرگ شدن محیط پیدا کردن Host، ساخت Dashboard و تعریف Action پیچیده می‌شود. یک Naming Convention ساده و قابل فهم تعریف کن. بهتر است نام Host با Inventory و DNS سازمان هماهنگ باشد. Groupها را بر اساس Site، نوع تجهیز یا نقش سرویس طراحی کن؛ برای مثال `Tehran/Servers` یا `Network/Switches`. Tagها را برای اطلاعاتی مثل Service، Site، Environment و Owner در نظر بگیر تا Actionها بتوانند Alert مربوط به Backup را به تیم مربوط و Alert شبکه را به تیم زیرساخت بفرستند. Tag جای Group را نمی‌گیرد؛ هرکدام کاربرد متفاوتی دارند. در Interface حواست به انتخاب DNS یا IP، Port و مسیر واقعی دسترسی از Zabbix Server یا Proxy باشد. Host ممکن است از لپ‌تاپ مدیر Ping شود اما Server Monitoring به آن Route نداشته باشد. برای SNMP Version و Community یا Credential امن باید درست تنظیم شود. Templateها را هم به Host متصل می‌کنی، بنابراین ساختار Host باید پیش از Template Assignment واضح باشد. در محیط حرفه‌ای اطلاعات Inventory و Owner را نیز ثبت کن. وقتی Alert مربوط به یک تجهیز ناشناخته می‌آید، تیم باید بداند این دستگاه کجاست، چه سرویسی ارائه می‌کند و مسئول آن چه کسی است. نظم Monitoring از Naming و Inventory شروع می‌شود، نه از Dashboard زیبا.

Zabbix Agent برای جمع‌آوری Metricهای داخل سیستم‌عامل طراحی شده است؛ مانند CPU، Memory، File System، Process و Service. Agent 2 نسل جدیدتر Agent با معماری Plugin-based است و برای بسیاری از Integrationهای جدید قابلیت‌های بیشتری ارائه می‌دهد. در Passive Check، Zabbix Server یا Proxy به Agent متصل می‌شود و مقدار Item را درخواست می‌کند. در Active Check، Agent فهرست Checkها را از Server یا Proxy دریافت می‌کند و سپس داده را خودش ارسال می‌کند. تفاوت جهت ارتباط روی Firewall، NAT، شعب و امنیت طراحی اثر دارد. اگر Host پشت NAT یا Firewall محدود قرار دارد، Active Check می‌تواند ساده‌تر باشد چون لازم نیست Server از بیرون به Agent اتصال ورودی برقرار کند. در Passive Check باید Port Agent از سمت Server یا Proxy قابل دسترس باشد. در هر دو حالت باید `Server`، `ServerActive` و `Hostname` با Configuration Zabbix هماهنگ باشند. اختلاف Hostname یکی از دلایل رایج دریافت نشدن Active Check است. Agent را با سطح دسترسی کمینه اجرا کن و فقط قابلیت‌هایی را فعال کن که لازم داری. UserParameter یا Script سفارشی می‌تواند قدرت زیادی بدهد، اما اگر بدون کنترل طراحی شود ریسک امنیتی ایجاد می‌کند. Timeout و Interval را هم معقول انتخاب کن؛ Monitoring نباید خودش باعث بار محسوس روی Server شود. بعد از نصب Agent، فقط Availability Icon را نگاه نکن. چند Item واقعی را در Latest Data بررسی کن و Timestamp را ببین. اگر Value جدید نمی‌آید، مسیر را از Service Agent، Configuration، Firewall، DNS و سپس Server/Proxy بررسی کن. این روش از حدس زدن جلوگیری می‌کند.

Item تعریف می‌کند چه داده‌ای از Host جمع شود، با چه روشی، هر چند وقت یک‌بار و با چه نوع داده‌ای ذخیره شود. هر Item یک Type، Key، Value Type، Update Interval و تنظیمات History/Trends دارد. Key باید دقیقاً Metric موردنظر را مشخص کند؛ برای مثال یک Key مربوط به فضای File System با Key مربوط به Load CPU تفاوت دارد. در SNMP Item، OID نیز تعیین می‌کند کدام مقدار از MIB خوانده شود. اگر Item از ابتدا غلط تعریف شود، Trigger و Graph بعدی هرچقدر زیبا باشند روی داده اشتباه بنا شده‌اند. Interval را بر اساس سرعت تغییر Metric و نیاز عملی انتخاب کن. Interface Utilization ممکن است به Interval کوتاه نیاز داشته باشد، در حالی که Expiry Certificate یا Inventory نیازی به Poll هر چند ثانیه ندارد. Interval خیلی کوتاه Database، Network و Device را بی‌دلیل درگیر می‌کند. Interval خیلی بلند نیز ممکن است Spike یا خرابی کوتاه مهم را از دست بدهد. Flexible یا Scheduling Interval برای برخی سناریوها مناسب است. Value Type و Unit را درست انتخاب کن تا Graph و Functionها معنی صحیح داشته باشند. Preprocessing می‌تواند داده خام را تبدیل، فیلتر یا استخراج کند، اما باید قابل توضیح و تست باشد. Unsupported Item را نادیده نگیر؛ Error Message معمولاً سرنخ می‌دهد که Key، Permission، Timeout یا دسترسی مشکل دارد. قبل از ساخت Trigger، Item را در Latest Data بررسی کن. چند Value متوالی، Timestamp و Unit را ببین و مطمئن شو داده همان چیزی است که تصور می‌کنی. این عادت ساده جلوی تعداد زیادی Alert اشتباه را می‌گیرد.

Zabbix برای نگهداری داده‌های زمانی از History و Trends استفاده می‌کند. History جزئیات مقادیر جمع‌آوری‌شده را نگه می‌دارد و برای تحلیل کوتاه‌مدت و بررسی دقیق Incident مفید است. Trends خلاصه‌های ساعتی برای داده‌های عددی نگه می‌دارند و برای مشاهده رفتار بلندمدت با حجم کمتر مناسب‌اند. اگر همه Itemها را با History طولانی نگه داری، Database می‌تواند بسیار سریع رشد کند. اگر History را بیش از حد کوتاه کنی، هنگام بررسی Incident ممکن است جزئیات لازم را از دست بدهی. Retention را بر اساس نوع Metric و نیاز کسب‌وکار تعیین کن. برای Troubleshooting شبکه شاید چند هفته History با جزئیات مفید باشد، اما برای Capacity Planning چند ماه یا یک سال Trend ارزش بیشتری دارد. داده‌ای مثل Inventory یا Certificate Expiry رفتار دیگری دارد. یک سیاست واحد برای همه Itemها معمولاً بهینه نیست. Housekeeping داده‌های قدیمی را مدیریت می‌کند و تنظیمات نامناسب آن می‌تواند روی Database اثر بگذارد. در محیط بزرگ باید رشد Tableها، I/O، Backup Database و زمان Maintenance را زیر نظر داشته باشی. همچنین تغییر Retention بعد از رشد شدید Database فوراً فضای Disk را آزاد نمی‌کند؛ رفتار Database Engine و Cleanup باید شناخته شود. هدف Retention جمع‌کردن بیشترین داده ممکن نیست؛ نگهداری داده‌ای است که برای Incident Analysis، Trend، Audit و Capacity Planning ارزش دارد. هر داده هزینه Storage، Backup و Query دارد، پس سیاست Retention باید مستند و قابل دفاع باشد.

Template مجموعه‌ای قابل استفاده مجدد از Item، Trigger، Graph، Discovery Rule و اجزای Monitoring است. به‌جای اینکه برای صد Windows Server تنظیمات مشابه را دستی بسازی، یک Template مناسب را Link می‌کنی و تغییرات بعدی را در یک نقطه مدیریت می‌کنی. Macro نیز Variable قابل جایگزینی است و اجازه می‌دهد مقادیری مثل Threshold، Community یا Parameter بین Hostها متفاوت باشند بدون اینکه Template را Clone کنی. این دو مفهوم پایه مقیاس‌پذیری Zabbix هستند. از Templateهای رسمی یا شناخته‌شده شروع کن، اما قبل از Production محتویاتشان را بررسی کن. هر Template ممکن است Itemهای زیادی داشته باشد که برای محیط تو لازم نیست یا Interval و Threshold آن با Baseline تو سازگار نباشد. User Macro را برای تنظیمات قابل تغییر مثل `{$DISK.FREE.MIN}` یا پارامترهای سرویس به کار ببر و Scope آن را بفهم؛ Macro می‌تواند در سطح Host، Template یا Global تعریف شود. اشتباه رایج Clone کردن Template برای هر مشتری یا هر Server است. این کار به‌مرور ده‌ها نسخه تقریباً یکسان می‌سازد و نگهداری را سخت می‌کند. بهتر است Template پایه، Template نقش سرویس و Macroهای Host-specific را ترکیب کنی. Naming و Versioning Template هم مهم است تا بعداً معلوم باشد هر Host چه سیاستی دارد. قبل از Update یک Template گسترده، اثر آن را روی Hostهای Link شده بررسی کن. اضافه کردن یک Trigger یا کاهش Interval می‌تواند ناگهان روی صدها Host فعال شود. تغییرات Template مثل تغییر Configuration شبکه باید کنترل‌شده، مستند و قابل بازگشت باشند.

Trigger یک Expression منطقی است که داده Itemها را ارزیابی می‌کند و مشخص می‌کند چه زمانی وضعیت Problem ایجاد شود. قدرت Trigger در این است که لازم نیست فقط یک مقدار آخر را مقایسه کند؛ می‌تواند Functionهایی مثل Average، Minimum، Maximum، Count یا زمان عدم دریافت داده را در یک بازه بررسی کند. Trigger باید وضعیت واقعی قابل اقدام را مدل کند. اگر هر نوسان کوچک Problem شود، Monitoring غیرقابل اعتماد خواهد شد. Severity را با اثر کسب‌وکاری و فوریت اقدام هماهنگ کن. Information یا Warning می‌تواند برای Trend یا بررسی روزانه کافی باشد، در حالی که High و Disaster باید برای رخدادهایی بمانند که واقعاً سرویس حیاتی را تهدید می‌کنند. نام Trigger نیز باید روشن باشد؛ به‌جای `Error 1` بنویس کدام Host، کدام Resource و چه Conditionی مشکل دارد. Operational Data و Tags می‌توانند Context بیشتری به Event بدهند. Recovery Expression در برخی Triggerها مفید است تا Problem فقط با رسیدن به یک وضعیت پایدار بسته شود. این کار از Flapping جلوگیری می‌کند؛ برای مثال Warning در ۸۰٪ فعال شود اما فقط وقتی مصرف به زیر ۷۰٪ برگشت Recovery شود. No Data نیز باید با دقت استفاده شود، زیرا نبود داده می‌تواند به معنی خرابی Agent، Network یا خود Monitoring باشد. هر Trigger جدید را با داده واقعی و حالت Recovery آزمایش کن. فقط فعال شدن Problem مهم نیست؛ باید ببینی Event چگونه بسته می‌شود، چه Notificationی می‌رود و در Maintenance یا Dependency چه رفتاری دارد.

در زیرساخت، خرابی‌ها مستقل از هم نیستند. اگر یک Router اصلی خاموش شود، ده‌ها Host پشت آن نیز از دید Zabbix Unreachable می‌شوند. اگر برای همه این Hostها Problem جداگانه با Severity بالا بسازی، تیم با انبوه Alert روبه‌رو می‌شود و علت اصلی گم می‌شود. Trigger Dependency به Zabbix می‌گوید Problem یک Trigger پایین‌دستی زمانی که Trigger بالادستی در وضعیت Problem است نباید همان‌طور پردازش شود. Event Correlation نیز برای ارتباط‌دادن Eventهای مرتبط و بستن یا مدیریت آن‌ها بر اساس قواعد مشخص به کار می‌رود. برای طراحی Dependency باید Topology واقعی را بشناسی. وابستگی را از روی ظاهر Dashboard حدس نزن؛ مسیر شبکه، Gateway، Hypervisor، Storage و سرویس‌های مشترک را مشخص کن. یک VM ممکن است به ESXi، Datastore و Network وابسته باشد و یک Application علاوه بر VM به Database و DNS هم نیاز داشته باشد. همه وابستگی‌ها را لازم نیست وارد کنی، اما نقاطی که خرابی آن‌ها موج بزرگی از Alarm ایجاد می‌کند ارزش بالایی دارند. Correlation زمانی مفید است که Eventها با Tag یا ویژگی مشترک قابل شناسایی باشند. برای مثال می‌توان Maintenance یا Eventهای مرتبط با یک Service را هماهنگ‌تر مدیریت کرد. اشتباه رایج این است که Dependency را به‌گونه‌ای بسازیم که یک Problem واقعی و مستقل را پنهان کند. بنابراین Suppression باید قابل توضیح و Test شده باشد. در Incident واقعی، Dashboard باید به تو کمک کند از «چه چیزهایی خراب دیده می‌شوند» به «کدام خرابی احتمالاً علت اصلی است» برسی. Dependency و Correlation جای تحلیل انسانی را نمی‌گیرند، اما اگر درست طراحی شوند زمان Triage را به‌طور محسوسی کم می‌کنند.

در Zabbix، Action تعیین می‌کند وقتی Event با شرایط مشخص ایجاد شد چه عملی انجام شود. Action می‌تواند Notification بفرستد، Remote Command اجرا کند یا عملیات دیگری را طبق Scenario انجام دهد. مهم‌ترین بخش برای پشتیبان شبکه، طراحی Condition، Operation و Escalation است. نباید همه Eventها به همه کاربران ارسال شوند. Event مربوط به Backup، Network یا Security می‌تواند بر اساس Host Group، Tag، Severity یا شرایط دیگر به گیرنده مناسب هدایت شود. Notification خوب باید اطلاعاتی داشته باشد که برای شروع Triage کافی باشد: نام Host، Problem، Severity، زمان، Operational Data، لینک مستقیم به Event یا Dashboard و در صورت امکان Context سرویس. پیام‌هایی مثل «Server Error» ارزش عملی کمی دارند. Recovery Message هم باید ارسال شود و مدت Problem یا وضعیت بازگشت را روشن کند. اگر مشکل بعد از مدت مشخص حل نشد، Escalation می‌تواند آن را به سطح بالاتر منتقل کند. Zabbix Action از Conditionها برای انتخاب Event و Operationها برای انجام اقدام استفاده می‌کند. قبل از فعال‌کردن Media Typeهایی مثل Email یا Webhook، Send Test و مسیر Delivery را بررسی کن. Credentialهای SMTP یا Tokenها باید امن نگهداری شوند. ارسال Alert به کانال عمومی یا افراد نامرتبط می‌تواند هم نویز و هم ریسک افشای اطلاعات ایجاد کند. بعد از راه‌اندازی، Delivery را Audit کن: چند Alert ارسال شد، چند مورد Actionable بود، کدام پیام دیر رسید و کدام Severity به فرد اشتباه رفت. Notification Policy باید همراه با تغییر ساختار تیم و سرویس‌ها بازبینی شود.

Maintenance Period برای زمانی است که می‌دانی Host یا Service به‌صورت برنامه‌ریزی‌شده تغییر خواهد کرد؛ مانند Patch، Reboot، Firmware Upgrade یا جابه‌جایی تجهیزات. اگر این بازه تعریف نشود، Monitoring می‌تواند موجی از Problem و Notification تولید کند که Incident واقعی نیستند. در Zabbix می‌توان Maintenance را برای Host یا Host Group و در بازه زمانی مشخص تعریف کرد و رفتار جمع‌آوری داده و Suppression Problem را مدیریت کرد. قبل از Maintenance باید Scope روشن باشد: کدام Hostها، چه زمانی، چه مدت و به دلیل چه Changeای تحت تأثیر هستند. مدت را بیش از حد بزرگ نکن، چون ممکن است خرابی واقعی بعد از پایان کار پنهان بماند. بعد از پایان Maintenance نیز Health Check انجام بده و مطمئن شو Hostها به وضعیت عادی برگشته‌اند و Problemهای Suppressed باقی نمانده‌اند. Maintenance جای Disable کردن Monitoring نیست. در بسیاری از سناریوها بهتر است داده همچنان جمع شود تا بعداً بتوان رفتار سیستم هنگام Patch یا Reboot را بررسی کرد. همچنین Maintenance باید با Change Management هماهنگ باشد و صاحب تغییر مشخص باشد. اگر زمان Change تمدید شد، Maintenance هم باید کنترل‌شده اصلاح شود. برای محیط‌های بزرگ می‌توان Maintenanceهای دوره‌ای برای Patch Windowهای ثابت تعریف کرد، اما Changeهای اضطراری نیاز به ثبت جداگانه دارند. در زمان تغییر برنامه‌ریزی‌شده، Dashboard باید همچنان معنی‌دار بماند و Incidentهای خارج از محدوده Maintenance را از دید تیم پنهان نکند.

Network Discovery در Zabbix می‌تواند بازه‌های IP را اسکن و بر اساس Checkهایی مثل ICMP، SNMP یا Service Port دستگاه‌ها را شناسایی کند. Discovery Rule فقط پیدا کردن IP نیست؛ می‌تواند Eventهای Discovery ایجاد کند و Actionهای بعدی مثل Add Host، Add to Group یا Link Template را فعال کند. Auto Registration نیز برای Agentهای Active مفید است تا Hostهایی که خودشان به Zabbix Server یا Proxy معرفی می‌شوند بر اساس Metadata به‌صورت کنترل‌شده ثبت شوند. در شبکه Production هرگز Range بسیار بزرگ را بدون برنامه اسکن نکن. Interval، تعداد Checkها و تأثیر روی Network و Device را در نظر بگیر. Discovery را به Subnetهای مشخص محدود کن و نتیجه را ابتدا مشاهده کن. اگر قرار است Host به‌صورت خودکار Template بگیرد، شرط‌های Metadata یا Service را دقیق تنظیم کن تا یک دستگاه ناشناخته Template نامناسب دریافت نکند. کشف خودکار جای Inventory و CMDB نیست. Device پیدا شده باید Owner، Role، Site و اهمیت سرویس داشته باشد تا Monitoring معنادار شود. همچنین Discovery می‌تواند تجهیزاتی را نشان دهد که قبلاً در Documentation نبوده‌اند؛ این نتیجه باید برای اصلاح Inventory استفاده شود، نه اینکه فقط به Dashboard اضافه شود. در محیط DHCP یا Client Network باید مراقب باشی که Discovery صدها Endpoint موقت نسازد. Scope Monitoring را بر اساس نیاز زیرساخت مشخص کن. هدف Automation، حذف کار تکراری همراه با کنترل است، نه ایجاد Configuration ناشناخته و غیرقابل مدیریت.

Low-Level Discovery یا LLD برای کشف منابع داخلی یک Host استفاده می‌شود؛ منابعی که تعداد و نامشان از قبل ثابت نیست، مثل File Systemها، Network Interfaceها، CPU Coreها یا SNMP Interfaceهای یک Switch. به‌جای اینکه برای هر Interface دستی Item و Trigger بسازی، Discovery Rule فهرست منابع را پیدا می‌کند و Item Prototype، Trigger Prototype و Graph Prototype برای هر مورد ایجاد می‌شوند. این قابلیت در محیط‌هایی که Interface یا Disk تغییر می‌کند بسیار مهم است. LLD با Macroهای کشف‌شده مثل نام Interface یا File System کار می‌کند. باید Filter تعریف کنی تا منابع بی‌اهمیت وارد Monitoring نشوند. برای مثال Loopback، Interfaceهای موقت یا Mount Pointهایی که نیاز به Alert ندارند می‌توانند با Filter حذف شوند. Context Macro نیز اجازه می‌دهد Threshold یک Resource خاص متفاوت باشد. مشکل رایج LLD، تولید صدها Item غیرضروری و رشد Database است. قبل از Link کردن Template روی تعداد زیاد Host، نتیجه Discovery را روی چند نمونه ببین. Keep Lost Resources Period را نیز بفهم تا وقتی Resource حذف شد، Itemهای مربوط فوراً یا با تأخیر پاک شوند. حذف شتاب‌زده می‌تواند History موردنیاز Incident را از بین ببرد. LLD یکی از ابزارهایی است که Monitoring را واقعاً مقیاس‌پذیر می‌کند، اما تنها وقتی Filter، Prototype و Retention درست باشند. هر Resource کشف‌شده باید دلیل Monitoring داشته باشد؛ «چون می‌توانیم جمع کنیم» دلیل کافی نیست.

Dashboard صفحه‌ای برای کنار هم قرار دادن Widgetها و نمایش وضعیت سرویس‌هاست. طراحی خوب از سؤال شروع می‌شود: مدیر شیفت در یک نگاه چه چیزی باید بداند؟ پشتیبان Network چه Problemهایی باید ببیند؟ مدیر IT چه شاخص‌هایی می‌خواهد؟ اگر صد Graph و Gauge را بدون اولویت کنار هم بگذاری، Dashboard در زمان Incident کندکننده می‌شود. Zabbix Dashboard می‌تواند Widgetهایی برای Problems، Host Availability، Graph، Gauge، Top Hosts، Map و داده‌های دیگر داشته باشد. یک Dashboard عملیاتی باید ابتدا وضعیت بحرانی و سرویس‌های حیاتی را نشان دهد. بعد شاخص‌های ظرفیت و Trend قرار می‌گیرند. رنگ و Severity باید معنی ثابت داشته باشند و Widgetها بر اساس Site یا Service قابل فیلتر باشند. Dashboard NOC با Dashboard مدیریتی یکسان نیست؛ NOC به Problem و Context فنی نیاز دارد، مدیریت به Availability، Trend و Summary اهمیت می‌دهد. از Screen بزرگ برای نمایش دائمی فقط اطلاعات Actionable استفاده کن. اگر Widget هرگز در تصمیم‌گیری استفاده نمی‌شود، احتمالاً جای آن در Dashboard اصلی نیست. Refresh Interval نیز نباید بی‌دلیل بسیار کوتاه باشد. برای محیط چندمشتری یا چندسایت، Permission و Data Exposure را نیز در نظر بگیر. پس از چند Incident از تیم بپرس آیا Dashboard کمک کرد یا مجبور شدند برای یافتن علت به چند صفحه دیگر بروند. طراحی Dashboard باید بر اساس تجربه عملی اصلاح شود. معیار موفقیت، سرعت درک وضعیت است نه تعداد نمودارها.

Graph یکی از مهم‌ترین ابزارهای تحلیل Monitoring است، چون یک مقدار منفرد بدون زمینه زمانی می‌تواند گمراه‌کننده باشد. Graph نشان می‌دهد Metric چه زمانی تغییر کرده، آیا تغییر ناگهانی یا تدریجی بوده، آیا الگوی روزانه دارد و آیا چند Metric هم‌زمان تغییر کرده‌اند. Zabbix برای Item عددی Simple Graph را به‌صورت مستقیم فراهم می‌کند و Graphهای سفارشی می‌توانند چند Item را کنار هم نشان دهند. هنگام Incident بازه زمانی را درست انتخاب کن. Zoom بسیار نزدیک ممکن است روند قبلی را پنهان کند و بازه بسیار بزرگ Spike کوتاه را محو کند. اگر CPU بالا رفته، آن را با Load، Disk Latency، Network Traffic یا Queue مرتبط مقایسه کن. Correlation بصری علت قطعی را ثابت نمی‌کند، اما Hypothesis خوبی برای بررسی بعدی می‌سازد. Scale و Unit را بخوان. دو محور با Unit متفاوت می‌توانند برداشت اشتباه ایجاد کنند. Average نیز Peak را پنهان می‌کند؛ برای ظرفیت‌سنجی Maximum و Percentile در برخی Metricها مهم‌اند. Graph را با Timeline Change و Backup Window تطبیق بده تا رفتار برنامه‌ریزی‌شده را با مشکل اشتباه نگیری. برای Report یا Incident، Screenshot Graph به‌تنهایی کافی نیست. Timestamp، Timezone، Host، Item، بازه و رویدادهای هم‌زمان را ثبت کن. هدف Graph «دیدن شکل» نیست؛ تبدیل داده زمانی به سؤال فنی قابل بررسی است.

Gauge و Single Value برای نمایش یک مقدار کلیدی مناسب‌اند؛ مانند درصد فضای آزاد Datastore، تعداد Problemهای High یا Availability یک سرویس. مزیت آن‌ها این است که وضعیت را سریع منتقل می‌کنند، اما همین سادگی می‌تواند خطرناک باشد. اگر فقط «CPU = ۸۷٪» را نشان بدهی و ندانی این مقدار لحظه‌ای است یا Average پنج دقیقه، Threshold چه بوده و Baseline چیست، تصمیم عجولانه ممکن است اشتباه باشد. در Zabbix Gauge Widget می‌تواند Min/Max، Threshold و رنگ‌بندی داشته باشد. Range را بر اساس Unit واقعی تعریف کن و Threshold رنگی را با Trigger Policy هماهنگ نگه دار. Gauge برای Metricهایی مناسب است که محدوده و معنی فعلی‌شان روشن است. برای Trend بلندمدت، Graph معمولاً اطلاعات بیشتری می‌دهد. Dashboard را با Gaugeهای متعدد پر نکن. عددی که فقط «جالب» است اما اقدام یا تصمیمی پشت آن نیست ارزش عملیاتی کمی دارد. همچنین رنگ قرمز را برای هر مقدار غیرعادی استفاده نکن؛ باید با Severity و مفهوم Problem هم‌راستا باشد. یک Dashboard پر از رنگ‌های هشدار، حتی اگر همه سرویس‌ها سالم باشند، اعتماد کاربر را کم می‌کند. هر Gauge را با یک سؤال همراه کن: اگر این عدد از محدوده خارج شد چه کسی چه کاری انجام می‌دهد؟ اگر پاسخ مشخصی نداری، شاید آن Metric باید در Graph یا Report باشد نه در صفحه اصلی NOC.

Network Map در Zabbix می‌تواند Hostها، Triggerها، Imageها، Linkها و Submapها را در یک نمای Topology کنار هم قرار دهد. ارزش Map زمانی است که رابطه سرویس‌ها و مسیر ارتباط را سریع نشان دهد. یک نقشه خوب کمک می‌کند هنگام Down شدن چند تجهیز بفهمی آیا همه پشت یک Switch یا WAN Link مشترک هستند. اگر Map فقط تصویر زیبای Rack یا ساختمان باشد و ارتباط عملیاتی نداشته باشد، در Incident کمک زیادی نمی‌کند. نقشه را بر اساس لایه منطقی طراحی کن. برای سازمان چندسایتی یک Map سطح بالا می‌تواند Siteها و WAN را نشان دهد و هر Site به Submap جزئی‌تر لینک شود. Label باید مختصر و قابل خواندن باشد. Linkها را فقط جایی رسم کن که معنی واقعی دارند و در صورت امکان Trigger یا وضعیت Link را به آن‌ها وصل کن. Map نباید جای Documentation دقیق شبکه را بگیرد. Diagram مهندسی همچنان باید Port، VLAN، IP Plan و جزئیات لازم را داشته باشد. Map Monitoring برای وضعیت زنده و Triage است. اگر Topology تغییر کرد، Map نیز باید در Change Process به‌روزرسانی شود؛ Map قدیمی در زمان Incident می‌تواند گمراه‌کننده باشد. برای NOC یک نمای ساده و سریع بهتر از یک نقشه بسیار شلوغ است. یک Network Map خوب باید Scope خرابی را در همان نگاه اول نشان دهد و بعد کارشناس را برای بررسی جزئیات به Dashboard یا Host Detail هدایت کند.

Availability Report زمانی معنی دارد که Trigger و تعریف سرویس درست باشند. Zabbix می‌تواند Availability Triggerها را در بازه زمانی گزارش کند، اما درصدی که می‌بینی مستقیم به این بستگی دارد که Problem و Recovery چگونه تعریف شده‌اند. اگر Trigger بیش از حد حساس یا برعکس خیلی دیر فعال شود، Report نیز واقعیت تجربه کاربر را دقیق نشان نمی‌دهد. بنابراین Report محصول نهایی طراحی Monitoring است، نه جایگزین آن. برای گزارش مدیریتی باید بازه، Timezone، Maintenance Planned، Scope سرویس و روش محاسبه روشن باشد. Availability Router با Availability سرویس CRM یکی نیست؛ ممکن است Router Up باشد ولی Application به دلیل Database Down در دسترس نباشد. اگر SLA روی سرویس کسب‌وکاری تعریف شده، Check نیز باید همان تجربه مورد توافق را نمایندگی کند. در گزارش ماهانه علاوه بر درصد، تعداد Incident، مدت طولانی‌ترین قطعی، علت‌های اصلی و Trend نسبت به ماه قبل ارزش دارد. درصد بالا به‌تنهایی نمی‌گوید آیا یک قطعی کوتاه در ساعت حیاتی رخ داده یا چند اختلال کوچک داشته‌ایم. Raw Alert Count هم معیار کیفیت نیست؛ باید Problemهای واقعی و اثرشان تحلیل شوند. Report باید قابل بازتولید باشد. اگر مدیر بعداً سؤال کرد «این ۹۹٫۷٪ چگونه محاسبه شده؟» تیم باید بتواند Trigger، بازه و Maintenanceها را نشان دهد. این شفافیت اعتماد به Monitoring را بالا می‌برد.

Zabbix Proxy یک جزء واسط برای جمع‌آوری داده از Hostهای یک Site یا Segment و ارسال آن به Zabbix Server مرکزی است. Proxy می‌تواند در شعبه‌ای با لینک WAN ناپایدار مفید باشد؛ داده را محلی جمع می‌کند و در قطع موقت ارتباط با Server در Database خودش Buffer نگه می‌دارد تا بعداً ارسال کند. Proxy پردازش نهایی Trigger و Configuration Management را جای Server انجام نمی‌دهد، اما حجم Polling مستقیم از مرکز را کم و معماری Distributed Monitoring را ساده‌تر می‌کند. برای طراحی Proxy باید مشخص کنی Active یا Passive باشد، چه Hostهایی به آن Assign می‌شوند، Database Proxy چه ظرفیتی نیاز دارد و اگر WAN چند ساعت قطع شد چه مدت داده باید Buffer شود. مسیر DNS، Time Sync و Firewall بین Proxy و Server و نیز بین Proxy و Deviceهای محلی باید بررسی شود. Proxy باید از همان دید شبکه‌ای که قرار است Hostها را Poll کند دسترسی واقعی داشته باشد. Proxy یک Single Point of Failure جدید هم می‌تواند ایجاد کند. خود Proxy را از Server مرکزی Monitoring کن و CPU، Memory، Disk، Queue و ارتباطش را ببین. اگر Proxy Down شود، ممکن است ده‌ها Host ظاهراً No Data شوند؛ این وضعیت را باید با Dependency یا Alert مشخص از خرابی خود Proxy جدا کنی. در شعب کوچک شاید Proxy لازم نباشد. استفاده از آن زمانی توجیه دارد که تعداد Host، محدودیت Firewall، کیفیت WAN یا نیاز Buffer ارزش افزوده ایجاد کند. معماری را بر اساس نیاز واقعی انتخاب کن، نه صرفاً چون Zabbix این قابلیت را دارد.

سیستم Monitoring اگر خودش کند، پر یا قطع شود ممکن است تصویری اشتباه از سلامت زیرساخت بدهد. Zabbix Internal Itemها و Statusهای مختلفی برای بررسی Processها، Queue، Cache و عملکرد Server فراهم می‌کند. در کنار آن باید CPU، RAM، Disk، Database Size، I/O، Backup Database، زمان Synchronization و Availability Frontend را زیر نظر داشته باشی. اگر Queue رشد کند، یعنی برخی Checkها دیرتر از زمان برنامه‌ریزی‌شده اجرا می‌شوند و داده تازه نیست. Database معمولاً حساس‌ترین بخش است. رشد History، Queryهای سنگین، Housekeeping و Storage Full می‌توانند کل Monitoring را مختل کنند. Alarm برای فضای آزاد Database Volume، Backup Failure و Replication در صورت استفاده لازم است. Time Sync نیز مهم است؛ اختلاف ساعت بین Zabbix، Proxy و Hostها Timeline Incident را به‌هم می‌ریزد. Monitoring خود Zabbix بهتر است تا حدی مستقل باشد. اگر همه Alertها فقط از خود Zabbix ارسال شوند و Zabbix کامل Down شود، ممکن است هیچ پیامی دریافت نکنی. برای محیط حیاتی می‌توان یک External Check ساده از بیرون، Monitoring ثانویه یا Health Endpoint مستقل داشت تا Down شدن Platform تشخیص داده شود. در Runbook باید مشخص باشد اگر Dashboard باز نشد یا داده تازه نبود، از کجا شروع کنی: Processها، Service، Database، Queue، Proxy و Network. Monitoring Tool هم یک سرویس Production است و باید Backup، Patch و Capacity Plan خودش را داشته باشد.

Ping فقط می‌گوید در آن لحظه ICMP Response دریافت شده؛ سلامت Windows Server بسیار فراتر از آن است. برای مانیتورینگ پایه باید CPU، Memory، Disk Free، Disk Latency یا Queue در صورت نیاز، Network Interface، Uptime و Clock را ببینی. سپس Serviceهای حیاتی، Event Log، Processهای مهم و Roleهای نصب‌شده را اضافه کنی. یک Server می‌تواند Ping بدهد اما Disk آن پر باشد، سرویس SQL متوقف شده باشد یا Login کاربران به دلیل مشکل Domain مختل شود. Zabbix Agent 2 برای Metricهای سیستم‌عامل و Serviceها مناسب است. Template رسمی Windows نقطه شروع خوبی است، اما باید Discovery و Triggerها را با نقش Server تطبیق بدهی. روی File Server فضای Volumeها و SMB-related Service مهم است؛ روی Application Server ممکن است Process و Port سرویس مهم‌تر باشد. Update Interval و Threshold را بر اساس Baseline و Criticality تنظیم کن. CPU یا RAM بالا را به‌تنهایی Incident اعلام نکن. Windows از Memory برای Cache استفاده می‌کند و یک Process ممکن است موقتاً CPU مصرف کند. باید Duration، User Experience و Metricهای مرتبط را ببینی. روی Disk نیز فقط درصد فضای آزاد کافی نیست؛ رشد، I/O و Volume نقش دارند. برای هر Windows Server یک Service Profile داشته باش: «این Server چه کاری انجام می‌دهد و چه چیزی باید برای سالم دانستن آن برقرار باشد؟». Monitoring را بر اساس همین پاسخ طراحی کن تا از جمع‌آوری ده‌ها Metric بی‌هدف دور بمانی.

Windows Event Logs اطلاعات بسیار زیادی تولید می‌کنند و اگر همه Eventها را بدون Filter وارد Zabbix کنی هم Agent و Database درگیر می‌شوند و هم نویز ایجاد می‌شود. برای هر سرویس باید Log Source و Eventهایی را انتخاب کنی که واقعاً به سلامت و رفتار همان سرویس مربوط باشند. Application، System و Security هرکدام کاربرد متفاوتی دارند و Roleهایی مثل AD DS، DNS یا Failover Clustering Logهای تخصصی خود را دارند. Service State نیز برای سرویس‌هایی که باید دائماً Running باشند Signal ساده اما مهمی است. برای Log Monitoring ابتدا Event ID، Source و Severity را از Incident واقعی یا مستندات رسمی شناسایی کن و سپس Filter بساز. یک Error تکرارشونده ممکن است Known Issue یا Noise باشد، در حالی که Event خاصی می‌تواند نشانه خرابی بحرانی باشد. Log را همراه با Timestamp، Host و Service Context نگه دار و Alarm را فقط برای موارد Actionable فعال کن. روی Serviceها Auto Start بودن را با الزام عملیاتی اشتباه نکن. بعضی Serviceها Trigger Start هستند و توقفشان طبیعی است. فقط Serviceهایی را Alert کن که طبق طراحی باید Running باشند. همچنین Restart خودکار Service می‌تواند Problem را پنهان کند؛ اگر Service چندبار Crash و دوباره Start می‌شود، Count رخداد و Event Log را ببین. Monitoring Log جای SIEM کامل نیست. Zabbix برای Alertهای عملیاتی مناسب است، اما نگهداری امنیتی گسترده و Correlation پیچیده ممکن است ابزار دیگری بخواهد. Scope را روشن نگه دار تا Platform Monitoring وظیفه خودش را خوب انجام دهد.

Active Directory مجموعه‌ای از سرویس‌های وابسته است؛ سلامت آن را نمی‌توان فقط با Up بودن Domain Controller سنجید. DNS، Replication، SYSVOL، Netlogon، Kerberos، Time Synchronization و دسترسی به Global Catalog در تجربه Login و اعمال Policy نقش دارند. Microsoft برای پایش AD روی بررسی Eventها و نشانه‌های رفتاری مهم تأکید می‌کند و در عملیات روزانه باید علاوه بر Resourceهای Server، سرویس‌های AD-specific را هم زیر نظر داشته باشی. برای هر DC Availability شبکه، DNS Service، NTDS/Netlogon، فضای Disk، Time Offset و Event Logهای مرتبط را بررسی کن. Replication Failure اگر زود تشخیص داده نشود می‌تواند باعث اختلاف اطلاعات بین DCها شود. اگر چند Site داری، Site Link و ارتباط WAN نیز Context مهمی است. Monitoring باید نشان دهد مشکل روی یک DC است یا روی کل Domain. Security Monitoring AD حوزه گسترده‌ای است و Monitoring عملیاتی نباید جای ابزارهای امنیتی را بگیرد، اما رخدادهایی مثل تغییر غیرعادی حساب‌های حساس، خطاهای مکرر Authentication یا توقف سرویس‌های کلیدی نیازمند Visibility هستند. دسترسی Monitoring به Security Log را با Least Privilege طراحی کن. Runbook AD باید قبل از Incident آماده باشد. اگر Replication Alert آمد، پشتیبان باید بداند چه Checkهایی انجام دهد و چه زمانی Escalate کند. Alertی که فقط می‌گوید «AD Problem» بدون DC، Partner و Context ارزش کمی دارد.

DNS و DHCP از سرویس‌هایی هستند که خرابی آن‌ها ممکن است به شکل «اینترنت ندارم»، «Domain Login کند است» یا «نام Server باز نمی‌شود» دیده شود. برای DNS فقط Running بودن Service کافی نیست؛ باید Query واقعی برای Record مشخص انجام شود و Response Time و نتیجه بررسی شود. برای DHCP نیز Service State، Scope Utilization، Free Address و خطاهای مرتبط اهمیت دارند. Scope نزدیک به پر شدن می‌تواند قبل از اینکه کاربران IP نگیرند هشدار پیشگیرانه ایجاد کند. برای DNS چند Check طراحی کن: Resolve یک Record داخلی حیاتی، Resolve خارجی در صورت نیاز، پاسخ از DNS Server مشخص و زمان پاسخ. اگر AD-integrated DNS داری، Replication و سلامت DC نیز مرتبط است. برای DHCP نسبت Used/Free Address را در Scopeهای مهم ببین و Exclusion/Reservation را در Capacity Analysis در نظر بگیر. Alarm DHCP فقط زمانی که Scope صددرصد پر شد دیر است. Warning را بر اساس نرخ رشد و زمان لازم برای اقدام تنظیم کن. در محیط با Lease Duration کوتاه یا کاربران متحرک، الگوی مصرف ممکن است سریع تغییر کند. DNS نیز ممکن است Service Up باشد اما Forwarder یا Zone مشکل داشته باشد؛ Synthetic Query این تفاوت را آشکار می‌کند. مانیتورینگ این دو سرویس باید با Troubleshooting هم پیوند داشته باشد. وقتی Help Desk افزایش Ticket درباره قطع شبکه را گزارش می‌کند، Dashboard DNS/DHCP می‌تواند سریع نشان دهد آیا مشکل مشترک زیرساختی وجود دارد یا نه.

SQL Server می‌تواند Service Running داشته باشد اما Application کند یا غیرقابل استفاده باشد. مانیتورینگ باید چند لایه داشته باشد: سلامت Windows Host، Availability SQL Service و Port، فضای Database و Log Volume، Backup Status، Connection و در صورت نیاز شاخص‌های Performance مثل Waitها، Batch Request، Buffer یا Queryهای مشخص. انتخاب Metric باید با Workload و تخصص DBA هماهنگ باشد؛ Monitoring عمومی نباید بدون دانش Database Thresholdهای پیچیده و قطعی اعلام کند. از دید پشتیبان شبکه، اول باید سؤال‌های ساده را جواب بدهی: آیا Server قابل دسترس است؟ SQL Service Running است؟ Port Listening است؟ Disk مربوط به Data یا Log نزدیک پر شدن است؟ Backup اخیر موفق بوده؟ Application می‌تواند یک Query سبک یا Connection Test انجام دهد؟ بعد از این لایه، اگر Performance Problem وجود دارد باید با DBA یا تیم Application عمیق‌تر بررسی شود. Disk Free برای SQL بسیار مهم است چون رشد Data و Transaction Log می‌تواند سریع باشد. Threshold را فقط درصدی نگذار؛ اندازه مطلق و Growth Rate را هم ببین. Backup Job Failure نیز باید Alert جداگانه داشته باشد. Query Monitoring را با Credential Least Privilege و Timeout مناسب انجام بده تا خود Check باعث بار نشود. داشبورد SQL باید بین زیرساخت و Database Context تعادل داشته باشد. هدف پشتیبان این نیست که با یک Graph هر مشکل Query را تشخیص دهد، بلکه باید Scope را سریع مشخص و Evidence درست برای Escalation جمع کند.

در VMware یک VM سالم به چند لایه وابسته است: ESXi Host، CPU و Memory Host، Datastore، Physical NIC، vSwitch/Port Group و در محیط مدیریتی vCenter. اگر فقط داخل Guest Agent نصب کنی، ممکن است مشکل Storage یا Host را دیر ببینی. اگر فقط ESXi را مانیتور کنی، Application داخل VM ممکن است خراب باشد. بنابراین Monitoring باید لایه Hypervisor و Guest را به هم مرتبط کند. شاخص‌های مهم شامل Host Availability، CPU/Memory Pressure، Datastore Free Space و Latency، وضعیت Physical NIC، Alarmهای vCenter، VM Power State و VMware Tools Status هستند. Thresholdهای Performance باید با Baseline و Best Practice نسخه همان محیط تطبیق داده شوند. Datastore Space خصوصاً مهم است چون Snapshot یا Growth VM می‌تواند فضای باقی‌مانده را سریع مصرف کند. در Cluster باید HA/DRS Eventها و Host Maintenance را Context بدهی تا Migration برنامه‌ریزی‌شده با Incident اشتباه نشود. اگر VM Restart شد، Timeline vCenter/ESXi و Windows Event Log را کنار هم ببین. Monitoring چندلایه اجازه می‌دهد Root Cause را سریع‌تر محدود کنی. برای Backup نیز Integration با VMware اهمیت دارد؛ Snapshotهای موقت Backup و Datastore I/O می‌توانند رفتار دوره‌ای ایجاد کنند. Baseline را طوری بساز که Backup Window شناخته شده باشد. هر Spike در همان ساعت الزاماً Problem نیست، اما اثر آن بر سرویس باید سنجیده شود.

RouterOS از SNMP برای ارائه اطلاعات مدیریتی به NMSهایی مثل Zabbix یا PRTG پشتیبانی می‌کند. با SNMP می‌توان Interface Counter، Traffic، Status و اطلاعات دیگری را جمع کرد و با Template مناسب روی Trend و Trigger استفاده کرد. RouterOS همچنین Logging داخلی دارد و Actionهای Log می‌توانند پیام‌ها را به مقصد Remote Syslog ارسال کنند. این دو مسیر مکمل‌اند: SNMP برای Metric و State، Log برای رخداد و متن جزئیات مناسب است. در SNMP تا حد امکان نسخه امن‌تر و Credential محدود استفاده کن. Community پیش‌فرض یا دسترسی باز از هر IP طراحی خوبی نیست. Firewall Router باید فقط Monitoring Server یا Proxy لازم را اجازه دهد. Interface Discovery را Filter کن تا Dynamic یا Interfaceهای بی‌اهمیت Dashboard را شلوغ نکنند. برای WAN علاوه بر Traffic، Link State، Errors و در صورت امکان Latency/Packet Loss را ببین. Log Remote باعث می‌شود حتی اگر Router Restart یا مشکل داخلی داشت، بخشی از رخدادها بیرون دستگاه نگه داشته شوند. Topicها را هدفمند انتخاب کن؛ ارسال همه Debug Logها می‌تواند حجم بسیار زیادی بسازد. Eventهای Authentication، Interface، VPN یا Routing را بر اساس نیاز عملیاتی انتخاب کن. WinBox برای بررسی لحظه‌ای عالی است، اما Monitoring باید تاریخچه و Alert داشته باشد. پیش از ورود به Router بهتر است تاریخچه تغییر Link، روند Utilization و Eventهای مرتبط را داشته باشی تا بررسی را با شواهد شروع کنی.

SNMP پروتکلی برای مدیریت و مانیتورینگ تجهیزات شبکه و بسیاری از دستگاه‌های زیرساختی است. NMS مقدار Objectها را با OID از Agent دستگاه می‌خواند. MIB نام و ساختار بسیاری از این Objectها را توصیف می‌کند تا به‌جای حفظ رشته‌های عددی، معنی Counter مشخص باشد. Interface Traffic، Operational Status، Errors و System Information نمونه‌های رایج هستند. SNMP Trap مسیر دیگری است که Device می‌تواند رخداد را به Manager ارسال کند، اما Polling و Trap کاربرد یکسانی ندارند. نسخه‌های SNMP از نظر امنیت تفاوت دارند. SNMPv1/v2c عمدتاً بر Community String تکیه دارند، در حالی که SNMPv3 قابلیت Authentication و Privacy قوی‌تری فراهم می‌کند. در محیط Production هر جا Device و ابزار پشتیبانی می‌کنند، v3 انتخاب بهتری است. دسترسی SNMP را در ACL/Firewall به NMS محدود کن و Credential را مثل رمز عبور مدیریت کن. Counterهای ترافیک باید درست تفسیر شوند. برخی Counterها افزایش تجمعی دارند و Monitoring از اختلاف مقدار در زمان، Rate می‌سازد. Counter Width و Wrap، Interface Speed و Unit روی نتیجه اثر دارند. اگر OID اشتباه یا نوع داده نادرست باشد، Graph می‌تواند عدد ظاهراً معتبر اما بی‌معنی نشان دهد. قبل از Import کردن MIBهای متعدد، ببین Template رسمی Device چه چیزی را پوشش می‌دهد. OID سفارشی را فقط وقتی اضافه کن که Metric واقعاً برای تصمیم یا Alert لازم باشد و معنی آن از مستندات Vendor روشن باشد.

برای Switch، مهم‌ترین سؤال فقط روشن بودن دستگاه نیست. باید بدانیم Uplinkها Up هستند، Traffic چه میزان است، Interface Error و Discard داریم یا نه، STP یا Link Flap رخ داده و آیا منابع دستگاه در محدوده عادی هستند. در Access Switch ممکن است صدها Port داشته باشی، اما Alert روی تک‌تک Portهای کاربر معمولاً نویز زیادی می‌سازد. Uplink، Trunk، Server Port و Portهای زیرساخت اهمیت متفاوتی دارند و Monitoring باید این تفاوت را بفهمد. از SNMP برای Operational Status، Traffic Counter، Error/Discard و System Metricهای موجود استفاده کن. Interface Description را در Switch استاندارد کن تا در Zabbix یا PRTG معلوم باشد هر Port به چه چیزی متصل است. اگر Description خالی باشد، Alarm `Gi1/0/24 down` در نیمه‌شب ارزش بسیار کمتری از `Uplink-to-Core down` دارد. Discovery Filter نیز باید Portهای بی‌اهمیت یا Administratively Down را مدیریت کند. Traffic بالا به‌تنهایی Fault نیست. باید آن را با Interface Speed، زمان، Baseline و کیفیت سرویس مقایسه کنی. Error و Discard می‌توانند سرنخ Cabling، Duplex، Congestion یا مشکل فیزیکی باشند، اما Root Cause باید با Counter و وضعیت دو سمت Link بررسی شود. Counter Reset بعد از Reboot را هم هنگام تحلیل Trend در نظر بگیر. برای Core و Distribution بهتر است Temperature، Fan، Power Supply، Stack/Chassis State و CPU/Memory در صورت پشتیبانی Vendor نیز Monitor شوند. Monitoring درست باید نشانه‌های خرابی زیرساخت را پیش از قطع کامل سرویس قابل مشاهده کند.

Bandwidth ظرفیت اسمی Link است، Traffic حجم داده عبوری و Utilization نسبت استفاده به ظرفیت است. این سه مفهوم را نباید یکی دانست. یک Link یک گیگابیتی ممکن است در Peak به ۸۰۰ مگابیت برسد و همچنان بدون Error کار کند، یا در Utilization کمتر با Drop و Latency مشکل داشته باشد. Errors معمولاً به خرابی دریافت/ارسال یا مشکلات فیزیکی اشاره می‌کنند و Discards می‌توانند در Congestion یا محدودیت Queue رخ دهند. تحلیل درست نیازمند مشاهده Counterهای دو سمت Link و Timeline است. برای Capacity Planning میانگین روزانه کافی نیست. Peakهای ساعات کاری، 95th Percentile در برخی سناریوهای WAN و مدت ماندن نزدیک ظرفیت را بررسی کن. اگر لینک فقط چند ثانیه به ۹۰٪ می‌رسد ممکن است طبیعی باشد؛ اگر هر روز دو ساعت Saturated است، ارتقای ظرفیت یا بررسی Traffic لازم می‌شود. Graph In/Out را جدا ببین چون بسیاری از Linkها الگوی نامتقارن دارند. Counter Error را به Rate تبدیل کن و با Traffic مقایسه کن. چند Error در میلیاردها Packet با هزاران Error در چند دقیقه یکسان نیست. Reset Counter یا Reboot Device می‌تواند Trend را تغییر دهد. اگر CRC یا Physical Error دیده می‌شود، کابل، SFP، Fiber و Port دو سمت باید بررسی شوند. Alert را طوری طراحی کن که Context داشته باشد: Link Name، Speed، Utilization، Error Rate و مدت زمان. پیام «Bandwidth High» بدون این اطلاعات تیم را مجبور می‌کند دوباره همه چیز را از ابتدا پیدا کند.

برای WAN و اینترنت، Up بودن Link فقط اولین سطح سلامت است. Latency زمان رفت‌وبرگشت Packet را نشان می‌دهد، Packet Loss درصد Packetهای از دست‌رفته و Jitter تغییرپذیری Delay است. سرویس‌هایی مثل VoIP، Remote Desktop و VPN ممکن است با Link کاملاً Up اما Latency یا Loss بالا تجربه بدی داشته باشند. Monitoring باید کیفیت ارتباط را در کنار Availability و Bandwidth ببیند. ICMP Check ساده برای Baseline مفید است، اما مقصد Check اهمیت دارد. Ping به Gateway ISP فقط Last Mile را می‌سنجد و Ping به یک مقصد اینترنتی مسیر بیشتری را شامل می‌شود. برای Site-to-Site VPN بهتر است Endpoint داخلی دو سمت را نیز Check کنی. اگر چند Target داری، می‌توانی مشکل Local Link را از مشکل یک Destination خاص بهتر جدا کنی. Jitter برای Traffic حساس به زمان مهم است، اما همه NMSها آن را به یک شکل اندازه نمی‌گیرند. روش Measurement را مستند کن. Packet Loss کوتاه و Burst با Average طولانی ممکن است پنهان شود، پس Interval و Aggregation باید مناسب سرویس باشد. همچنین ICMP ممکن است توسط برخی شبکه‌ها Rate Limit شود؛ یک نتیجه غیرعادی باید با ابزارهای دیگر تأیید شود. Dashboard WAN باید Quality، Utilization و Availability را کنار هم نشان دهد. هنگام شکایت کاربر، Timeline این Metricها را با VPN Log و ISP Incident مقایسه کن تا Evidence برای Escalation داشته باشی.

اگر وب‌سایت یا پنل CRM روی Port 443 Listening باشد، هنوز ممکن است صفحه Login خطا بدهد یا Backend Database در دسترس نباشد. HTTP/HTTPS Monitoring باید تا جایی که لازم است تجربه واقعی سرویس را شبیه‌سازی کند: DNS Resolve، TCP Connection، TLS، HTTP Status Code، Response Time و در صورت نیاز وجود متن یا محتوای مشخص در Response. Zabbix Web Scenario و HTTP Agent می‌توانند برای چنین Checkهایی استفاده شوند و PRTG نیز Sensorهای HTTP دارد. Check ساده Status Code 200 برای بسیاری از سرویس‌ها شروع خوبی است، اما Redirect، Authentication و API Response باید شناخته شوند. اگر سرویس بعد از Login است، Credential مخصوص Monitoring با حداقل دسترسی بساز. Password را در Macro یا Secret مناسب نگه دار و در URL یا متن Alert افشا نکن. Timeout نیز باید متناسب با SLA و رفتار سرویس باشد. Synthetic Check را از مکان درست اجرا کن. Check از LAN داخلی تجربه کاربر اینترنتی را نشان نمی‌دهد و Check خارجی ممکن است مشکل داخلی را نبیند. برای سرویس مهم می‌توان Check داخلی و خارجی داشت تا Scope خرابی سریع‌تر مشخص شود. مراقب باش درخواست Monitoring خودش بار زیاد یا Transaction واقعی ناخواسته ایجاد نکند. وقتی Alert Web ایجاد شد، Status، Response Time و مرحله شکست را در پیام قرار بده. این Context فرق «DNS شکست»، «TLS شکست» و «Application 500» را روشن می‌کند و Triage را سریع‌تر می‌سازد.

گواهی TLS معمولاً تاریخ انقضای مشخص دارد و فراموش‌شدن تمدید آن می‌تواند سرویس کاملاً سالم را از دید کاربران غیرقابل اعتماد یا غیرقابل دسترس کند. چون تاریخ انقضا قابل پیش‌بینی است، Monitoring Certificate یکی از ساده‌ترین نمونه‌های اقدام پیشگیرانه است. باید Expiry Date، تعداد روز باقی‌مانده و در صورت نیاز Chain و Hostname Validation را بررسی کنی. Alert بهتر است چند مرحله داشته باشد؛ مثلاً اطلاع زودهنگام، Warning نزدیک‌تر و High در روزهای آخر. فقط Public Websiteها را فراموش نکن. VPN Portal، RDP Gateway، vCenter، Reverse Proxy، API، Mail و سرویس‌های داخلی نیز ممکن است Certificate داشته باشند. Inventory Certificate باید Owner، CA، محل استفاده و روش Renewal را مشخص کند. اگر Auto-Renewal داری، Monitoring همچنان لازم است تا شکست Renewal یا Deploy تشخیص داده شود. Check باید به همان Hostname متصل شود که کاربر استفاده می‌کند؛ اتصال صرف به IP ممکن است نام Certificate را درست نسنجند. همچنین Clock Monitoring مهم است، چون Time نادرست می‌تواند اعتبار Certificate را اشتباه نشان دهد. برای Certificateهای داخلی نیز Trust Chain و CA Availability بسته به معماری اهمیت دارد. وقتی Alert نزدیک انقضا آمد، Runbook باید مشخص کند Renewal دست چه کسی است، CSR یا Auto-Renew چگونه انجام می‌شود و پس از Deploy چه Checkی لازم است. Alert بدون Owner ممکن است هفته‌ها باز بماند.

TCP Check می‌تواند مشخص کند آیا از نقطه Monitoring تا Host و Port مشخص اتصال برقرار می‌شود یا نه. این Check از Ping معنادارتر است چون Service Endpoint را می‌سنجد، اما هنوز سلامت کامل Application را ثابت نمی‌کند. برای مثال اتصال TCP به Port 1433 نشان می‌دهد مسیر و Listener SQL در دسترس‌اند، نه اینکه Queryهای Application موفق هستند. بنابراین TCP Check یک لایه از Health Model است. Portهای حیاتی مانند RDP، SQL، HTTPS، SMTP یا سرویس اختصاصی را بر اساس نقش Server انتخاب کن. از Check کردن صدها Port بی‌دلیل خودداری کن. Timeout را معقول بگذار و Check را از همان Zabbix Server یا Proxyای اجرا کن که نمایندگی Site موردنظر است. Firewall ممکن است فقط از بعضی Segmentها اجازه دهد، بنابراین محل Check روی نتیجه اثر دارد. اگر TCP Check شکست خورد، Triage شامل DNS/IP، Route، Firewall، Host Availability، Service State و Local Listening است. Alert باید Destination و Port را مشخص کند. برای Serviceهایی که Banner یا Protocol Response دارند، Check لایه بالاتر می‌تواند اطلاعات بیشتری بدهد. در طراحی Dependency، اگر Host کامل Down است، Alert جدا برای همه Portها ممکن است لازم نباشد. با Trigger Dependency می‌توان Root Problem را برجسته کرد و نویز را کم کرد.

Backup Monitoring نباید به دیدن یک پیام Success در Console محدود شود. باید آخرین Job Status، Age آخرین Backup موفق، حجم، Duration، Repository Free Space، هشدارهای Job و در صورت وجود Health Check یا Verification را ببینی. یک Job ممکن است Success باشد اما Backup برای مدت طولانی Test Restore نشده باشد. هدف نهایی Backup قابلیت بازیابی است، نه صرفاً تولید فایل Backup. در Veeam می‌توان وضعیت Jobها، Repository و رخدادهای مرتبط را از API، Integration یا Notificationهای مناسب وارد Monitoring کرد. Age معیار مهمی است: اگر Job به هر دلیل اصلاً Run نشود، Trigger صرفاً بر اساس Failure Event ممکن است چیزی نبیند؛ اما «آخرین Backup موفق بیش از X ساعت قبل» این وضعیت را آشکار می‌کند. Threshold باید با Schedule همان Job هماهنگ باشد. Repository Capacity را با Growth Trend مانیتور کن. نزدیک شدن به پر شدن Storage می‌تواند کل Backup Chain را متوقف کند. Immutability و Hardened Repository نیز نیاز به Capacity و Health Monitoring دارند. Credential و API Token را با Least Privilege نگه دار. حداقل دوره‌ای Restore Test یا SureBackup/Verification را در Process داشته باش و نتیجه آن را گزارش کن. Dashboard مدیریتی Backup بهتر است تعداد Workloadهای Protected، آخرین Success، Failed Job و ظرفیت Repository را نشان دهد، نه صدها Event جزئی.

UPS و تجهیزات محیطی بخشی از Availability سرویس IT هستند. اگر UPS از طریق SNMP یا Network Management Card داده ارائه کند، می‌توان وضعیت برق ورودی، Battery State، Load، Runtime Remaining، Temperature و Alarmهای سخت‌افزاری را مانیتور کرد. برای Rack یا Server Room، Sensor دما و رطوبت در صورت وجود می‌تواند قبل از Overheat هشدار بدهد. Monitoring این بخش باید با مشخصات Vendor و ظرفیت واقعی تجهیزات هماهنگ باشد. Battery Runtime یک عدد ثابت نیست و به Load و وضعیت باتری بستگی دارد. Alert روی Low Battery باید فرصت اقدام ایجاد کند، اما Threshold باید با سیاست Shutdown و زمان حضور تیم مرتبط باشد. UPS Load نزدیک ظرفیت نیز باید Trend شود؛ اضافه شدن Server جدید ممکن است به‌تدریج ظرفیت ایمن را کاهش دهد. SNMP Credential و Management Interface UPS را در شبکه مدیریتی محدود کن. Firmware و دسترسی Web این دستگاه‌ها هم باید مثل سایر تجهیزات زیرساختی مدیریت شوند. اگر UPS فقط USB دارد، Agent یا Integration محلی ممکن است لازم باشد، اما طراحی باید Fail-safe باشد. در Runbook برق مشخص کن چه کسی هنگام Power Failure مسئول است، چه زمانی Generator یا Shutdown کنترل‌شده فعال می‌شود و کدام Serverها اولویت دارند. Monitoring باید این تصمیم را پشتیبانی کند، نه اینکه فقط یک Battery Percentage نشان دهد.

تجهیزات شبکه معمولاً Logهای مهمی درباره Interface Change، Authentication، VPN، Routing و System Event تولید می‌کنند. اگر Log فقط روی خود Device باقی بماند، در Reboot، Storage محدود یا خرابی دستگاه ممکن است بخشی از Evidence از دست برود. Remote Syslog اجازه می‌دهد پیام‌ها به Server مرکزی ارسال شوند و Timeline چند Device در کنار هم دیده شود. MikroTik RouterOS نیز می‌تواند Log Action از نوع Remote تعریف کند و Topicهای انتخابی را ارسال کند. قبل از ارسال، Scope را مشخص کن. Debug Log دائمی روی Deviceهای زیاد می‌تواند حجم بسیار بزرگی ایجاد کند. Severity و Facility یا Topic را بر اساس نیاز انتخاب کن. Timezone و NTP همه Deviceها باید هماهنگ باشد؛ Log با ساعت نادرست در Incident Investigation ارزش کمتری دارد. Retention را نیز با حجم و نیاز Audit/Operations تنظیم کن. Zabbix می‌تواند برخی Logها را برای Triggerهای عملیاتی بخواند، اما Syslog Server یا Log Platform ممکن است برای Search و Retention گسترده مناسب‌تر باشد. نقش‌ها را قاطی نکن: Monitoring از Log Signal مهم Alert می‌سازد، Log Management امکان جست‌وجوی عمیق‌تر تاریخچه را می‌دهد. در Incident واقعی، Event Monitoring را با Syslog همان بازه مقایسه کن. مثلاً Link Down Alert، Interface Log و تغییر Configuration کنار هم می‌توانند Timeline قابل دفاع بسازند.

در PRTG مدل Monitoring بر پایه Probe، Group، Device و Sensor سازمان‌دهی می‌شود. Probe داده را در شبکه جمع می‌کند، Device نماینده تجهیز یا سیستم است و Sensor یک جنبه مشخص را اندازه می‌گیرد؛ برای مثال Ping، SNMP Traffic یا HTTP. این مدل با Zabbix متفاوت نام‌گذاری شده اما هدف مشابه است: Data Collection را به ساختار قابل مدیریت تبدیل کند. فهم این ساختار قبل از Auto-Discovery ضروری است تا صدها Sensor بی‌هدف ساخته نشود. Local Probe همراه Core/Server اصلی کار می‌کند و Remote Probe می‌تواند در Site دیگر قرار گیرد تا داده را محلی جمع کند. مانند Zabbix Proxy، محل Probe روی دید شبکه‌ای Checkها اثر دارد. Credentialها می‌توانند از Group به Device ارث برسند، بنابراین Hierarchy باید با دقت طراحی شود و Override فقط جایی انجام شود که لازم است. هر Sensor منابع مصرف می‌کند و License/Capacity نیز ممکن است بر تعداد Sensor اثر داشته باشد. برای هر Device فقط Sensorهایی را فعال کن که Signal مفید دارند. Auto-Discovery نقطه شروع است، نه طراحی نهایی؛ بعد از Discovery Sensorهای غیرضروری را حذف یا Pause نکن بدون اینکه دلیل Monitoring مشخص باشد. PRTG برای بسیاری از شرکت‌های کوچک رابط سریع و Sensorهای آماده زیادی دارد. با این حال انتخاب ابزار باید بر نیاز، مقیاس، تیم، Integration، هزینه و قابلیت نگهداری استوار باشد، نه صرفاً ظاهر Dashboard.

Auto-Discovery در PRTG می‌تواند شبکه را بررسی و Deviceها و Sensorهای مناسب را بر اساس Templateها اضافه کند. این قابلیت برای شروع سریع مفید است، اما اگر Range بزرگ یا Credential گسترده داشته باشی ممکن است تعداد زیادی Device و Sensor تولید شود که ارزش عملیاتی ندارند. Discovery باید در Scope مشخص، ترجیحاً Segmentهای شناخته‌شده و با Accountهای محدود اجرا شود. نتیجه Discovery را باید Review کنی، نه اینکه هر چیز پیدا شده را خودکار Production Monitoring فرض کنی. Inheritance باعث می‌شود تنظیماتی مثل Credential، Interval، Schedule و Notification از Objectهای بالاتر به پایین منتقل شوند. این قابلیت مدیریت را ساده می‌کند، اما یک تغییر در Group بالا می‌تواند روی تعداد زیادی Device اثر بگذارد. قبل از تغییر Parent Setting، Scope Inheritance را ببین و Objectهایی را که Override دارند بشناس. Naming و Grouping منطقی از همین‌جا اهمیت پیدا می‌کند. Auto-Discovery تکرارشونده می‌تواند Deviceهای جدید را پیدا کند، اما در شبکه DHCP یا Client Segment ممکن است نتیجه نامناسب باشد. برای زیرساخت ثابت مثل Server VLAN و Network Deviceها مفیدتر است. Credential Discovery نیز باید مطابق Least Privilege باشد و Account Administrator عمومی برای اسکن گسترده استفاده نشود. بعد از Discovery، Sensorهایی که واقعاً برای SLA، Capacity، Incident یا Preventive Maintenance لازم‌اند نگه دار. ابزار هرچه Sensor بیشتری بسازد لزوماً Monitoring بهتری ایجاد نمی‌کند؛ کیفیت Signal و قابلیت اقدام معیار اصلی است.

PRTG برای Sensorها Notification Triggerهایی بر اساس State، Threshold، Speed یا Volume فراهم می‌کند و Notification Template تعیین می‌کند پیام چگونه ارسال شود. مانند هر NMS دیگر، باید از ارسال همه Warningها به همه افراد خودداری کنی. Delay قبل از Notification می‌تواند Spike کوتاه را فیلتر کند و Repeat Interval باید طوری باشد که پیام به نویز تبدیل نشود. Dependency نیز برای جلوگیری از Alarmهای پایین‌دستی هنگام Down شدن Parent اهمیت دارد. Maps در PRTG می‌توانند Objectهای Monitoring را همراه با Status در یک نمای سفارشی نمایش دهند. برای NOC بهتر است Map ساده، قابل خواندن و محدود به سرویس‌های مهم باشد. Report نیز برای جمع‌بندی Historical Data و Availability مفید است، اما باید Period، Sensor و Aggregation مشخص باشد. Report زیبا اگر Sensor پایه به‌درستی طراحی نشده باشد نتیجه قابل اتکایی نمی‌دهد. Notification Template ممکن است Email، Push یا روش‌های دیگر داشته باشد؛ Credential و گیرنده را بر اساس Policy سازمان مدیریت کن. Test Notification را قبل از Production اجرا و Recovery/Back-to-Up را هم بررسی کن. در گزارش مدیریتی، Context سرویس و Maintenance را فراموش نکن. کنار هم قرار گرفتن این قابلیت‌ها یک چرخه عملی می‌سازد: Sensor وضعیت را می‌سنجد، Notification مشکل قابل اقدام را می‌رساند، Map به Triage سریع کمک می‌کند و Report رفتار گذشته را نشان می‌دهد. هر کدام وظیفه متفاوتی دارند.

Zabbix و PRTG هر دو می‌توانند بخش بزرگی از نیاز Monitoring شبکه و Server را پوشش دهند، اما مدل مدیریت، توسعه‌پذیری، License، تجربه رابط، Ecosystem و نیاز عملیاتی سازمان متفاوت است. انتخاب حرفه‌ای با سؤال «کدام بهتر است؟» شروع نمی‌شود؛ با Inventory، تعداد Site و Device، نوع Metricها، نیاز Integration، Skill تیم، بودجه، الزامات امنیتی و روش نگهداری شروع می‌شود. ابزاری که تیم نتواند درست نگهداری کند حتی اگر Featureهای بیشتری داشته باشد نتیجه خوبی نمی‌دهد. Zabbix در محیط‌هایی که Template، Automation، Linux/Database Administration و Customization عمیق مهم است انعطاف زیادی دارد. PRTG برای بسیاری از سناریوها با Sensorهای آماده و Workflow سریع می‌تواند راه‌اندازی ساده‌تری ارائه دهد. این توصیف به معنی برتری مطلق هیچ‌کدام نیست؛ باید Pilot واقعی انجام شود و Coverage و هزینه عملیاتی سنجیده شود. در مقایسه فقط License Cost را نبین. زمان آموزش، Backup Platform، Upgrade، Database، Probe/Proxy، Integration، Notification و Support هم هزینه دارند. همچنین مهاجرت بعدی سخت است، بنابراین Naming، Documentation و Export Configuration از ابتدا ارزش دارد. اگر سازمان از قبل یک ابزار دارد، تعویض صرفاً برای علاقه شخصی پشتیبان منطقی نیست. ابتدا Gap را مستند کن و ببین آیا با Configuration فعلی قابل حل است. ابزار وسیله است؛ Monitoring Process مهم‌تر از Brand است.

Monitoring داخلی ممکن است نشان دهد Server، Firewall و Application همه Up هستند، اما کاربران خارج سازمان به دلیل DNS عمومی، ISP، CDN یا Certificate به سرویس دسترسی نداشته باشند. External Monitoring یعنی Check سرویس از نقطه‌ای خارج از همان شبکه تا مسیر واقعی‌تری از دید کاربر سنجیده شود. برای سرویس عمومی، ترکیب Check داخلی و خارجی کمک می‌کند Scope مشکل سریع مشخص شود. اگر Internal HTTP Check موفق و External Check ناموفق باشد، فرضیه‌هایی مانند Public DNS، NAT/Firewall، ISP یا Route خارجی مطرح می‌شوند. اگر هر دو شکست بخورند، احتمال مشکل خود Application یا Server بیشتر می‌شود. داشتن بیش از یک نقطه خارجی برای سرویس بسیار حیاتی می‌تواند خطای یک Provider یا Region خاص را هم تفکیک کند. Check بیرونی باید امن و سبک باشد. Credential حساس را بدون نیاز در سرویس Third-party قرار نده. برای صفحات Authentication، Endpoint مخصوص Health در صورت امکان بهتر است. نرخ Check را طوری تنظیم کن که Traffic بی‌دلیل ایجاد نکند. همچنین Data Residency و Privacy ابزار خارجی را در سازمان‌های حساس بررسی کن. در Alert پیام باید مشخص کند Check از کدام Location شکست خورده است. اگر فقط بنویسد «Website Down»، ممکن است تیم داخلی به اشتباه Server را Restart کند در حالی که مشکل مسیر خارجی است.

Capacity Planning یعنی استفاده از داده تاریخی برای پیش‌بینی اینکه Resource چه زمانی به محدوده‌ای می‌رسد که سرویس یا رشد کسب‌وکار را محدود می‌کند. Disk Growth واضح‌ترین مثال است، اما CPU، Memory، Datastore، WAN، Backup Repository، DHCP Scope و حتی تعداد License یا Sensor نیز می‌توانند Trend داشته باشند. تصمیم ظرفیت نباید با نگاه به یک Peak لحظه‌ای گرفته شود؛ باید الگوی رشد و Seasonality شناخته شود. برای Disk، مقدار Free Space و Growth Rate هفتگی یا ماهانه را کنار هم ببین. اگر مصرف هر ماه ۱۰۰ گیگابایت رشد می‌کند، تخمین ساده زمان رسیدن به Threshold می‌تواند فرصت خرید یا پاک‌سازی ایجاد کند. برای WAN Peak ساعات کاری و مدت Saturation مهم‌تر از Average شبانه‌روزی است. در VMware نیز Datastore Capacity را با Snapshot و Provisioning Policy مرتبط کن. Forecast همیشه عدم‌قطعیت دارد. رشد ممکن است با پروژه جدید ناگهان تغییر کند، بنابراین عدد پیش‌بینی را حقیقت قطعی معرفی نکن. Changeهای برنامه‌ریزی‌شده کسب‌وکار را وارد تحلیل کن. Threshold ظرفیت نیز باید Lead Time خرید و اجرای تغییر را در نظر بگیرد؛ اگر خرید Storage دو ماه زمان می‌برد، Alert یک هفته قبل دیر است. گزارش Capacity خوب Action دارد: Resource، Trend، زمان تقریبی عبور، Confidence، Owner و پیشنهاد. Graph بدون تصمیم فقط تزئین گزارش است.

Monitoring خودکار بسیاری از مشکلات را Alert می‌کند، اما عملیات حرفه‌ای هنوز به Review دوره‌ای نیاز دارد. Daily Check روی Problemهای باز، Backupهای اخیر، فضای بحرانی، WAN و سرویس‌های حیاتی تمرکز دارد. Weekly Check می‌تواند Trend، Alert Noise، Patch/Maintenance، Capacity کوتاه‌مدت و Failed Jobهای تکراری را مرور کند. Monthly Review برای Availability، Capacity Planning، SLA، Backup Restore Test، Inventory Change و اصلاح Thresholdها مناسب است. Checklist باید کوتاه اما Actionable باشد. اگر ۱۰۰ مورد دارد که هیچ‌کس کامل انجام نمی‌دهد، ارزشش کم می‌شود. هر آیتم باید Owner، Frequency و Evidence داشته باشد. بسیاری از Checkها را می‌توان با Dashboard یا Report خودکار کرد، اما Review انسانی باید روی Exception و تصمیم تمرکز کند. نتیجه Review باید ثبت شود. «همه چیز خوب بود» بدون Timestamp یا Evidence برای Audit و انتقال شیفت کافی نیست. Problemهای تکراری باید به Problem Management یا Improvement Task تبدیل شوند؛ بستن هر Alert به‌تنهایی جلوی تکرار را نمی‌گیرد. روتین را با اندازه سازمان تطبیق بده. شرکت کوچک ممکن است Daily Review ده دقیقه‌ای داشته باشد و محیط بزرگ NOC شیفتی. اصل ثابت این است که سلامت زیرساخت نباید وابسته به اینکه یک نفر «یادش باشد» Consoleها را باز کند.

وقتی Alert می‌آید، اولین وظیفه Triage است: اعتبار Alert، Scope، Severity، Impact و احتمال Cause را سریع مشخص کن. Monitoring باید Evidence اولیه بدهد اما پشتیبان نباید بدون بررسی اقدام مخرب انجام دهد. بعد تصمیم می‌گیری Incident در سطح خودت قابل حل است یا نیاز به Escalation دارد. Runbook مجموعه مراحل استاندارد برای Problemهای شناخته‌شده است تا پاسخ به Incident به حافظه فرد وابسته نباشد. Runbook خوب شامل Trigger Condition، Checkهای اولیه، Command یا مسیر GUI مجاز، معیار تصمیم، اقدام کم‌خطر، Rollback، Escalation Contact و Evidence موردنیاز است. برای مثال Disk Full Runbook باید اول مشخص کند کدام Volume، چه چیزی رشد کرده و آیا Cleanup مجاز است؛ نباید مستقیم فایل حذف کند. WAN Down Runbook باید Power/Link، Interface، ISP Status و Scope را مرحله‌بندی کند. Escalation را با Deadline و Context انجام بده. ارسال پیام «VMware مشکل دارد» به متخصص کافی نیست. Host، زمان، Alarm، Graph، Change اخیر و کارهایی که انجام شده‌اند را منتقل کن. این کار زمان دوباره‌کاری را کم می‌کند. Severity نیز باید با Impact و Urgency هماهنگ باشد، نه با استرس کاربر. پس از Incident، اگر Runbook ناقص بود آن را اصلاح کن. Monitoring و Runbook باید با هم رشد کنند: Alert می‌گوید چه اتفاقی افتاده و Runbook می‌گوید گام بعدی چیست.

Monitoring Server معمولاً به تعداد زیادی Server، Network Device، API و Credential دسترسی دارد، بنابراین خودش یک دارایی حساس است. اگر NMS compromise شود، مهاجم ممکن است Topology، IPها، نام Hostها، Credentialهای SNMP یا Tokenهای Integration را ببیند. امنیت Monitoring باید از ابتدا طراحی شود: دسترسی مدیریتی محدود، MFA در صورت پشتیبانی، Role-Based Access، شبکه مدیریتی، Firewall و Patch منظم. Agentها و SNMP را فقط از Server/Proxyهای لازم مجاز کن. SNMPv3 را در صورت پشتیبانی ترجیح بده و Community پیش‌فرض را حذف کن. API Token و Webhook Secret را در متن عمومی Macro یا Script رها نکن. Userهای Zabbix/PRTG باید بر اساس نقش و Scope مشتری یا Site Permission داشته باشند؛ همه افراد Administrator نباشند. Frontend را با HTTPS معتبر ارائه کن و Logهای Login و تغییر Configuration را بررسی کن. Backup Configuration و Database نیز شامل اطلاعات حساس است و باید Encryption/Access Control مناسب داشته باشد. Remote Probe یا Proxy در شعبه هم باید Hardening شود، چون بخشی از Trust Monitoring است. Monitoring امنیتی گسترده ممکن است SIEM بخواهد، اما خود NMS باید حداقل روی Login Failure، تغییرات حساس و Availability خودش Visibility داشته باشد. اصل Least Privilege در Monitoring هم مثل سایر زیرساخت‌ها ضروری است.

اگر Zabbix یا PRTG Server از بین برود، علاوه بر Dashboard و Alert، تاریخچه و Configuration ارزشمند نیز ممکن است از دست برود. برای Zabbix مهم‌ترین دارایی‌ها Database، فایل‌های Configuration، Scriptهای سفارشی، External Checkها و Secretهای لازم برای Recovery هستند. برای PRTG نیز Configuration، Probe/Server Data و Custom Sensorها باید طبق روش رسمی محصول Backup شوند. خود NMS باید بخشی از برنامه Backup سازمان باشد. RPO و RTO Monitoring را مشخص کن. شاید از دست رفتن چند ساعت History قابل قبول باشد اما از دست رفتن Template، Trigger و Notification Policy نباشد. Backup Database باید Application-consistent و قابل Restore باشد و Restore Test دوره‌ای انجام شود. نگهداری Backup روی همان Server مانیتورینگ در خرابی کامل کمک زیادی نمی‌کند. در Recovery Plan ترتیب کار مهم است: OS/Platform، Database، Configuration، Credential/Secret، DNS/IP و سپس Agent/Proxy Connectivity. اگر IP Monitoring Server تغییر کند، Firewall و Agent Configuration ممکن است نیاز به اصلاح داشته باشند. Documentation باید Version نرم‌افزار و Dependencyها را ثبت کند. یک Lab Restore ارزش بیشتری از فرض «Backup داریم» دارد. بعد از Restore بررسی کن آیا Latest Data می‌آید، Triggerها کار می‌کنند و Notification ارسال می‌شود. DR زمانی کامل است که سرویس Monitoring واقعاً دوباره عملیات را ادامه دهد.

در پروژه نهایی فرض کن یک شرکت دفتر مرکزی و یک شعبه دارد، دو Domain Controller، File Server، SQL/CRM، VMware، چند Switch، MikroTik Router، اینترنت اصلی و پشتیبان، Veeam Backup و UPS دارد. وظیفه تو این است که Monitoring را از صفر طراحی کنی، نه اینکه فقط Zabbix نصب کنی. ابتدا Service Catalog و Criticality را مشخص کن، سپس Hostها، Dependencyها، Data Collection Method، Thresholdها، Alert Route، Dashboard و عملیات دوره‌ای را طراحی کن. هر Metric باید دلیل داشته باشد. برای دفتر مرکزی Zabbix Server و برای شعبه در صورت توجیه Proxy در نظر بگیر. Windowsها Agent 2، Network Deviceها SNMPv3 در صورت پشتیبانی، MikroTik SNMP/Remote Log، VMware Integration و Backup Job Monitoring داشته باشند. برای CRM Synthetic HTTP و SQL/Port Check، برای اینترنت Latency/Loss از چند مقصد و برای Certificateها Expiry Alert تعریف کن. UPS و Repository Capacity را فراموش نکن. Dashboard NOC باید Problemهای بحرانی، WAN، Backup، Virtualization و Capacity را ساده نشان دهد. Notification را بر اساس Service/Severity به مسئول مناسب بفرست و Dependency طراحی کن تا قطع Core یا WAN صدها پیام نسازد. Daily/Weekly/Monthly Checklist و Runbook برای پنج Incident پرتکرار تهیه کن. Maintenance Window را با Change Management هماهنگ کن. در پایان طرح را با Failure Test اعتبارسنجی کن: WAN را در Lab قطع کن، Service را Stop کن، Threshold Disk را شبیه‌سازی کن و ببین آیا Alert درست، گیرنده درست و Recovery درست کار می‌کنند. یک NOC حرفه‌ای از Diagram، Tool، Process و انسان با هم ساخته می‌شود؛ هیچ Dashboardی به‌تنهایی عملیات خوب ایجاد نمی‌کند.