Контроль непрерывной работы приложений.NET в производстве?
Учитывая относительно типичную.NET 4 системы в среде SOA (т.е. Windows Server 2008 R2, УСПОКОИТЕЛЬНЫЕ веб-сервисы на IIS 7, Windows Services для обмена сообщениями NServiceBus, SQL Server 2008 R2, и т.д.), каковы лучшие практики или фактические решения (без цены предприятия) для выполнения 24x7 производительность, контролирующая в производстве?
Не обязательно, сколько CPU/Memory/Disk IO это использует, а скорее например сколько createAccount () вызовы в минуту было сделано, что является средним временем generateResponse () метод берет, и обнаружьте необычные скачки дельты между, например, generateResponseStarted, и generateResponseComplete (метод был вызван (который в свою очередь может назвать третью сторону), и ответ готов быть возвращенным соответственно).
После некоторого поиска с помощью Google кажется, что опции для низкоуровневых профилировщиков (как dotTrace) и реализующий Счетчики производительности и использующий тех, которые имеют PerfMon или некоторый другой продукт типа OpManager.
Что Вы порекомендуете? Был бы, реализовывая счетчики производительности для работающего приложения, значительно ухудшают производительность в производственной системе? В противном случае есть ли какие-либо хорошие библиотеки, которые оптимизировали реализацию в.NET? Если да, как люди контролируют производительность своих приложений кроме дискового CPU памяти?
@Ryan Hayes
Спасибо, я ищу способ видеть, что необычное замедляется или скачки в производственных системах. Например, все было хорошо во время стресс-тестирования, но по некоторым причинам у третьей стороны, на которую мы полагаемся, есть некоторые проблемы, или DB замедляется должный распараллелить блокировку, или SAN уступает дорогу, или любые другие неожиданные сценарии. Низкоуровневое профилирование является слишком большим количеством издержек при включении счетчиков только, когда существует проблема, является слишком поздним в той точке. Плюс мы будем пропускать исторические данные для сравнения его с (мне была бы нужна своего рода система предупреждений для того, когда дельта за пределами приемлемого порога). Я задаюсь вопросом, как люди контролируют производительность своих производственных систем и по их опыту каков был бы лучший подход для не связанный с памятью/CPU/сервером вид контроля.
2 ответа
Вы можете попробовать AlertGrid. Похоже, это может быть решением ваших проблем.
Вы можете посылать различные параметры в AlertGrid из вашего приложения (имя нового аккаунта, время выполнения важной части логики и так далее). Служба AlertGrid может сделать несколько вещей с вашими данными. Во-первых, он может обрабатывать некоторые правила уведомления, построенные на основе присланных вами параметров (например, если время выполнения чего-то важного > X секунд -> отправить sms ответственному лицу).
Через две недели у AlertGrid появится куча новых возможностей. Похоже, что наиболее важной для вас будет возможность строить графики параметров, полученных от вашей системы.
Обратите внимание, что AlertGrid не может обнаружить параметры от ваших систем - вместо этого вам нужно их отправить. Это может показаться дополнительной работой, но мы считаем, что она сопоставима с затратами времени на установку и настройку некоторых специализированных инструментов. С другой стороны, благодаря такому подходу AlertGrid преодолевает некоторые ограничения (он может быть интегрирован со всем, что может отправлять http-запросы).
Я полагаю, что вам будет гораздо легче понять, когда вы создадите аккаунт в AlertGrid и пройдете его интерактивный учебник.
Как вы могли заметить, я являюсь разработчиком в команде AlertGrid:)
Отказ от ответственности: На момент написания статьи мы знаем, что цены на AlertGrid будут снижены в ближайшем будущем, поэтому не смотрите на них прямо сейчас, вы можете связаться с нашей линией поддержки для получения дополнительной информации о ценах. Бесплатный аккаунт доступен и должен быть достаточным для начала.
Вопрос в том, что вы действительно пытаетесь узнать из мониторинга производительности?
Вы хотите сделать свой код быстрее? Тогда я бы предложил использовать инструменты профилирования в тестовой среде, чтобы узнать, где вы можете улучшить свой код.
Хотите узнать, с какими максимальными нагрузками может справиться ваша система? Тогда я бы посоветовал провести нагрузочное тестирование в тестовой среде. Если вы точно знаете, насколько сильно вы можете продвинуть свою систему, не разрушая ее, тогда вам не нужно будет запускать мониторинг в производство.
Для производства вы, вероятно, захотите максимизировать производительность. Чтобы сделать это, обычно приходится сильно продвигать тестовую среду и получать надежные метрики, так что вам не нужно устанавливать мониторы производительности в производственной среде. Что касается производства, вы просто хотите знать, когда вы достигли этого пика, а затем изящно деградировать, или что вы сочтете нужным. Как правило, хорошее ведение журнала - лучший способ контролировать производительность системы (помимо оборудования) и фиксировать исключительные особенности производительности.
Все системы разные, и ваш опыт может отличаться. Воспринимайте это как предложение, а не как это делает ВСЕ, потому что всегда бывают исключительные случаи, когда вам, возможно, придется запустить профилирование в производственной среде.