Нещодавно Девід О'Брайєн відкрив свою власну компанію Xirus (https://xirus.com.au), зосередившись на хмарних продуктах Microsoft Azure Stack. Вони призначені для узгодженого створення та запуску гібридних додатків у центрах обробки даних, у прикордонних розташуваннях, віддалених офісах та хмарі.
Девід навчає окремих осіб та компанії всьому, що пов'язано з Microsoft Azure та Azure DevOps (колишньому VSTS) і досі займається практичним консультуванням та інфракодуванням. Він уже 5 років є володарем премії Microsoft MVP (найцінніший професіонал Майкрософт), а нещодавно отримав нагороду MVP Azure. Як співорганізатор Melbourne Microsoft Cloud і Datacentre Meetup, О'Брайєн регулярно виступає на міжнародних конференціях, поєднуючи свій інтерес до подорожей світом із пристрастю ділитися ІТ-історіями з спільнотою. Блог Девіда знаходиться за адресою Він також публікує свої онлайн-тренінги з Pluralsight.
У виступі розповідається про важливість метрик для розуміння того, що відбувається у вашому середовищі та того, як працює ваш додаток. Microsoft Azure має потужний і простий спосіб відображення метрик для всіх видів робочих навантажень, і в лекції говориться, як можна їх використовувати.
О 3 годині ночі, в неділю, під час сну вас раптово будить сигнал текстового повідомлення: "надкритичний додаток знову не відповідає". Що ж відбувається? Де і в чому причина «гальм»? З цієї доповіді ви дізнаєтеся про сервіси, які Microsoft Azure пропонує клієнтам для збирання логів і, зокрема, метрик ваших робочих навантажень. Девід розповість, які метрики повинні вас цікавити під час роботи на хмарній платформі і як дістатися до них. Ви дізнаєтеся про інструменти з відкритим вихідним кодом та побудову панелей моніторингу і в результаті отримаєте достатньо знань для створення власних панелей.
І якщо вас о 3-й ночі знову розбудить повідомлення про падіння критичної програми, ви зможете швидко розібратися в його причині.
Доброго дня, сьогодні ми говоритимемо про метрики. Мене звуть Девід О'Браєн, я співзасновник і власник невеликої консалтингової австралійської компанії Xirus. Ще раз дякую за те, що прийшли сюди провести зі мною свій час. Тож навіщо ми тут? Щоб поговорити про метрики, точніше, я розповім вам про них, і перш ніж робити якісь речі, почнемо з теорії.
Я розповім, що таке метрики, що можна з ними зробити, на що потрібно звернути увагу, як збирати та включати збір метрик у Azure та що таке візуалізація метрик. Я покажу вам, як виглядають ці речі в хмарі Microsoft і як працювати з цією хмарою.
Перш ніж розпочати, я попрошу підняти руки тих, хто використовує Microsoft Azure. А хто працює з AWS? Я бачу, мало хто. А з Google? ALI Cloud? Одна людина! Чудово. Що таке метрики? Офіційне визначення Національного інституту стандартів і технологій США виглядає так: «Метрика – це стандарт виміру, який описує умови та правила виконання виміру будь-якої властивості та служить для розуміння результатів виміру». Що це означає?
Розглянемо для прикладу метрику зміни вільного простору диска віртуальної машини. Наприклад, нам видається число 90 і це число означає відсотки, тобто обсяг вільного простору диска становить 90%. Зазначу, що не дуже цікаво читати опис визначення метрик, який займає 40 сторінок у форматі PDF.
Однак метрика не каже, яким чином отримано результат виміру, вона лише показує цей результат. Що ж ми робимо із метриками?
По-перше, вимірюємо значення чогось, щоб потім використовувати результат виміру.
Наприклад, ми дізналися про обсяг вільного простору диска і тепер можемо його використовувати, використовувати цю пам'ять і т.д. Після того, як ми отримали результат метрики, ми маємо його інтерпретувати. Наприклад, метрика видала результат 90. Ми повинні знати, що означає це число: обсяг вільного простору або обсяг зайнятого простору диска у відсотках або гігабайтах, латентність мережі, що дорівнює 90 мс, і так далі, тобто нам потрібно витлумачити значення метрики. Для того, щоб метрики взагалі мали сенс, після інтерпретації одного значення метрики нам потрібно забезпечити збирання безлічі значень. Це дуже важливо, оскільки багато людей не усвідомлюють необхідності збирання метрик. Microsoft зробила дуже легким процес отримання метрик, але ви самі маєте забезпечити їх збір. Ці метрики зберігаються лише 41 день і на 42-й день зникають. Тому залежно від властивостей вашого зовнішнього чи внутрішнього обладнання ви повинні потурбуватися про те, як зберігати метрики більш ніж 41 день — у вигляді логів, журналів тощо. Таким чином, після збору ви повинні розмістити їх у якомусь місці, що дозволяє за необхідності підняти всю статистику зміни результатів метрик. Помістивши їх туди, ви зможете розпочати з ними ефективну роботу.
Тільки після того, як ви отримаєте значення метрик, інтерпретуєте їх та зберете, ви зможете створити SLA – угоду про рівень надання послуги. Цей SLA може не мати особливого значення для ваших клієнтів, він важливіший для ваших колег, менеджерів, тих, хто забезпечує роботу системи та стурбований її функціональністю. Метрика може вимірювати кількість тикетів - наприклад, ви отримуєте 5 тикетів на день, і в даному випадку вона показує швидкість реагування на запити користувачів та швидкість усунення несправностей. Метрика не повинна просто повідомляти, що ваш сайт завантажується за 20 мс або швидкість відповіді становить 20 мс, метрика – це більше ніж просто один технічний показник.
Тому завдання нашої розмови – уявити вам розгорнуту картину суті метрик. Метрика служить для того, щоб глянувши на неї, ви змогли отримати повну картину процесу.
Як тільки ми одержали метрику, то можемо на 99% гарантувати робочий стан системи, тому що це не просто погляд на лог-файл, в якому написано, що система працює. Гарантія 99% працездатності означає, що, наприклад, у 99% випадків API відповідає нормальної швидкості 30 мс. Це саме те, що цікавить ваших користувачів, ваших колег та менеджерів. Багато наших клієнтів відстежують логи веб-серверів, при цьому вони не помічають у них жодних помилок і думають, що все гаразд. Наприклад, вони бачать показник швидкості мережі 200 Мб/с і думають: «ок, все чудово!». Але щоб досягти цих 200, користувачам потрібна швидкість відповіді в 30 мілісекунд, і це саме той показник, який не вимірюється та не збирається у лог-файлах. При цьому користувачі дивуються, що сайт дуже повільно завантажується, тому що, не маючи потрібної метрики, не знають причини такої поведінки.
Але оскільки у нас є SLA, що гарантує 100% працездатності, клієнти починають висловлювати обурення, тому що насправді сайт дуже важко користуватися. Тому для створення об'єктивного SLA необхідно бачити повну картину процесу, створювану метриками, що збираються. Це предмет моєї постійної суперечки з деякими провайдерами, які при створенні SLA не уявляють, що означає термін «uptime», і в більшості випадків не пояснюють своїм клієнтам, як працює їх API.
Якщо ви створили сервіс, наприклад API для третьої особи, ви повинні розуміти, що означає отримана метрика 39,5 – відповідь, вдала відповідь, відповідь на швидкості 20 мс або на швидкості 5 мс. Саме ви повинні адаптувати їх SLA до свого власного SLA, до своїх власних метриків.
З'ясувавши все це, можна розпочати створення шикарної панелі моніторингу. Скажіть, хто вже користувався додатком для інтерактивної візуалізації Grafana? Чудово! Я великий фанат цього open source, тому що ця штука є безкоштовною і нею легко користуватися.
Якщо ви ще не користувалися Grafana, я розповім, як із нею працювати. Хто народився у 80-90-х, мабуть, пам'ятає дбайливих ведмежат CareBears? Не знаю, наскільки ці ведмедики були популярні в Росії, але щодо метрик ми повинні виступати такими ж «дбайливими ведмедиками». Як я сказав, вам потрібна розгорнута картина роботи всієї системи, і вона не повинна стосуватися тільки вашого API, вашого сайту або служби, запущеної на віртуальній машині.
Ви повинні організувати збирання тих метрик, які найбільш повно відображають роботу всієї системи. Більшість із вас є розробниками ПЗ, тому ваше життя постійно змінюється, пристосовуючись до нових вимог продукту, і так само, як ви стурбовані процесами кодування, ви повинні перейматися метриками. Ви повинні знати, як метрика стосується кожного рядка написаного вами коду. Наприклад, наступного тижня ви починаєте нову маркетингову компанію і очікуєте, що ваш сайт відвідає велику кількість користувачів. Для аналізу цієї події вам знадобляться метрики, і, можливо, потрібна буде ціла панель для відстеження активності цих людей. Метрики знадобляться для того, щоб розібратися, наскільки вдала і як насправді працює ваша маркетингова компанія. Вони допоможуть вам, наприклад, розробити ефективну систему CRM — систему управління взаємовідносин з клієнтами.
Отже, давайте приступимо до нашого хмарного сервісу Azure. У ньому дуже легко знаходити та організовувати збір метрик, тому що тут є Azure Monitor. Цей монітор централізує керування конфігурацією вашої системи. Кожен із елементів Azure, який ви хочете застосувати у своїй системі, має безліч включених за замовчуванням метрик. Це безкоштовна програма, яка працює прямо «з коробки» і не вимагає жодних попередніх налаштувань, вам не потрібно нічого писати та «прикручувати» до своєї системи. Ми переконаємось у цьому, переглянувши наступне демо.
Крім того, є можливість відправляти ці метрики стороннім додаткам, таким як система зберігання та аналізу логів Splunk, хмарна програма з управління логами SumoLogic, інструмент для обробки логів ELK, IBM Radar. Правда, тут є невеликі відмінності, які залежать від використовуваних вами ресурсів – віртуальної машини, мережевих сервісів, баз даних Azure SQL, тобто використання метриків відрізняється залежно від функцій вашого робочого середовища. Не скажу, що ці відмінності серйозні, але, на жаль, вони все ж таки присутні, і це слід враховувати. Увімкнення та пересилання метрик можливе кількома способами: через Portal, CLI/Power Shell або за допомогою шаблонів ARM.
Перш ніж приступити до першої демонстрації, я відповім на питання, які у вас є. Якщо питань немає, почнемо. На екрані показано, як виглядає сторінка Azure Monitor. Хтось із вас може сказати, що цей монітор не працює?
Отже, тепер все гаразд, ви бачите як виглядають сервіси монітора. Можу сказати, що це чудовий та дуже простий інструмент для повсякденної роботи. З його допомогою можна здійснювати моніторинг програм, мережі та інфраструктури. Нещодавно інтерфейс моніторингу був покращений, і якщо раніше послуги розташовувалися в різних місцях, то зараз вся інформація по сервісах консолідується на домашній сторінці монітора.
Таблиця метрик – це вкладка по дорозі HomeMonitorMetrics, на яку можна зайти, щоб побачити всі метрики і вибрати необхідні. Але якщо вам потрібно включити збір метрик, потрібно використати шлях каталогу HomeMonitorDiagnostic settings та перевірити чекбокси метрик Enabled/Disabled. За замовчуванням практично всі метрики перебувають у включеному стані, але якщо потрібно включити щось додаткове, то вам доведеться змінити статус діагностики з Disabled на Enabled.
Для цього потрібно клікнути по рядку обраної метрики і на вкладці, що відкрилася, включити режим діагностики. Якщо ви збираєтеся аналізувати обрану метрику, то після натискання на посилання Turn on diagnostic потрібно відзначити в вікні чекбокс Send to Log Analytics.
Log Analytics трохи схожий на Splunk, але коштує дешевше. Цей сервіс дозволяє збирати всі ваші метрики, логи та все, що вам знадобиться, та розміщувати їх у робочому просторі Log Analytics. Сервіс використовує спеціальну мову обробки запитів KQL – Kusto Quarry Language, її роботу ми розглянемо у наступному демо. Поки що зазначу, що за його допомогою ви можете формувати запити щодо метрик, ліг, термінів, тенденцій, шаблонів тощо. та створювати панелі моніторингу.
Отже, ми відзначаємо чекбокс Send to Log Analytics та чекбокси панелі LOG: DataPlaneRequests, MongoRequests та QueryRuntimeStatistics, а нижче на панелі METRIC – чекбокс Requests. Потім присвоюємо якесь ім'я і зберігаємо налаштування. У командному рядку це два рядки коду. До речі, оболонка Azure Cloud у цьому сенсі нагадує Google, який також дозволяє використовувати командний рядок у вашому веб-браузері. AWS не має нічого подібного, тому Azure в цьому сенсі набагато зручніше.
Наприклад, я можу запустити демо через веб-інтерфейс, не використовуючи для цього жодного коду на своєму ноутбуці. Для цього я маю пройти автентифікацію за допомогою свого облікового запису Azure. Далі можна використовувати, наприклад, terrafone, якщо ви вже користуєтеся, дочекатися підключення до сервісу і отримати робоче середовище Linux, яке Microsoft використовує за умовчанням.
Далі я використовую Bash, вбудований в Azure Cloud Shell. Дуже корисною штукою є вбудований у браузер IDE, полегшена версія VS Code. Далі я можу зайти до свого шаблону метрики помилок, змінити його та налаштувати під свої потреби.
Налаштувавши в цьому шаблоні збір метрик, можна застосувати його для створення метрик для всієї своєї інфраструктури. Після того, як ми застосували метрики, зібрали та зберегли їх, нам знадобиться їх візуалізувати.
Azure Monitor займається лише метриками і не дає змоги отримати загальну картину стану вашої системи. У вас може використовуватися низка інших програм, які запущені поза середовищем Azure. Отже, якщо вам потрібно моніторити всі процеси, візуалізувавши всі зібрані метрики в одному місці, то Azure Monitor для цього не підійде.
Для вирішення цього завдання Microsoft пропонує інструмент Power BI - комплексне ПЗ для бізнес аналізу, що включає візуалізацію різних даних. Це досить дорогий продукт, вартість якого залежить від необхідного набору функцій. За замовчуванням він пропонує вам 48 видів оброблюваних даних та пов'язаний із сховищами даних SQL Azure, Azure Data Lake Storage, службами машинного навчання Azure та Azure Databricks. Використовуючи масштабованість, ви можете кожні 30 хвилин отримувати нові дані. Це може бути достатньо для ваших потреб або не достатньо, якщо вам потрібна візуалізація моніторингу в режимі реального часу. У цьому випадку рекомендується використовувати такі програми, як згадану мною Grafan. Крім того, у документації Microsoft описана можливість відправки метрик, логів та таблиць подій за допомогою SIEM – інструментів у системи візуалізації Splunk, SumoLogic, ELK та IBM radar.
23:40 хв
Продовження буде зовсім скоро.
Небагато реклами 🙂
Дякую, що залишаєтеся з нами. Вам подобаються наші статті? Бажаєте бачити більше цікавих матеріалів? Підтримайте нас, оформивши замовлення або порекомендувавши знайомим, , унікальний аналог entry-level серверів, який був винайдений нами для Вас: (Доступні варіанти з RAID1 і RAID10, до 24 ядер і до 40GB DDR4).
Dell R730xd вдвічі дешевше в дата-центрі Equinix Tier IV в Амстердамі? Тільки в нас у Нідерландах! Dell R420 – 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB – від $99! Читайте про те
Джерело: habr.com