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

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

Дейвид обучава индивиди и компании за всичко, свързано с Microsoft Azure и Azure DevOps (бивш VSTS) и продължава да предоставя практически консултации и инфракодиране. Той е носител на награда Microsoft MVP (Най-ценен професионалист на Microsoft) вече 5 години и наскоро получи наградата MVP Azure. Като съорганизатор на Melbourne Microsoft Cloud и Datacentre Meetup, О'Брайън редовно изнася лекции на международни конференции, съчетавайки интереса си към пътуванията по света с желанието да споделя ИТ истории със общността. Блогът на Дейвид може да бъде намерен на david-obrien.net, той също така публикува онлайн обучения в 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 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 Е5-2650 v4 на стойност 9000 евро за копейки?

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