Я запускаю сервер Nagios среднего размера. В настоящее время он отслеживает примерно 40 серверов с 180 услугами и с каждым днем только растет.
Я перешел со старой установки Nagios, которая была настроена очень эзотерически, что заставило меня перенастроить все с нуля.
Теперь, когда сервер запущен и работает для большей части того, что мы необходимость это потому, что я собираюсь сделать его немного более масштабируемым; в настоящее время каждый хост - это отдельный файл в /etc/nagios/hosts/, и каждый хост имеет все свои службы в одном файле. Это, очевидно, не оптимально, но и не запутывает всю мою конфигурацию в сотнях разных файлов.
Итак, мой вопрос заключается в следующем: для любых опытных администраторов Nagios, как лучше всего использовать hostgroups / servicegroups? без чрезмерное усложнение конфигурации?
Группы хостов и шаблоны.
Шаблоны позволяют вам определять классы для ваших хостов и сервисов, например «нормальная служба», «критическая служба», «хост с низким приоритетом». Они также служат полезным способом разделения обязанностей, если у вас есть несколько команд с разными обязанностями, поэтому у вас может быть шаблон "хоста 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, у вас может быть дерево каталогов, подобное следующему:
Я стараюсь создать каталог для каждого типа ресурсов (команды, контактные группы, контакты, эскалации, группы хостов, хосты, сервисные группы, временные периоды), за исключением сервисов, которые группируются с хостами или группами хостов, которые их используют.
Точная структура может варьироваться в зависимости от потребностей вашей организации. На прошлой работе я использовал подкаталоги в 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.1
Обычно у меня не так много шаблонов, поэтому обычно у меня есть hosts.d/templates.cfg файл и services.d/templates.cfg файл. Если вы используете их более активно, они могут перейти в файлы с соответствующими именами в templates.d каталог.
1 Мне также нравится иметь check_http_blindly команда, которая в основном check_http -H $HOSTADDRESS$ -I $HOSTADDRESS$ -e HTTP/1.; он возвращает ОК, даже если получает код ответа 403.
Широко используйте службы, группы хостов и шаблоны. Создайте группы хостов и назначьте службы группам хостов. Используйте сервисные группы для зависимостей, эскалации и логической группировки в веб-интерфейсе.
Если у вас есть группы для всего, добавление нового хоста занимает всего 3 или 4 строки: имя, адрес, шаблон (ы) и (необязательно) группы хостов. Все можно создать по шаблону.
Обязательно прочтите документацию по наследство, а также трюки для экономии времени страница. Множественное наследование может оказаться сложной задачей, но при правильном использовании это огромная экономия времени.
Я использую эту схему:
У каждой сущности есть свой файл. Кроме того, с помощью шаблонов вы всегда можете сделать вашу конфигурацию чище более читаемой. Например, у вас может быть средняя загрузка, дисковое пространство, память на каждом хосте. Так что довольно просто и удобно создать общий шаблон и использовать его.
Я привык настраивать свои серверы nagios (до того, как я переключился на Icinga) таким образом, и нет недостатка в производительности, пока вы не достигнете более 500 служб, по крайней мере, с 512 МБ памяти / 1 сервером ЦП. Группы хостов и сервисные группы можно рассматривать полностью отдельно, и я бы рекомендовал этот подход, поскольку он позволяет иметь один файл на сервере (службы для этого сервера определены в этом файле), а затем в файле для каждой группы хостов / сервисных групп. Это только более понятно / понятно.
Если вы столкнетесь с проблемами масштабируемости, вы можете взглянуть на nagios-nrpe-server, который выполняет проверки на стороне клиента, и все, что делает ваш сервер nagios, запрашивает только результаты; которые экономят ресурс чека. (Nagios запускает check_nrpe, клиент запрашивается, выполняет локальные проверки и отвечает на nagios). Помните, что все проверки не могут обрабатываться таким образом (например, SNMP).
В завершение, и даже если это может показаться выходящим за рамки вашего вопроса, я бы предложил переключиться на Icinga, который является более масштабируемым, поддерживается более сильным сообществом, действительно заботящимся о реализации новых функций и поддержке пользователей. Конфигурация такая же (те же файлы конфигурации, тот же синтаксис).
Вы не можете усложнить конфигурацию, создав группы. Как говорит asciiphil, вы создаете файл или можете определить те же группы в некоторых из существующих файлов, таких как (hosts.cfg или что-то еще), и вы создаете этот файл или говорите nagios, что этот файл активен (это если вы создаете новое поле, если оно еще не активно), и это находится в файле nagios.cfg, где вы указываете путь к вновь созданному файлу. "cfg_file = / usr / local / nagios / etc / objects / NEW_FILE.cfg"
Другое дело - просто создавать группы в зависимости от вашей инфраструктуры. Если, например, у меня есть Linux и Windows Server, я сделаю две разные группы: одну для Linux, а другую - для Windows. То же самое и с услугами. В зависимости от того, как вы хотите настроить и видеть, когда вы отслеживаете на мониторе, как вы хотели бы видеть их как группы.
А для файла или детали как сделать группу просто.
define hostgroup{
hostgroup_name novell-servers
alias Novell Servers
members netware1,netware2,netware3,netware4
}
И в конфигурации хоста / или если вы используете шаблон или если вы уже определили шаблон хоста или службу и используете use, вы можете автоматически указать всем хостам / окнам или хостам Linux, чтобы они были членами определенной группы хостов, которую вы создали.