Передовий досвід сервера Nagios?

Я запускаю сервер Nagios середнього розміру. Він відстежує приблизно 40 серверів із 180 сервісами на даний момент і лише зростає з кожним днем.

Я перейшов зі старої установки Nagios, яка була налаштована дуже езотерично, і змусила мене переробити все з нуля.

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

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

Групи господарів та шаблони.

Шаблони дозволяють визначити класи для ваших хостів і служб, наприклад, "звичайний сервіс", "критична служба", "хост з низьким пріоритетом". Вони також служать корисним способом розподілу обов'язків, якщо у вас є декілька команд з різними обов'язками, тому ви можете мати шаблон "Linux Linux" та шаблон "host host", кожен з яких визначає відповідну контактну інформацію.

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

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

що дозволить отримати контактну інформацію (та ескалацію) для команди Windows, а також показники та пороги опитування для "нормального" хоста.

Хост-групи дозволяють згрупувати всі чеки для підмножини хостів. sshНа кожному хості, який ви спостерігаєте, повинні бути такі речі, як "baseline-linux-hosts", які перевіряють навантаження, дисковий простір, здатність та будь-які інші речі. Додайте такі групи, як "https-сервери", з чеками на підключення HTTP, підключення HTTPS та дати закінчення терміну дії сертифіката SSL; "сервери файлів" з перевіркою доступності NFS та SMB і, можливо, більш агресивними дисками; або "віртуальні машини" з перевіркою на правильність роботи інструментів доступності VM.

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

Якщо ви використовуєте cfg_dirдирективу у своєму nagios.cfgфайлі, Nagios здійснюватиме рекурсивний пошук через цей каталог. Скористайтеся цим. Для налаштування cfg_dir=/etc/nagios/conf.d, ви можете мати дерево каталогів на зразок наступного:

• /etc/nagios/conf.d/
  • commandds.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, тому є одна директорія для керованих маріонетками хостів і окрема для хостів, що керуються рукою.

Зауважте, що вищезазначене також розбиває команди на кілька файлів, як правило, за протоколом. Таким чином, 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 сервісів принаймні за допомогою сервера процесора 512 Мб / 1 процесора. групи хостів і групи послуг можна розглядати повністю окремо, і я рекомендую такий підхід, оскільки він дозволяє мати один файл на сервері (послуги цього сервера визначені в цьому файлі), а потім - на файл для хост-груп / груп послуг. Це лише більш зрозуміло / зрозуміло.

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

На закінчення, і навіть якщо це може здатися поза вашим питанням, я б запропонував перейти на Icinga, який є більш масштабованим способом, який має більш сильне співтовариство, яке дійсно піклується про нові реалізації функцій та підтримку користувачів. Конфігурація однакова (ті ж файли конфігурації, той самий синтаксис).

Я використовую цю схему:

• господарі,
• групи господарів,
• віддалені послуги,
• місцеві служби.

У кожної організації є свій файл. Окрім шаблонів, ви завжди можете зробити ваш конфігуратор чистішим легше для читання. Наприклад, у вас може бути середнє завантаження, дисковий простір, пам'ять на кожному хості. Тож створити загальний шаблон і використовувати його досить просто і зручно.

Ви не можете ускладнити конфігурацію із створенням груп. Як кажуть asciiphil, ви створюєте файл або можете визначати ті самі групи в деяких існуючих файлах, як (hosts.cfg або що-небудь раніше), і ви створюєте цей файл або ви скажете нагіосам, що цей файл активний (це якщо ви створюєте новий файл, якщо ні, він уже активний), і це у файлі nagios.cfg, куди ви ставите шлях новоствореного файлу. "cfg_file = / usr / local / nagios / тощо / об'єкти / NEW_FILE.cfg"

Інша справа - це просто створення груп залежно від вашої інфраструктури. Якщо, наприклад, у мене є Linux та Windows сервер, я зроблю дві різні групи: одна для Linux та інша для Windows. Так само і з послугами. Залежно від того, як ви хочете налаштувати та бачити під час моніторингу на моніторі, як ви хотіли б бачити їх як групи.

А для файлу чи частини, як зробити групу, це просто.

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

А в конфігурації хоста / або якщо ви використовуєте шаблон або якщо ви вже визначили шаблон хостингу або службу та використовуєте використання, ви можете автоматично повідомити всі хости / вікна або Linux, щоб вони були членами визначеної створеної вами групи хостів.