Дейвид О’Брайън (Xirus): Метрики! Метрики! Метрики! Част 1

Наскоро Дейвид О’Брайън основа собствена компания Xirus (https://xirus.com.au), която се фокусира върху облачните продукти на Microsoft Azure Stack. Те са предназначени за последователно изграждане и стартиране на хибридни приложения в центрове за данни, на ръба, в дистанционни офиси и в облака.

Дейвид обучава физически лица и компании на всичко, свързано с Microsoft Azure и Azure DevOps (бивш VSTS) и все още предлага практически консултации и инфраструктурно кодиране. Той вече 5 години е носител на наградата Microsoft MVP (Най-ценен професионалист на Майкрософт) и наскоро получи наградата MVP Azure. Като съорганизатор на Meetup Melbourne Microsoft Cloud и Datacentre, О’Брайън редовно участва в международни конференции, съчетавайки страстта си към пътуванията с желанието си да споделя ИТ истории с общността. Блогът на Дейвид е на адрес david-obrien.net, той също така публикува своите онлайн обучения в Pluralsight.

В изказването се обсъжда важността на метриките за разбиране на това, което се случва в средата ви и как функционира приложението ви. Microsoft Azure предлага мощен и опростен начин за визуализиране на метрики за всички видове работни натоварвания, а в лекцията се обсъжда как можете да ги използвате.

В 3 часа през нощта, в неделя, по време на сън, ви съbudи изведнъж сигнал от текстово съобщение: “свръхкритичното приложение отново не отговаря”. Какво се случва? Къде и каква е причината за „забавянето“? От това доклад ще научите за услугите, които 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? Чудесно! Аз съм голям фен на този проект с отворен код, защото е безплатен и е лесен за използване.

Ако все още не сте ползвали 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 Query 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 минути да получавате нови данни. Това може да бъде достатъчно за вашите нужди или недостатъчно, ако ви е необходима визуализация на мониторинга в реално време. В такъв случай е препоръчително да се използват приложения като споменатото от мен Grafana. Освен това, в документацията на Microsoft е описана възможността за изпращане на метрики, логове и таблици за събития с помощта на SIEM - инструменти в системи за визуализация Splunk, SumoLogic, ELK и IBM radar.

23:40 мин

Продължението ще бъде съвсем скоро…

Малко реклама 🙂

Благодарим ви, че оставате с нас. Харесвате ли нашите статии? Искате ли да виждате повече интересни материали? Подкрепете ни, като направите поръчка или препоръчате на познати, облачни VPS за разработчици от $4.99, уникален аналог на entry-level сървъри, който е създаден от нас за вас: Цялата истина за VPS (KVM) E5-2697 v3 (6 ядра) 10GB DDR4 480GB SSD 1Gbps от $19 или как да делите правилно сървър? (с налични опции за RAID1 и RAID10, до 24 ядра и до 40GB DDR4).

Dell R730xd на половин цена в дата центъра Equinix Tier IV в Амстердам? Всичко това само при нас 2 х Intel TetraDeca-Core Xeon 2x E5-2697v3 2.6GHz 14C 64GB DDR4 4x960GB SSD 1Gbps 100TB от 199 $ в Нидерландия! Dell R420 — 2x E5-2430 2.2GHz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB — от 99 $! Чете се за това Как да построим инфраструктура от корпоративен клас с помощта на сървъри Dell R730xd E5-2650 v4 на стойност 9000 евро за малко пари?

Източник: habr.com