Лучшие практики мониторинга веб-приложений

Ответ 1

Nagios хорош, хорошо, может быть, системное тестирование (Selenium) работает регулярно.

Изменить: Hyperic и Заземление также выглядят интересно.

Существует, вероятно, система тестовых наборов, которая также может поддерживать тестирование давления для вас. Я не могу вспомнить имя с головы, возможно, кто-то может упомянуть один ниже.

Другие вещи, которые мне нравятся:

Лучшим девизом для инфраструктуры всегда является исправление, обнаружение, ремонт. Поднимите его, дойдете до его корня и вылечите/предотвратите его, если сможете.

Поскольку система существует на многих уровнях, мы должны тестировать на многих уровнях:

Изменить: иметь все ошибки или предупреждения, отправленные непосредственно вашему менеджеру по телефону по электронной почте. Таким образом, вы можете отслеживать события в одном месте.

1) Соединение: отслеживайте подключение к Интернету с сервера и извне. Запишите это где-нибудь

2) Сервер: отслеживайте все процессы, которые вам нужны, чтобы убедиться, что они запущены и не привязывают сервер. Используйте сервер HP или что-то подобное с уведомлением об отказе оборудования, которое он может выполнять с уровня BIOS. Уведомлять и регистрировать, если они есть.

3) Программное обеспечение. Определите ключевое программное обеспечение, которое всегда должно выполняться. Установите уровни производительности, если они есть, а затем контролируйте их. Nagios должен быть в состоянии помочь в этом. В окнах это может быть немного больше. Когда возникает исключение, вы можете запустить script из него для автоматического перезапуска процессов. Система моей мечты позволяет мне взаимодействовать с серверами через SMS, если сервер видит это как исключение, которое я должен разрешить, или тот, который будет выполняться автоматически, если я не отменяю по sms. Однажды..

4) Удаленная мощность. Убедитесь, что возможности удаленного питания - reset находятся в ваших руках. Возможно, вам захочется запланировать еженедельную перезагрузку, если вы когда-либо используете окна для чего-либо.

5) Тестирование бизнес-логики. Регулярно запускайте скрипты, проверяющие рабочий процесс вашей системы. Селен, вероятно, может достичь этого, но мне нравится записывать результаты, чтобы сказать, что это было в это время, и в этих файлах были ошибки. Если возможно, в любом месте, система проверит себя через ваши скрипты.

6) Резервные копии. Создайте резервную копию, которую вы можете установить и забыть. Если вы можете получить что-то в виртуальных машинах, это будет идеально, поскольку вы можете масштабировать, перемещать или развертывать любую часть своей инфраструктуры в любом месте. У меня были случаи, когда я переместил мертвый сервер на свой ноутбук, и пусть он запускается в vmware, пока я исправил проблему.

Ответ 2

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

Также убедитесь, что у вас есть регулярный запрос URL, который является разумным сквозным тестом системы. Если ваш сайт поддерживает поиск, попробуйте выполнить nagios, чтобы убедиться, что индекс поиска здоров, веб-сервер и сервер базы данных.

Кроме того, убедитесь, что ваши приложения отправляют вам электронную почту в любое время, когда ваши пользователи видят ошибку, или существует необработанное исключение. Таким образом, вы знаете, как приложение не работает в поле.

Ответ 3

Если бы мне пришлось выбирать один тип тестирования, это было бы тестирование функциональности конечного пользователя системы. Важно учитывать, что пользователь. При тестировании таких вещей, как доступность базы данных, время работы сервера и т.д., Все это важно, тестирование рабочих потоков через вашу систему с помощью системы удаленного тестирования пользовательского интерфейса охватывает все эти базы. Если вы знаете, что критические части вашей системы доступны конечному пользователю, то вы знаете, что ваша система довольно хорошо.

• Определите важные рабочие потоки в вашей системе.. Например, если вы написали сайт электронной коммерции, вы можете определить рабочий процесс "поиска продукта", поместить продукт в корзину покупок и покупки продукта ".
• Назначьте приоритет рабочим потокам и сначала создайте тесты с более высоким приоритетом. Вы всегда можете добавлять дополнительные тесты после развертывания в производство.
• Сборка пользовательских интерфейсов с использованием одной из доступных платформ пользовательского интерфейса. Существует множество бесплатных и коммерческих интерфейсов тестирования пользовательского интерфейса, которые можно запускать автоматическим способом. Сначала создайте базовый набор тестов, которые адресуют критические рабочие потоки.
• Установите хотя бы одно удаленное место для запуска тестов.. Вы хотите протестировать каждый аспект вашей системы, что означает его дистанционное тестирование. Подключено ли подключение к Интернету? Работает ли веб-сервер? Работает ли соединение с сервером базы данных? Etc и т.д. Если вы тестируете удаленно, вы убедитесь, что система доступна для внешнего мира, что означает, что она, скорее всего, работает от конца до конца. Вы также можете выполнять эти тесты внутренне, но я думаю, что очень важно запускать их извне.
• Убедитесь, что ваше решение включает в себя как отчетность, так и уведомление. Если один из ваших критических тестов рабочего процесса выходит из строя, вы хотите, чтобы кто-то узнал об этом, чтобы исправить проблему как можно скорее. Если некритическая задача выходит из строя, возможно, вам нужна только отчетность, чтобы вы могли исправлять проблемы вне диапазона.

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

Ответ 4

Ahhh, мониторинг. Как я люблю тебя и твои вибрации в 3 часа ночи.

По сути, вам нужен способ проверить внутреннее состояние вашего приложения как в определенный момент, так и за промежутки времени (последнее очень важно для обнаружения проблем до их возникновения). Другой способ думать об этом - это прославленное модульное тестирование.

У нас есть собственная (очень приятная) система мониторинга, поэтому я не могу комментировать Nagios или другие приложения. Наш пример использования похож на ваш, хотя (приложение cgi на apache).

• Добавьте метод типа logging.monitor(), который будет записывать информацию на диск. Это должно поддерживать, по крайней мере, протоколирование простых чисел и цифр чисел (ассоциация ключей = > может быть невероятно удобна).
• Имейте процесс, который сбрасывает журналы мониторинга и сохраняет их в базе данных.
• Имейте процесс, который берет информацию о базе данных, проверяет их против правил и отправляет предупреждения. Имейте в виду, что что-то может быть шелушащимся. Просто потому, что вы получили 404 раз, это не значит, что приложение оно вниз.
• Уметь отключать оповещения (очень полезно для обслуживания или для чтения вашей электронной почты).

Это все довольно высокий уровень. Важно то, что с течением времени у вас есть история состояния приложения. Затем вы можете создавать правила (возможно, только сырые sql-запросы, которые вы помещаете в конфигурацию где-нибудь), которые говорят: "Если запросы в секунду удваиваются, отправьте предупреждение SlashDotted" или "если 50% ответов - 404, отправьте предупреждение". Он также управляет системой, потому что вы можете количественно оценить любые комментарии о том, вверх, вниз, быстро или медленно.

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

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

Ответ 5

Я использую Munin и Monit, и были очень довольны обоими из них.

Ответ 6

Внутреннее ведение журнала является прекрасным и денди, но когда ваше приложение исчезает, или ваш бокс /enviro падает, вам также нужен внешний контроль. http://www.pingdom.com/ был очень надежным для меня.

Мой единственный совет: я бы не потратил слишком много времени на это. мой лучший пример - твиттер, сколько энергии они вкладывают в систему, способную к полумирам, вместо того, чтобы просто инвестировать в это время и энергию, чтобы выбросить больше аппаратного обеспечения/масштабировать его.

Скорее всего, это приведет вас к снижению, ваши журналы и системы здравоохранения все равно будут пропущены.

Ответ 7

Единственным наиболее важным способом мониторинга любого интернет-сайта является мониторинг снаружи. Цель должна состоять в том, чтобы следить за вашим сайтом таким образом, который наиболее точно отражает то, как ваши пользователи используют сайт. В 99% случаев, как только вы знаете, что ваш сайт находится снаружи, относительно легко найти первопричину. Самое главное - как можно скорее узнать, что ваши клиенты не могут загрузить ваш сайт.

Это обычно означает использование внешней службы мониторинга производительности. Они очень с самого низкого конца (mon.itor.us, pingdom) до высокого уровня (Webmetrics, Gomez, Keynote). И как всегда, вы получаете то, за что платите. Что нужно искать, когда вы совершаете покупки для службы мониторинга, выполните следующие действия:

• Размер и распределение сети мониторинга
• Независимо от того, сможет ли мониторинг отслеживать ваш сайт с помощью реального браузера (в противном случае вы не будете тестировать ваш сайт, как настоящий пользователь)
• Язык сценариев (до script транзакций с вашим сайтом)
• Отдел поддержки, который поможет вам на этом пути, и предоставит экспертное мнение о том, как правильно контролировать.

Удачи!

Ответ 8

Веб-мониторинг IP Patrol или SiteSentry были полезны для нас. Во-вторых, это немного напоминает доверие сайта, но немного красивее.

Ответ 9

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

Ответ 10

Помимо того, что для мониторинга, на который уже был дан ответ, вам нужно убедиться, что независимо от используемой вами системы вы получаете только one уведомление об ошибке, которая происходит несколько раз, по каждому запросу, Или ваш почтовый ящик исчерпает память:) Плюс, это просто раздражает...

Разделите резервные сдвиги между командой поддержки/разработчика, поэтому одному человеку не нужно называть его каждый вечер. Это будет носить людей. Мониторинг - это хорошо, но каждый должен получить шанс на время от времени. Ваш мобильный телефон, жужжащий в 2 часа ночи в течение нескольких ночей, скоро станет очень старым, поверьте мне. И не каждый разработчик используется для круглосуточной поддержки, поэтому вам нужно найти баланс между использованием мониторинга и злоупотреблением мониторингом.

В принципе, есть отдельные уровни эскалации, и если небо не падает, определите "ночью безмятежность сейчас" ночью", где меньшая эскалация уровни не выходят.

Ответ 11

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

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

Ответ 12

Вы можете посмотреть AlertGrid. Это веб-приложение позволяет фильтровать и пересылать оповещения в вашу команду (по всему миру). У этого есть также хорошая способность контролировать, если что-то не произошло.

Ответ 13

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

Друзья мои также рекомендовали Cacti и Hyperic, но у меня нет личного опыта с ними.

Последнее: один из других ответов предложил запустить инструмент, который подчеркивает ваш сайт. Я бы не рекомендовал делать это на вашем сайте, если у вас нет надежного спокойного периода, когда никто не бьет его; даже тогда вы можете неожиданно его опустить. Гораздо лучше иметь промежуточный сервер, где вы можете запускать тесты нагрузки, прежде чем вносить изменения в производство.

Ответ 14

Хорошо, может быть, системное тестирование (Selenium) работает регулярно.

= > 100% ACK. Для этого мы используем http://www.alertfox.com. с нашей учетной записью PRO2 они запускают регрессионный тест за 1 час, что отлично. Вы даже можете сделать это со своей бесплатной учетной записью, но ограничены только одним датчиком транзакций.

Ответ 15

Один из наших клиентов использует Techout (www.techout.com) и очень доволен этой услугой.

Существует никаких ограничений на оповещения, независимо от того, какой тип или сколько, и они предлагают оповещения по электронной почте, голосовой почте и SMS-сообщениям - и если что-то происходит, звонок из живого человека, чтобы помочь вам.

Все это на основе сервиса - вы не устанавливаете программное обеспечение, и у вас есть консультант, который работает с вами, чтобы определить наилучший подход для вашего бизнеса. Это один из наиболее удобных веб-приложений мониторинга, потому что они заботятся обо всем.

Ответ 16

Я бы просто добавил, что вы можете предсказать вероятность ошибки, основанную на истории прошлых ошибок и фиксировав их. Если вы планируете сократить частоту и серьезность проблем, которые были исправлены до этого момента, вы будете иметь обзор предсказуемых новых проблем. Если в течение некоторого времени все работает без ошибок, то двумя источниками проблем будут последние изменения или проблемы с масштабируемостью.

Из вышеизложенного это звучит как масштабируемость - это ваше единственное беспокойство, но я просто упомянул тест частоты прошлых ошибок, потому что команды, на которых я постоянно думал, что они исправили последнюю ошибку, и их больше нет. Пока не будет.

Ответ 17

Немного изменив строку, я действительно думаю, что полезен и сильно изменился, как я отслеживаю свои приложения, чтобы где-то регистрировать исключения javascript. Там очень хорошая реализация, которая регистрирует это непосредственно из браузеров пользователей в Google Analytics. Это необходимо для веб-приложений, ориентированных на Javascript, и может дать вам результаты, основанные непосредственно на браузерах пользователей, что может привести к очень неожиданным ошибкам (iE и мобильный браузер - боль)

Отказ от ответственности: мой пост ниже

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

Ответ 18

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

Это проверка доступности и целостности, поиск изменений в вашем присутствии в Интернете (сайты, DNS, WHOIS, заголовки и т.д.) и потеря подключения. Это бесплатно, и вы можете попробовать его здесь.