- Диагностировать приложение, находящееся в продакшене, и экосистему вокруг него – собирать статистику об исключениях, аптайм, состояние веб-сервера, время ответа, и так далее.
- Показывать тренды, – как ведут себя пользователи, куда они ходят, что делают, сколько проводят времени, возвращаются ли.
Было много прекрасных средств, но я не нашел объединившее бы все функции, и желательно интегрировавшее весь этот опыт в экосистему, которая уже есть – мою Visual Studio. Если вам интересен такой новый инструмент – Application Insights – с помощью которого можно не только смотреть, но и загружать, например, файлы для IntelliSense – велком под кат. Уточняю – это не мегагайд о том, «как сделать», это обзор, поэтому будет много ярких картинок.
Итак, если мы понимаем, что «да, у нас есть виртуальная машина, мы с ней можем делать все», и «да, это PaaS, и он нужен для того, чтобы нам не надо было делать всего с виртуальной машиной, а раз – и выложили приложение». Но что происходит, когда мы, используя любой из подходов, всё-таки выкладываем свое приложение? Дальше начинается тестирование и отлов багов. Идеального софта не бывает – даже если мы вроде бы предусмотрели всё, мы можем забыть о какой-то мелочи в окружении приложения – и получить интересный баг. Или баг из-за поведения соседнего компонента (или, опять же, экосистемы), которое наблюдалось ровно десять секунд. Как отлавливать всё это? Конечно, есть множество инструментов – Intellitrace, счетчики производительности, тесты, многое другое. Но если мы будем иметь инструмент, который объединяет все вышеперечисленное?
Инструмент называется Application Insights. Это – компонент Visual Studio Online, и он бесплатен для аккаунтов Visual Studio Online (подробнее про VSO), в которых до 5 членов команды. Внедрить его можно непосредственно в приложение (например, Cloud Service Windows Azure), установить его агент на сервере (Windows Server) и сказать, чтобы он начал мониторить все сайты и приложения, которые есть на этом сервере, либо связать его с System Center Operation Manager (что есть самый сложный сценарий, так как это уже, мягко говоря, уровень выше, нежели «просто инструмент»).
Для того, чтобы использовать AI, нам нужно:
- Аккаунт
Visual Studio Online (он бесплатен, и простого Basic хватит – аккаунт нужен для использования AI) – бесплатно зарегистрировать аккаунт можно здесь. - Подписка Windows Azure (можно и без подписки, но если не хочется экспериментировать с боевым сервером, то можно поднять виртуальную машину с веб-сервером – для тестов хватит бесплатного триала).
- Виртуальная машина с Visual Studio 2013 ALM (удобства ради – чтобы не экспериментировать на локальной машине).
- Visual Studio 2013 Ultimate. Скачать Visual Studio 2013.
- Веб-проект (проекты), которые уже работают на IIS либо которые можно развернуть на веб-сервер.
Что будем делать первым? Настраивать инфраструктуру. Дальше – смотреть, что может делать AI.
Настройка инфраструктуры
Настроим базовый элемент нашего опыта использования AI –ВМ Visual Studio 2013 ALM. Данная ВМ необязательна и, если у вас есть Visual Studio Ultimate 2013, то можно пропустить этот пункт. Если же нет, то процесс получения данной ВМ описан здесь.
ВМ будет нужен внешний интернет, поэтому, если вы используете Hyper-V, то необходимо будет создать виртуальный свич.
Войдем на ВМ под учетной записью Brian Keller (VSALM\Brian). Пароль: P2ssw0rd. Запустим Visual Studio Ultimate 2013, и введем учетные данные для доступа к Visual Studio Online, который должен был быть зарегистрирован еще до пункта «Что будем делать?».
Создадим виртуальную машину в Azure. Если у вас уже есть веб-сервер с работающими приложениями – можно работать там, действия ничем не отличаются.
Подключитесь к ВМ, нажав кнопку Connect.
Теперь активируем AI в Visual Studio Online. Для этого перейдем на http://ift.tt/O0zkgw ([account] – имя вашего аккаунта) и нажмем на Try Application Insights. Если спросит код на инвайт, используем VSAppInsights6225162023.
После перехода на страницу AI мы увидим инструкции. Первым делом мы должны загрузить Microsoft Monitoring Agent (MMA) и установить его на сервере. Этот агент включит мониторинг приложений на сервере. Его можно загрузить либо на странице с инструкциями либо по ссылке. Во время установки единственными нестандартными вопросами являются режим подключения агента и ключ. Его можно установить и подключить к VSO, к SCOM, либо установить без подключения. Нам будет достаточно подключения к VSO.
Скопируем с портала AI значения Account ID и Instrumentation Key, вставим в соответствующие поля на странице настройки подключения к VSO, и нажмем Validate Connection (это обязательно). Установим опцию для немедленного старта мониторинга всех работающих на сервере приложений после установки агента. После установки агента запустится командное окно, в котором будет доложено о начале мониторинга приложений.
Для интереса можно поизучать Monitoring Agent PowerShell Prompt, который устанавливается вместе с агентом – это набор командлетов, которыми можно пользоваться для, например, получения списка отслеживаемых приложений и их статус (командлет “Get-WebApplicationMonitoringStatus”). Их мы рассматривать пока не будем.
Возвращаемся на портал AI, на котором появится основная функциональность AI в виде набора вкладок: Overview, Availability, Performance, Usage, Diagnostics. Если их нет, нужно подождать – данные еще не подгрузились.
Мы настроили инфраструктуру. Этого достаточно (особенно если вы решили уже в Production отправиться) для поступления и анализа данных. Если нет – можно использовать любой механизм нагрузочного тестирования для имитации нагрузки. Многое зависит от размера нагрузки – например, если тестируется бэкенд, совершенно необязательно, что при обработке 1000 строк из документа может возникнуть проблема. А вы планировали, что в документе будет миллиард строк? Это важно. AI покажет, если потребляется слишком много ресурсов, и это будет ценным фактором дальнейшего планирования и хорошо, если мы это увидим на ранних этапах разработки.
Мониторинг и профайлинг с помощью Application Insights — обзор
Вернемся немного назад и вспомним, что такое AI. AI – это подфункциональность Visual Studio Online, с помощью которой любой член команды может в реальном режиме мониторить доступность, производительность и различные аспекты использования приложений/сервисов. Ниже несколько замечаний по функциям AI:
Availability:
- Availability дает не только статистику о том, сколько запросов было сделано и об их времени выполнения, но также большое количество диагностических данных, которые можно открыть в Visual Studio и провести анализ, чтобы увеличить показатели Availability. AI может мониторить только те сайты/приложения, которые доступны публично по HTTP.
Usage:
- Данные по использованию делятся в AI на данные о действиях пользователя и действия приложения.
- Возможно использование из кода с помощью Telemetry SDK для веб-страниц (JS), сервисов (.NET), Windows Store (JS/.NET) и Windows Phone 8 (.NET).
- Для каждого приложения можно определить такие метрики, как количество просмотров страниц, событий и ошибок (и данные о них), а также всю типичную аналитику – разброс по ОС, разрешениям экранов, браузеров, языков и так далее.
Performance и Diagnostics
- Производительность и диагностику можно проводить для .NET и Java
Availability
- Начнем со вкладки Availability. Availability – это мера, с помощью которой можно увидеть доступность объекта за определенный промежуток времени с разных сторон.
Перейдем на вкладку Availability.
Availability можно рассматривать с разных сторон, и каждый аналитик может иметь собственные представления об этом. Сразу после создания проекта и подсоединения его к AI вкладка Availability будет предлагать создать Synthetic Monitor, или то, как хочет пользователь мониторить доступность проекта. Создадим самый простой – URL Ping Test, его предлагается создать сразу же.
После создания монитора нажмите на появившуюся зеленую кнопку, чтобы перейти на отчет.
По умолчанию доступен отчет за последние 24 часа. Сразу после создания мы не найдем ничего интересного – для того, чтобы увидеть репрезентативную выборку, нужно подождать и нагрузить проект. Далее на скриншотах будут использоваться несколько проектов, которые находятся в продакшене.
Нижний график отображает 24 часа постоянно – для того, чтобы в любой момент можно было посмотреть данные за нужный период, выделив его. После выделения периода графики выше отреагируют с минимальной задержкой.
Наведя на пики, можно увидеть результаты выполнения монитора. У нас был простой монитор с пингом, поэтому результат будет либо цифрой, либо символом крестика – значит, не дошел.
Мониторы создаются нажатием на соответствующую кнопку-плюс. Доступно два варианта – New Single URL Test и New Multistep Web Test. Single URL Test нужен для слежения за одной страницей, в Multistep Web Test можно загрузить уже настроенный Web Test из Visual Studio. С Multistep Web Test разберемся в одной из следующих статей, Single URL Test умещается в пределах одного диалога.
Для просмотра подробной информации по конкретному монитору нажмем на его имя. Здесь — информация о конкретном мониторе, выполнении его работы, географических локациях и так далее. Эта информация – великолепный источник, который может натолкнуть на мысль о том, что нужно, например, добавить серверов, обслуживающих конкретный регион, либо переработать логику.
Но что это за ошибки? Коллеги из Японии ждали двадцать секунд, потом что-то произошло. Нажмем на этот крестик, чтобы понять, что.
Появится окно с информацией об этом запросе.
Теперь понятно – ошибка по тайм-ауту. Можем двигаться дальше и загрузить файл Web Test Result в Visual Studio. Сложные тесты – Multiple – дают возможность выполнять юнит-тесты конкретных страниц и, например, добавлять тестовые сущности. Если в таком процессе произойдет ошибка – она опять же отразится на графике и можно будет посмотреть, где вылетело исключение.
С Availability все (большую тему про Multiple Web Test рассмотрим позже). Перейдем ко вкладке Performance.
Performance
После перехода на вкладку Performance нас ожидает большое количество информации к размышлению за определенный период – выбранный на одной из вкладок период будет сохраняться в течение сеанса.
Первый блок — “Response Time and Load vs. Dependencies” – показывает скорость запросов, среднюю скорость запроса и различные зависимости. Как и на вкладке Availability, у этого блока есть два графика – за выбранный период и за 24 часа.
Следующий блок — “Response Time Distribution” – показывает график с распределением времени, затраченного на ответы. С этим у нас все хорошо – большинство запросов заняло меньше <50 мс.
Самые медленные запросы удостоились в AI отдельного блока — “Top 10 Slowest Requests by Issue Count». Особым богатством информации этот блок не располагает, но позволяет увидеть, какая страница/представление загружалась дольше всего. Обратите внимание на MVC View rendering – сам рендеринг элементов был не такой уж и долгий, основное время ушло на загрузку.
Еще один блок — “Average Instance Count” – показывает среднее количество серверов. Если у вас ферма – будет показывать распределение по количеству. В нашем случае это один сервер, и извлечь пользу из этого факта не получится.
Блок “Exceptions Rate” — один из наиболее интересных. Он показывает распределение по количеству исключений на одну секунду.
Как видим, что-то очень активно происходило — возникали исключения. На более подробную информацию ведет ссылка Exceptions Rate – по нажатию перейдем на кастомизированную под эту информацию вкладку Diagnostics. Там же есть кнопка Exception Events, которая и выведет нам все исключения, произошедшие во время выполнения приложения. Все эти данные можно отсортировать, например, по классу исключения.
Нажатие на исключение вызовет еще одно окно с информацией об этом исключении, и, внимание, ссылкой на файл IntelliTrace — история каждого исключения сохраняется.
Оставшиеся блоки – это информация о ресурсах сервера – CPU, сети, памяти – выделенных для приложения. Причину странного поведения приложения или даже сервера не всегда можно обнаружить сразу (мысль о проверке логов или Task Manager может придти слишком поздно), поэтому распределение по нагрузке может показать полезные аномалии.
Каждый из блоков имеет название, при нажатии на котором происходит переход на настроенную вкладку Diagnostics. Например, если вы обратили внимание на аномалию с памятью на сервере, то это стоит того, чтобы проверить эту вкладку – возможно, у вас произошло Memory Event. Каждый такой Memory Event будет иметь файл дампа памяти, по которому можно определить, что послужило причиной такого поведения.
Переходим на следующую вкладку – Feature Usage.
Features
Эта вкладка зависит от того, настроили ли вы свой код телеметрии с помощью Telemetry SDK. Это также рассмотрим в следующих статьях, сейчас обзорно посмотрим, как это работает.
Телеметрия делится на определенное количество фич. Первая фича, Top Pages, показывает, каким образом пользователи используют приложение, куда ходят и как часто.
Второй блок, Relative % of Sessions, показывает распределение количества запросов к разным секциям сайта в рамках сессии (периода нахождения пользователя на сайте).
Вторая фича – Page Views – показывает иерархию запросов по различным страницам, включая структуру URL и почасовую разбивку.
Тут можно посмотреть по разным страницам дополнительную информацию: среднее количество уникальных пользователей, количество сессий и так далее.
Внутри Page Views есть секция DETAILS — почасовая разбивка информации по посещениям.
Фича Events содержит в себе определяемые разработчиком события, которые нужно логировать и показывать в AI. Фича Event Insights связана напрямую с Events и показывает расширенную информацию по событиям.
Фича Slowest Requests показывает среднее время загрузки различных страниц.
Это что касается Features (фич). Напомню, что вкладка Usage опирается уже на действия разработчика, и разработчик вправе взаимодействовать с AI в этом аспекте так, как ему это требуется. Переходим к следующей секции USAGE – Users.
Эта секция посвящена людям-клиентам. Как люди используют приложение, сколько уникальных посещений, сколько посещений, и, что самое главное, что делают люди и где они это делают.
Секция эта большая, наполненная полезными данными. График User Frequency показывает время, которое проходит между тем, как уже заходивший пользователь ушел, и тем, когда он вновь зашел на ваш сайт/приложение. Если это внутренний сайт для сотрудников, можно увидеть, что с ними все хорошо – они возвращаются на этот сайт в течение дня.
График New vs. Returning показывает процент новых посетителей и возвратившихся.
Engagement Level – это распределение активностей на сессию. Активность – это когда человек куда-то ходит в процессе, а не находится на одной странице.
Следующий пункт – это Authenticated Active Users. Показывает то же самое, что и предыдущий пункт, но для аутентифицировавшихся пользователей. Логика зависит от Telemetry SDK и разработчика.
Пункт Loyalty показывает за определенное время динамику лояльности пользователей – сколько из них пришло первый раз, сколько из этих пришедших пришло второй раз, много раз, длительность сессий, и так далее.
Аналогично с пунктом Environment – без Telemetry SDK новых данных не будет. Если Features – это про сайт, Users – про людей, то Environment – это про то, что людей и сайт связывает – та экосистема, которая окружает любого пользователя, и которая может дать ценные сведения аналитику: операционная система, браузер, тип устройства, реферрал (если пользователь пришел по ссылке с чужого сайта), язык, разрешение дисплея и так далее. Порой обнаруживаются интересные детали – например, может обнаружится, что при планировании отбросили разрешения экрана до 1280х640, но оказалось, что среди пользователей это до сих пор популярно (пример надуман).
Если интересна разбивка по версиям конкретной системы – все доступно при нажатии на название ОС.
В Screen Resolutions доступны разрешения экрана.
Browsers сделаны аналогично операционным системам – иерархия название браузера->версия.
Global покажет географическое расположение пользователей и запросов. Не всегда полезная для аналитики информация, так как многие пользователи предпочитают ходить через ресурсы других государств.
Нажатие на расположение приведет к более детальному отображению – по странам. Все это полезно, когда мы пишем глобальный проект, и нам, например, интересно понять динамику приходящих из конкретных стран клиентов, и сконцентрировать усилия менеджеров по продаже именно на этих странах либо регионах.
Languages – язык, который прописан в запросах от пользователей. Полезно, когда нам нужно понять, на какой из Language Pack для нашего проекта нужно сконцентрировать особое внимание.
Резюме
Application Insights выглядит интересным инструментом, который может стать неплохим помощником для разработчиков, работающих над проектами совершенно разного уровня – от локальных или интранет-приложений до глобальных корпоративных проектов. Учитывая тот факт, что AI бесплатен для VSO, в котором меньше пяти пользователей, этот инструмент обязательно нужно попробовать – вдруг именно его не хватает в вашем повседневном наборе разработчика.
This entry passed through the Full-Text RSS service — if this is your content and you're reading it on someone else's site, please read the FAQ at http://ift.tt/jcXqJW.
Комментариев нет:
Отправить комментарий