Збір даних про продуктивність для короткочасних, ефемерних серверів

Ми створюємо стек програмного забезпечення для обробки медичних зображень, який зараз розміщується на різних ресурсах AWS. Як частина цієї програми, ми маємо кілька довготривалих серверів (бази даних, балансування навантаження, веб-додатки і т.д.). Збір даних про продуктивність на цих серверах досить простий - мій go-to-рецепт Nagios (для моніторингу/сповіщень) і Munin (для збору даних про продуктивність і відображення тенденцій) працюватиме нормально.

Однак, як частина цієї програми, ми постійно запускаємо та припиняємо обчислювальні екземпляри на EC2. У типовому використанні ці обчислювальні екземпляри запускаються, налаштовуються, отримують завдання з черги повідомлень, а потім приступають до роботи з обробкою цього завдання, яке займає від 15 хвилин до 8 годин. Після завершення роботи ці випадки припиняються, ніколи не будуть почуті знову.

Що таке гідна стратегія збору даних про ефективність цих короткочасних випадків?

Я не обов'язково потребую моніторингу на них - якщо вони не зможуть з будь-якої причини, наша програма виявить це і обробляє повторний запуск завдання на іншому прикладі або піднімає прапор, щоб адміністратор міг подивитися на речі. Тим не менш, він все одно буде корисним для збору інформації, як-от CPU (користувач, бездіяльність, iowait тощо), використання пам'яті, мережевий трафік, дані для читання/запису на диск і т.д. відстежувати ідентифікатор екземпляра машини, який виконує кожне завдання, і було б дуже корисно, щоб можна було шукати дані про продуктивність для конкретного ідентифікатора екземпляра для усунення несправностей і профілювання.

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

Зрештою, я думаю, що це вимагатиме моніторингу, який:

  • використовує базу даних (MySQL, SQLite тощо) для налаштування та зберігання даних
  • надає API для додавання/видалення хостів і служб

Чи є інші речі, про які я маю подумати при оцінці варіантів?

Можливо, я надмірно роздумую про це, і просто повинен запустити sar з інтервалом в 1 хвилину на цих короткочасних примірниках і зібрати файли sar db до завершення.

3

5 Відповіді

Zenoss має плагін EC2Manager, який автоматично додає всі ваші екземпляри EC2 (навіть у відкритій версії) та відстежує зміни EC2. Zenoss може бути більш важкою, ніж ви дійсно хочете, хоча.

2
додано
Хм, мені доведеться перевірити це. Я оцінив Zenoss багато років тому як альтернативу Nagios, але знайшов його дуже незграбним. Можливо, з того часу все покращилося.
додано Автор fisch2, джерело

Для ефемерних екземплярів Nagios не дуже підходить, оскільки вам доведеться постійно переписувати конфігураційні файли.

Нещодавно я досліджував, які "добре відомі/підтримувані" системи моніторингу добре підходять у таких ситуаціях.

Наступні системи моніторингу полегшують додавання/видалення хостів:

Я думаю, вам знадобиться якийсь центральний CMDB, щоб бути джерелом істини. Потім ви можете використовувати CMDB як джерело даних для Puppet/Chef/etc, який зможе налаштувати контрольовані хости та додати їх до сервера моніторингу.

1
додано

Якщо ви піклуєтеся про збір даних про продуктивність, а не про моніторинг, і ви хочете щось, що не вимагає налаштування кожного разу, коли примірник народжується або вмирає, collectd буде чудово підходити.

Налаштуйте один примірник як сервер, тобто плагін мережу , налаштований на отримання даних і плагін RRDtool налаштований для запису даних. Налаштуйте свої ефемерні екземпляри за допомогою будь-яких плагінів , які потрібно зібрати відповідні дані продуктивності та мережевий плагін, налаштований на передачу даних на сервер.

Оскільки ці екземпляри є нетривалими, потрібно змінити стандартний

Відродження і старе питання, я знаю, але я не зміг втриматися від включення.
додано Автор Kasper Holdum, джерело

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

Якщо ви використовуєте якісне рішення щодо вирівнювання навантаження в хмарі , що може бути практично більш корисним, ніж моніторинг за кожним екземпляром, оскільки балансування навантаження може зробити більш обгрунтоване рішення маршрутизації на основі кращих умов у реальному часі (наприклад, # з'єднання, час відповіді вузла/затримка, географічне розташування).

Однак ми прагнемо зробити те ж саме та потенційно інтегруватися з комерційним пакетом моніторингу використання. Інакше, Zenoss , здається, має консервоване рішення.

0
додано

Тут Zabbix був би відмінним вибором.

Легко налаштувати, і ви можете налаштувати автоматичну реєстрацію та виявлення, зібрати дані про продуктивність і очистити записи після X днів.

0
додано