David O'Brien lancerede for nylig sit eget firma, Xirus (https://xirus.com.au), med fokus på Microsoft Azure Stack cloud-produkter. De er designet til konsekvent at bygge og køre hybridapplikationer i datacentre, kantplaceringer, fjernkontorer og skyen.
David træner enkeltpersoner og virksomheder i alt, hvad Microsoft Azure og Azure DevOps (tidligere VSTS) angår, og han udfører stadig praktisk rådgivning og infrakodning. Han har været en Microsoft MVP (Microsoft Most Valuable Professional) Award-vinder i 5 år og modtog for nylig Azure MVP Award. Som medarrangør af Melbourne Microsoft Cloud og Datacentre Meetup taler O'Brien regelmæssigt ved internationale konferencer og kombinerer sin interesse for at rejse verden rundt med en passion for at dele it-historier med samfundet. Davids blog er placeret på , udgiver han også sin online træning på Pluralsight.
Foredraget taler om vigtigheden af metrics for at forstå, hvad der sker i dit miljø, og hvordan din applikation klarer sig. Microsoft Azure har en kraftfuld og nem måde at vise metrics for alle slags arbejdsbelastninger, og foredraget forklarer, hvordan du kan bruge dem alle.
Klokken 3 om morgenen på en søndag, mens du sover, bliver du pludselig vækket af en sms: "superkritisk app svarer ikke igen." Hvad sker der? Hvor og hvad er årsagen til "bremserne"? I dette foredrag lærer du om de tjenester, som Microsoft Azure tilbyder kunder til at indsamle logfiler og især metrics fra dine cloud-arbejdsbelastninger. David vil fortælle dig, hvilke metrics du bør være interesseret i, når du arbejder på en cloud-platform, og hvordan du kommer til dem. Du lærer om open source-værktøjer og opbygning af dashboards og ender med tilstrækkelig viden til at skabe dine egne dashboards.
Og hvis du bliver vækket igen klokken 3 af en besked om, at en kritisk applikation er gået ned, kan du hurtigt finde ud af årsagen.
God eftermiddag, i dag vil vi tale om metrics. Mit navn er David O'Brien, jeg er medstifter og ejer af et lille australsk konsulentfirma, Xirus. Tak igen, fordi du kom her for at bruge din tid sammen med mig. Så hvorfor er vi her? For at tale om metrikker, eller rettere, vil jeg fortælle dig om dem, og før vi gør nogen ting, lad os starte med teorien.
Jeg fortæller dig, hvad metrics er, hvad du kan gøre med dem, hvad du skal være opmærksom på, hvordan du indsamler og aktiverer metrics-indsamling i Azure, og hvad metricsvisualisering er. Jeg viser dig, hvordan disse ting ser ud i Microsoft-skyen, og hvordan du arbejder med denne sky.
Før vi begynder, vil jeg bede om håndsoprækning fra dem, der bruger Microsoft Azure. Hvem arbejder med AWS? Jeg ser få. Hvad med Google? ALI Cloud? En mand! Store. Så hvad er metrics? Den officielle definition af US National Institute of Standards and Technology er: "En metrik er en målestandard, der beskriver betingelserne og reglerne for måling af en ejendom og tjener til at forstå måleresultaterne." Hvad betyder det?
Lad os tage et eksempel på en metrik til at ændre den ledige diskplads på en virtuel maskine. For eksempel får vi tallet 90, og dette tal betyder procent, det vil sige mængden af ledig diskplads er 90%. Jeg bemærker, at det ikke er særlig interessant at læse beskrivelsen af definitionen af metrics, som tager 40 sider i pdf-format.
Metrikken siger dog ikke, hvordan måleresultatet blev opnået, den viser kun dette resultat. Hvad gør vi med metrics?
Først måler vi værdien af noget for derefter at bruge måleresultatet.
For eksempel fandt vi ud af mængden af ledig diskplads, og nu kan vi bruge den, bruge denne hukommelse osv. Når vi har modtaget det metriske resultat, skal vi fortolke det. For eksempel returnerede metrikken et resultat på 90. Vi skal vide, hvad dette tal betyder: mængden af ledig plads eller mængden af brugt diskplads i procent eller gigabyte, netværksforsinkelse svarende til 90 ms, og så videre, dvs. , skal vi fortolke betydningen af den metriske værdi. For overhovedet at være meningsfulde, skal vi efter fortolkning af en enkelt metrisk værdi sikre, at der indsamles flere værdier. Dette er meget vigtigt, fordi mange mennesker ikke er klar over behovet for at indsamle metrics. Microsoft har gjort det meget nemt at indsamle metrics, men det er op til dig at sikre, at de bliver indsamlet. Disse målinger gemmes i kun 41 dage og forsvinder på den 42. dag. Derfor bør du, afhængigt af egenskaberne for dit eksterne eller interne udstyr, sørge for, hvordan du gemmer metrics i mere end 41 dage - i form af logs, logs mv. Efter indsamling bør du derfor placere dem et sted, der giver dig mulighed for at hente alle statistikker over ændringer i metriske resultater, hvis det er nødvendigt. Når du har lagt dem der, kan du begynde at arbejde med dem effektivt.
Først efter at du har opnået metrikken, fortolket dem og indsamlet dem, kan du oprette en SLA - serviceniveauaftale. Denne SLA er måske ikke af stor betydning for dine kunder; den er vigtigere for dine kolleger, ledere, dem, der vedligeholder systemet og er bekymrede for dets funktionalitet. Metrikken kan måle antallet af billetter - for eksempel modtager du 5 billetter om dagen, og i dette tilfælde viser den hastigheden af svar på brugeranmodninger og hastigheden af fejlfinding. En metric skal ikke bare sige, at dit websted indlæses på 20 ms, eller at din responshastighed er 20 ms, en metrisk er mere end blot én teknisk indikator.
Derfor er opgaven med vores samtale at præsentere dig for et detaljeret billede af essensen af metrikker. Metrikken tjener til, at du ved at se på den kan få et komplet billede af processen.
Når vi har metrikken, kan vi 99% garantere, at systemet fungerer, for det er ikke kun at se på en logfil, der siger, at systemet virker. En 99% oppetidsgaranti betyder, at for eksempel 99% af tiden API'en reagerer med en normal hastighed på 30 ms. Det er netop det, der interesserer dine brugere, dine kolleger og ledere. Mange af vores kunder overvåger webserverlogs, men de bemærker ingen fejl i dem og tror, at alt er i orden. For eksempel ser de en netværkshastighed på 200 Mb/s og tænker: "ok, alt er fantastisk!" Men for at opnå disse 200 skal brugerne have en responshastighed på 30 millisekunder, og det er netop den indikator, der ikke måles og ikke samles i logfiler. Samtidig er brugerne overraskede over, at webstedet indlæses meget langsomt, fordi de ikke har de nødvendige målinger, og de kender ikke årsagerne til denne adfærd.
Men da vi har en 100 % oppetid SLA, begynder kunderne at klage, fordi siden faktisk er meget svær at bruge. For at skabe en objektiv SLA er det derfor nødvendigt at se det komplette billede af processen skabt af de indsamlede metrics. Dette er et løbende problem, jeg har med nogle udbydere, som, når de opretter SLA'er, ikke aner, hvad udtrykket "oppetid" betyder, og i de fleste tilfælde ikke forklarer deres kunder, hvordan deres API fungerer.
Hvis du har oprettet en tjeneste, for eksempel en API til en tredje person, bør du forstå, hvad den resulterende metrik på 39,5 betyder - svar, vellykket svar, svar ved 20 ms hastighed eller 5 ms hastighed. Det er op til dig at tilpasse deres SLA til din egen SLA, til dine egne metrics.
Når du har fundet ud af alt dette, kan du begynde at skabe et fantastisk dashboard. Fortæl mig, har nogen allerede brugt Grafana interaktiv visualiseringsapplikation? Store! Jeg er en stor fan af denne open source, fordi denne ting er gratis og nem at bruge.
Hvis du ikke har brugt Grafana endnu, vil jeg fortælle dig, hvordan du arbejder med det. Enhver født i 80'erne og 90'erne husker sikkert CareBears? Jeg ved ikke, hvor populære disse bjørne var i Rusland, men når det kommer til målinger, burde vi være de samme "plejebjørne". Som sagt skal du have et stort billede af, hvordan hele systemet fungerer, og det skal ikke kun handle om din API, din hjemmeside eller den service, der kører i en virtuel maskine.
Du skal organisere indsamlingen af de metrics, der bedst afspejler driften af hele systemet. De fleste af jer er softwareudviklere, så dit liv ændrer sig konstant, tilpasser sig nye produktkrav, og ligesom du er optaget af kodningsprocesser, bør du bekymre dig om metrics. Du skal vide, hvordan metrikken relaterer sig til hver linje kode, du skriver. For eksempel starter du i næste uge en ny marketingkampagne og forventer, at et stort antal brugere besøger dit websted. For at analysere denne begivenhed skal du bruge metrics, og du har muligvis brug for et helt dashboard til at spore disse personers aktivitet. Du skal bruge målinger for at forstå, hvor vellykket din marketingkampagne er, og hvordan den rent faktisk klarer sig. De hjælper dig for eksempel med at udvikle et effektivt CRM - customer relationship management system.
Så lad os komme i gang med vores Azure cloud-tjeneste. Det er meget nemt at finde og organisere metriksamling, fordi den har Azure Monitor. Denne skærm centraliserer din systemkonfigurationsstyring. Hvert af de Azure-elementer, som du vil anvende på dit system, har mange metrics aktiveret som standard. Dette er et gratis program, der fungerer lige ud af æsken og ikke kræver nogen foreløbige indstillinger; du behøver ikke at skrive eller "skrue" noget til dit system. Vi vil bekræfte dette ved at se på følgende demo.
Derudover er det muligt at sende disse metrics til tredjepartsapplikationer, såsom Splunk-loglagrings- og analysesystemet, den skybaserede logadministrationsapplikation SumoLogic, ELK-logbehandlingsværktøjet og IBM Radar. Sandt nok er der små forskelle, der afhænger af de ressourcer, du bruger - en virtuel maskine, netværkstjenester, Azure SQL-databaser, det vil sige, at brugen af metrics varierer afhængigt af funktionerne i dit arbejdsmiljø. Jeg vil ikke sige, at disse forskelle er alvorlige, men desværre er de stadig til stede, og det bør tages i betragtning. Aktivering og afsendelse af metrics er muligt på flere måder: gennem Portal, CLI/Power Shell eller ved at bruge ARM-skabeloner.
Inden jeg starter min første demo, vil jeg besvare alle spørgsmål, du måtte have. Hvis der ikke er nogen spørgsmål, så lad os komme i gang. Skærmen viser, hvordan Azure Monitor-siden ser ud. Kan nogen af jer sige, at denne skærm ikke virker?
Så nu er alt fint, du kan se, hvordan skærmtjenesterne ser ud. Jeg kan sige, at dette er et fremragende og meget enkelt værktøj til hverdagsarbejde. Det kan bruges til at overvåge applikationer, netværk og infrastruktur. For nylig er overvågningsgrænsefladen blevet forbedret, og hvis tidligere tjenester var placeret forskellige steder, er alle informationer om tjenester nu konsolideret på skærmens hjemmeside.
Metric-tabellen er en fane langs HomeMonitorMetrics-stien, som du kan gå til for at se alle tilgængelige metrics og vælge dem, du har brug for. Men hvis du har brug for at aktivere metrics-indsamling, skal du bruge HomeMonitorDiagnostic-indstillingsmappestien og markere afkrydsningsfelterne Aktiverede/Deaktiverede metrics. Som standard er næsten alle metrics aktiveret, men hvis du har brug for at aktivere noget yderligere, skal du ændre diagnosticeringsstatussen fra Deaktiveret til Aktiveret.
For at gøre dette skal du klikke på linjen for den valgte metrisk og på fanen, der åbner, aktivere diagnostisk tilstand. Hvis du skal analysere den valgte metrik, skal du, efter at have klikket på linket Slå diagnostik til, markere afkrydsningsfeltet Send til loganalyse i det vindue, der vises.
Log Analytics minder lidt om Splunk, men koster mindre. Denne service giver dig mulighed for at samle alle dine metrics, logfiler og alt andet, du har brug for, og placere dem i Log Analytics-arbejdsområdet. Tjenesten bruger et særligt KQL-forespørgselsbehandlingssprog - Kusto Quarry Language, vi vil se på dets arbejde i næste demo. Indtil videre vil jeg bemærke, at du med dens hjælp kan oprette forespørgsler vedrørende målinger, logfiler, termer, trends, mønstre osv. og oprette dashboards.
Så vi markerer afkrydsningsfeltet Send til Log Analytics og LOG-panelets afkrydsningsfelter: DataPlaneRequests, MongoRequests og QueryRuntimeStatistics, og nedenfor på METRIC-panelet – afkrydsningsfeltet Requests. Derefter tildeler vi et navn og gemmer indstillingerne. På kommandolinjen repræsenterer dette to linjer kode. I øvrigt ligner Azure Cloud-skallen i denne forstand Google, som også giver dig mulighed for at bruge kommandolinjen i din webbrowser. AWS har ikke noget lignende, så Azure er meget mere praktisk i denne forstand.
For eksempel kan jeg køre en demo gennem webgrænsefladen uden at bruge nogen kode på min bærbare computer. For at gøre dette skal jeg godkende med min Azure-konto. Så kan du bruge fx terrafone, hvis du allerede bruger det, vent på forbindelsen til tjenesten og få det Linux arbejdsmiljø som Microsoft bruger som standard.
Dernæst bruger jeg Bash, indbygget i Azure Cloud Shell. En meget nyttig ting er IDE indbygget i browseren, en letvægtsversion af VS Code. Dernæst kan jeg gå ind i min skabelon for fejlmålinger, redigere den og tilpasse den, så den passer til mine behov.
Når du har konfigureret metrics-indsamling i denne skabelon, kan du bruge den til at oprette metrics for hele din infrastruktur. Når vi har anvendt metrics, indsamlet dem og gemt dem, bliver vi nødt til at visualisere dem.
Azure Monitor beskæftiger sig kun med metrics og giver ikke et samlet billede af dit systems tilstand. Du har muligvis en række andre programmer, der kører uden for Azure-miljøet. Så hvis du skal overvåge alle processer, visualisere alle de indsamlede metrics på ét sted, så er Azure Monitor ikke egnet til dette.
For at løse dette problem tilbyder Microsoft Power BI-værktøjet, en omfattende software til forretningsanalyse, der inkluderer visualisering af en lang række data. Dette er et ret dyrt produkt, hvis omkostninger afhænger af det sæt funktioner, du har brug for. Som standard tilbyder den dig 48 slags data at behandle og er knyttet til Azure SQL Data Warehouses, Azure Data Lake Storage, Azure Machine Learning Services og Azure Databricks. Ved at bruge skalerbarhed kan du modtage nye data hvert 30. minut. Dette er muligvis eller ikke tilstrækkeligt til dine behov, hvis du har brug for realtidsovervågningsvisualisering. I dette tilfælde anbefales det at bruge applikationer som den Grafana, jeg nævnte. Derudover beskriver Microsoft-dokumentationen muligheden for at sende metrics, logfiler og hændelsestabeller ved hjælp af SIEM-værktøjer til visualiseringssystemerne Splunk, SumoLogic, ELK og IBM radar.
23:40 min
Fortsættes meget snart...
Nogle annoncer 🙂
Tak fordi du blev hos os. Kan du lide vores artikler? Vil du se mere interessant indhold? Støt os ved at afgive en ordre eller anbefale til venner, , en unik analog af entry-level servere, som blev opfundet af os til dig: (tilgængelig med RAID1 og RAID10, op til 24 kerner og op til 40 GB DDR4).
Dell R730xd 2 gange billigere i Equinix Tier IV datacenter i Amsterdam? Kun her i Holland! Dell R420 - 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB - fra $99! Læse om
Kilde: www.habr.com