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

Shinken
Згідно з офіційним сайтом, Shinken — фреймворк моніторингу; переписаний з нуля на пітоні Nagios Core, з поліпшеною підтримкою великих оточень більш гнучкий.
Масштабованість
Згідно документації, кожен тип використовуваних процесів може запускатися на окремому хості. Це дуже корисна можливість, оскільки ви можете захотіти мати базу даних в найдешевшому місці, процеси збору інформації в кожному датацентрі, і процеси розсилки повідомлень ближче до свого фізичного розташування. Користувач Shinken на схемі щасливий, це точно є доброю ознакою:
Shinken simple distributed architecture
Ця система також має готову конфігурацію для міжрегіонального моніторингу, звана Realms (Сфери).
Тут ви можете помітити дещо дивовижне: інформація збирається в регіональні бази даних, а не в один майстер-базу. Також існує менша різновид конфігурації зі сферами для менших розподілених конфігурацій, яка вимагає всього одну базу даних і кілька хостів для установки:
Shinken simple multi-regional distributed architecture
Ще однією больовою точкою при оцінці масштабованості є відмовостійкість. Цю інформацію я процитую з документації:
Ніхто не ідеальний. Сервер може впасти, як і додаток, тому адміністратори мають підміни: вони можуть взяти конфігурацію впали елементів і переподнять їх. На поточний момент єдиний процес, який не має підміни — Арбітр, але в майбутньому він буде доопрацьований. Армибр регулярно перевіряє, чи доступні всі інші процеси, і якщо планувальник або інший процес мертві, він посилає їх конфігурацію на іншу ноду, визначену адміністратором. Всі процеси сповіщається про зміну, так що вони можуть використовувати нову ноду для доступу до процесу, і не будуть намагатися використовувати зазбоившую. Якщо нода була втрачена через мережевих проблем, і повернулася в лад, Арбітр помітить це і попросить ноду, яка виступала заміною, скинути свою тимчасову роль.
Інтеграція з системами управління конфігурацією
Автоматичне знаходження хостів і сервісів добре покривається документацією, і, оскільки конфігурація зберігається в файлах, ви досить просто можете генерувати її з допомогою Chef\Puppet, грунтуючись на інформації, наявній в системі конфігурації (наприклад, PuppetDB).
Логування дій
Оскільки конфігурація зберігається в файлах, ви можете використовувати наявні інструменти типу системи контролю версій (Git, Mercurial) для відстеження змін та їх власників. В документації я не знайшов жодних підтверджень того, що Shinken записує куди-небудь дії користувача у веб-інтерфейсі.
UI
Shinken UI
Shinken WebUI за запевненням використовують його людей добре показав себе при роботі з тисячами машин і десятками груп.
Недоліки
Прошерстів документацію, я не знайшов видимих недоліків. Єдина річ, яка мене бентежить, це стрімка розробка минулого і дуже повільний темп комітів в сьогоденні: близько 40 цього року, більшість — вливання пулл-реквестов з багфиксами. Система або занадто гарна для подальшого розвитку (чого не буває в природі, навіть такі старі, як vim та emacs отримують нові релізи), або тепер це ще один відкритий проект з недостатньо великим співтовариством або проблемами з мейнтейнером — це така інформація, яку хотілося б знати до початку використання такої комплексної речі, як система моніторингу.
Frédéric Mohier, колишній коли-то в команді розробки Shinken люб'язно надав інформацію з цього питання: більше року тому декілька розробників з команди, будучи незгодними з політикою розробки, покинуло проект і зробило форк, названий Alignak, в даний момент активно розробляється, перший стабільний реліз (1.0) планується на грудень 2016.
Посилання
Sensu
Sensu — фреймворк для моніторингу (або платформа, як вони самі про себе кажуть), але не готова система моніторингу.
Її сильні сторони включають:
  • Інтеграція з Puppet \ Chef — визначайте, що перевіряти, і куди відправляти повідомлення прямо у вашій системі управління конфігурацією
  • Використання наявних технічних рішень там, де це можливо, замість винаходу велосипеда (Redis, RabbitMQ)
Sensu витягає події з черги і виконує на них обробники, от і все. Обробники (Handlers) можуть посилати повідомлення, виконувати що-то на сервері, або робити що завгодно ще, чого ви їх навчите.
Масштабованість
Sensu має гнучку архітектуру, оскільки кожен компонент може бути продубльований і замінений кількома шляхами. Приклад простий відмовостійкої системи описаний в наступній презентації; ось загальна схема:
Sensu architectural diagram
HAProxy і Redis-sentinel ви можете побудувати систему, в якій, за наявності хоча б однієї живої машини кожного типу (Sensu API, Sensu Dashboard, RabbitMQ, Redis) моніторинг буде продовжувати працювати без будь-якого ручного втручання.
Інтеграція з системами управління конфігурацією
Вбудована (Puppet, Chef, EC2?!) але тільки в платній версії, що погано, особливо якщо у вас тисячі серверів і ви не хочете платити за те, що має безкоштовні аналоги.
Логування дій
Вбудоване, проте тільки в платній редакції.
UI
Uchiwa screenshot
Інтерфейс за умовчанням для Sensu, Uchiwa, має багато обмежень. Він виглядає занадто простим для оточення з тисячами хостів, які мають великий розкид по ролям. Платна версія має свій власний дашборд, однак він не сильно відрізняється від безкоштовної редакції, і тільки додає кілька виключених з-коробки можливостей відкритої версії.
Недоліки
  • Відсутність історичної інформації і дуже обмежені можливості створення перевірок, заснованої на ній;
  • Підхід "зроби сам" — немає готового моніторингу, який можна було б включити для вашої системи відразу після установки;
  • Агрегування подій нетривіально;
  • Замудреная відправка повідомлень, що страшно (тому що це та частина системи, яка повинна бути простою і надійною) — неправда, я отримав неправильне враження від документації, спасибі x70b1 за роз'яснення;
  • Шлях "ми не хочемо винаходити колесо" має свої обмеження, які можуть бути вам знайомі, якщо ви коли-небудь використовували подібні системи (в моєму випадку, це була система моніторингу Prometheus, яка залишала ряд функцій на відкуп користувачеві, наприклад, авторизацію\аутентифікацію\ідентифікацію).
Посилання
Icinga 2
Icinga це форк Nagios'а, у другій версії переписаний з нуля. На відміну від Shinken, цей живий, часто оновлюється проект.
Масштабованість
Загальна архітектура:
Icinga 2 architecture
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
Icinga 2 web interface
IcingaWeb2 виглядає непоганим UI з великою кількістю додатків під різні потреби. З того, що я бачив, він виглядає найбільш гнучким і розширюваним, в той же час з коробки підтримуючи всі можливості, які ви можете очікувати.
Недоліки
Єдиним недоліком, який я зустрів, є складність початкової настройки. Непросто зрозуміти погляд Icinga на моніторинг, якщо ви до цього використовували щось абсолютно інше, як у моєму випадку, Zabbix.
Zabbix
Zabbix — стабільна і надійна система моніторингу із сталою швидкістю розвитку. Він має величезне співтовариство користувачів і більшість питань, якими ви задастеся, вже десь отвечены, так що вам не доведеться зайвий раз хвилюватися, а можливо те чи інше в Zabbix.
Масштабованість
Сервер працює з єдиною базою даних, і незалежно від ваших дій, з будь-якими іншими ресурсами на руках (пам'ять, мережу, CPU), ви в якийсь момент упретеся в обмеження IO на диску, що використовується базою даних. З 6000 IOPS Amazon ми підтримуємо близько двох тисяч nvps, нових значень в секунду, що непогано, але все ж залишає бажати кращого. Проксі і partitioning бази даних покращує продуктивність, однак з точки зору отказаустойчивости ви все ще маєте одну-єдину БД, яка є точкою для відмови всієї системи.
Інтеграція з системами управління конфігурацією
Zabbix слабо підготовлений для різноманітного оточення, яке управляється системою управління конфігурацій. Він має вбудовані можливості для low-level виявлення хостів і сервісів, але вони мають свої обмеження і не мають прив'язки до системи конфігурації. Єдина можливість для подібної інтеграції — власне рішення, що використовує API.
Логування дій
Zabbix добре логирует дії користувачів, за винятком одного сліпої плями: зміни, зроблені через API, більшою частиною не логгируются, що може бути або може не бути проблемою для вас. Ще одна річ, яку я хотів би зазначити, це те, що всі проблеми з Zabbix записані десь у баг-трекері, і, якщо вони отримують достатньо уваги з боку співтовариства, то рано чи пізно усуваються.
UI
Dashboard is a main screen of Zabbix
UI Zabbix'а зручний і включає в себе багато можливостей. Зворотна сторона — він практично не розширюємо, ви або миритися з тим, що пропонує вам стандартний dashboard, або створюєте свій власний. Доробка стандартного UI є дуже нетривіальним завданням із-за її складності.
Недоліки
  • Тільки базова аналітика про те, що відбувається в даний момент (не в плані поточних проблем, а частоти походження та подібної інформації). Ситуація сильно покращилася з появою "топ 100 стріляючих тригерів" 3.0;
  • Налаштування планових робіт (maintenance), на відміну від систем, заснованих на Nagios, не може бути виставлена на рівні тригера, і була досить складною до недавньої переробки 3.2;
  • Генерація алертів з-коробки залишає бажати кращого (що, втім, є проблемою всіх до єдиної систем моніторингу). У нашому випадку довелося розробити зовнішню систему аггрегации алертів (можливо, коли-небудь вона буде опублікована в opensource);
  • Розслідування проблем з продуктивністю без відповідного досвіду перетворюється в безлад, тому що у вас є один неподільний сервер, який вам необхідно діагностувати.
Disclaimer
Це довга запис з великою кількістю картинок і ще більшою кількістю тексту. Тут ви не знайдете однозначної відповіді на прості запитання на кшталт "що краще", але інформацію для відповіді на ці питання, спираючись на свій досвід і бажання. Я розглядаю умови роботи у Linux та стеження за Linux-хостами, тому підтримка системою різних платформ в розрахунок не приймалася. Також за умову приймалося вимога можливості стежити за тисячами машин і тисячами сервісів.
На мою думку, тільки Zabbix і Icinga 2 є достатньо зрілими для використання в "энтерпрайзе", головне питання, яке повинен поставити собі той, хто обирає систему — яка філософія моніторингу йому ближче, оскільки обидві вони дозволяють отримати один і той же результат, використовуючи абсолютно різні підходи.
Джерело: Хабрахабр

0 коментарів

Тільки зареєстровані та авторизовані користувачі можуть залишати коментарі.