Найкращий інструмент для моніторингу резервних копій тощо і тенденції статистики з цих даних [закрито]

Я провів деякі дослідження нагіосів, opennms та zenoss, але не впевнений, що знайшов те, що шукаю.

Основна рушійна сила для мене зараз - це можливість контролювати резервні копії. Сюди входять mysql, mssql та, зрештою, деякі резервні копії файлової системи.

У нас є інструмент, який завершує процес резервного копіювання для цих різних систем та збирає статистику. Отже, такі предмети, як:

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

Я хочу мати можливість A) мати сповіщення, якщо завдання не виконуються згідно з графіком B) мати змогу встановлювати порогові значення для статистики, яка спричинить сповіщення C) я хочу мати можливість трендувати та графікувати статистику

Планую надсилати цю інформацію в моніторингову програму через HTTP POST. Або додаток для моніторингу також може витягнути його з файлу журналу.

Однак у нас будуть інші процеси з іншими "довільними" (з точки зору системи моніторингу) статиками, які захочуть контролювати та тренувати, тому гнучкість дуже важлива.

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

Дякую.

Наступні дії :

Я вирішив спробувати наступне в заданому порядку:

• Zabbix: здавалося, що більше "на одному місці", ніж інші, і його було легко встановити в Ubuntu Lucid RC
• opsview
• Nagios w / nagvis, pnp4nagios, nagiosgraph
• кактуси без вбудованого модуля
• Мунін: трохи страшно від простоти, але це може виявитися благом у довгостроковій перспективі

Повідомляю, як тільки я прийняв рішення, це може пройти деякий час, поки це не відбудеться.

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

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

check_file може відстежувати розмір та вміст файлів (використовуючи регулярні вирази), тому ви можете виводити статистику резервного копіювання у файл та стежити за ними.

Єдине, чого ви не отримаєте від Nagios - це тренди та графіки; Я рекомендую для цього подивитися Муніна , оскільки його просто налаштувати і, як і у Nagios, є стеки доданих плагінів.

це має бути досить легко встановити за допомогою zabbix.

встановлення користувальницьких (і дуже потужних) порогових значень легко - ви можете написати будь-який вираз, який вам подобається, так що на кшталт "сповістити мене, якщо більше ніж 3 з цих 5 серверів не мали успішної резервної копії". ви також можете використовувати 6 різних рівнів суворості та ескалації для досягнення гнучких повідомлень та оповіщення.

zabbix має вбудовані можливості зберігання та візуалізації даних - всі дані зберігаються в базі даних, а для побудови єдиного показника вам не потрібна ніяка конфігурація - ви просто отримаєте графік для нього "безкоштовно". для тривалого зберігання та тенденції в розрахунку на середню годину.

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

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

Звичайно, можливий загальний моніторинг операційних систем, додатків, snmp та ipmi пристроїв тощо.

виконання

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

 function handle {
         echo Error
         error problem occured
 }
 set -e
 trap handle ERR

тому я отримую помилку в журналах, коли будь-яка з команд [наприклад, mysqldump або rsync] не вдається.

всі резервні копії потрапляють у сховище rdiff, тому я збільшую п’ять днів.

всі резервні копії передаються за допомогою rsync на центральний сервер зберігання даних.

на сервері зберігання всі резервні копії перевіряються щодня і після успішної перевірки даних на локальному диску вони копіюються на зовнішній привід usb.

перевірка

backupninja.log на всіх серверах контролюється nagios. я перевіряю, чи містять вони лише повідомлення про помилку та інформацію. все інше запускає оповіщення.

кожна резервна копія "торкається" тестового файлу, наявність та свіжість якого відстежується на центральному сервері резервного копіювання за допомогою нагіосів.

крім того, більш критичні звалища sql перевіряються на їх розмір [не тільки свіжість] та повноту [наприклад, наприкінці mysql сміттєвих відвалів я очікую свіжих міток часу в

- Дамп завершено 2010-04-22 23:21:02

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

usb-диски обертаються щотижня і зберігаються в автономному режимі, про всяк випадок. це може бути надмірним для більшої кількості даних, але прекрасно працює для ~ 300 ГБ повільно мінливих файлів / скидів.

тенденції

Я використовую простий користувацький плагін Munin для розміру ділянки diff / data для кожного сховища rdiff.

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

nagios може робити тренди, але вам потрібно вивести perfdata ( http://nagios.sourceforge.net/docs/1_0/perfdata.html ) у своєму плагіні. Якщо ви використовуєте pnp4nagios http://docs.pnp4nagios.org/pnp-0.4/start тоді все буде рентгенографічного для вас.

Я виявив, що використовувати opsview http://www.opsview.org/ набагато простіше, ніж налаштувати nagios та pnp4nagios. Особливо, якщо ви єдиний адміністратор з розумом в Linux. Opsview - це нагіоси з великим вебуєм, що дозволяє майже всі дії веб-браузера. Оскільки це nagios, ви можете використовувати всі плагіни nagios, якими ви користувалися в минулому. Чудовий інструмент.

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

Я рекомендую OpenNMS . Пакет є повністю відкритим кодом, активно підтримується та регулярно удосконалюється. Для довідки я знайшов інформацію про їх конфігурацію wiki для моніторингу Symantec Backup Exec .

З їх веб-сайту ..

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

Розкриття інформації: Я тут не маю комерційного інтересу, але власник групи OpenNMS , згаданої вище "організації комерційних послуг, навчання та підтримки", є моїм другом.

Це можна зробити легко за допомогою Circonus ( http://circonus.com/ ). Ми регулярно імпортуємо такі показники за допомогою DTD Resmon XML.