Application Insights. Про аналітику та інші нові інструменти

Близько року тому я написав невелику статтю про використання превью версії Microsoft сервісу діагностики і моніторингу Application Insights (AI). З тих пір в AI з'явилося дуже багато цікавих доповнень. І ось, трохи більше місяця тому, AI нарешті отримав General Availability.



У цій статті я проведу ще один огляд AI, з урахуванням нових доповнень, і поділюся досвідом його використання на реальних проектах.

Почну з того, що я працюю в Лабораторії Касперського, в команді, яка займається розробкою .NET сервісів. В основному в якості хостингу ми використовуємо хмарні платформи Microsoft і Amazon. Наші сервіси обробляють досить високе навантаження від мільйонів користувачів і забезпечують високу продуктивність. Нам важливо підтримувати хорошу репутацію сервісів, для досягнення якої потрібно дуже швидко реагувати на проблеми і знаходити «вузькі місця», які можуть вплинути на продуктивність. Подібні проблеми можуть виникати при генерації аномально високою навантаження або ж неспецифічного користувацької активності, різних відмовах інфраструктурних (наприклад, БД) або зовнішніх сервісів, також ніхто не скасовував і банальні помилки в логіці сервісів.

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

AI – це багатоплатформовий інструмент для збору і візуалізації діагностичної телеметрії. Якщо у вас, наприклад, .NET додаток, то для підключення AI вам достатньо створити контейнер AI на порталі Microsoft Azure, після цього підключити до додатка nugget пакет ApplicationInsigts.

Буквально з коробки AI почне збирати інформацію по основним лічильників продуктивності машини (пам'ять, процесор), на якій працює ваша програма.

Подібну серверну телеметрію можна почати збирати і без модифікації коду програми: для цього досить на машину встановити спеціальний діагностичний агент. Список стягуються лічильників може бути змінений правкою файлу ApplicationInsights.config.

image
Наступний цікавий момент — це «моніторинг залежностей». AI відстежує всі вихідні зовнішні HTTP виклики вашого додатка. Під зовнішніми викликами або залежностях розуміються звернення вашого додатка до бази даних та іншим third party сервісів. Якщо ваш додаток являє собою сервіс, хостящійся в інфраструктурі IIS, то AI буде перехоплювати телеметрію по всім запитам до ваших сервісів, включаючи всі зовнішні запити (завдяки пробросу додаткової діагностичної інформації через CallContext потоку). Тобто завдяки цьому ви зможете знайти що цікавить вас запит, а також подивитися всі його залежності. Application Map дозволяє вам переглянути повну карту за зовнішнім залежностях вашого додатка.


Якщо у вашій системі мають місце явні проблеми з зовнішніми сервісами, то теоретично ця картинка здатна дати вам деяку інформацію про проблему.

Ви можете зануритися глибше для більш детального вивчення інформації за зовнішніми запитами


Незалежно від платформи ви можете підключити до вашого додатком розширюване Application Insights API, який дозволить вам зберігати довільну телеметрію. Це можуть бути логи або які-небудь кастомні лічильники продуктивності.

Наприклад, ми пишемо в AI агреговану інформацію по усім основним методам наших сервісів, таку як кількість викликів, відсоток помилок і час виконання операцій. Крім цього ми зберігаємо інформацію критично важливим областям додатки, таких як продуктивність і доступність зовнішніх сервісів, розміри черг повідомлень (Azure Queue, ServiceBus), пропускну здатність їх обробки і т. п.

Моніторинг залежностей, про який я писав раніше, досить потужний інструмент, але на даний момент він здатний автоматично перехоплювати тільки всі вихідні HTTP запити, тому ми змушені самостійність писати телеметрію по залежностях, які викликалися через інший транспорт. У нашому випадку це Azure ServiceBus і RMQ, які працюють за кастомным протоколами.

Телеметрія, яку ви збираєте не обов'язково повинна мати плоску структуру (counterName-counterValue). Вона може містити багаторівневу структуру з різним вкладеністю. Це досягається за рахунок використання динамічного типу даних.

Приклад структури зберігається метрики
{
"metric": [ ],
"context": {
...
"custom": {
"dimensions": [
{ "ProcessId": "4068" }
],
"metrics": [
{
"dispatchRate": {
"value": 0.001295,
"count": 1.0,
"min": 0.001295,
"max": 0.001295,
"stdDev": 0.0,
"sampledValue": 0.001295,
"sum": 0.001295
}
},
"durationMetric": {
"name": "коваленко.org",
"type": "Aggregation",
"value": 468.71603053650279,
"count": 1.0,
"min": 468.71603053650279,
"max": 468.71603053650279,
"stdDev": 0.0,
"sampledValue": 468.71603053650279
}
} ] }
}


AI дозволяв писати подібну складну телеметрію і рік тому, але її практично не можна було використовувати, оскільки в той час графіки можна було будувалися тільки за простим метрик. Єдиним варіантом використання цієї телеметрії були кастомні запити, які могли оцінювати тільки частоту виникнення. Тепер же з'явився дуже потужний інструмент Analytics.

Даний інструмент дозволяє вам писати різні запити до вашої телеметрії, звертаючись за допомогою спеціального (SQL-подібні мови до властивостей довільних подій.

Для прикладу синтаксису, можна подивитися на запит, який виводить 10 будь-яких успішних запитів до вашого веб-додатки за останні 10 хвилин:

requests | where success == "True" and timestapm > ago(10m) | take 10

В комплекті даної мови є безліч готових операторів для аналізу (агрегатні функції і з'єднання, пошук перцентилей, медіан, побудова звітів тощо) і візуалізації телеметрії у вигляді графіків.





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

До складу AI входить компонент ProactiveDetection, який на основі алгоритмів машинного навчання здатний визначати аномалії у збирається телеметрії. Наприклад, кількість запитів до ваших сервісів різко зросла чи впало, збільшилася кількість помилок або сумарна тривалість деяких операцій.


Ви також можете налаштувати алерти на потрібні вам лічильники телеметрії.

AI зберігає телеметрію протягом 30 днів. Якщо вам цього недостатньо, то ви можете скористатися функцією Continues Export, яка дозволить вам експортувати телеметрію в Azure Blobs. Використання Azure Stream Analytics при пошуку в експортованої телеметрії вакансій, що вас закономірностей є хорошою практикою.

Power BI потужний інструмент для візуалізації та аналізу даних. Ви можете підключити до нього спеціальний Application Insights Power BI adapter і автоматично переправляти деяку діагностику в Power BI. Для цього достатньо побудувати в Analytics потрібний запит і натиснути кнопку експорту. В результаті цього ви отримаєте невеликий M-скрипт, який буде використовуватися в якості джерела даних AI.



Іноді зручно спостерігати в реальному часі за здоров'ям системи. Особливо це актуально після установки оновлень. Зовсім недавно в AI з'явився інструмент Live Metrics Stream, який дає таку можливість.


AI може також виступати і в якості сервісу моніторингу. Ви можете імпортувати тести з Visual Studio, перевіряють працездатність вашого додатка. Або ви можете прямо з порталу AI створити набір перевірок для геораспределенной валідації доступності вакансій, що вас кінцевих точок. AI буде виконувати перевірки за розкладом і виводити результати на відповідний графік.

Існує також спеціальний плагін, який дозволяє відображати телеметрію c отлаживаемого в дабеге програми прямо в Visual Studio.

Це далеко не всі інструменти. Рекомендується також використовувати AI і для аналізу користувача телеметрії.

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

Цією рекомендацією варто керуватися і виходячи з того, що троттлінг AI не дасть вам зберігати більше 300 діагностичних подій в секунду. З залежностями все складніше.

Наприклад, у наших сервісах БД викликається приблизно 10 тисяч разів в секунду. AI ж зберігає загальний rate запитів, але детальна інформація (тривалість, URL, код повернення тощо) збережеться тільки по кільком сотням запитів, дані по іншим запитам губляться. Незважаючи на це, нам поки вистачає даних для локалізації виникаючих проблем.

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

Продовжуємо стежити за подальшим розвитком даного інструменту.
Джерело: Хабрахабр

0 коментарів

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