Как начать наблюдение за новое приложение
Опубликовано: Март 2016
Применимо к:System Center 2012 R2 Operations Manager, System Center 2012 - Operations Manager, System Center 2012 SP1 - Operations Manager
При изучении новое приложение, можно использовать шаблон наблюдения за производительностью приложений .NET в System Center 2012 — Operations Manager Настройка мониторинга для него. Ниже даются некоторые начальные параметры, которые помогут получить нужные знания о новом приложение. Кроме того, рекомендуется начинать мониторинг в среде тестирования или разработки.
Параметры мониторинга для нового приложения
Эту стратегию для мониторинга новое приложение поможет узнать, как ведет себя приложение в вашей системе и для клиента.
Запуск наблюдения за серверную только с простой системы и краткосрочных параметров
Во-первых, упрощения конфигурации: выполняйте мониторинг одного приложения на одном сервере. Во-вторых при первой настройке мониторинга производительности приложений .NET для нового приложения, следует сохранить параметры, необходимо реализовать достаточно долго для выявления некоторых трендов. Суточные данные должны дать вам достаточно сведений для понимания производительности и тенденций использования приложения.
Определение базового уровня производительности с использованием параметров по умолчанию и некоторых индивидуальных параметров
Как правило, рекомендуется использовать параметры по умолчанию. Параметры по умолчанию позволят вам видеть все крупные проблемы с приложением, при этом влияние мониторинга на приложение сведется к минимуму.
Если вы не получаете событий исключений или производительности, можно использовать следующую процедуру, чтобы понять, как выглядит базовая производительность.
Чтобы начать мониторинг, вы можете выполнить изменение следующих параметров:
Снизьте пороги производительности. Этот параметр позволит вам установить базовые показатели производительности, замерив текущие характеристики производительности приложения.
Включение всех пространств имен. Вы хотите узнать, какие пространства имен участвуют и если определенных пространств имен в первую очередь, может пропустить пространства имен, где происходит ошибка.
Соберите все исключения, а не только критические исключения. Вам необходимо знать виды возникающих исключений. Применение обработчиков известных исключений позволяет ограничить количество исключений, которое вы будете получать.
Это может выразиться в большом объеме данных — чрезмерном для долгосрочного мониторинга, но сначала такой объем данных будет полезен, поскольку он покажет тренды, например, пути следования клиентов в системе, а также позволит узнать, как выглядит нормальная производительность.
По завершении сбора данных используйте отчеты Application Advisor, такие как "Анализ производительности приложения", чтобы увидеть состояние наблюдаемых приложений. Отчет позволит вам узнать, какова средняя длительность самых "тяжелых" (долгосрочных) вызовов системы, а также определить максимальное время, затраченное на обработку запросов. Это даст вам возможность установить индивидуальные пороги на основании реальной производительности приложения. Вы также увидите, какие функции работают быстрее, чем другие, и сможете создать индивидуальные транзакции веб-страниц, веб-методов или функций для критически важных методов, чтобы обеспечить их реагирование в рамках более строгого (по сравнению с остальным приложением) соглашения об уровне обслуживания. Дополнительные сведения о просмотре отчетов см. область и запуск и отчета советника по приложениям в приоритетность предупреждений с помощью советника по приложениям.
Изменение параметров и сравнение с базовыми показателями
Установив базовый показатель производительности, начинайте тонкую настройку параметров мониторинга, которая позволит ему регистрировать все виды возникающих исключений. Фиксируя все исключения, вы увидите, имеются ли в приложении стандартные обработчики исключений, регистрирующие исключения, о которых вы бы предпочли бы получать оповещения. С каждой регулировкой объем полученных вами данных будет уменьшаться и они будут становиться более информативными.
Удалите пользовательские параметры и установите пороги на основании собранных данных.
Добавьте зависимости стеков вызовов в события производительности и исключений, обнаруженных во время фазы базовые определенных пространств имен.
Добавьте обработчики исключений для приложений уровня «все catch» обработчиков, предотвращающих выход за пределами приложения, а также для обработчиков исключений .NET Framework исключений.
Добавьте специализированные транзакции для мониторинга производительности общих методов, которые должны использовать более строгое соглашение об уровне обслуживания, чем само приложение.
Сравните новые данные со своими базовыми показателями. К примеру, это позволит вам увидеть реальное среднее время ответа. Теперь, когда вы узнали, какие исключения производительности отправляет приложение, вы можете добавить нужные вам определенные пространства имен, вместо того чтобы вести мониторинг всех пространств имен. Настройка мониторинга приложения будет выполнена на основании зафиксированных уровней производительности и вы получите оповещение, если показатели выйдут за пределы обычного диапазона.
Поэтапное развертывание приложения на другие наблюдаемые серверы в вашей системе
По прошествии некоторого периода мониторинга приложения с применением новой конфигурации, как только вы посчитаете его работоспособным, увеличьте количество серверов развертывания приложения, к примеру, от одного до 10. Как только оно покажет себя работоспособным на этом новом уровне, расширьте развертывание и мониторинг на еще большее количество серверов, и т. д. Такой подход постепенного развертывания поможет вам получить уверенность в мониторинге приложения и гарантировать работоспособность вашей системы.
Начать наблюдение на стороне клиента
Если вы уверены, что приложение выполняется в пределах системы, это самое время для наблюдения за испытывает клиента. Это какие клиентские мониторинга приложений. Чтобы включить наблюдение на стороне клиента, см. Как настроить мониторинг приложений .NET
Полезность данной информации для оператора
Используя эту базовую информацию, оператор может определить, где находится неполадка в приложении или инфраструктуре, а также понять, находится ли ее устранение в компетенции отдела разработки или она может быть исправлена самим оператором.