Лучшие практики сервера Nagios?

Я использую сервер Nagios среднего размера. В настоящее время он контролирует около 40 серверов с 180 службами и с каждым днем ​​только растет.

Я мигрировал со старой установки Nagios, которая была настроена очень эзотерически, заставляя меня переконфигурировать все с нуля.

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

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

Группы хостов и шаблоны.

Шаблоны позволяют вам определять классы для ваших хостов и сервисов, например, «обычный сервис», «критический сервис», «хост с низким приоритетом». Они также служат полезным способом разделения обязанностей, если у вас есть несколько команд с разными обязанностями, поэтому вы можете иметь шаблон "хост Linux" и шаблон "хост Windows", каждый из которых определяет соответствующую контактную информацию.

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

host foo {
    use windows-host,normal-priority-host
    ...
}

который будет получать контактную информацию (и сведения об эскалации) для команды Windows, а также частоту и пороги опроса для «нормального» хоста.

Группы хостов позволяют группировать все проверки для подмножества ваших хостов. Есть такие вещи, как «baseline-linux-hosts», которые проверяют нагрузку, дисковое пространство, sshвозможности и все, что должно быть на каждом хосте, который вы отслеживаете. Добавьте группы, такие как «https-серверы», с проверками HTTP-соединения, HTTPS-соединения и дат истечения срока действия SSL-сертификата; «файловые серверы» с проверками доступности NFS и SMB и, возможно, более агрессивными проверками дисков; или «виртуальные машины» с проверками правильности работы инструментов доступности виртуальных машин.

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

Если вы используете cfg_dirдирективу в своем nagios.cfgфайле, Nagios будет выполнять рекурсивный поиск по этому каталогу. Используйте это. Для настройки у cfg_dir=/etc/nagios/conf.dвас может быть дерево каталогов, подобное следующему:

• /etc/nagios/conf.d/
  • commands.d /
    • http.cfg
    • nrpe.cfg
    • smtp.cfg
    • ssh.cfg
  • hosts.d /
    • host1.cfg
    • host2.cfg
    • host3.cfg
  • hostgroups.d /
    • hostgroup1.cfg
    • hostgroup2.cfg

Я склонен создавать каталог для каждого типа ресурса (команды, группы контактов, контакты, эскалации, группы хостов, хосты, группы сервисов, периоды времени), за исключением сервисов, которые группируются с хостами или группами хостов, которые их используют.

Точная структура может варьироваться в зависимости от ваших организационных потребностей. На прошлой работе я использовал подкаталоги hosts.dдля каждого отдельного сайта. В моей нынешней работе большинство определений хостов Nagios управляются Puppet, поэтому есть один каталог для хостов, управляемых Puppet, и отдельный каталог для хостов, управляемых вручную.

Обратите внимание, что вышеизложенное также разбивает команды на несколько файлов, как правило, по протоколу. Таким образом, nrpe.cfgфайл будет иметь команды check_nrpeи check_nrpe_1arg, в то время как http.cfgмогли бы check_http, check_http_port, check_https, check_https_port, и check_https_cert. ¹

У меня обычно нет огромного количества шаблонов, поэтому у меня обычно есть hosts.d/templates.cfgфайл и services.d/templates.cfgфайл. Если вы используете их более интенсивно, они могут перейти в соответствующие файлы в templates.dкаталоге.

¹ Мне также нравится иметь check_http_blindlyкоманду, которая в основном check_http -H $HOSTADDRESS$ -I $HOSTADDRESS$ -e HTTP/1.; он возвращает ОК, даже если он получает код ответа 403.

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

Если у вас есть группы для всего, добавление нового хоста занимает всего 3 или 4 строки: имя, адрес, шаблон (ы) и (необязательно) группы хостов. Все может быть шаблонно.

Обязательно прочитайте документы по наследованию , а также страницу с советами по экономии времени . Множественное наследование может быть сложным, но при правильном использовании это значительно экономит время.

Я использовался для настройки своих серверов nagios (до того, как я переключился на Icinga) таким образом, и нет недостатка в производительности, пока вы не достигнете более 500 сервисов, по крайней мере, с 512Mb сервером CPU / 1 CPU. Группы хостов и сервисные группы могут обрабатываться полностью раздельно, и я бы рекомендовал этот подход, поскольку он позволяет иметь один файл на сервер (сервисы для этого сервера определены в этом файле), а затем - файл на группу хостов / сервисные группы. Это только более понятно / ясно.

Если у вас возникают проблемы с масштабируемостью, вы можете взглянуть на nagios-nrpe-server, который выполняет проверки на стороне клиента, и все, что делает ваш сервер nagios - запрашивает только результаты; которые щадят ресурс чека. (Nagios запускает check_nrpe, клиент запрашивается, выполняет проверки локально и отвечает обратно nagios). Помните, что все проверки не могут быть обработаны таким образом (например, SNMP).

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

Я использую эту схему:

• хосты,
• группы узлов сети,
• удаленные услуги,
• местные службы.

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

Вы не можете усложнить настройку с созданием групп. Как говорит asciiphil, вы создаете файл или можете определить те же группы в некоторых из существующих файлов, таких как (hosts.cfg или что-либо еще), и вы создаете этот файл или говорите nagios, что этот файл активен (это если вы создаете новое поле, если оно еще не активно), и это находится в файле nagios.cfg, где вы указываете путь к вновь созданному файлу. "Cfg_file = / USR / местные / Nagios / и т.д. / объекты / NEW_FILE.cfg"

Другое дело просто создавать группы в зависимости от вашей инфраструктуры. Если, например, у меня Linux и Windows Server, я сделаю две разные группы: одну для Linux и другую для Windows. То же самое и с услугами. В зависимости от того, как вы хотите настроить и увидеть, когда вы проводите мониторинг на мониторе, как бы вы хотели, чтобы вы видели их как группы.

А для файла или части, как составить группу, это просто.

    define hostgroup{
    hostgroup_name novell-servers
    alias Novell Servers
    members netware1,netware2,netware3,netware4
    }

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