Nagios

Материал из Xgu.ru

Перейти к: навигация, поиск


Настройка Nagios для FreeBSD

Источник:[1]
Перевод: Игорь Чубин

Nagios — это приложение, предназначенное для выполнения мониторинга систем и сетей. Оно следит за назначенными приложениями и службами и генерирует оповещения в зависимости от поведения наблюдаемых служб. До какого-то времени проект был известен как NetSaint. В настоящий момент, хотя сайт NetSaint работает, дальнейшая разработка проекта продолжается под именем Nagios.

Nagios это рекурсивный акроним, расшифровывающийся как Nagios Ain't Gonna Insist On Sainthood (Nagios не собирается настаивать на святости — намек на прежнее название проекта, NetSaint — сетевой святой).


Содержание

[править] Предварительная подготовка

Установите из портов перечисленные приложения:

  • MySQL 4x server : /usr/ports/databases/mysql40-server
  • MySQL 4x client : /usr/ports/databases/mysql40-client
  • Apache 1.3x : /usr/ports/www/apache13
  • Net-SNMP : /usr/ports/net-mgmt/net-snmp
  • Nagios : /usr/ports/net-mgmt/nagios (WITH_MYSQL="YES")

[править] Настройка SNMP

В системе, за которой вы собираетесь наблюдать с помощью Nagios, должен быть установлен и сконфигурирован SNMP. Настройка SNMP выполняется достаточно просто. Обязательно поменяйте названия сообществ (community), приведённые в конфигурационном файле. Названия сообществ это фактически пароли, и оставляя их неизменными вы ставите под удар безопасность системы.

Есть два способа настроить SNMP в Unix:

  • Запустить snmpconf и ответить на все вопросы, которые будут задаваться;
  • Создать свой собственный конфигурационный файл /usr/local/share/snmp/snmpd.conf вручную.

Выберите любой удобный вам способ.

[править] Создание файла конфигурации

Ниже пример конфигурационного файла snmpd.conf созданного с помощью программы snmpconf. 

syslocation: Meganetwork, Russia
sysservices 0
syscontact      admin@yourlan.com

                #community      #hosts allowed
rwcommunity     private         trusted.host.com
rocommunity     everyone        10.0.0.0/24

В этом конфигурационном файле присутствует самая базовая конфигурация:

  • rwcommunity указывает, кто может выполнять запись в MIB хоста (вместо private укажите другое слово — это пароль);
  • rocommunity указывает, кто может смотреть дерево SNMP.

По умолчанию название rocommunity public, но из соображений безопасности его лучше изменить на другое. Имя community это фактически пароль.

Если вы используете другую операционную систему, процедура будет незначительно отличаться. Другими будут пути к конфигурационным файлам.

[править] Настройка Nagios

Сейчас, когда и Nagios и его дополнительные модули (plugins) уже проинсталлированы, почти можно начинать. Однако, Nagios даже не запустится, если его перед этим правильно не настроить.

Для начала можно ознакомиться с тем, примеры каких файлов есть в каталоге /usr/local/etc/nagios: 

# ls /usr/local/etc/nagios/*sample
cgi.cfg-sample 
checkcommands.cfg-sample 
contactgroups.cfg-sample 
contacts.cfg-sample 
dependencies.cfg-sample 
escalations.cfg-sample 
hostgroups.cfg-sample 
hosts.cfg-sample 
misccommands.cfg-sample 
nagios.cfg-sample 
resource.cfg-sample 
services.cfg-sample 
timeperiods.cfg-sample

Поскольку это файлы-примеры, разработчики Nagios добавили к каждому из них суффикс -sample. Прежде всего нужно переименовать или скопировать файлы, чтобы в названии не было этого суффикса. (Если эти файлы не переименовать, Nagios будет всё равно будет искать файлы .cfg и, естественно, ничего не найдёт).

Перед тем как переименовывать файлы, сделайте их резервную копию, чтобы в случае чего можно было всегда вернуться и посмотреть как сделано в примере. 

# cd /usr/local/etc/nagios/etc
# mkdir sample 
# cp *.cfg-sample sample/

Быстро переименовать множество файлов можно следующим образом: 

# for i in *cfg-sample; do mv -v $i `basename $i "-sample"`; done

В итоге в каталоге должны остаться такие файлы: 

cgi.cfg 
checkcommands.cfg 
contactgroups.cfg 
contacts.cfg 
dependencies.cfg 
escalations.cfg 
hostgroups.cfg 
hosts.cfg 
misccommands.cfg 
nagios.cfg 
resource.cfg 
sample/ 
services.cfg 
timeperiods.cfg

Прежде всего нужно посмотреть главный конфигурационный файл, nagios.cfg. В FreeBSD вы можете оставить все как есть, потому что при инсталляции в конфигурационном файле были установлены правильные пути. Единственное, что можно поменять это параметр check_external_commands, установленный по умолчанию в 0. Если вы хотите добавить новые возможности к Nagios, или напрямую вызывать команды Unix через web-интерфейс Nagios, установите этот параметр равным 1. Чтобы эта возможность заработала, нужно установить ещё несколько опций в файле cgi.cfg. Например, указать, каким пользователям разрешается выполнять внешние команды.

Для того чтобы заставить Nagios работать, нужно модифицировать несколько конфигурационных файлов. Вообще, настраивать Nagios намного проще чем может показаться.

Сначала лучше всего запускать Nagios в режиме отладки. Вызов в режим отладки выполняется так: 

# nagios -v /usr/local/etc/nagios/nagios.cfg

Команда загрузит все конфигурационные файлы и сообщит обо всех ошибках, которые она найдет. Исправляйте все ошибки по очереди, а потом запускайте команду снова. Перечисленные ниже файлы можно просто стереть и заменить их собственными версиями, которые представлены ниже.

  • hosts.cfg
  • services.cfg
  • contacts.cfg
  • contactgroups.cfg
  • hostgroups.cfg
  • dependencies.cfg
  • escalations.cfg.

Мы не будем выполнять продвинутую настройку, которая требует использования файлов dependecies.cfg и escalations.cfg. Удалите примеры файлов, чтобы они не смущали Nagios и создайте на их месте пустые файлы с такими же названиями.

Это можно сделать так: 

# cd /usr/local/etc/nagios
# rm dependencies.cfg 
# rm escalations.cfg
# touch dependencies.cfg 
# touch escalations.cfg

или так 

# cd /usr/local/etc/nagios
# echo "" > dependencies.cfg 
# echo "" > escalations.cfg

[править] Настройка мониторинга

[править] Файл hosts.cfg

Сначала нужно описать хосты, за которыми будет выполняться наблюдение. Можно описать сколь-угодно много хостов, но для простоты мы начнем с одного. 

# Generic host definition template
define host{
# The name of this host template - referenced i
name                            generic-host    
# Other host definitions, used for template recursion/resolution
# Host notifications are enabled
notifications_enabled           1     
# Host event handler is enabled   
event_handler_enabled           1        
# Flap detection is enabled  
flap_detection_enabled          1     
# Process performance data
process_perf_data               1
# Retain status information across program restarts       
retain_status_information       1   
# Retain non-status informatddion across program restarts    
retain_nonstatus_information    1       
# DONT REGISTER THIS DEFINITION - ITS NOT A REAL HOST,
# JUST A TEMPLATE!
register                        0        
}

# Host Definition
define host{
# Name of host template to use
use                     generic-host             
host_name               domain.com
alias                   My Registered Domain
address                 www.domain.com
check_command           check-host-alive
max_check_attempts      10
notification_interval   120
notification_period     24x7
notification_options    d,u,r
}

Первый описанный хост это не настоящий хост, а шаблон, на котором основываются описания всех остальных хостов. Такой же механизм можно встретить и в других конфигурационных файлах, когда конфигурация основывается на предварительно определенном множестве значений по умолчанию.

При такой конфигурации мы выполняем наблюдение только за хостом www.domain.com и выполняем только одну проверку — проверяем, живой ли хост. Параметр host_name является здесь принципиально важным, поскольку другие конфигурационные файлы обращаются к описанию сервера по этому имени.

[править] Файл hostgroups.cfg

Теперь нужно добавить хост в группу хостов (hostgroup). Даже в нашей простой конфигурации, когда хост один, все равно нужно добавлять его в группу, чтобы Nagios знал какую контактную группу (contact group) нужно использовать для отправки оповещений. О контактной группе подробнее ниже. 

define hostgroup{
hostgroup_name  domain-servers
alias           Domain Servers
contact_groups  domain-admins
members         domain.com
}

Мы определили группу хостов domain-servers и связали её с контактной группой domain-admins. Теперь переходим к описанию контактной группы.

[править] Файл contactgroups.cfg 

define contactgroup{
contactgroup_name       domain-admins
alias                   Domain.Com Admins
members                 bob, bill
}

Мы определили контактную группу domain-admins и добавили пользователей bob и bill в эту группу. Такая конфигурация гарантирует, что оба пользователя получат предупреждение в том случае, если что-то не так с серверами за которые отвечает группа domain-admins. Правда, нужно иметь в виду, что индивидуальные настройки по каждому из пользователей могут перекрыть эти настройки.

Следующим шагом нужно указать контактную информацию и настройки оповещений.

[править] Файл contacts.cfg 

define contact{
contact_name                    bob
alias                           Bob Buddy
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-by-email,notify-by-epager
host_notification_commands      host-notify-by-email,host-notify-by-epager
email                           bob@domain.com
pager                           domian-admin@localhost.localdomain
}

define contact{
contact_name                    bill
alias                           Bill Buddy
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-by-email,notify-by-epager
host_notification_commands      host-notify-by-email
email                           bill@domain.com
}

Помимо того что в этом файле приводится дополнительная контактная информация пользователей, одно из полей, contact_name, имеет ещё одно назначение. CGI-cкрипты используют имена, заданные в этих полях для того чтобы определить, имеет пользователь право доступа к какому-то ресурсу или нет. Вы должны настроить аутентификацию, основывающуюся на .htaccess, но кроме этого нужно использовать те же имена, которые использованы выше, для того чтобы пользователи могли работать через Web-интерфейс.

Теперь, когда хосты и контакты настроены, можно переходить к настройке мониторинга отдельных сервисов, за которыми должно проводиться наблюдение.

[править] Файл services.cfg 

# Generic service definition template
define service{
# The 'name' of this service template, 
# referenced in other service definitions
name    generic-service  
# Active service checks are enabled
active_checks_enabled  1 
# Passive service checks are enabled/accepted
passive_checks_enabled  1 
# Active service checks should be parallelized 
# (disabling this can lead to major performance problems)
parallelize_check  1  
# We should obsess over this service (if necessary)
obsess_over_service  1  
# Default is to NOT check service 'freshness'
check_freshness   0  
# Service notifications are enabled
notifications_enabled  1 
# Service event handler is enabled
event_handler_enabled  1 
# Flap detection is enabled
flap_detection_enabled  1 
# Process performance data
process_perf_data  1 
# Retain status information across program restarts
retain_status_information 1  
# Retain non-status information across program restarts
retain_nonstatus_information 1  
# DONT REGISTER THIS DEFINITION - 
# ITS NOT A REAL SERVICE, JUST A TEMPLATE!
register   0
}

# Service definition
define service{
# Name of service template to use
use    generic-service   
host_name   host1.domain.com
service_description  HTTP
is_volatile   0
check_period   24x7
max_check_attempts  3
normal_check_interval  5
retry_check_interval  1
contact_groups   domain-admins
notification_interval  120
notification_period  24x7
notification_options  w,u,c,r
check_command   check_http
}

# Service definition
define service{
# Name of service template to use
use    generic-service   

host_name   host1.domain.com
service_description  PING
is_volatile   0
check_period   24x7
max_check_attempts  3
normal_check_interval  5
retry_check_interval  1
contact_groups   domain-admins
notification_interval  120
notification_period  24x7
notification_options  c,r
check_command   check_ping!100.0,20%!500.0,60%
}

Мы указали Nagios выполнять наблюдение за двумя службами. В первом описании службы, которое названо HTTP, выполняется проверка web-сервера на доступность и в случае проблем генерирует оповещение. Во втором случае выполняется наблюдение за статистикой ping, и если время ответа возрастает слишком сильно или значительно увеличивается процент потерь, сообщает об этом. Команды с помощью которых выполняются проверки: check_http и check_ping, которые были установлены как дополнительные модули Nagios.

Доступно огромное количество дополнительных модулей Nagios, но если какой-то проверки всё же нет, её можно всегда написать самостоятельно. Например, нет модуля, проверяющего работает или нет Tomcat. Можно написать скрипт, который загружает jsp страницу с удалённого Tomcat-сервера и возвращает результат в зависимости от того, если в загруженной странице какой-то текст на странице или нет. (При добавлении новой команды нужно обязательно упомянуть её в файле checkcommand.cfg, который мы не трогали).

[править] Запуск Nagios

Теперь, после того как сконфигурированы хосты и службы для мониторинга, можно приступать собственно к этому процессу. Выполните запуск Nagios с помощью специального стартового скрипта: 

# /usr/local/etc/rc.d/nagios start

Если все пойдёт гладко, Nagios запустится. Следующая команда должна показать вам, работает ли Nagios в действительности, а если да, то какой процесс, с каким идентификатором, ему соответствует: 

# /usr/local/etc/rc.d/nagios status
PID TTY          TIME CMD
22645 ?        00:00:00 nagios

[править] Web-интерфейс

Сейчас Nagios выполняет мониторинг. Он уже будет присылать оповещения, если возникнет какая-то проблема с каким-нибудь из серверов. Но для того чтобы выполнять интерактивное наблюдение за службами было удобнее, лучше настроить web-интерфейс. Web-интерфейс ещё хорош тем, что даёт полную картину системы благодаря умелому применению графических средств и предоставления дополнительной статистической информации.

Естественно, для того чтобы это можно было сделать, нужно чтобы на хосте работал web-сервер, который сможет предоставить доступ к web-интерфейсу Nagios. В данной статье предполагается, что вы используете Apache. Воспользуемся конфигурацией web-сервера, которая приводится в документации Nagios.

[править] Дополнение к httpd.conf 

ScriptAlias /nagios/cgi-bin/ /usr/local/www/nagios/cgi-bin/
<Directory "/usr/local/www/nagios/cgi-bin/">
AllowOverride AuthConfig
Options ExecCGI
Order allow,deny
Allow from all
</Directory>

Alias /nagios/ /usr/local/www/nagios/
<Directory "/usr/local/www/nagios">
Options None
AllowOverride AuthConfig
Order allow,deny
Allow from all
</Directory>

Эти строки создают алиас /nagios/cgi-bin/ в web-сервере и указывают его на каталог cgi-bin со скриптами в дистрибутиве Nagios. Если предположить, что web-сервер доступен по адресу http://127.0.0.1/, то web-интерфейс Nagios должен находится здесь: http://127.0.0.1/nagios/. Сейчас web-интерфейс уже должен работать, но некоторые из страниц могут не загружаться. 

It appears as though you do not have permission to view information for any of the
hosts you requested...

If you believe this is an error, check the HTTP server authentication requirements for
accessing this CGI and check the authorization options in your CGI configuration file.

"Похоже, что у вас нет прав на просмотр информации по хостам, которую вы запросили.
Если Вы полагаете, что это - ошибка, проверьте аутентификационные настройки доступа к CGI-скриптам HTTP-сервера и проверьте опции авторизации в вашем конфигурационном файле CGI."

Эта предосторожность сделана из соображений безопасности. Только авторизованные пользователи должны иметь возможность работать с интерфейсом Nagios. Аутентификация выполняется браузером по методу Basic HTTP Authentication (проще говоря, через .htaccess). Nagios берёт имя пользователя, под которым прошёл аутентификацию пользователь, и находит секцию с соответствующим contact_name в contacts.cfg. Отсюда он узнаёт, к каким разделам сайта Nagios пользователь имеет доступ, а к каким — нет.

Если web-сервер готов к использованию аутентификации на базе .htaccess, её конфигурирование выполняется очень просто. Если не готов, прочитайте как это сделать в документации на web-сервер. Будем исходить из предположения, что web-сервер готов использовать .htaccess.

Во-первых, нужно создать файл .htaccess в каталоге /usr/local/share/nagios/cgi-bin. Если вы хотите полностью закрыть web-интерфейс Nagios, вы можете положить копию этого файла в каталог /usr/local/share/nagios.

Добавьте следующие строки в конфигурационный файл .htaccess: 

AuthName "Nagios Access"
AuthType Basic
AuthUserFile /usr/local/nagios/etc/htpasswd.users
require valid-user

Когда вы создаёте первого пользователя, файл с паролями указанный в .htaccess, не существует. Для того чтобы он создался, при первом вызове htpasswd нужно указать ключ -c: 

# htpasswd -c /usr/local/nagios/etc/htpasswd.users bob
New password: ******
Re-type new password: ******
Adding password for user bob

Для всех остальных пользователей команду htpasswd вызывайте без ключа -c, иначе файл будет создан заново. После того как все нужные пользователи будут добавлены, можно вернуться к web-интерфейсу. Должен появится диалог аутентификации. После успешной аутентификации можно использовать web-интерфейс.

Обратите внимание, что пользователи могут получать информацию только о тех серверах, с которыми они ассоциированы в конфигурационном файле. Некоторые из секций web-интерфейса по умолчанию вообще отключены для всех. Если вы хотите их включить, это делается в файле cgi.cfg. Например, для того чтобы пользователю bob разрешить доступ к секции Process Info, раскомментируйте строку authorized_for_system_information и добавьте bob к списку имён, разделённых запятыми.

Это всё что нужно для того чтобы выполнить начальную настройку Nagios с целью выполнения мониторинга ваших серверов и служб. Дальше можно заняться тонкой настройкой системы мониторинга, редактируя конфигурационные файлы в соответствии с вашими мыслями и желаниями.

Посмотрите список дополнительных модулей (plugin) для Nagios. Существует огромное множество всего за чем Nagios может наблюдать, и что может контролировать. В Nagios есть программы для удаленного отслеживания уровня заполненности дискового пространства и нагрузки на систему.

[править] Дополнительная информация

Подборка материалов на сайте onix.opennet.ru:

Источник — «http://xgu.ru/wiki/Nagios»