Графічні рішення Nagios vs Munin / Кактуси / Ganglia

У мене налаштування сервера nagios для моніторингу ~ 30 серверів Windows. Я хочу додати кілька трендових діаграм. Я читав, що плагіни для графічного нагіосу є простими, і багато людей використовують окремі, окремі інструменти для побудови графіків / трендів.

Які обмеження щодо плагінів для графічного нагіоса порівняно з окремими продуктами, такими як ganglia / munin / кактуси?

Мене цікавлять конкретні функції та переваги, які пропонують окремі пакети, а плагіни для графічного нагіосу - ні.

враховуючи, що у вас вже є установка nagios, розгляньте nagiosgraph або pnp4nagios.

nagiosgraph та pnp4nagios роблять досить гарну роботу зі складання даних про продуктивність nagios. nagiosgraph має підхід до налаштування на основі параметрів, pnp4nagios має підхід на основі шаблонів.

• обидва автоматично виявляють нових хостів / послуг кожного разу, коли змінюється конфігурація nagios
• обидва роблять масштабування графіка
• обидва надають графіки, коли ви переходите мишею на конкретні хости / послуги
• обидва надають безліч способів нарізати і нарізати кубиками ваші дані
• обидва виявляють та графікують критичні та попереджувальні рівні, які ви вже визначили в нагіосах
• обидва можуть бути вбудовані безпосередньо в рамку nagios для безперебійної безперебійної навігації від поточного стану до історії та назад

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

установка не тривіальна, але й не складна. багато залежить від того, наскільки ви хочете налаштувати речі. наприклад, nagiosgraph є 'install.pl' або 'rpm -i nagiosgraph.rpm' або 'dpkg -i nagiosgraph.deb'. pnp4nagios є './configure; зробити; зробити встановлення '.

n2rrd також може виконати деякі з цих речей, але це не так відшліфовано і вимагає більше роботи для налаштування.

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

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

одна фінальна записка. У тренді насправді дві частини: збір даних та відображення даних. якщо ви використовуєте окрему графічну систему, а не розширюєте існуючу установку nagios, то, можливо, вам доведеться встановити додаткові компоненти на ваші машини Windows, щоб збирати дані.

Я погоджуюся з рисьманом. NAGIOS призначений для отримання негайних якісних даних (це в порядку X чи ні?); munin - це історичні кількісні дані (наскільки повна X зараз, і наскільки повною вона була в цьому році?). Всі мої установки NAGIOS, деякі з яких контролюють кілька сотень служб, пов'язані з системами munin для здійснення кількісного моніторингу.

Зауважте також, що мунін має спеціальні гачки для введення даних у NAGIOS. Він розуміє концепцію ПОГОРОДЖЕННЯ та КРИТИЧНИХ порогових значень, і там, де потрібне повідомлення (і перегляд на "великій дошці" NAGIOS), дуже просто мати єдину змінну munin, яка інформує про стан єдиної служби NAGIOS.

Звичайний робочий процес полягає в тому, що ніхто не дивиться на графіки munin, поки NAGIOS не попередить, що поріг був порушений, але тоді графіки муніну стають неоціненними для з'ясування того, чи щось з часом повільно наростає, або це нестандартне - збільшення темпу, або ми маємо щотижневий цикл "вгору-вниз", який повільно збільшується в амплітуді, або що.

Як каже рись, шлях UNIX - це "одна задача, один інструмент". Створення ланцюжка інструментів munin та NAGIOS дуже добре працює для мене, щоб забезпечити кількісний та якісний моніторинг, а також повідомлення. Він також має явну перевагу зберігання інтерфейсів в чистоті: коли ви дивитеся на NAGIOS, ви бачите просте уявлення про те , як добре все працює прямо зараз , без будь - яких історичних даних захаращують вигляд; Коли ви дивитесь на munin, ви бачите історичну інформацію, що стосується питання, готового до вашого аналізу, без помилок "хост вниз" або "sshd не буде говорити зі мною", що переповнює погляд.

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

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

На переповнення стека ми використовуємо n2rrd, який є плагіном Nagios для графічних даних про продуктивність. Я певною мірою погоджуюся з lynxman, що він має велике хакерське відчуття.

Однак:

• За допомогою n2rrd ви можете змусити кактусів робити графіки на основі даних замість rrd2graph.cgi, що постачається з n2rrd
• n2rrd з rrd2graph.cgi підтримує масштабування
• Щодо складних сукупних графіків - ви в основному маніпулюєте графіками rrd вручну і можете робити з ними все, що завгодно.

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

У мене є кілька прикладів цих графіків у моєму нещодавньому Деякі поради щодо кращої публікації про помилки сервера графіків RRD . Також сторінка n2rrd включає як демонстрацію кактусів, так і rrd2graph.

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

Я вимагаю точних даних, а показ даних rrd не є точним - нормалізується! Для більшості користувачів це добре, оскільки для початку вони не використовують дуже точні дані. Вони використовують дані, частота вибірки яких часто становить хвилину або більше, і це не дасть вам дуже точного опису того, що відбувається. Це також означає, що якщо у вас десь є шип у ваших даних, ви його ніколи не побачите.

Врахуйте це - скажімо, ваша мережа Gb гуде при швидкості близько 10 Мб / сек, і раптом протягом декількох хвилин спостерігається шип 100 Мб / сек. Також зауважте, якщо це був лише 30-секундний шип, ви, можливо, навіть не бачили його зі швидкістю вибірки декількох хвилин. Якщо ви подивитеся на дані за день, то цей «сплеск» може відображатися лише як 15 Мб / сек, хоча фактичне значення також залежить від ряду інших факторів. Також існує велика ймовірність, що ви вважаєте, що ваша мережа є щасливою, коли її немає!

Що ще більше засмучує мене - це нормалізовані дані до фізичної ширини графіка та діапазону осі x. Що це означає, що той колосок, про який я говорив, ви не бачили? Якщо ви збільшуєте його, магічно з'являється! Я буду дотримуватися gnuplot - графіки можуть бути не такими гарними, але вони суцільні, і gnuplot ніколи не змінює дані перед їх відображенням.

-знак

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