Найкращі практики моніторингу веб-додатків [закрито]

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

Використовувати шви Nagios як хороший варіант, але хотіли отримати більше думок про те, які найкращі інструменти / практики моніторингу для веб-додатків загалом, а особливо для програми Django? Також вітаються рекомендації щодо того, що слід контролювати, окрім очевидних процесора, пам'яті, дискового простору та підключення до бази даних.

Наш веб-додаток написаний на Django, ми працюємо на Linux (Ubuntu) під Apache + Fast CGI з базою даних PostgreSQL.

EDIT У нас є повністю віртуалізоване середовище під Linode.

EDIT Ми використовуємо django-журналювання, тому у нас є спосіб відокремити інформацію, помилки, критичні проблеми тощо.

Nagios - це добре, добре, що, можливо, регулярно працює системне тестування (селен).

Редагувати: Hyperic та Groundwork також виглядають цікаво.

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

Інші речі, які я люблю робити:

Найкращий девіз для інфраструктури - це завжди виправлення, виявлення, ремонт. Підніміть його, дістаньтесь до його кореня і вилікуйте / запобігайте, якщо можете.

Оскільки система існує на багатьох рівнях, ми повинні тестувати на багатьох рівнях:

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

1) Підключення : стежте за підключенням до Інтернету з сервера та зовні. Запишіть це десь

2) Сервер : відстежуйте всі необхідні вам процеси, щоб переконатися, що вони працюють, а не закріплюють сервер. Використовуйте сервер HP або щось еквівалентне із сповіщенням про несправність апаратного забезпечення, яке він може робити з рівня BIOS. Повідомте та зареєструйте, якщо вони є.

3) Програмне забезпечення : Визначте ключове програмне забезпечення, яке завжди потрібно запускати. Встановіть рівні продуктивності, якщо такі є, а потім контролюйте їх. Нагіос повинен допомогти в цьому. На вікнах це може бути трохи більше. Коли виникає виняток, ви повинні мати можливість запустити з нього сценарій для автоматичного перезапуску процесів. Система моєї мрії дозволяє мені взаємодіяти з серверами за допомогою SMS, якщо сервер сприймає це як виняток, який я повинен дозволити, або такий, який відбудеться автоматично, якщо я не скасую SMS. Одного дня..

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

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

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

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

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

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

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

1. Визначте важливі робочі потоки у вашій системі. Наприклад, якщо ви написали веб-сайт електронної комерції, ви можете визначити робочий процес "пошук товару, розміщення товару в кошику для покупок і придбання товару".
2. Визначте пріоритети робочих потоків і спочатку побудуйте тести з більш високим пріоритетом. Ви завжди можете додати додаткові тести після запуску у виробництво.
3. Створюйте тести інтерфейсу користувача, використовуючи одну з доступних платформ тестування інтерфейсу. Існує ряд безкоштовних та комерційних платформ тестування інтерфейсу, які можна запускати автоматизовано. Спершу створіть базовий набір тестів, які розглядають критичні робочі потоки.
4. Налаштуйте принаймні одне віддалене місце, з якого можна запускати тести. Ви хочете перевірити кожен аспект своєї системи, а це означає тестувати її віддалено. Чи підключено Інтернет? Чи працює веб-сервер? Чи працює підключення до сервера баз даних? І т. Д., Тощо. Якщо ви тестуєте віддалено, ви переконуєтесь, що ваша система доступна для зовнішнього світу, а це означає, що вона, швидше за все, працює наскрізно. Ви також можете запускати ці тести всередині, але я думаю, що критично важливо проводити їх зовні.
5. Переконайтеся, що ваше рішення включає як звітування, так і сповіщення. Якщо один із ваших критичних тестів робочого циклу не вдається, ви хочете, щоб хтось знав про нього, щоб якомога швидше вирішити проблему. Якщо некритичне завдання не вдається, можливо, вам потрібна лише звітність, щоб ви могли вирішити проблеми поза зоною.

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

Аааа, моніторинг. Як я люблю тебе та твої вібрації о 3 ранку.

По суті, вам потрібен спосіб перевірити внутрішній стан вашої програми, як у конкретний момент, так і протягом періоду часу (останній дуже важливий для виявлення проблем до їх виникнення). Інший спосіб думати про це - як прославлене юніт-тестування.

У нас є своя (дуже приємна) система моніторингу, тому я не можу коментувати Nagios чи інші програми. Наш варіант використання схожий на ваш, однак (додаток cgi на apache).

1. Додайте метод типу logging.monitor (), який реєструватиме інформацію на диску. Це повинно підтримувати, принаймні, реєстрацію простих чисел і наборів чисел (асоціація ключ => значення може бути неймовірно зручною).
2. Запропонуйте процес, який видаляє журнали моніторингу та зберігає їх у базі даних.
3. Майте процес, який бере інформацію бази даних, перевіряє їх на відповідність правилам та розсилає попередження. Майте на увазі, що щось може бути неприємним. Те, що ви отримали 404 один раз , не означає, що додаток його знизив.
4. Є спосіб вимкнути сповіщення (дуже корисно для технічного обслуговування або для читання електронної пошти).

Це все досить високий рівень. Важливим є те, що у вас є історія стану програми протягом часу. Після цього ви можете створити правила (можливо, просто необроблені запити sql, які ви десь вклали в конфігурацію), які говорять: "Якщо запити в секунду подвоїлися, надішліть попередження SlashDotted" або "якщо 50% відповідей складають 404, надішліть попередження ". Це також призводить до смішного управління, оскільки ви можете кількісно оцінити будь-який коментар про те, вгору, вниз, швидко чи повільно.

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

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

Я використовую Munin і Monit , і я дуже задоволений обома.

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

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

Швидше за все, що в кінцевому підсумку вас знесе, ваші лісозаготівлі та системи охорони здоров’я все одно пропустили.

Найважливіший спосіб моніторингу будь-якого веб-сайту - це зовнішній моніторинг. Метою має бути моніторинг вашого сайту таким чином, щоб найбільш точно відображати, як користувачі користуються цим сайтом. У 99% випадків, як тільки ви дізнаєтесь, що ваш сайт не працює, порівняно легко знайти першопричину. Найголовніше - якнайшвидше знати, що ваші клієнти не можуть завантажити ваш сайт.

Це, як правило, означає використання зовнішньої служби моніторингу продуктивності. Вони від самого низького рівня (mon.itor.us, pingdom) до найвищого (Webmetrics, Gomez, Keynote). І як завжди, ви отримуєте те, за що платите. На що слід звернути увагу, купуючи послугу моніторингу:

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

Удачі!

Веб-моніторинг за допомогою IP Patrol або SiteSentry були для нас корисними. Другий - трохи схожий на впевненість на сайті, але трохи гарніший хаха.

Чи замислювались ви і про моніторинг функціональності? Дуже приємно мати сценарій (або мовою сценаріїв, як Perl або Pyton, або за допомогою якогось інструменту, такого як WebTest ), який розмовляє з вашим додатком і робить деякі важливі кроки, такі як вхід в систему, здійснення покупки тощо.

Окрім того, що слід контролювати, на що вже було дано відповідь, вам потрібно переконатися - незалежно від використовуваної вами системи - що ви отримуєте лише одне повідомлення про помилку, яка трапляється кілька разів, на кожен запит. Або у вашої папки "Вхідні" закінчиться пам'ять :) Плюс, це просто дратує ...

Розподіліть зміни в режимі очікування між командою підтримки / розробників, щоб одна особа не повинна була телефонувати щовечора. Це змучить людей. Моніторинг - це добре , але кожному потрібно час від часу отримати шанс на життя. Ваш мобільний телефон, який гуде о 02:00 протягом декількох ночей, дуже скоро постаріє, повірте мені. І не кожен розробник звик підтримувати цілодобово та без вихідних, тому вам потрібно знайти баланс між використанням моніторингу та зловживанням моніторингом.

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

Я використовую Nagios + CruiseControl + Selenium для запуску високорівневих тестів критично важливих веб-додатків. Я досить сильно опікся простою помилкою jquery, яка перешкоджала користувачам проходити онлайн-форму реєстрації.

http://www.agileatwork.com/the-holy-trinity-of-web-2-0-application-monitoring/

Ви можете поглянути на AlertGrid . Ця веб-програма дозволяє фільтрувати та пересилати сповіщення вашій команді (у всьому світі). Він також має приємну здатність контролювати, якщо щось не сталося.

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

Мої друзі також рекомендували кактуси та Hyperic , але у мене немає особистого досвіду з тими.

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

Один з наших клієнтів використовує Techout (www.techout.com) і дуже задоволений послугою.

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

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

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

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

Трохи змінивши рядок, щось, що я справді вважаю корисним, і дуже змінило спосіб моніторингу моїх програм - це десь реєструвати винятки javascript. Існує дуже приємна реалізація, яка реєструє дані безпосередньо з браузерів користувачів у Google Analytics. Це обов’язково для веб-додатків, орієнтованих на Javascript, і може дати вам результати, засновані безпосередньо на браузерах користувачів, що може призвести до дуже несподіваних помилок (iE та мобільний браузер - це біль)

Застереження: Мій пост нижче

http://www.directperformance.com.br/en/javascript-debug-simples-com-google-analytics

Для моніторингу присутності в Інтернеті я б запропонував послугу, над якою я працюю: Sucuri NBIM (монітор цілісності на основі мережі).

Він перевіряє наявність та цілісність, шукає зміни у вашій присутності в Інтернеті (сайти, DNS, WHOIS, заголовки тощо) та втрату зв’язку. Це безкоштовно, і ви можете спробувати тут .