Порівняння систем моніторингу: Shinken vs Sensu vs Icinga 2 vs Zabbix

Shinken

Згідно з офіційним сайтом, Shinken - фреймворк моніторингу; переписаний з нуля на пітоні Nagios Core, з поліпшеною підтримкою великих оточень і більш гнучкий.

Масштабування

Згідно з документацією, кожен тип процесів, що використовуються, може запускатися на окремому вузлі. Це дуже корисна можливість, оскільки ви можете захотіти мати базу даних в найдешевшому місці, процеси збору інформації в кожному датацентрі, і процеси розсилки повідомлень ближче до свого фізичного розташування. Користувач Shinken на схемі щасливий, це точно є хорошою ознакою:

Ця система також має готову конфігурацію для міжрегіонального моніторингу, звана Realms (Сфери).

Тут ви можете помітити дещо дивовижне: інформація збирається в регіональні бази даних, а не в одну майстер-базу. Також існує менший різновид налаштувань зі сферами для менших налаштованих конфігурацій, яка вимагає всього одну базу даних і кілька хостів для установки:

Ще однією больовою точкою при оцінці масштабованості є відмовостійкість. Цю інформацію я процитую з документації:

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

Інтеграція з системами керування конфігурацією

Автоматичне знаходження вузлів і сервісів добре покривається документацією, і оскільки налаштування зберігається у файлах, ви досить просто можете створювати її за допомогою Chef\Puppet, ґрунтуючись на інформації, що вже є в системі конфігурації (наприклад, PuppetDB).

Логування дій

Оскільки налаштування зберігається у файлах, ви можете використовувати наявні інструменти типу системи контролю версій (Git, Mercurial) для відстеження змін та їх власників. У документації я не знайшов жодних підтверджень того, що Shinken записує будь-які дії користувача в веб-інтерфейсі.

UI

Shinken WebUI за запевненням людей, що використовують його, добре показав себе при роботі з тисячами машин і десятками груп.

Недоліки

Прошерстивши документацію, я не знайшов видимих недоліків. Єдина річ, яка мене бентежить, це стрімка розробка в минулому і дуже повільний темп коммітів в сьогоденні: близько 40 цього року, більшість - вливання пулл-реквестів з багфіксами. Система або дуже хороша для подальшого розвитку (чого не буває в природі, навіть такі старички, як vim і emacs отримують нові релізи), або тепер це ще один відкритий проект з недостатньо великим співтовариством або проблемами з мейнтейнером - це така інформація, яку хотілося б знати до початку використання такої комплексної речі, як система моніторингу.

Frédéric Mohier, який був колись у команді розробки Shinken люб'язно надав інформацію з цього питання: більше року тому кілька розробників з команди, будучи незгодними з політикою розробки, покинуло проект і зробило форк, названий Alignak, в даний момент активно розробляється, перший стабільний реліз (1.0) планується на грудень 2016.

Посилання

• Detection and Handling of State Flapping — Shinken Manual

Sensu

Sensu - фреймворк для моніторингу (або платформа, як вони самі про себе говорять), але не готова система моніторингу.

Її сильні сторони включають:

• Інтеграція з Puppet\Chef - визначайте, що перевіряти, і куди надсилати сповіщення прямо у вашій системі керування конфігурацією
• Використання наявних технічних рішень там, де це можливо, замість винаходу велосипедів (Redis, RabbitMQ)

Sensu витягує події з черги і виконує на них обробники, ось і все. Обробники (Handlers) можуть надсилати повідомлення, виконувати щось на сервері, або робити що завгодно ще, чого ви їх навчите.

Масштабування

Sensu має гнучку архітектуру, оскільки кожен компонент може бути продубльований і замінений кількома шляхами. Приклад простої відмовостійкої системи описано в наступній презентації; ось загальна схема:

З HAProxy і Redis-sentinel ви можете побудувати систему, в якій, при наявності хоча б однієї живої машини кожного типу (Sensu API, Sensu Dashboard, RabbitMQ, Redis) моніторинг буде продовжувати працювати без будь-якого ручного втручання.

Інтеграція з системами керування конфігурацією

Вбудована (Puppet, Chef, EC2?!) але тільки в платній версії, що погано, особливо якщо у вас тисячі серверів і ви не хочете платити за щось, що має безкоштовні аналоги.

Логування дій

Вбудоване, однак тільки в платній редакції.

UI

Типовий інтерфейс Sensu, Uchiwa, має багато обмежень. Він виглядає занадто простим для оточення з тисячами хостів, які мають великий розкид по ролях. Платна версія має свій власний дашборд, однак він не сильно відрізняється від безкоштовної редакції, і тільки додає кілька вимкнених з-коробки можливостей відкритої версії.

Недоліки

• Відсутність історичної інформації і дуже обмежені можливості створення перевірок, заснованої на ній;
• Підхід «» зроби сам «» - немає готового моніторингу, який можна було б включити для вашої системи відразу після установки;
• Агрегування подій нетривіально;
• Замудрена відправка повідомлень, що страшно (тому що це та частина системи, яка повинна бути найпростішою і надійною) - неправда, я отримав неправильне враження від документації, спасибі x70b1 за роз'яснення;
• Шлях «» ми не хочемо винаходити колесо «» має свої обмеження, які можуть бути вам знайомі, якщо ви коли-небудь використовували подібні системи (у моєму випадку, це була система моніторингу Prometheus, яка залишала ряд функцій на відкуп користувачеві, наприклад, авторизацію\автентифікацію\ідентифікацію).

Посилання

• Sensu — What I've Learnt
• MOTD integration

Icinga 2

Icinga це форк Nagios'a, у другій версії переписаний з нуля. На відміну від Shinken, цей живий проект часто оновлюється.

Масштабування

Загальна архітектура:

Icinga 2 має добре продуману схему розподіленого моніторингу. Єдиний мінус, який я виявив при піднятті тестового кластера - складне початкове налаштування навіть найпростішої розподіленої схеми.

Інтеграція з системами керування конфігурацією

Інтеграція досить хороша, ось дві презентації за темою: The Road to Lazy Monitoring with Icinga 2 and Puppet от Tom de Vylder, и Icinga 2 and Puppet: Automated Monitoring от Walter Heck. Ключовою особливістю Icinga є зберігання конфігурації у файлах, що дозволяє легко генерувати конфігурацію засобами Puppet, що в моєму випадку вийшло, використовуючи PuppetDB як джерело інформації про всі вузли і сервіси.

Логування дій

Як я виявив, логування дій представлено в модулі director. Вбудованої підтримки аудиту в IcingaWeb2 в даний момент немає.

UI

IcingaWeb2 виглядає непоганим UI з великою кількістю доповнень під різні потреби. З того, що я бачив, він виглядає найбільш гнучким і розширюваним, в той же час з коробки підтримуючи всі можливості, які ви можете очікувати.

Недоліки

Єдиним недоліком, який я зустрів, є складність початкового налаштування. Непросто зрозуміти погляд Icinga на моніторинг, якщо ви до цього використовували щось зовсім інше, як, в моєму випадку, Zabbix.

Zabbix

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

Масштабування

Сервер працює з єдиною базою даних, і незалежно від ваших дій, з будь-якими іншими ресурсами на руках (пам'ять, мережа, CPU), ви в якийсь момент уперетеся в обмеження IO на диску, що використовується базою даних. З 6000 IOPS в Amazon ми підтримуємо близько двох тисяч nvps, нових значень в секунду, що непогано, але все ж залишає бажати кращого. Проксі і partitioning бази даних покращує продуктивність, однак з точки зору відмови ви все ще маєте одну-єдину БД, яка є точкою відмови для всієї системи.

Інтеграція з системами керування конфігурацією

Zabbix слабко підготовлений для різноманітного середовища, яке управляється системою управління конфігурацій. Він має вбудовані можливості для low-level виявлення хостів і сервісів, але вони мають свої обмеження і не мають прив'язки до системи конфігурації. Єдина можливість для подібної інтеграції - власне рішення, що використовує API.

Логування дій

Zabbix добре логує дії користувачів, за винятком однієї сліпої плями: зміни, зроблені через API, здебільшого не логгуються, що може бути або може не бути проблемою для вас. Ще одна річ, яку я хотів би згадати, це те, що всі проблеми з Zabbix записані десь у лід-трекері, і, якщо вони отримують достатньо уваги з боку спільноти, то рано чи пізно усуваються.

UI

UI Zabbix'a зручний і включає в себе багато можливостей. Зворотній бік - він практично не розширюємо, ви або змиряєтеся з тим, що пропонує вам стандартний dashboard, або створюєте свій власний. Доопрацювання стандартного UI є дуже нетривіальним завданням через його складність.

Недоліки

• Тільки базова аналітика про те, що відбувається в даний момент (не в плані поточних проблем, а частоти з походження і подібної інформації). Ситуація сильно покращилася з появою «» топ 100 стріляючих тригерів «» в 3.0;
• Налаштування планових робіт (maintenance), на відміну від систем, заснованих на Nagios, не може бути виставлена на рівні тригера, і була досить складною до недавньої переробки 3.2;
• Генерація алертів з-коробки залишає бажати кращого (що, втім, є проблемою всіх до єдиної систем моніторингу). У нашому випадку довелося розробити зовнішню систему аггрегації алертів (можливо, коли-небудь вона буде опублікована в opensource);
• Розслідування проблем з продуктивністю без відповідного досвіду перетворюється на безлад, тому що у вас є один неподільний сервер, який вам необхідно діагностувати.

Disclaimer

Це довгий запис з великою кількістю картинок і ще більшою кількістю тексту. Тут ви не знайдете однозначної відповіді на прості запитання на зразок «» що краще «», але інформацію для відповіді на ці запитання, ґрунтуючись на вашому досвіді і бажаннях. Я розглядаю умови роботи в Linux і стеження за Linux-хостами, тому підтримка системою різних платформ в розрахунок не приймалася. Також за умову приймалася вимога можливості стежити за тисячами машин і тисячами сервісів.

На мою думку, тільки Zabbix і Icinga 2 є досить зрілими для використання в "ентерпрайзі" ", головне питання, яке має поставити собі той, хто вибирає систему - яка філософія моніторингу йому ближче, оскільки обидві вони дозволяють отримати один і той же результат, використовуючи зовсім різні підходи.