Як ви не відстаєте від конфігурацій Nagios / Capistrano під час використання EC2?

Я використовую Amazon EC2 для свого мобільного додатку. Залежно від завантаження програми в даний момент часу, я можу породити нові екземпляри, а потім зняти їх, коли завантаження буде меншим, щоб заощадити витрати.

Як можна слідкувати за конфігураціями Nagios для такого динамічного середовища? Якщо справа стосується керованого обладнання, файли конфігурації передбачувані. У цьому випадку потрібно буде додати Nagios, Capistrano та купу інших файлів конфігурації. Capistrano повинен знати, де розгорнути нову збірку для сервера додатків. Nagios потрібно знати, щоб видалити наявний екземпляр або додати новий екземпляр для моніторингу. Нагіос також повинен знати, чи навмисно було знято вузол чи хост не працює через помилку.

Як це робиться з чудовим світом VPS / динамічних примірників?

Ми використовуємо інструмент управління конфігурацією (Chef у нашому випадку), який записує конфігурацію Nagios з інформації про вузол.

Написав мій власний невеликий набір скриптів для php, які записують конфігурації nagios у файл. Nagios легко, тому що це лише текстовий файл, тому все, що вам потрібно зробити, - це створити шаблон для кожного типу сервера. Потім, коли сервер починає додавати файл за допомогою шаблону. Єдині дані, що змінюються у файлі, - це ip та ім'я хоста.

Для більш статичних серверів я створив сценарій, який працює ec2-describe-instancesі створює файл для кожного повернутого екземпляра. Кожен екземпляр позначений тегом: Призначення = XXXX, тому я знаю, який шаблон застосувати.

Для наших груп автоматичного масштабування ми встановлюємо сповіщення за допомогою as-put-notification-configurationкоманди, яка надсилає повідомлення в чергу SQS. PHP-скрипт виконується за допомогою crontab. Коли сценарій виконується, він перевіряє чергу на наявність нових серверів. Щоразу, коли він знаходить новий сервер, він створює новий файл. Те саме відбувається, коли сервер видаляється. Можливо, простіше використовувати шеф-кухаря або щось подібне, якщо ви його вже використовуєте, але якщо ви цього не можете, ви можете написати просту службу php, як мою, за кілька днів.

Ми використовуємо Opsview , який є ще однією базою даних nagios + база + rest-api обгортка. Я не знаю, чи це найкраще рішення для всіх (або навіть нас), але воно дозволяє нам динамічно налаштувати сервер Nagios через простий API REST з вузла (або іншого адміністративного вузла), коли він з'являється, і видалити його з конфігурація, коли це зроблено. Я використовую визначення шаблонів хостів як частину маніфесту ляльок сервера Opsview (/ Nagios), а контрольовані хости просто реєструються в ньому та приєднуються до правильного шаблону хоста як частини їхнього маніфестного лялечки.

Більш "загальний" підхід, який повинен працювати майже з усім, навіть з оригінальними Nagios та його статичними файлами, - це Puppet Stored Configuration - це дозволяє вам щось скриптувати, щоб налаштувати будь-який інструмент, який ви хочете, однак вам подобається на основі інформації, яку збирає лялька її маніфест.

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

Пара способів.

• Використання попередньо налаштованих шаблонів Amazon EC2.

• Використання маріонеткового маніфесту з варіабелізованими шаблонами.

• Налаштуйте VPN між вашою мережею nagios та Amazon VM. У нас працює нагіос і відстежують всі наші випадки амазонки. Нам навіть не потрібна гумка-ip. Ми використовуємо openvpn для VPN.

• Створіть Nagios, який прослуховує зовнішню команду, та оновіть її конфігурацію відповідно. Врешті-решт машини можуть зареєструвати, скасувати реєстрацію, призупинити, відновити їх самостійно на Nagios.

У мене немає срібної кулі для вирішення цієї проблеми з нагіосами. Але для capistrano є capify-ec2 , розширення для capistrano, яке вирішує списки ролей сервера, використовуючи можливості тегів Amazon.