автоматизация nagios в больших масштабах

Я хотел бы знать, есть ли у вас опыт или идеи о том, как настроить nagios в больших масштабах.

Раньше мы использовали nagios и nagiosql для ручной настройки, это было довольно удобно для нескольких серверов.

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

Например, сценарий может быть таким: при запуске нового сервера mysql существует специальный рецепт для перезаписи файла настроек nagios. Recipe может получить все данные из пакетов данных шеф-повара о каждом сервере и создать настройки на основе ролей в шеф-поваре.

За последние 18 месяцев я реализовал три немного разных решения для мониторинга Nagios с помощью Chef. Все они основаны на ресурсе шаблонов Chef для генерации файлов конфигурации с использованием синтаксиса ERB, и этот бит работал очень хорошо. У вас есть Ruby-массив или хэш хостов и служб, и создаются файлы конфигурации Nagios. Тестировать и отлаживать довольно просто.

Полная конфигурация на основе пакетов данных. В этом случае есть nagios_hosts и nagios_services пакет данных, и у каждого хоста есть ключ, который говорит, какие проверки службы запускаются, например check_load, check_disk. Эта установка быстро запускается и работает достаточно хорошо, хотя, если хосты удалены или добавлены новые, кто-то должен быть рядом, чтобы обновить пакеты данных. На практике об этом легко забыть, и все может устареть, что может привести к неприятностям.
Конфигурация на основе атрибутов Chef. Здесь я использовал Chef REST API, чтобы запросить один или несколько серверов Chef, чтобы получить списки узлов и назначить им служебные проверки в зависимости от назначенных им ролей. Зависимость от Chef означает, что сложно контролировать системы, не относящиеся к Chef, например, устройства, сетевые устройства или узлы, на которых Chef по какой-либо причине не запускается. Chef в конечном итоге отправляет огромное количество данных JSON по сети для большого количества узлов, и обработка всех этих данных создает нагрузку на сервер (ы) Chef, а также на сервер Nagios, когда он генерирует файлы конфигурации.
Приложение Rails, генерирующее файлы конфигурации Nagios. В итоге я нарушил зависимость Chef, сохранив информацию о конфигурации Nagios в базе данных и заставив приложение Rails генерировать файлы конфигурации. Каждый сервер Nagios отправляет запрос REST и загружает файлы конфигурации, созданные с помощью ERB и базы данных MySQL. Это довольно большая работа, но пока что она хорошо работает для мониторинга узлов Chef и других узлов.

Поэтому, пройдя через все это, я, вероятно, рекомендовал бы использовать что-то вроде варианта №2 для небольших (от десятков до сотен) узлов. Я бы постарался сделать это простым. Я использовал систему атрибутов Chef для определения и переопределения пороговых значений для проверок службы на основе ролей, и хотя она работает, она слишком сложна, и в итоге поваренная книга превратилась в непослушный беспорядок.

Удачи!