با حوصله بخوان، مثالها را تحلیل کن و تمرینها را انجام بده؛ هدف حفظ کردن تعریفها نیست
journalctl Log systemd را جستجو میکند
systemd در بسیاری از توزیعها سرویسها و Boot را مدیریت میکند؛ systemctl status و journalctl سرنخهای اصلیاند راهاندازی دوباره مکرر سرویس بدون خواندن Log علت را پنهان میکند گزارش رویداد ثبت زمانی اتفاقها و خطاهای سیستم است و برای ساختن Timeline کمک میکند؛ زمان گزارش کاربر را با Log همان بازه مقایسه کن هر خطای ثبتشده علت اصلی نیست و باید با نشانه مرتبط شود در Linux مدیریت سرویسها، فایلها، Userها و شبکه بر پایه ابزارها و فایلهای پیکربندی مشخص انجام میشود؛ systemd وضعیت Serviceها و وابستگی آنها را مدیریت میکند و journal میتواند رویدادهای Kernel، Service و فرایندهای مختلف را ثبت کند؛ Permissionهای فایل از Owner، Group و Other و بیتهای دسترسی تشکیل میشوند و استفاده از sudo باید کنترلشده باشد؛ پیش از تغییر باید مسیر فایل پیکربندی، Service مرتبط و Log همان Service شناخته شود پایش مؤثر فقط جمع کردن عدد و Log نیست؛ باید وضعیت عادی سرویس شناخته شود، Metricهای معنادار انتخاب شوند و Alert زمانی ایجاد شود که نیاز به اقدام دارد؛ Syslog چارچوبی برای انتقال پیامهای رویداد ارائه میدهد و SNMP برای مشاهده و مدیریت بسیاری از تجهیزات شبکه استفاده میشود؛ همگام بودن زمان سیستمها برای ارتباط دادن رویدادهای چند دستگاه ضروری است و Log باید در کنار وضعیت سرویس و تغییرات همان بازه تحلیل شود
/var/log محل رایج Log است
گزارش رویداد ثبت زمانی اتفاقها و خطاهای سیستم است و برای ساختن Timeline کمک میکند؛ زمان گزارش کاربر را با Log همان بازه مقایسه کن در Linux مدیریت سرویسها، فایلها، Userها و شبکه بر پایه ابزارها و فایلهای پیکربندی مشخص انجام میشود؛ systemd وضعیت Serviceها و وابستگی آنها را مدیریت میکند و journal میتواند رویدادهای Kernel، Service و فرایندهای مختلف را ثبت کند؛ Permissionهای فایل از Owner، Group و Other و بیتهای دسترسی تشکیل میشوند و استفاده از sudo باید کنترلشده باشد؛ پیش از تغییر باید مسیر فایل پیکربندی، Service مرتبط و Log همان Service شناخته شود پایش مؤثر فقط جمع کردن عدد و Log نیست؛ باید وضعیت عادی سرویس شناخته شود، Metricهای معنادار انتخاب شوند و Alert زمانی ایجاد شود که نیاز به اقدام دارد؛ Syslog چارچوبی برای انتقال پیامهای رویداد ارائه میدهد و SNMP برای مشاهده و مدیریت بسیاری از تجهیزات شبکه استفاده میشود؛ همگام بودن زمان سیستمها برای ارتباط دادن رویدادهای چند دستگاه ضروری است و Log باید در کنار وضعیت سرویس و تغییرات همان بازه تحلیل شود
زمان دقیق رخداد با زمان مشکل تطبیق داده شود
Log بدون زمان همگامشده ارزش کمتری دارد؛ زمان دقیق رخداد پیام را با زمان گزارش کاربر و Log سیستمهای وابسته مقایسه کن و اگر اختلاف ساعت وجود دارد ابتدا آن را در Timeline لحاظ کن در Linux مدیریت سرویسها، فایلها، Userها و شبکه بر پایه ابزارها و فایلهای پیکربندی مشخص انجام میشود؛ systemd وضعیت Serviceها و وابستگی آنها را مدیریت میکند و journal میتواند رویدادهای Kernel، Service و فرایندهای مختلف را ثبت کند؛ Permissionهای فایل از Owner، Group و Other و بیتهای دسترسی تشکیل میشوند و استفاده از sudo باید کنترلشده باشد؛ پیش از تغییر باید مسیر فایل پیکربندی، Service مرتبط و Log همان Service شناخته شود پایش مؤثر فقط جمع کردن عدد و Log نیست؛ باید وضعیت عادی سرویس شناخته شود، Metricهای معنادار انتخاب شوند و Alert زمانی ایجاد شود که نیاز به اقدام دارد؛ Syslog چارچوبی برای انتقال پیامهای رویداد ارائه میدهد و SNMP برای مشاهده و مدیریت بسیاری از تجهیزات شبکه استفاده میشود؛ همگام بودن زمان سیستمها برای ارتباط دادن رویدادهای چند دستگاه ضروری است و Log باید در کنار وضعیت سرویس و تغییرات همان بازه تحلیل شود
grep برای جستجو مفید است
grep خطوط مطابق Pattern را در متن یا Log پیدا میکند و با زمان، نام سرویس یا Error میتواند حجم زیاد Log را محدود کند؛ Pattern خیلی کلی نتیجه بیاستفاده میسازد در Linux مدیریت سرویسها، فایلها، Userها و شبکه بر پایه ابزارها و فایلهای پیکربندی مشخص انجام میشود؛ systemd وضعیت Serviceها و وابستگی آنها را مدیریت میکند و journal میتواند رویدادهای Kernel، Service و فرایندهای مختلف را ثبت کند؛ Permissionهای فایل از Owner، Group و Other و بیتهای دسترسی تشکیل میشوند و استفاده از sudo باید کنترلشده باشد؛ پیش از تغییر باید مسیر فایل پیکربندی، Service مرتبط و Log همان Service شناخته شود پایش مؤثر فقط جمع کردن عدد و Log نیست؛ باید وضعیت عادی سرویس شناخته شود، Metricهای معنادار انتخاب شوند و Alert زمانی ایجاد شود که نیاز به اقدام دارد؛ Syslog چارچوبی برای انتقال پیامهای رویداد ارائه میدهد و SNMP برای مشاهده و مدیریت بسیاری از تجهیزات شبکه استفاده میشود؛ همگام بودن زمان سیستمها برای ارتباط دادن رویدادهای چند دستگاه ضروری است و Log باید در کنار وضعیت سرویس و تغییرات همان بازه تحلیل شود
Log Rotation از پر شدن Disk جلوگیری میکند
گزارش رویداد ثبت زمانی اتفاقها و خطاهای سیستم است و برای ساختن Timeline کمک میکند؛ زمان گزارش کاربر را با Log همان بازه مقایسه کن در Linux مدیریت سرویسها، فایلها، Userها و شبکه بر پایه ابزارها و فایلهای پیکربندی مشخص انجام میشود؛ systemd وضعیت Serviceها و وابستگی آنها را مدیریت میکند و journal میتواند رویدادهای Kernel، Service و فرایندهای مختلف را ثبت کند؛ Permissionهای فایل از Owner، Group و Other و بیتهای دسترسی تشکیل میشوند و استفاده از sudo باید کنترلشده باشد؛ پیش از تغییر باید مسیر فایل پیکربندی، Service مرتبط و Log همان Service شناخته شود پایش مؤثر فقط جمع کردن عدد و Log نیست؛ باید وضعیت عادی سرویس شناخته شود، Metricهای معنادار انتخاب شوند و Alert زمانی ایجاد شود که نیاز به اقدام دارد؛ Syslog چارچوبی برای انتقال پیامهای رویداد ارائه میدهد و SNMP برای مشاهده و مدیریت بسیاری از تجهیزات شبکه استفاده میشود؛ همگام بودن زمان سیستمها برای ارتباط دادن رویدادهای چند دستگاه ضروری است و Log باید در کنار وضعیت سرویس و تغییرات همان بازه تحلیل شود؛ برای این بخش، تمرکز عملی روی «Log Rotation از پر شدن Disk جلوگیری میکند» است و باید بتوانی آن را از مفاهیم نزدیک در درس «Logهای Linux و عیبیابی» جدا تشخیص بدهی
فرض کن در Server Linux مشکلی گزارش شده و احتمال میدهی به Logهای Linux و عیبیابی مربوط باشد. قبل از تغییر، وضعیت فعلی را با systemctl، journalctl، ip، ss، df، free و ps بررسی میکنی و نتیجه را با یک حالت سالم یا مستند معتبر مقایسه میکنی. اگر شواهد فرضیه را تأیید کردند، فقط همان بخش مرتبط را تغییر میدهی و بعد همان تست را دوباره اجرا میکنی تا مطمئن شوی مشکل واقعاً برطرف شده است
این اشتباهها را تکرار نکن
- تغییر دادن تنظیمات مرتبط با Logهای Linux و عیبیابی قبل از اینکه مطمئن شوی مشکل واقعاً به همین بخش مربوط است
- نتیجهگیری درباره Logهای Linux و عیبیابی فقط از روی یک نشانه و بدون انجام تست نهایی
حالا خودت انجام بده
- در یک نمونه آزمایشی مرتبط با Logهای Linux و عیبیابی، فقط وضعیت فعلی را مشاهده کن و سه نکتهای را که برای تشخیص حالت سالم مهماند یادداشت کن
- با systemctl، journalctl، ip، ss، df، free و ps وضعیت مرتبط با Logهای Linux و عیبیابی را بدون تغییر بررسی کن، سه داده واقعی جمع کن و توضیح بده هرکدام چه چیزی به تو میگویند
- یک خطای فرضی مرتبط با Logهای Linux و عیبیابی بنویس و مشخص کن اولین تست کمخطر تو چیست و چه نتیجهای فرضیهات را رد میکند
نکتههایی که باید با خودت ببری
- journalctl Log systemd را جستجو میکند
- /var/log محل رایج Log است
- زمان دقیق رخداد با زمان مشکل تطبیق داده شود
- grep برای جستجو مفید است
- Log Rotation از پر شدن Disk جلوگیری میکند
- با root دائمی کار نکن و قبل از ویرایش فایل تنظیمات نسخه برگشت داشته باش
قبل از رفتن به درس بعد، جواب را برای خودت توضیح بده
این نکته را با یک مثال توضیح بده: journalctl Log systemd را جستجو میکند. بعد بگو در عمل چطور آن را بررسی میکنی.
گزارش رویداد ثبت زمانی اتفاقها و خطاهای سیستم است و برای ساختن Timeline کمک میکند؛ زمان گزارش کاربر را با Log همان بازه مقایسه کن
این نکته را با یک مثال توضیح بده: /var/log محل رایج Log است. بعد بگو در عمل چطور آن را بررسی میکنی.
گزارش رویداد ثبت زمانی اتفاقها و خطاهای سیستم است و برای ساختن Timeline کمک میکند؛ زمان گزارش کاربر را با Log همان بازه مقایسه کن
این نکته را با یک مثال توضیح بده: زمان دقیق رخداد با زمان مشکل تطبیق داده شود. بعد بگو در عمل چطور آن را بررسی میکنی.
Log بدون زمان همگامشده ارزش کمتری دارد. زمان دقیق رخداد پیام را با زمان گزارش کاربر و Log سیستمهای وابسته مقایسه کن و اگر اختلاف ساعت وجود دارد ابتدا آن را در Timeline لحاظ کن
برای ذخیره پیشرفت، دوره را رسمی شروع کن
با ثبتنام، تکمیل درسها و نمره آزمون روی حساب ذخیره میشود
