Географічно розподілені, стійкі до відмов та "розумні" системи моніторингу додатків / хостів


12

Привітання,

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

Вимоги досить складні;

  • Немає жодної точки відмови. Дійсно. Я мертвий серйозний! Необхідно мати можливість переносити пошкодження одного / декількох вузлів, як "майстер", так і "працівник", і ви можете припустити, що жодне місце моніторингу ("сайт") не має в ньому декількох вузлів або знаходяться в одній мережі. Тому це, ймовірно, виключає традиційні методи HA, такі як DRBD або Keepalive.

  • Розподілена логіка, я хотів би розгорнути 5+ вузлів у декількох мережах, у кількох центрах обробки даних та на кількох континентах. Я хочу, щоб "Пташине око" переглядав мою мережу та програми з точки зору моїх клієнтів, бонусні бали за логіку моніторингу не зациклювались, коли у вас 50+ вузлів або навіть 500+ вузлів.

  • Необхідно вміти обробляти досить розумну кількість перевірок хоста / послуги, a la Nagios, для показників бальних парків передбачається 1500-2500 хостів і 30 послуг на хоста. Було б дуже приємно, якби додавання більше вузлів моніторингу дозволило вам масштабувати відносно лінійно, можливо, через 5 років я, можливо, буду шукати моніторинг 5000 хостів та 40 служб на хост! Додаючи з моєї примітки вище про "розподілену логіку", було б непогано сказати:

    • У звичайних умовах ці перевірки повинні виконуватися на $ n або n% моніторингових вузлів.
    • Якщо виявлено збій, запустіть перевірку на ще $ n або n% вузлів, співвіднесіть результати та використовуйте їх, щоб визначити, чи були виконані критерії для подання сповіщення.
  • Графіки та зручні функції управління. Нам потрібно відстежувати наші домовленості про домовленості та розуміння того, чи є наші «високодоступні» додатки до 24x7, дещо корисними. В ідеалі пропоноване рішення повинно складати звіти "поза коробкою" з мінімальними фафами.

  • Повинно мати надійну API або плагін для розробки замовлених чеків.

  • Потрібно чітко розуміти сповіщення. Я не хочу обов'язково знати (через SMS, о 3 ранку!), Що один вузол моніторингу вважає, що мій основний роутер не працює. Я дійсно хочу знати , якщо певний відсоток з них згоден , що що - то в стилі фанк відбувається;) По суті, я говорю тут про «Кворум» Логіка, або застосування здорового глузду до розподіленого божевілля!

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

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

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

Раді уточнити будь-які потрібні моменти. Ура, хлопці та дівчата :-)


2
Це дійсно дивно, я збирався задати подібне питання. На цьому тижні у нас були скарги клієнтів на відключення сайтів, але лише з певних місць. Наші системи оповіщення не виявили цих проблем. Ми зв’язалися з нашим провайдером, і вони підтвердили, що у деяких були деякі проблеми з хребтом. Тож мене теж цікавить рішення. Дякую!
splattne

І яке було остаточне рішення?
ewwhite

Відповіді:


4

насправді не відповідь, але деякі вказівки:

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

  • У мене були надмірні налаштування нагіосів, але в набагато меншому масштабі - 80 серверів, ~ 1 к сервісів. один виділений головний сервер, один підлеглий сервер витягує конфігурацію з головного через рівні проміжки часу кілька разів на день. обидва сервера охоплювали моніторинг одних і тих же машин, вони мали перехресну перевірку здоров'я між собою. я використовував nagios здебільшого в якості основи для виклику спеціальних перевірок продукту [купа завдань Cron, виконуючи сценарії, виконуючи "контроль штучного потоку", результати зберігання входять до sql, nrpe плагіни посуду перевіряють на успішні / невдалі виконання тих, хто за останні х хвилин]. всі працювали дуже гарно.

  • Ваша логіка кворуму звучить добре - трохи схожа на мої "штучні потоки" - в основному, продовжуйте, доповнюючи себе; -]. і nrpe просто перевірити якийсь прапор [або sql db зі статусом позначки часу], як це відбувається.

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

щоб відповісти на деякі запитання:

  • в моєму випадку моніторинг середовища був типовим налаштуванням ведучого-підлеглого (первинний sql або сервер додатків + гарячий режим очікування), а не головний майстер.
  • моє налаштування включало "фактор фільтрації людини" - групу резолюцій, яка була "резервною копією" для SMS-повідомлення. там уже була платна група техніків, які з інших причин мали 24/5 змін, вони отримали "перевірку нагіо-листів" як додаткове завдання, не надто навантажуючи їх. і вони відповідають за те, щоб переконатися, що db-admins / it-ops / app-admins посуд насправді встає та виправляє проблеми; -]
  • Я чув багато хороших речей про zabbix - для оповіщення та побудови тенденцій, але ніколи не використовував його. для мене munin робить трюк, я зламав просту плагіну Nagios, перевіряючи, чи є "червоний" [критичний] колір у списку серверів munin - лише додаткова перевірка. ви також можете прочитати значення з munin rrd-файлів, щоб зменшити кількість запитів, які ви надсилаєте на моніторовану машину.

1
@astinus - добре для розважливих сповіщень, я використовував користувацький сценарій сповіщення. замість того, щоб покладатися на нагіоси сповіщати поштою / пейджером, я зберігав повідомлення до fifo que і мав споживача, який розсилав повідомлення на основі користувацької логіки [на основі досить гнучких розкладів дзвінків тощо], додатково був деякий ліміт повідомлень, що надсилаються за годину, так що один не отримує 50 смс за короткий час. Я бачу подібні підходи в масштабніших масштабах - нагіос - це просто скелет, і люди сценаріюють навколо нього і фактично використовують все менше і менше його можливостей.
pQd

1
Що стосується ієрархії, то, що я маю на даний момент, є цілком "модульна" настройка Nagios, де ваш etc / каталог містить "основну" конфігурацію, яка поділяється (і однакова) на всіх хостах, а потім etc / module / $ NAME (тобто : Пошта, веб, мережа, DNS), який на 100% переноситься між серверами. Включити з cfg_dir =) Ви вводите будь-які конкретні модулі команди, плагіни та все до цього каталогу. Зробити> 1 сервер запустити ці перевірки досить просто, оскільки ви просто скопіюєте модуль у стільки скриньок Nagios, скільки потрібно, однак ще раз, логіка оповіщення спричиняє проблеми :-)
nixgeek

1
@ астинус №2. у моєму випадку налаштування реплікації master-> slave відбувається кожні 6 год. якщо майстер просто помирає [відключення електроенергії тощо] - раб сповістить усіх про те, що господар помер [перехресний перегляд між серверами]. можна уявити інший сценарій - коли господар помирає через неправильну конфігурацію. якщо це трапиться до 5 хв до того, як конфігурація синхронізується з веденою службою - буде повідомлення. якщо це безпосередньо перед синхронізацією конфігурації - на жаль, ми не маємо системи моніторингу. "хто буде дивитися на сторожа"? ну, можливо, ще один дуже простий нагіос.
pQd

1
@pQd - цікаво, я погоджуюся, що реалізація логіки у користувацьких скриптах сповіщення - це, мабуть, шлях. Однак стає досить складно уникнути дублювання сповіщень від 2+ хостів, якщо ви скажете 50 хостингу для моніторингу, і я ще не бачу, щоб хто-небудь (публічно) вклав свою спільну логіку в належну систему передачі повідомлень, як Кролик або Амазонка SQS.
nixgeek

1
@ astinus # 3, у моєму випадку це рішення "рівня 8" [моделі iso osi]: первинні нагіоси надсилали sms'es людям за дзвінками + поштою до 24/5 "групи резолюцій", а 2-го нагіосу - лише розсилкою " роздільна група '. ця група повинна була фільтрувати дублікати перед ескалацією;
pQd

1

Те, що ви просите, звучить дуже схоже на те, що Шинкен зробив для Nagios.

Шинкен - переписувач Nagios.

  • Сучасна мова (Python)
  • Сучасна система розподіленого програмування (Pyro)
  • Моніторингові сфери (багатожиткові), HA, запасні частини
  • API Livestatus
  • Плагін Nagios сумісний
  • Рідне виконання NRPE
  • Ділова критичність об'єктів
  • Правила бізнесу можуть застосовуватися до стану об'єктів (керування кластером або наявністю пулу)
  • Для графіки можна використовувати PNP4nagios на основі Graphite або RRDtool
  • Стабільний і розгортається у великих середовищах
  • Великі розгортання можуть зв'язати його з Splunk для подання звітів або подивитися на Graphite, де RRDtool не підходить.

Це має бути їжею для роздумів.

Ура

Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.