Використання Visual Studio Application Insights — досвід інженера з тестування

Висловлюємо велике спасибі за підготовку статті Ігорю Щегловитову, старшому інженерові з тестування з Лабораторії Касперського, за допомогу в написанні цієї статті і цінний практичний досвід. Інші наші статті по темі Azure можна знайти по тегу azureweek, а також по тегу mstesting — статті з тестування.
Application Insights (надалі просто AI)– це механізм для збору та аналізу користувача телеметрії: різних лічильників продуктивності, подій (логів) і тп. На поточний момент він підтримує не тільки ASP.NET додатки, але і інші, в тому числі Java, IOS, JavaScript та ін



При підключенні та налаштування пакету AI він за замовчуванням починає збирати деякі показники, наприклад для веб-додатків це інформація за запитами до веб сервера, а також різні серверні лічильники (наприклад, час запиту, завантаження CPU). Крім цього, AI має розширене API, який дозволяє зберігати кастомні і бізнес-лічильники і логи.
Наша команда займається розробкою хмарних сервісів Azure. Логи зберігаються в Azure Storage, а лічильники продуктивності (серверні і перфоманс), читаються та аналізуються в автоматичному режимі окремим сервером моніторингу. Для логування ми використовуємо Serilog. На відміну від інших логгерів, він (коробки) дозволяє писати структурні логи, виділяючи окремі властивості.
В даний час для безлічі популярых логгерів, таких як Serilog, log4net, Nlog існують доповнення, які дозволяють передавати логи в AI. Якщо ви користуєтеся даними логерами, а також маєте активну підписку Azure, то можете спробувати в безкоштовному режимі можливості AI.

Нижче приклад налаштування Serilog для збереження логів в AI:

Через NuGet підключаємо пакет Serilog.Sinks.ApplicationInsights:


(даний пакет автоматично підключить залежний від нього Application Insights API)

Далі, при конфігуруванні логера Serilog, треба вказати розширення ApplicationInsights, наприклад, ось так:

Log.Logger = new LoggerConfiguration().WriteTo.ApplicationInsights(string.Empty).CreateLogger();

У Azure порталі попередньою версією створюємо новий контейнер Application Insigts



Після створення, на вкладці «Основне» копіюємо ключ инструментирования



Тепер в коді перед стартом програми слід прописати:
TelemetryConfiguration.Active.InstrumentationKey = "{ключ-инструментирования}";

Якщо ж ви, наприклад, використовуєте логуванняNlog, то для перенапрвления логів вAIдосить підключити пакет"Application Insights NlogTarget"


Після цього в конфіги програми автоматично з'явиться секція:
<nlog>
<extensions>
<add assembly="Microsoft.ApplicationInsights.NLogTarget"/>
</extensions>
<targets>
<target type="ApplicationInsightsTarget" name="aiTarget"/>
</targets>
<rules>
<logger name=".*" minlevel="Trace" writeTo="aiTarget"/>
</rules>
</nlog>

Основна проблема при використанніNLog— він дозволяє писати тільки рядки, без загальних властивостей. Крім використання логеров, користувальницькі події вAIможна відправляти і черезAPIось приклад:


<I>var</I><I> telemetry = new</I><I>TelemetryClient</I><I>(</I><I>);</I>
<I>...</I>
<I>try </I>
<I>{ </I>
<I>var</I><I>eventTelemetry</I><I> = new</I><I>EventTelemetry</I><I>("log"); </I>
<I>eventTelemetry</I><I>. Properties["</I><I>CustomProperty</I><I>"] = "test"; </I>
<I>telemetry.Track</I><I>(</I><I>eventTelemetry</I><I>);</I>
<I>catch (Exception ex)</I>
<I>{</I>
<I></I><I>var</I><I> properties = new Dictionary <string, string> </I>
<I> {{"</I><I>CustomProperty</I><I> ","test"}};</I>
<I></I><I>telemetry.TrackException</I><I>(ex, properties);</I>
<I>} </I>

Тепер, після запуску програми, логи будуть перенаправлятися в AI.

На відміну від лог-форвадеров, явне використання AI API дозволяє писати телеметрію в різні контейнери AI. Це зручно, коли у вас велике додаток, що складається з безлічі компонентів: сервісів, веб інтерфейсу і тп. У цьому разі при відправленні телеметрії в AI, у примірниках TelemetryClient ви можете явно задавати властивість InstrumentationKey.

Наприклад, для вашої програми ви створили три різних контейнера: один для аналізу продуктивності, інший для логів, третій для моніторингу користувача активності. Що стосується останнього, для аналізу користувацької активності UI додатків в AI API передбачений спеціальний метод TrackPageView. Ви можете зберігати дані, по яким сторінок (вкладок) заходив той чи інший користувач (нагадаю, що зберігати події в AI можна і безпосередньо у JavaScript коді), на основі чого можна робити якісь висновки.

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



Причому кожне логируемое окремо властивість індексується і ви можете фільтрувати логи за конкретним значенням, через меню фільтра:



Це дуже зручно, оскільки дозволяє відстежувати появу нових подій, наприклад, якихось нових винятків.

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

Крім логів, якщо у вас веб-додаток (наприклад MVC Web API), то, підключивши Nuget пакет Application Insights Web (без будь-яких додаткових налаштувань), AI буде потрапляти інформація по всіх веб запитам.



Крім цього, AI буде збирати залежності, пов'язані із запитами. Наприклад, при HTTP-запиті стався виклик БД. В логах AI ви побачите цю зв'язок, а також інформацію по пов'язаному запитом (URL, код повернення ...).

Крім цього, на вкладці «Сервери» будуть доступні різні серверні лічильники продуктивності (CPU, Memory ...). За замовчуванням їх не так багато, але через ApplicationInsights.config ви можете додати ті лічильники, які вам потрібні.



Використовуючи функціональність правил оповіщення, ви можете створити правило, при настанні якого на вказаний e-mail буде приходити відповідна нотифікація (наприклад, перевищено граничне значення CPU).

У нашій команді ми розробляємо асинхронні сервіси. Ми не використовує транзакції в прямому сенсі цього слова. Для забезпечення цілісності даних при виконання тривалих БЖ, коли при виклику одного API методу стан об'єктів БД змінюється більш ніж 1 разів, ми використовуємо черги і Service Bus (для прикладу: API-метод провалидировал дані, змінив стан об'єкта, відправив повідомлення-команду в чергу і повернув результат викликається стороні; обробник черзі підняв повідомлення, виконав якесь дію і поклав нове повідомлення в чергу і так далі).

Кількість логів, які створюються при одному такому БЖ, може досягати десятків записів. Для їх зв'язки ми використовуємо спеціальний кастомный хедер conversationId. Він пробрасывается у всіх командах і повідомленнях при виконанні всього процесу. Даний хедер може бути заданий викликає стороною. Він логируется як настроюється властивість. Таким чином вказавши значення conversationId у вікні пошуку, можна отримати всю ланцюжок логів БЖ:



Крім експлуатації, такий підхід дуже корисний і при інтеграційному тестуванні.
Я займаюся розробкою інтеграційних тестів для наших хмарних сервісів. Автоматизовані тестові сценарії живуть в MTM, запускаються через спеціальний білд. Тести в більшості випадків клієнт-серверні. За повідомленням з помилкою в інформації впав тесту далеко не завжди зрозуміла причина падіння. Часто для діагностики потрібні саме серверні логи. Окремо шукати і дивитися логи по кожному тесту не зручно і займає багато часу. Тут мені на допомогу прийшла така функціональність, як кастомні діагностичні адаптери MSTest.

Якщо коротко, то під діагностичним адаптером в даному контексті розуміється збірка, що містить спеціальний клас, який успадковується від Microsoft.VisualStudio.TestTools.Execution.DataCollector. Якщо тест агент налаштований на використання даного діагностичного адаптера, то під час виконання тесту запускаються відповідні подія, логіка якого визначена в методах OnTestCaseStart, OnTestCaseEnd. В цих методах, у вас є доступ до контексту тесту, в тому числі до його назви, станом і тп. Ось приклад реалізації діагностичного адаптера:

[DataCollectorConfigurationEditor("configurationeditor://CompanyName/LogConfigEditor/4.0")]
[DataCollectorTypeUri("datacollector://CompanyName/LogCollector/4.0")]
[DataCollectorFriendlyName("log collector.")]
public class LogCollecter : DataCollector
{
public override void Initialize(
XmlElement configurationElement,
DataCollectionEvents events,
DataCollectionSink sink,
DataCollectionLogger logger,
DataCollectionEnvironmentContext environmentContext)
{
_stopwatch = new Stopwatch();

_dataEvents = events; // The test events
_dataLogger = logger; // The error log and warning
_dataSink = sink;

Configuration.Init(configurationElement);
events.TestCaseStart += OnTestCaseStart;
events.TestCaseEnd += OnTestCaseEnd;
}
private void OnTestCaseStart(object sender, TestCaseEventArgs e)
{
_stopwatch.Start();
}
private void OnTestCaseEnd(object sender, TestCaseEndEventArgs e)
{
Guard.CheckNotNull(e, "TestCaseFailedEventArgs is null");

var testCaseEndDate = DateTime.Now;
if (_stopwatch.IsRunning)
{
_stopwatch.Stop();
}
if (e.TestOutcome == TestOutcome.Failed)
{
//Тут можна зібрати логи і прикріпити їх до результату тесту.
_dataSink.SendFileAsync(e.Context, Configuration.ZipFilePath, true);
}
}
private Stopwatch _stopwatch;
private DataCollectionEvents _dataEvents;
private DataCollectionLogger _dataLogger;
private DataCollectionSink _dataSink;
}

Після реалізації діагностичного адаптера, збірку з ним треба підкласти на всі сервери з встановленими тестовими агентами (включаючи машину, на якій відбувається конфігурування налаштувань Lab Management), в папку %Microsoft Visual Studio 12.0\Common7\IDE\PrivateAssemblies\DataCollectors.

Далі запустити MTM, і поставити галочку навпроти адаптера.



Більш детально про діагностичні адаптори, форми їх конфігурації та налаштування читайте тут msdn.microsoft.com/en-us/library/dd286727.aspx.

В кожному тестовому класі, в методі TestInitialize був доданий код ініціалізації conversationId, який надалі проставляється в хедерах при створенні wcf і http клієнтів. Даний сonversationId шарився з діагностичним адаптером. І при виникненні помилки в результатах тесту з'являвся інформації про conversationId. А знаючи conversationId через AI можна дуже просто подивитися всі серверні події, пов'язані з конкретним тестом.

Application Insights — це дуже потужний інструмент, який дозволяє підключити до вашого додатком збір різної діагностичної телеметрії, а також спростити її подальший візуальний аналіз використовуючи дружній інтерфейс порталу. Якщо у вас є підписка Azure, то ви можете використовувати AI в двох режимах Free і Premium. Основне обмеження Free режиму – максимальна кількість користувальницьких події – 5 млн в місяць, і додаються дані зберігаються протягом 7 днів, після чого видаляються. У версії Premium ці обмеження зняті. Безкоштовно можна використати протягом 30 днів.

Різні корисні ресурси


Джерело: Хабрахабр

0 коментарів

Тільки зареєстровані та авторизовані користувачі можуть залишати коментарі.