Нядаўна Дэвід О'Браэн адкрыў сваю ўласную кампанію 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 у 2 разы танней у дата-цэнтры Equinix Tier IV у Амстэрдаме? Толькі ў нас у Нідэрландах! Dell R420 – 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB – ад $99! Чытайце аб тым
Крыніца: habr.com