با حوصله بخوان، مثالها را تحلیل کن و تمرینها را انجام بده؛ هدف حفظ کردن تعریفها نیست
CPU بالا باید با مدت و Process بررسی شود
CPU بالا باید با مدت و Process بررسی شود پردازنده دستورهای سیستمعامل و برنامهها را اجرا میکند و زمان پردازش را بین کارها تقسیم میکند؛ در Task Manager فقط درصد لحظهای را نبین؛ نام Process، مدت درگیری و الگوی تکرار را هم بررسی کن CPU صددرصد برای چند ثانیه میتواند طبیعی باشد؛ مشکل وقتی مهم میشود که ماندگار باشد یا پاسخگویی سیستم را مختل کند پایش مؤثر فقط جمع کردن عدد و Log نیست؛ باید وضعیت عادی سرویس شناخته شود، Metricهای معنادار انتخاب شوند و Alert زمانی ایجاد شود که نیاز به اقدام دارد؛ Syslog چارچوبی برای انتقال پیامهای رویداد ارائه میدهد و SNMP برای مشاهده و مدیریت بسیاری از تجهیزات شبکه استفاده میشود؛ همگام بودن زمان سیستمها برای ارتباط دادن رویدادهای چند دستگاه ضروری است و Log باید در کنار وضعیت سرویس و تغییرات همان بازه تحلیل شود برای عیبیابی درست، این بخش را فقط بهعنوان یک اصطلاح حفظ نکن و توجه داشته باش که Log زمانی ارزش دارد که Timestamp درست، منبع مشخص و Context کافی داشته باشد؛ جمعآوری متمرکز کمک میکند رخدادهای چند Server و Network Device در یک Timeline دیده شوند؛ Retention نیز باید با نیاز عملیاتی و سیاست امنیتی هماهنگ باشد و Alert باید به اقدام مشخص منتهی شود نه فقط افزایش تعداد پیامها
اوج با Trend فرق دارد
اوج با Trend فرق دارد Trend جهت تغییر Metric در روزها و ماههاست و برای پیشبینی ظرفیت از یک Snapshot لحظهای ارزش بیشتری دارد پایش مؤثر فقط جمع کردن عدد و Log نیست؛ باید وضعیت عادی سرویس شناخته شود، Metricهای معنادار انتخاب شوند و Alert زمانی ایجاد شود که نیاز به اقدام دارد؛ Syslog چارچوبی برای انتقال پیامهای رویداد ارائه میدهد و SNMP برای مشاهده و مدیریت بسیاری از تجهیزات شبکه استفاده میشود؛ همگام بودن زمان سیستمها برای ارتباط دادن رویدادهای چند دستگاه ضروری است و Log باید در کنار وضعیت سرویس و تغییرات همان بازه تحلیل شود برای عیبیابی درست، این بخش را فقط بهعنوان یک اصطلاح حفظ نکن و توجه داشته باش که Log زمانی ارزش دارد که Timestamp درست، منبع مشخص و Context کافی داشته باشد؛ جمعآوری متمرکز کمک میکند رخدادهای چند Server و Network Device در یک Timeline دیده شوند؛ Retention نیز باید با نیاز عملیاتی و سیاست امنیتی هماهنگ باشد و Alert باید به اقدام مشخص منتهی شود نه فقط افزایش تعداد پیامها نکتهای که هنگام پشتیبانی نباید از آن عبور کنی این است که Monitoring باید از سؤال «چه چیزی برای سرویس مهم است» شروع شود؛ Availability، Latency، Error Rate، Capacity و رخدادهای امنیتی نمونههایی از شاخصهایی هستند که بسته به سرویس معنا پیدا میکنند؛ Threshold بدون Baseline میتواند Alert زیاد و بیارزش تولید کند، بنابراین رفتار عادی و ساعات اوج باید شناخته شود
Memory Used بدون شرایط کافی نیست
Memory Used بدون شرایط کافی نیست Memory Used بالا لزوماً مشکل نیست چون سیستمعامل از RAM برای Cache هم استفاده میکند؛ Available Memory، Paging و اثر روی نرمافزار را کنار آن ببین پایش مؤثر فقط جمع کردن عدد و Log نیست؛ باید وضعیت عادی سرویس شناخته شود، Metricهای معنادار انتخاب شوند و Alert زمانی ایجاد شود که نیاز به اقدام دارد؛ Syslog چارچوبی برای انتقال پیامهای رویداد ارائه میدهد و SNMP برای مشاهده و مدیریت بسیاری از تجهیزات شبکه استفاده میشود؛ همگام بودن زمان سیستمها برای ارتباط دادن رویدادهای چند دستگاه ضروری است و Log باید در کنار وضعیت سرویس و تغییرات همان بازه تحلیل شود در یک شبکه یا سیستم واقعی، این موضوع زمانی روشن میشود که Monitoring باید از سؤال «چه چیزی برای سرویس مهم است» شروع شود؛ Availability، Latency، Error Rate، Capacity و رخدادهای امنیتی نمونههایی از شاخصهایی هستند که بسته به سرویس معنا پیدا میکنند؛ Threshold بدون Baseline میتواند Alert زیاد و بیارزش تولید کند، بنابراین رفتار عادی و ساعات اوج باید شناخته شود نکتهای که هنگام پشتیبانی نباید از آن عبور کنی این است که Log زمانی ارزش دارد که Timestamp درست، منبع مشخص و Context کافی داشته باشد؛ جمعآوری متمرکز کمک میکند رخدادهای چند Server و Network Device در یک Timeline دیده شوند؛ Retention نیز باید با نیاز عملیاتی و سیاست امنیتی هماهنگ باشد و Alert باید به اقدام مشخص منتهی شود نه فقط افزایش تعداد پیامها
Paging زیاد میتواند فشار RAM باشد
RAM فضای کاری موقت برنامهها و سیستمعامل است و با خاموش شدن سیستم دادههای آن باقی نمیماند؛ وقتی RAM کم باشد سیستم ممکن است بیشتر از Page File روی دیسک استفاده کند و کند شود فضای خالی Disk جای RAM را نمیگیرد پایش مؤثر فقط جمع کردن عدد و Log نیست؛ باید وضعیت عادی سرویس شناخته شود، Metricهای معنادار انتخاب شوند و Alert زمانی ایجاد شود که نیاز به اقدام دارد؛ Syslog چارچوبی برای انتقال پیامهای رویداد ارائه میدهد و SNMP برای مشاهده و مدیریت بسیاری از تجهیزات شبکه استفاده میشود؛ همگام بودن زمان سیستمها برای ارتباط دادن رویدادهای چند دستگاه ضروری است و Log باید در کنار وضعیت سرویس و تغییرات همان بازه تحلیل شود برای عیبیابی درست، این بخش را فقط بهعنوان یک اصطلاح حفظ نکن و توجه داشته باش که Monitoring باید از سؤال «چه چیزی برای سرویس مهم است» شروع شود؛ Availability، Latency، Error Rate، Capacity و رخدادهای امنیتی نمونههایی از شاخصهایی هستند که بسته به سرویس معنا پیدا میکنند؛ Threshold بدون Baseline میتواند Alert زیاد و بیارزش تولید کند، بنابراین رفتار عادی و ساعات اوج باید شناخته شود
وضعیت پایه رفتار عادی را مشخص میکند
وضعیت پایه، وضعیت عادی و سالم سیستم است که برای مقایسه هنگام خرابی استفاده میشود؛ مصرف معمول CPU، Latency و Config سالم نمونه وضعیت پایه است عدد خارج از عادت لزوماً بد نیست؛ اثر روی سرویس را هم ببین پایش مؤثر فقط جمع کردن عدد و Log نیست؛ باید وضعیت عادی سرویس شناخته شود، Metricهای معنادار انتخاب شوند و Alert زمانی ایجاد شود که نیاز به اقدام دارد؛ Syslog چارچوبی برای انتقال پیامهای رویداد ارائه میدهد و SNMP برای مشاهده و مدیریت بسیاری از تجهیزات شبکه استفاده میشود؛ همگام بودن زمان سیستمها برای ارتباط دادن رویدادهای چند دستگاه ضروری است و Log باید در کنار وضعیت سرویس و تغییرات همان بازه تحلیل شود در یک شبکه یا سیستم واقعی، این موضوع زمانی روشن میشود که Log زمانی ارزش دارد که Timestamp درست، منبع مشخص و Context کافی داشته باشد؛ جمعآوری متمرکز کمک میکند رخدادهای چند Server و Network Device در یک Timeline دیده شوند؛ Retention نیز باید با نیاز عملیاتی و سیاست امنیتی هماهنگ باشد و Alert باید به اقدام مشخص منتهی شود نه فقط افزایش تعداد پیامها
فرض کن در سامانه Monitoring مشکلی گزارش شده و احتمال میدهی به پایش CPU و RAM مربوط باشد. قبل از تغییر، وضعیت فعلی را با Dashboard پایش، Syslog/Event Viewer و SNMP بررسی میکنی و نتیجه را با یک حالت سالم یا مستند معتبر مقایسه میکنی. اگر شواهد فرضیه را تأیید کردند، فقط همان بخش مرتبط را تغییر میدهی و بعد همان تست را دوباره اجرا میکنی تا مطمئن شوی مشکل واقعاً برطرف شده است
این اشتباهها را تکرار نکن
- تغییر دادن تنظیمات مرتبط با پایش CPU و RAM قبل از اینکه مطمئن شوی مشکل واقعاً به همین بخش مربوط است
- نتیجهگیری درباره پایش CPU و RAM فقط از روی یک نشانه و بدون انجام تست نهایی
حالا خودت انجام بده
- در یک نمونه آزمایشی مرتبط با پایش CPU و RAM، فقط وضعیت فعلی را مشاهده کن و سه نکتهای را که برای تشخیص حالت سالم مهماند یادداشت کن
- با Dashboard پایش، Syslog/Event Viewer و SNMP وضعیت مرتبط با پایش CPU و RAM را بدون تغییر بررسی کن، سه داده واقعی جمع کن و توضیح بده هرکدام چه چیزی به تو میگویند
- یک خطای فرضی مرتبط با پایش CPU و RAM بنویس و مشخص کن اولین تست کمخطر تو چیست و چه نتیجهای فرضیهات را رد میکند
نکتههایی که باید با خودت ببری
- CPU بالا باید با مدت و Process بررسی شود
- اوج با Trend فرق دارد
- Memory Used بدون شرایط کافی نیست
- Paging زیاد میتواند فشار RAM باشد
- وضعیت پایه رفتار عادی را مشخص میکند
- هشدارها را طوری تنظیم کن که معنیدار باشند و تیم را با Alert بیارزش خسته نکنند
قبل از رفتن به درس بعد، جواب را برای خودت توضیح بده
این نکته را با یک مثال توضیح بده: CPU بالا باید با مدت و Process بررسی شود. بعد بگو در عمل چطور آن را بررسی میکنی.
پردازنده دستورهای سیستمعامل و برنامهها را اجرا میکند و زمان پردازش را بین کارها تقسیم میکند؛ در Task Manager فقط درصد لحظهای را نبین؛ نام Process، مدت درگیری و الگوی تکرار را هم بررسی کن
این نکته را با یک مثال توضیح بده: اوج با Trend فرق دارد. بعد بگو در عمل چطور آن را بررسی میکنی.
Trend جهت تغییر Metric در روزها و ماههاست و برای پیشبینی ظرفیت از یک Snapshot لحظهای ارزش بیشتری دارد
این نکته را با یک مثال توضیح بده: Memory Used بدون شرایط کافی نیست. بعد بگو در عمل چطور آن را بررسی میکنی.
Memory Used بالا لزوماً مشکل نیست چون سیستمعامل از RAM برای Cache هم استفاده میکند؛ Available Memory، Paging و اثر روی نرمافزار را کنار آن ببین
برای ذخیره پیشرفت، دوره را رسمی شروع کن
با ثبتنام، تکمیل درسها و نمره آزمون روی حساب ذخیره میشود
