Recent David O’Brien launched his own company Xirus (https://xirus.com.au), focusing on Microsoft Azure Stack cloud products. These are designed for consistent creation and deployment of hybrid applications in data centers, edge locations, remote offices, and the cloud.
David trains individuals and companies on all things related to Microsoft Azure and Azure DevOps (formerly VSTS) and continues to engage in hands-on consulting and infrastructure coding. He has been a Microsoft MVP (Most Valuable Professional) for 5 years and recently received the MVP Azure award. As a co-organizer of the Melbourne Microsoft Cloud and Datacentre Meetup, O’Brien regularly speaks at international conferences, combining his interest in traveling the world with a passion for sharing IT stories with the community. David's blog can be found at , where he also publishes his online training sessions on Pluralsight.
The presentation discusses the importance of metrics for understanding what is happening in your environment and how your application operates. Microsoft Azure provides a powerful and straightforward way to display metrics for all types of workloads, and the lecture covers how to utilize them all.
At 3 a.m. on a Sunday, you are suddenly awakened by a text alert: 'a critical application is unresponsive again.' What’s going on? Where and what is causing the 'slowdowns'? This talk will introduce you to the services Microsoft Azure offers clients for log collection and specifically for metrics of your cloud workloads. David will explain which metrics should be of interest when working on a cloud platform and how to access them. You will learn about open-source tools and dashboard building, ultimately gaining enough knowledge to create your own dashboards.
And if at 3 a.m. you are once again awakened by a message about a critical application failure, you will be able to quickly understand the cause.
Bună ziua, azi vom vorbi despre metrici. Mă numesc David O’Brien, sunt co-fondator și proprietar al unei mici companii de consultanță din Australia, Xirus. Vă mulțumesc încă o dată că ați venit aici să-mi petreceți timpul. Așadar, de ce suntem aici? Pentru a discuta despre metrici; mai exact, eu vă voi vorbi despre ele, și înainte de a face ceva, să începem cu teoria.
Voi explica ce sunt metricile, ce se poate face cu ele, la ce trebuie să acordați atenție, cum să colectați și să includeți colectarea metricilor în Azure și ce înseamnă vizualizarea metricilor. Voi arăta cum arată aceste lucruri în cloud-ul Microsoft și cum să lucrați cu acest cloud.
Înainte de a începe, vă rog să ridicați mâinile cei care folosesc Microsoft Azure. Cine lucrează cu AWS? Văd că sunt câțiva. Dar cu Google? ALI Cloud? Un singur om! Grozav. Așadar, ce sunt metricile? Definiția oficială a Institutului Național de Standarde și Tehnologie din SUA este: „Metrica este un standard de măsurare care descrie condițiile și regulile de efectuare a măsurării unei proprietăți și servește la înțelegerea rezultatelor măsurării.” Ce înseamnă acest lucru?
Să luăm, de exemplu, o metrică pentru schimbarea spațiului liber pe disk al unei mașini virtuale. De exemplu, ni se dă numărul 90, iar acest număr reprezintă un procent, adică volumul de spațiu liber pe disk este de 90%. Aș dori să subliniez că nu este foarte interesant să citim o descriere a definiției metricilor care ocupă 40 de pagini în format PDF.
Metica însă nu spune cum a fost obținut rezultatul măsurării, ci doar arată acest rezultat. Ce facem cu metricile?
În primul rând, măsurăm valoarea a ceva pentru a folosi apoi rezultatul măsurării.
De exemplu, am aflat volumul de spațiu liber pe disc și acum putem să-l folosim, să utilizăm această memorie etc. După ce am obținut rezultatul metricii, trebuie să-l interpretăm. De exemplu, metrica a returnat un rezultat de 90. Trebuie să știm ce înseamnă acest număr: volumul de spațiu liber sau volumul de spațiu ocupat pe disc în procente sau gigaocteți, latența rețelei, care este de 90 ms etc., adică trebuie să interpretăm semnificația valorii metricii. Pentru ca metricile să aibă sens, după interpretarea unei valori de metrică, trebuie să ne asigurăm că strângem mai multe valori. Acest lucru este foarte important, deoarece mulți oameni nu conștientizează necesitatea strângerii metricilor. Microsoft a facilitat mult procesul de obținere a metricilor, dar trebuie să vă ocupați singuri de strângerea acestora. Aceste metrici sunt păstrate timp de doar 41 de zile și în a 42-a zi dispar. Așadar, în funcție de proprietățile echipamentului vostru extern sau intern, trebuie să vă preocupați de cum să păstrați metricile mai mult de 41 de zile - sub formă de loguri, jurnale etc. Astfel, după strângere, trebuie să le depozitați într-un loc care permite, dacă este necesar, să accesați întreaga statistică a modificării rezultatelor metricilor. Punându-le acolo, veți putea începe să lucrați eficient cu ele.
Numai după ce obțineți valorile metricilor, le interpretați și le strângeți, veți putea crea un SLA - acord de nivel de serviciu. Acest SLA poate să nu aibă mare importanță pentru clienții dumneavoastră, fiind mai important pentru colegii, managerii și cei care se ocupă de funcționarea sistemului și sunt preocupați de funcționalitatea acestuia. Metrica poate măsura numărul de ticheturi - de exemplu, primiți 5 ticheturi pe zi, iar în acest caz arată viteza de reacție la cererile utilizatorilor și rapiditatea soluționării problemelor. Metrica nu trebuie să spună doar că site-ul dvs. se încarcă într-un timp de 20 ms sau că viteza de răspuns este de 20 ms; metrica reprezintă mai mult decât o simplă indicator tehnic.
Prin urmare, scopul discuției noastre este să vă prezentăm o imagine detaliată a esenței metricilor. Metrica servește pentru ca, uitându-vă la ea, să puteți obține o imagine completă a procesului.
Odată ce am primit metrica, putem garanta cu 99% siguranță funcționarea sistemului, deoarece nu este vorba doar de o privire asupra jurnalelor, în care se spune că sistemul funcționează. O garanție de 99% a funcționalității înseamnă că, de exemplu, în 99% din cazuri, API-ul răspunde cu o viteză normală de 30 ms. Exact asta îi interesează pe utilizatorii, colegii și managerii dvs. Mulți dintre clienții noștri monitorizează jurnalele serverelor web, fără a observa nicio eroare în ele, și cred că totul este în regulă. De exemplu, ei văd indicatorul de viteză a rețelei de 200 mb/s și cred: „ok, totul este excelent!”. Dar pentru a obține acele 200, utilizatorii au nevoie de un timp de răspuns de 30 de milisecunde, iar acesta este exact indicatorul care nu este măsurat și nu este colectat în jurnalele. Utilizatorii sunt surprinși că site-ul se încarcă foarte încet, deoarece, fără metrica necesară, nu știu cauza acestui comportament.
Dar, deoarece avem un SLA care garantează 100% funcționalitate, clienții încep să exprime nemulțumiri, deoarece în realitate utilizarea site-ului este foarte dificilă. Prin urmare, pentru a crea un SLA obiectiv, trebuie să vedem imaginea de ansamblu a procesului, creată prin metricile colectate. Acesta este subiectul disputelor mele constante cu anumite furnizori, care, în crearea SLA-ului, nu își imaginează ce înseamnă termenul „uptime” și, în majoritatea cazurilor, nu explică clienților lor cum funcționează API-ul lor.
Dacă ați creat un serviciu, de exemplu, un API pentru o terță parte, trebuie să înțelegeți ce înseamnă metrica obținută de 39,5 – un răspuns, un răspuns reușit, un răspuns la o viteză de 20 ms sau la o viteză de 5 ms. Este responsabilitatea dvs. să adaptați SLA-ul lor la propriul dvs. SLA, la propriile dvs. metrici.
După ce am clarificat toate acestea, putem începe să creăm un panou de monitorizare impresionant. Spuneți-mi, a folosit cineva aplicația de vizualizare interactivă Grafana? Grozav! Sunt un mare fan al acestui open source, deoarece este gratuit și ușor de utilizat.
Dacă nu ați folosit încă Grafana, vă voi arăta cum să lucrați cu ea. Cei născuți în anii '80 și '90 își amintesc probabil de urșii grijulii CareBears? Nu știu cât de populari au fost acești ursuleți în Rusia, dar în ceea ce privește metricile, trebuie să ne comportăm ca niște «ursuleți grijulii». Așa cum am spus, aveți nevoie de o imagine de ansamblu asupra activității întregului sistem, care să nu se limiteze doar la API-ul dumneavoastră, site-ul dumneavoastră web sau serviciul care rulează pe o mașină virtuală.
Trebuie să organizați colectarea metricilor care reflectă cel mai bine activitatea întregului sistem. Majoritatea dintre voi sunteți dezvoltatori de software, așa că viața voastră se schimbă constant, adaptându-se noilor cerințe ale produsului, și la fel cum sunteți preocupat de procesele de codare, trebuie să vă faceți griji și pentru metrici. Trebuie să știți în ce mod metrica se leagă de fiecare linie de cod pe care o scrieți. De exemplu, săptămâna viitoare începeți o nouă campanie de marketing și vă așteptați ca site-ul dumneavoastră să fie vizitat de un număr mare de utilizatori. Pentru a analiza acest eveniment, veți avea nevoie de metrici, iar poate va fi necesar un întreg tablou de bord pentru a urmări activitatea acestor oameni. Metricile vă vor fi necesare pentru a înțelege cât de reușită este și cum funcționează în realitate campania dumneavoastră de marketing. Ele vă pot ajuta, de exemplu, să dezvoltați un CRM eficient — un sistem de management al relațiilor cu clienții.
Așadar, haideți să ne îndreptăm spre serviciul nostru cloud Azure. Aici este foarte ușor să găsiți și să organizați colectarea metricilor, deoarece existe Azure Monitor. Acest monitor centralizează gestionarea configurației sistemului dumneavoastră. Fiecare dintre elementele Azure pe care doriți să le implementați în sistemul dumneavoastră are o mulțime de metrici incluse în mod implicit. Este o aplicație gratuită care funcționează direct «din cutie» și nu necesită configurații prealabile, nu trebuie să scrieți nimic și să «atașați» la sistemul dumneavoastră. Ne vom convinge de acest lucru prin vizionarea următorului demo.
În plus, există posibilitatea de a trimite aceste metrici către aplicații terțe, cum ar fi sistemul de stocare și analiză a jurnalelor Splunk, aplicația cloud pentru gestionarea jurnalelor SumoLogic, instrumentul de procesare a jurnalelor ELK, IBM Radar. Totuși, există mici diferențe, care depind de resursele pe care le folosiți – mașini virtuale, servicii de rețea, baze de date Azure SQL, adică utilizarea metricilor variază în funcție de funcțiile mediu de lucru. Nu pot spune că aceste diferențe sunt semnificative, dar, din păcate, există și ar trebui luate în considerare. Activarea și trimiterea metricilor este posibilă prin mai multe metode: prin Portal, CLI/Power Shell sau folosind șabloane ARM.
Înainte de a începe prima demonstrație, voi răspunde la întrebările pe care le aveți. Dacă nu sunt întrebări, putem începe. Pe ecran este arătat cum arată pagina Azure Monitor. Poate cineva dintre voi poate spune că acest monitor nu funcționează?
Așadar, acum totul este în regulă, vedeți cum arată serviciile monitorului. Pot spune că este un instrument excelent și foarte simplu pentru activitățile zilnice. Cu ajutorul lui, puteți monitoriza aplicații, rețele și infrastructură. Recent, interfața de monitorizare a fost îmbunătățită, iar dacă înainte serviciile erau dispersate în diferite locuri, acum toate informațiile despre servicii sunt consolidate pe pagina principală a monitorului.
Tabloul de bord al metricilor este un tab de pe calea HomeMonitorMetrics, la care se poate accesa pentru a vedea toate metricile disponibile și a alege cele necesare. Dar dacă aveți nevoie să activați colectarea metricilor, trebuie să folosiți calea din catalogul HomeMonitorDiagnostic settings și să verificați casetele de selectare pentru metricile Enabled/Disabled. În mod implicit, aproape toate metricile sunt activate, dar, dacă trebuie să activați ceva suplimentar, va trebui să schimbați starea de diagnosticare din Disabled în Enabled.
Pentru aceasta, trebuie să faceți clic pe linia metricii selectate și pe tab-ul care se deschide, să activați modul de diagnosticare. Dacă intenționați să analizați metricul selectat, după apăsarea pe linkul Turn on diagnostic, trebuie să bifezi caseta de selectare Send to Log Analytics care apare în fereastra deschisă.
Log Analytics este oarecum similar cu Splunk, dar este mai ieftin. Acest serviciu permite colectarea tuturor metricelor, jurnalelor și a tot ceea ce aveți nevoie, organizându-le în spațiul de lucru Log Analytics. Serviciul folosește un limbaj special de procesare a interogărilor, KQL – Kusto Query Language, pe care îl vom explora în următorul demo. Deocamdată, ar trebui menționat că, cu ajutorul său, puteți forma interogări privind metricile, jurnalele, termenii, tendințele, tiparele etc. și puteți crea tablouri de bord.
Așadar, bifăm checkbox-ul Send to Log Analytics și checkbox-urile de pe tabloul LOG: DataPlaneRequests, MongoRequests și QueryRuntimeStatistics, iar mai jos, pe tabloul METRIC – checkbox-ul Requests. Apoi, atribuim un nume și salvăm setările. În linia de comandă, aceasta reprezintă două linii de cod. Apropo, interfața Azure Cloud seamănă în acest sens cu Google, care permite de asemenea utilizarea liniei de comandă în browser. AWS nu are nimic similar, așa că Azure este mult mai convenabil în acest sens.
De exemplu, pot lansa demo-ul prin interfața web, fără a folosi cod pe laptopul meu. Pentru aceasta, trebuie să mă autentific cu contul meu Azure. Apoi, pot folosi, de exemplu, terrafone, dacă deja îl folosiți, aștept conectați la serviciu și primesc un mediu de lucru Linux, care este utilizat implicit de Microsoft.
Apoi, folosesc Bash-ul integrat în Azure Cloud Shell. Un lucru foarte util este IDE-ul integrat în browser, o versiune simplificată a VS Code. Apoi, pot accesa șablonul meu de metrică de erori, să-l modific și să-l configurez conform nevoilor mele.
După ce ați configurat colectarea metricelor în acest șablon, îl puteți aplica pentru a crea metrici pentru întreaga dvs. infrastructură. După ce am aplicat metricile, le-am colectat și salvate, va trebui să le vizualizăm.
Azure Monitor se ocupă doar de metrici și nu oferă posibilitatea de a obține o imagine de ansamblu a stării sistemului dumneavoastră. Puteți utiliza o serie de alte aplicații care rulează în afara mediului Azure. Așadar, dacă trebuie să monitorizați toate procesele, vizualizând toate metricile colectate într-un singur loc, atunci Azure Monitor nu este potrivit pentru aceasta.
Pentru a aborda această problemă, Microsoft oferă instrumentul Power BI – un software cuprinzător pentru analiza business-ului, care include vizualizarea unei varietăți de date. Acesta este un produs destul de costisitor, a cărui preț depinde de setul de funcții necesar pentru dumneavoastră. În mod implicit, acesta vă oferă 48 de tipuri de date prelucrate și este legat de depozitele de date SQL Azure, Azure Data Lake Storage, serviciile de învățare automată Azure și Azure Databricks. Folosind scalabilitatea, puteți obține date noi la fiecare 30 de minute. Acesta poate fi suficient pentru nevoile dumneavoastră sau nu, dacă aveți nevoie de vizualizare în timp real. În acest caz, se recomandă utilizarea unor aplicații precum Grafana, menționată de mine. În plus, documentația Microsoft descrie posibilitatea de a trimite metrici, jurnale și tabele de evenimente folosind SIEM – instrumente în sistemele de vizualizare Splunk, SumoLogic, ELK și IBM radar.
23:40 min
Continuarea va veni foarte curând…
Puțin publicitate 🙂
Mulțumim că rămâneți cu noi. Vă plac articolele noastre? Doriți să vedeți mai multe materiale interesante? Susțineți-ne, efectuând o comandă sau recomandându-ne prietenilor, , un echivalent unic pentru serverele entry-level, care a fost creat de noi pentru voi: (sunt disponibile opțiuni cu RAID1 și RAID10, până la 24 nuclee și până la 40GB DDR4).
Dell R730xd la jumătate de preț în centrul de date Equinix Tier IV din Amsterdam? Numai la noi în Olanda! Dell R420 — 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB — de la 99 $! Citiți despre
Sursa: habr.com
