Product SiteDocumentation Site

12.4. مانیتورینگ

مانیتورینگ یک عبارت عمومی است و فعالیت‌های مرتبط با آن اهداف گوناگونی را دنبال می‌کنند: از یک طرف، پیگیری منابع مصرفی فراهم شده توسط ماشین امکان پیشبینی میزان اشباع و بروزرسانی‌های متعاقب با آن را فراهم می‌کند؛ از طرف دیگر، هشدار به مدیر سیستم به محض اینکه یک سرویس از دسترس خارج شود یا به درستی کار نکند به معنی رفع سریع‌تر مشکلات در زمان بروز حادثه است.
Munin با نمایش نمودارهای گرافیکی برای مقادیر مختلف از پارامترهای متعدد (حافظه مصرفی، فضای اشغال شده دیسک، بار پردازنده، ترافیک شبکه، بار وب سرور/پایگاه‌داده و از این قبیل) ناحیه اول را پوشش می‌دهد. Nagios با بررسی مداوم سرویس‌ها و نحوه کارکرد و قابل دسترس بودن آن‌ها، همراه با ارسال پیام به مدیر سیستم با استفاده از کانال‌های مناسب (ایمیل، پیامک و از این قبیل) ناحیه دوم را پوشش می‌دهد. هر دو ابزار ساختاری ماژولار دارند که به توسعه هر یک از آن‌ها و افزودن پارامترها یا سرویس‌های خاص کمک می‌کند.

12.4.1. راه‌اندازی Munin

هدف Munin مانیتور کردن ماشین‌های متعدد است؛ بنابراین، طبیعی است که از معماری کلاینت/سرور استفاده کند. میزبان مرکزی - یا grapher - داده را از تمام میزبان‌های قابل مانیتور کردن دریافت کرده و نمودارهای گرافیکی تولید می‌کند.

12.4.1.1. پیکربندی میزبان‌ها برای مانیتور شدن

اولین گام نصب بسته munin-node است. فرآیند پس‌زمینه‌ای که توسط این بسته نصب می‌شود به درگاه ۴۹۴۹ گوش کرده و داده‌های دریافتی از پلاگین‌های فعال را ارسال می‌کند. هر پلاگین یک برنامه ساده است که توضیح مرتبط با داده دریافتی همراه با آخرین مقدار بدست آمده را باز می‌گرداند. پلاگین‌ها در مسیر /usr/share/munin/plugins/ ذخیره شده‌اند اما تنها آن‌هایی که به صورت پیوند نمادین در /etc/munin/plugins/ قرار داشته باشند، استفاده می‌گردند.
زمانی که بسته نصب شود، مجموعه‌ای از پلاگین‌های فعال بر اساس نرم‌افزار موجود و پیکربندی فعلی میزبان تشخیص داده می‌شوند. اگرچه، این پیکربندی خودکار وابسته به قابلیتی است که هر پلاگین باید فراهم کرده باشد و بهتر است که نتایج را به صورت دستی مرور و ویرایش کنیم. مرور گالری پلاگین می‌تواند جالب باشد با این وجود که همه پلاگین‌ها ممکن است شامل مستندات جامع نباشند. با این حال، تمام پلاگین‌ها اسکریپت هستند که اکثر آن‌ها ساده بوده و دارای توضیحات خوبی می‌باشند. مرور /etc/munin/plugins/ شیوه خوبی برای اطلاع از کارکرد هر پلاگین و تشخیص اینکه کدام یک باید حذف شود می‌باشد. به طور مشابه، فعال‌سازی یک پلاگین جالب در /usr/share/munin/plugins/ به سادگی ایجاد پیوند نمادین با استفاده از ln -sf /usr/share/munin/plugins/plugin /etc/munin/plugins/ می‌باشد. به یاد داشته باشید اگر نام پلاگین به زیرخط یا “_” تمام شود، پلاگین نیازمند یک پارامتر است. این پارامتر باید در نام مرتبط با پیوند نمادین ذخیره‌سازی شود؛ برای نمونه، پلاگین “if_” باید همراه با پیوند نمادین if_eth0 فعال‌سازی شود، تا بتواند ترافیک شبکه رابط eth0 را مانیتور کند.
زمانی که تمام پلاگین‌ها راه‌اندازی شوند، پیکربندی فرآیند پس‌زمینه به منظور تعریف کنترل دسترسی به داده‌های گردآوری شده باید بروزرسانی گردد. اینکار شامل عبارت‌های allow در فایل /etc/munin/munin-node.conf می‌شود. پیکربندی پیشفرض به صورت allow ^127\.0\.0\.1$ است که تنها اجازه دسترسی به میزبان محلی را می‌دهد. یک مدیرسیستم معمولا خطی مشابه را همراه با نشانی IP میزبان grapher می‌افزاید، سپس اقدام به راه‌اندازی مجدد فرآیند پس‌زمینه با استفاده از service munin-node restart می‌کند.

12.4.1.2. پیکربندی Grapher

“grapher” در واقع رایانه‌ای است که داده‌ها را گردآوری کرده و نمودارهای مرتبط با آن را رسم می‌کند. نرم‌افزار مورد نیاز در بسته munin قرار دارد. پیکربندی استاندارد munin-cron را هر ۵ دقیقه یکبار اجرا کرده، تا اطلاعات از تمام میزبان‌های موجود در /etc/munin/munin.conf گردآوری شوند (فقط میزبان محلی به صورت پیشفرض قرار دارد)، داده‌های بدست آمده را در فایل‌های RRD، که مخفف Round Robin Database و مناسب ذخیره‌سازی داده‌های متغیر در طول زمان است، ذخیره‌سازی می‌کند که این فایل‌ها در مسیر /var/lib/munin/ قرار دارند و در نهایت یک صفحه HTML همراه با نمودارها در /var/cache/munin/www/ ایجاد می‌کند.
بنابراین تمام ماشین‌های مانیتور شده باید در فایل پیکربندی /etc/munin/munin.conf قرار داشته باشند. هر ماشین به عنوان یک قسمت کامل همراه با نام آن و حداقل یک مدخل address که شامل نشانی IP ماشین است، قرار می‌گیرد.
[ftp.falcot.com]
    address 192.168.0.12
    use_node_name yes
قسمت‌ها می‌توانند پیچیده‌تر باشند، تا با ترکیب داده‌های بدست آمده از چند ماشین نمودارهای اضافی رسم گردد. مثال‌های موجود در فایل پیکربندی نقطه آغاز مناسبی برای سفارشی‌کردن این فرآیند هستند.
آخرین گام انتشار صفحات تولید شده است؛ اینکار نیازمند پیکربندی سرور وب به گونه‌ای است که محتوای /var/cache/munin/www/ از طریق یک وبسایت قابل دسترس باشد. دسترسی به این وبسایت می‌تواند با استفاده از مکانیزم احرازهویت یا کنترل دسترسی مبتنی بر IP مدیریت شود. برای جزئیات مرتبط قسمت 11.2, “سرور وب (HTTP)” را مشاهده کنید.

12.4.2. راه‌اندازی Nagios

برخلاف Munin، الزامی بر نصب Nagios روی میزبان‌های مانیتور شده نیست؛ از Nagios بیشتر به منظور بررسی موجود بودن سرویس‌های شبکه استفاده می‌شود. برای نمونه، Nagios می‌تواند به یک سرور وب متصل شده و بررسی کند یک صفحه مشخص در زمان مشخص قابل دسترس است یا خیر.

12.4.2.1. نصب

اولین گام در راه‌اندازی Nagios نصب بسته‌های nagios3، nagios-plugins و nagios3-doc است. نصب بسته‌ها منجر به پیکربندی یک رابط وب و ایجاد کاربر nagiosadmin می‌شود (که برای آن گذرواژه درخواست خواهد شد). افزودن سایر کاربران به سادگی درج آن‌ها در فایل /etc/nagios3/htpasswd.users با استفاده از دستور htpasswd در آپاچی است. اگر در زمان نصب پرسشی از طرف Debconf مطرح نشد، می‌توان از dpkg-reconfigure nagios3-cgi برای تعریف گذرواژه nagiosadmin استفاده کرد.
نشانی http://server/nagios3/ در مرورگر، رابط وب مربوط به آن را نمایش می‌دهد؛ به طور مشخص، به یاد داشته باشید که Nagios برخی پارامترهای ماشینی که در آن اجرا می‌شود را مانیتور می‌کند. با این حال، برخی ویژگی‌های تعاملی از جمله افزودن دیدگاه به یک میزبان ممکن است کار نکند. این ویژگی‌های در پیکربندی پیشفرض برای Nagios غیرفعال هستند، که بنا بر دلایل امنیتی بسیار محدود کننده است.
همانطور که در /usr/share/doc/nagios3/README.Debian توضیح داده شده است، فعال‌سازی برخی ویژگی‌ها نیازمند ویرایش /etc/nagios3/nagios.cfg و تنظیم پارامتر check_external_commands آن به “1” است. همچنین نیاز داریم تا مجوزهای نوشتن روی دایرکتوری که توسط Nagios استفاده می‌شود را با استفاده از دستورات مشابه زیر تنظیم کنیم:
# service nagios3 stop
[...]
# dpkg-statoverride --update --add nagios www-data 2710 /var/lib/nagios3/rw
# dpkg-statoverride --update --add nagios nagios 751 /var/lib/nagios3
# service nagios3 start
[...]

12.4.2.2. پیکربندی

رابط وب Nagios بسیار کاربردی است، اما اجازه تغییر پیکربندی یا افزودن میزبان‌ها و سرویس‌های قابل مانیتور را نمی‌دهد. پیکربندی کلی از طریق فایل‌های اشاره شده در فایل پیکربندی مرکزی /etc/nagios3/nagios.cfg مدیریت می‌شود.
بدون درک از مفاهیم Nagios نباید مستقیم سراغ این فایل‌ها رفت. پیکربندی شامل اشیایی از نوع زیر می‌باشد:
  • یک host ماشینی است که باید مانیتور شود؛
  • یک hostgroup مجموعه‌ای از میزبان‌ها است که برای نمایش یا در نظر گرفتن برخی عناصر پیکربندی، باید گروه‌بندی شوند؛
  • یک service شامل عنصری قابل آزمون مرتبط با یک میزبان یا گروه میزبانی است. در اکثر موارد برای بررسی یک سرویس شبکه بکار می‌رود، اما می‌تواند برای بررسی محدوده مجاز برخی پارامترها نیز استفاده شود (برای نمونه، فضای آزاد دیسک یا بار پردازنده)؛
  • یک servicegroup مجموعه‌ای از سرویس‌ها است که برای نمایش باید گروه‌بندی شوند؛
  • یک contact شخصی است که می‌تواند هشدارها را دریافت کند؛
  • یک contactgroup مجموعه‌ای از چنین افرادی است؛
  • یک timeperiod بازه‌ای از زمان است که طی آن برخی سرویس‌ها باید بررسی شوند؛
  • یک command دستوری است که به منظور بررسی یک سرویس مشخص فراخوانی می‌شود.
با توجه به نوع، هر شی شامل قابلیت‌هایی است که می‌تواند سفارشی شود. فهرست کامل آن بسیار طولانی است، اما مهم‌ترین قابلیت‌ها همان روابط بین اشیا است.
یک service از command استفاده می‌کند تا وضعیت یک قابلیت موجود درhost (یا hostgroup) را طی بازه timeperiod بررسی کند. در صورت بروز مشکل، Nagios یک هشدار به تمام اعضای موجود در contactgroup مرتبط با سرویس ارسال می‌کند. با توجه به کانال تعریف شده برای هر فرد در شی contact، پیام برای وی فرستاده می‌شود.
یک سیستم ارث‌گرایی امکان اشتراک‌گذاری مجموعه‌ای از قابلیت‌ها را بین چندین شی مختلف بدون تکرار اطلاعات فراهم می‌کند. علاوه بر این، پیکربندی پیشفرض شامل برخی از اشیای استاندارد می‌باشد؛ در اکثر موارد، تعریف میزبان‌ها، سرویس‌ها و افراد جدید به سادگی مشتق شدن از این اشیای عمومی است. فایل‌های موجود در /etc/nagios3/conf.d/ منبع خوبی از اطلاعات درباره چگونگی کارکرد این اشیا است.
مدیرسیستم‌های شرکت فالکوت از پیکربندی زیر استفاده می‌کنند:

مثال 12.3. فایل /etc/nagios3/conf.d/falcot.cfg

define contact{
    name                            generic-contact
    service_notification_period     24x7
    host_notification_period        24x7
    service_notification_options    w,u,c,r
    host_notification_options       d,u,r
    service_notification_commands   notify-service-by-email
    host_notification_commands      notify-host-by-email
    register                        0 ; Template only
}
define contact{
    use             generic-contact
    contact_name    rhertzog
    alias           Raphael Hertzog
    email           hertzog@debian.org
}
define contact{
    use             generic-contact
    contact_name    rmas
    alias           Roland Mas
    email           lolando@debian.org
}

define contactgroup{
    contactgroup_name     falcot-admins
    alias                 Falcot Administrators
    members               rhertzog,rmas
}

define host{
    use                   generic-host ; Name of host template to use
    host_name             www-host
    alias                 www.falcot.com
    address               192.168.0.5
    contact_groups        falcot-admins
    hostgroups            debian-servers,ssh-servers
}
define host{
    use                   generic-host ; Name of host template to use
    host_name             ftp-host
    alias                 ftp.falcot.com
    address               192.168.0.6
    contact_groups        falcot-admins
    hostgroups            debian-servers,ssh-servers
}

# 'check_ftp' command with custom parameters
define command{
    command_name          check_ftp2
    command_line          /usr/lib/nagios/plugins/check_ftp -H $HOSTADDRESS$ -w 20 -c 30 -t 35
}

# Generic Falcot service
define service{
    name                  falcot-service
    use                   generic-service
    contact_groups        falcot-admins
    register              0
}

# Services to check on www-host
define service{
    use                   falcot-service
    host_name             www-host
    service_description   HTTP
    check_command         check_http
}
define service{
    use                   falcot-service
    host_name             www-host
    service_description   HTTPS
    check_command         check_https
}
define service{
    use                   falcot-service
    host_name             www-host
    service_description   SMTP
    check_command         check_smtp
}

# Services to check on ftp-host
define service{
    use                   falcot-service
    host_name             ftp-host
    service_description   FTP
    check_command         check_ftp2
}
این فایل پیکربندی دو میزبان مانیتور شده را تعریف می‌کند. اولی سرور وب است که بررسی‌های موجود برای درگاه‌های ۸۰ و ۴۴۳ انجام می‌شود. Nagios همچنین بررسی می‌کند که سرور SMTP روی درگاه ۲۵ اجرا شود. دومی سرور FTP است که بررسی به منظور دریافت پاسخ ظرف مدت ۲۰ ثانیه در آن صورت می‌گیرد. فراتر از این تاخیر، یک warning صادر می‌شود؛ فراتر از ۳۰ ثانیه، هشدار به منزله بحرانی در نظر گرفته می‌شود. رابط وب Nagios همچنین نشان می‌دهد که سرویس SSH در حال مانیتور شدن است: این اطلاعات از میزبان‌هایی می‌آید که متعلق به گروه ssh-servers هستند. سرویس استاندارد منطبق با آن در فایل /etc/nagios3/conf.d/services_nagios2.cfg تعریف شده است.
کاربرد ارث‌گرایی را به یاد داشته باشید: یک شی می‌تواند از شی دیگری با استفاده از “use parent-name” ارث‌بری کند. شی والد باید قابل شناسایی باشد، که نیازمند اختصاص قابلیت “name identifier” به آن می‌باشد. اگر قرار بر واقعی نبودن شی والد باشد، اما تنها به صورت والد عمل کند، اختصاص قابلیت “register 0” به آن به Nagios می‌گوید که از آن شی صرف نظر کند، که در این صورت نبود برخی پارامترهای مورد نیاز آن مشکلی را بوجود نمی‌آورد.