Стратегії моніторингу інфраструктури

Останнім часом я стикаюся з деяким простоєм на деяких сайтах Drupal, які я розгорнув. Я б хотів підходити до проблеми активно, а не реагувати на ті простої шляхом перезавантаження служб або самого сервера. Я читав про такі інструменти для моніторингу, як nagios, munin, кактуси тощо, щоб відстежувати стан здоров'я вашого сервера / інфраструктури, але я його ще не пробував у виробництві. Я маю справу з Drupal майже в 99% разів, і я хотів би дізнатися пропозиції щодо моніторингу рівня сервера та моніторингу рівня Drupal (код програми).

В основному, я хотів би, щоб мене повідомили, коли завантаження сервера велике, можливо, було б вказано на винуватця (або жертву), щоб я міг приймати обгрунтовані рішення. Я також хотів би знати, що люди використовують для моніторингу рівня Drupal (наприклад, надсилання електронної пошти), коли є помилка / попередження PHP. (Що відбувається, коли сервер електронної пошти не працює?)

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

• Дроптор

• Нова Реліквія ( Acquia використовує її для своїх клієнтів)

Обидва - це комерційні підходи SaaS, з безкоштовними обмеженими варіантами спробувати послугу.

Також є параметр моніторингу з відкритим кодом Zabbix зі своїм модулем Drupal http://drupal.org/project/zabbix , але тоді ви повинні налаштувати і створити сам сервер.

Усі ці параметри мають свої модулі Drupal для надсилання інформації про сервер та інформацію про drupal на сервер монітора.

ОНОВЛЕННЯ. Мунін також має специфічний модуль Drupal , який має 2.x відділення на базі Друша.

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

Але ризикуючи, що це перетвориться на питання щодо рекомендацій щодо покупок, послуга, яку я використовую для перелічених вами вимог, - це Pingdom :

• Повідомляє, якщо сайти працюють (звичайно)
• Виміряє, скільки часу потрібно на реагування
• Виміряє чутливість та доступність на будь-якому користувальницькому порті TCP / UDP
• Перевірка наявності електронної пошти
• Дозволяє використовувати власні запити HTTP, дозволяючи перевірити різні аспекти вашої програми
• Обширна звітність
• Моніторинг у всьому світі, і вони додають ще близько десятка сайтів моніторингу кожні кілька місяців

Ось декілька друпально-агностичних пропозицій:

• Are My Sites Up періодично надсилатиме ваші сервери та надсилатиме вам електронне повідомлення електронною поштою (або SMS, якщо ви отримуєте невільний пакет), якщо ваш сайт не працює в режимі офлайн або не відповідає.
• Load Impact - це ще один чудовий безкоштовний інструмент, який може піддавати стрес-тестуванню ваш веб-сайт, щоб ви могли сказати, коли саме він починає виходити з ладу.

Що стосується самого додатка Drupal, я б запропонував використовувати Xdebug + Webgrind або XHProf для профілю коду і слідкувати за цим питанням: Найкращий спосіб орієнтувати продуктивність стека Drupal

Мені подобається pingdom для невеликих / середніх сайтів, тому що це корисно: воно говорить про те, що щось не так з точки зору клієнта, що підлягає дії. Такі речі, як середня завантаженість, насправді нічого не означають, якщо у вас є диво неправильно налаштований стек (чого не слід) або ви забиваєте Digg / Reddit (у цьому випадку все одно ви нічого не можете зробити, у вас повинно бути підготовлений).

З блогу Теда Дзюби:

Я називаю такі типи сповіщень Cool Story, Bro коротко. Це біти інформації, які не вказують на якийсь проблемний стан і не вимагають жодних дій. Класні історії - це речі, про які ви навіть не повинні отримувати сповіщення. Вони марнують ваш час і роблять вас параноїком. Оповіщення Cool Story Bro - такі речі:

• Середнє завантаження на сервері вище 20.
• У черзі завдань є більше X робочих одиниць. Вітаю, глупо, твоя черга робить саме те, що має робити.
• Деякі показники перевищують середньо емпірично визначене значення. Мене особисто ображають подібні лайна.

Читай допис у блозі, це смішно.

Я використовую check_drupal для моніторингу різних Drupal-сайтів. Це плагін nagios, який не потребує змін коду на самому Drupal-сайті. Єдина вимога полягає в тому, що на сервері має бути присутнім друк .