David O'Brien lanserte nylig sitt eget selskap, Xirus (https://xirus.com.au), med fokus på Microsoft Azure Stack-skyprodukter. De er designet for å konsekvent bygge og kjøre hybridapplikasjoner i datasentre, kantplasseringer, eksterne kontorer og skyen.
David trener enkeltpersoner og bedrifter i alt som har med Microsoft Azure og Azure DevOps (tidligere VSTS) å gjøre, og driver fortsatt med praktisk rådgivning og infrakoding. Han har vært en Microsoft MVP (Microsoft Most Valuable Professional) Award-vinner i 5 år og mottok nylig Azure MVP Award. Som medarrangør av Melbourne Microsoft Cloud and Datacentre Meetup, taler O'Brien regelmessig på internasjonale konferanser, og kombinerer sin interesse for å reise verden rundt med en lidenskap for å dele IT-historier med samfunnet. Davids blogg ligger på , publiserer han også sin nettbaserte opplæring på Pluralsight.
Foredraget snakker om viktigheten av beregninger for å forstå hva som skjer i miljøet ditt og hvordan applikasjonen din fungerer. Microsoft Azure har en kraftig og enkel måte å vise beregninger for alle slags arbeidsbelastninger, og foredraget forklarer hvordan du kan bruke dem alle.
Klokken 3 på en søndag, mens du sover, blir du plutselig vekket av en tekstmelding: "superkritisk app svarer ikke igjen." Hva skjer? Hvor og hva er årsaken til "bremsene"? I denne foredraget vil du lære om tjenestene som Microsoft Azure tilbyr kunder for å samle inn logger og spesielt beregninger fra skyarbeidsbelastningene dine. David vil fortelle deg hvilke beregninger du bør være interessert i når du jobber på en skyplattform og hvordan du kommer til dem. Du vil lære om åpen kildekode-verktøy og dashbordbygging, og ende opp med nok kunnskap til å lage dine egne dashboards.
Og hvis du blir vekket igjen klokken 3 av en melding om at en kritisk applikasjon har krasjet, kan du raskt finne årsaken.
God ettermiddag, i dag skal vi snakke om beregninger. Mitt navn er David O'Brien, jeg er medgründer og eier av et lite australsk konsulentselskap, Xirus. Takk igjen for at du kom hit for å tilbringe tiden din med meg. Så hvorfor er vi her? For å snakke om beregninger, eller rettere sagt, vil jeg fortelle deg om dem, og før du gjør noen ting, la oss starte med teorien.
Jeg skal fortelle deg hva metrikk er, hva du kan gjøre med dem, hva du må være oppmerksom på, hvordan du samler inn og aktiverer metrikkinnsamling i Azure, og hva metrikkvisualisering er. Jeg skal vise deg hvordan disse tingene ser ut i Microsoft-skyen og hvordan du jobber med denne skyen.
Før vi begynner, vil jeg be om håndsopprekning fra de som bruker Microsoft Azure. Hvem jobber med AWS? Jeg ser få. Hva med Google? ALI Cloud? En mann! Flott. Så hva er beregninger? Den offisielle definisjonen av US National Institute of Standards and Technology er: "En metrikk er en målestandard som beskriver betingelsene og reglene for å måle en eiendom og tjener til å forstå måleresultatene." Hva betyr det?
La oss ta et eksempel på en beregning for å endre ledig diskplass til en virtuell maskin. For eksempel får vi tallet 90, og dette tallet betyr prosent, det vil si at mengden ledig diskplass er 90%. Jeg legger merke til at det ikke er særlig interessant å lese beskrivelsen av definisjonen av metrikk, som tar 40 sider i pdf-format.
Beregningen sier imidlertid ikke hvordan måleresultatet ble oppnådd, den viser kun dette resultatet. Hva gjør vi med beregninger?
Først måler vi verdien av noe for deretter å bruke måleresultatet.
For eksempel fant vi ut hvor mye ledig diskplass og nå kan vi bruke det, bruke dette minnet osv. Når vi har mottatt det metriske resultatet, må vi tolke det. For eksempel returnerte metrikken et resultat på 90. Vi må vite hva dette tallet betyr: mengden ledig plass eller mengden brukt diskplass i prosent eller gigabyte, nettverksforsinkelse lik 90 ms, og så videre, dvs. , må vi tolke betydningen av den metriske verdien. For at beregninger i det hele tatt skal være meningsfulle, etter å ha tolket en enkelt metrisk verdi, må vi sørge for at flere verdier samles inn. Dette er veldig viktig fordi mange mennesker ikke er klar over behovet for å samle inn beregninger. Microsoft har gjort det veldig enkelt å samle inn beregninger, men det er opp til deg å sørge for at de blir samlet inn. Disse beregningene lagres i bare 41 dager og forsvinner på den 42. dagen. Derfor, avhengig av egenskapene til ditt eksterne eller interne utstyr, bør du ta vare på hvordan du lagrer beregninger i mer enn 41 dager - i form av logger, logger, etc. Derfor, etter innsamling, bør du plassere dem på et sted som lar deg hente opp all statistikk over endringer i metriske resultater om nødvendig. Når du har lagt dem der, kan du begynne å jobbe med dem effektivt.
Først etter at du har skaffet deg beregningene, tolket dem og samlet dem, kan du opprette en SLA - service level agreement. Denne serviceavtalen er kanskje ikke så viktig for kundene dine; den er viktigere for dine kolleger, ledere, de som vedlikeholder systemet og er bekymret for funksjonaliteten. Beregningen kan måle antall billetter - for eksempel mottar du 5 billetter per dag, og i dette tilfellet viser den hastigheten på svar på brukerforespørsler og hastigheten på feilsøkingen. En beregning skal ikke bare si at nettstedet ditt laster inn på 20 ms eller at responshastigheten er 20 ms, en beregning er mer enn bare én teknisk indikator.
Derfor er oppgaven med samtalen vår å gi deg et detaljert bilde av essensen av beregninger. Beregningen tjener slik at du ved å se på den kan få et fullstendig bilde av prosessen.
Når vi har metrikken, kan vi 99% garantere at systemet fungerer, fordi det ikke bare ser på en loggfil som sier at systemet fungerer. En 99 % oppetidsgaranti betyr at for eksempel 99 % av tiden API-en svarer med en normal hastighet på 30 ms. Det er nettopp dette som interesserer dine brukere, dine kolleger og ledere. Mange av våre kunder overvåker webserverlogger, men de merker ingen feil i dem og tror at alt er i orden. For eksempel ser de en nettverkshastighet på 200 Mb/s og tenker: "ok, alt er bra!" Men for å oppnå disse 200 trenger brukerne en responshastighet på 30 millisekunder, og det er nettopp denne indikatoren som ikke måles og ikke samles i loggfiler. Samtidig er brukere overrasket over at nettstedet laster veldig sakte, fordi de ikke har de nødvendige beregningene, og vet ikke årsakene til denne oppførselen.
Men siden vi har en 100 % oppetid SLA, begynner kunder å klage fordi siden faktisk er veldig vanskelig å bruke. Derfor, for å lage en objektiv SLA, er det nødvendig å se det fullstendige bildet av prosessen opprettet av de innsamlede beregningene. Dette er et pågående problem jeg har med noen leverandører som, når de oppretter SLAer, ikke har noen anelse om hva begrepet "oppetid" betyr og i de fleste tilfeller ikke forklarer kundene hvordan deres API fungerer.
Hvis du opprettet en tjeneste, for eksempel et API for en tredje person, bør du forstå hva den resulterende beregningen på 39,5 betyr - respons, vellykket respons, respons på 20 ms hastighet eller 5 ms hastighet. Det er opp til deg å tilpasse deres SLA til din egen SLA, til dine egne beregninger.
Når du har funnet ut av alt dette, kan du begynne å lage et fantastisk dashbord. Fortell meg, har noen allerede brukt Grafana interaktiv visualiseringsapplikasjon? Flott! Jeg er en stor fan av denne åpen kildekode fordi denne tingen er gratis og enkel å bruke.
Hvis du ikke har brukt Grafana ennå, skal jeg fortelle deg hvordan du jobber med det. Noen født på 80- og 90-tallet husker sikkert CareBears? Jeg vet ikke hvor populære disse bjørnene var i Russland, men når det kommer til beregninger, bør vi være de samme «omsorgsbjørnene». Som sagt trenger du et stort bilde av hvordan hele systemet fungerer, og det skal ikke bare handle om API-en din, nettstedet ditt eller tjenesten som kjører i en virtuell maskin.
Du må organisere innsamlingen av de beregningene som best gjenspeiler driften av hele systemet. De fleste av dere er programvareutviklere, så livet ditt er i konstant endring, tilpasser seg nye produktkrav, og akkurat som du er opptatt av kodeprosesser, bør du være opptatt av beregninger. Du må vite hvordan beregningen er relatert til hver linje med kode du skriver. Neste uke starter du for eksempel en ny markedsføringskampanje og forventer at et stort antall brukere besøker nettstedet ditt. For å analysere denne hendelsen trenger du beregninger, og du trenger kanskje et helt dashbord for å spore aktiviteten til disse personene. Du trenger beregninger for å forstå hvor vellykket markedsføringskampanjen din er og hvordan den faktisk gir resultater. De vil hjelpe deg for eksempel med å utvikle et effektivt CRM – customer relationship management system.
Så la oss komme i gang med vår Azure-skytjeneste. Det er veldig enkelt å finne og organisere metrikksamling fordi den har Azure Monitor. Denne monitoren sentraliserer systemkonfigurasjonsadministrasjonen. Hvert av Azure-elementene du vil bruke på systemet ditt har mange beregninger aktivert som standard. Dette er et gratis program som fungerer rett ut av esken og som ikke krever noen foreløpige innstillinger; du trenger ikke å skrive eller "skru" noe til systemet ditt. Vi vil bekrefte dette ved å se på følgende demo.
I tillegg er det mulig å sende disse beregningene til tredjepartsapplikasjoner, som Splunk-logglagrings- og analysesystemet, den skybaserte loggadministrasjonsapplikasjonen SumoLogic, ELK-loggbehandlingsverktøyet og IBM Radar. Riktignok er det små forskjeller som avhenger av ressursene du bruker - en virtuell maskin, nettverkstjenester, Azure SQL-databaser, det vil si at bruken av beregninger varierer avhengig av funksjonene til arbeidsmiljøet ditt. Jeg vil ikke si at disse forskjellene er alvorlige, men dessverre er de fortsatt til stede, og dette bør tas i betraktning. Aktivering og sending av beregninger er mulig på flere måter: gjennom Portal, CLI/Power Shell eller ved å bruke ARM-maler.
Før jeg starter min første demo, vil jeg svare på spørsmål du måtte ha. Hvis det ikke er noen spørsmål, la oss komme i gang. Skjermen viser hvordan Azure Monitor-siden ser ut. Kan noen av dere si at denne skjermen ikke fungerer?
Så nå er alt bra, du kan se hvordan monitortjenestene ser ut. Jeg kan si at dette er et utmerket og veldig enkelt verktøy for arbeidshverdagen. Den kan brukes til å overvåke applikasjoner, nettverk og infrastruktur. Nylig har overvåkingsgrensesnittet blitt forbedret, og hvis tidligere tjenester var plassert på forskjellige steder, er nå all informasjon om tjenester konsolidert på skjermens hjemmeside.
Metrikktabellen er en fane langs HomeMonitorMetrics-banen, som du kan gå til for å se alle tilgjengelige beregninger og velge de du trenger. Men hvis du trenger å aktivere metrikkinnsamling, må du bruke katalogbanen for HomeMonitorDiagnostic-innstillinger og merke av for Aktiverte/Deaktiverte beregninger. Som standard er nesten alle beregninger aktivert, men hvis du trenger å aktivere noe ekstra, må du endre diagnosestatusen fra Deaktivert til Aktivert.
For å gjøre dette, klikk på linjen for den valgte beregningen og aktiver diagnosemodus på fanen som åpnes. Hvis du skal analysere den valgte beregningen, må du etter å ha klikket på Slå på diagnosekoblingen merke av for Send til logganalyse i vinduet som vises.
Log Analytics ligner litt på Splunk, men koster mindre. Denne tjenesten lar deg samle alle dine beregninger, logger og alt annet du trenger og plassere dem i Log Analytics-arbeidsområdet. Tjenesten bruker et spesielt KQL-spørringsbehandlingsspråk - Kusto Quarry Language, vi vil se på arbeidet i neste demo. Foreløpig vil jeg legge merke til at med hjelpen kan du opprette spørsmål angående beregninger, logger, termer, trender, mønstre osv. og lage dashboards.
Så vi merker av for Send til logganalyse og avmerkingsboksene i LOG-panelet: DataPlaneRequests, MongoRequests og QueryRuntimeStatistics, og nedenfor på METRIC-panelet – avkrysningsboksen Forespørsler. Deretter tildeler vi et navn og lagrer innstillingene. På kommandolinjen representerer dette to linjer med kode. Forresten, Azure Cloud-skallet ligner i denne forstand Google, som også lar deg bruke kommandolinjen i nettleseren din. AWS har ikke noe sånt, så Azure er mye mer praktisk i denne forstand.
For eksempel kan jeg kjøre en demo gjennom webgrensesnittet uten å bruke noen kode på den bærbare datamaskinen min. For å gjøre dette må jeg autentisere med Azure-kontoen min. Da kan du bruke for eksempel terrafone, hvis du allerede bruker det, vent på tilkoblingen til tjenesten og få Linux-arbeidsmiljøet som Microsoft bruker som standard.
Deretter bruker jeg Bash, innebygd i Azure Cloud Shell. En veldig nyttig ting er IDE innebygd i nettleseren, en lett versjon av VS Code. Deretter kan jeg gå inn i malen for feilberegninger, redigere den og tilpasse den for å passe mine behov.
Når du har satt opp metrikksamling i denne malen, kan du bruke den til å lage beregninger for hele infrastrukturen din. Når vi har brukt beregningene, samlet dem og lagret dem, må vi visualisere dem.
Azure Monitor omhandler kun beregninger og gir ikke et helhetlig bilde av helsen til systemet ditt. Du kan ha en rekke andre programmer som kjører utenfor Azure-miljøet. Så hvis du trenger å overvåke alle prosesser, visualisere alle de innsamlede beregningene på ett sted, så er ikke Azure Monitor egnet for dette.
For å løse dette problemet tilbyr Microsoft Power BI-verktøyet, en omfattende programvare for forretningsanalyse som inkluderer visualisering av en lang rekke data. Dette er et ganske dyrt produkt, hvis kostnad avhenger av settet med funksjoner du trenger. Som standard tilbyr den 48 typer data å behandle og er koblet til Azure SQL Data Warehouses, Azure Data Lake Storage, Azure Machine Learning Services og Azure Databricks. Ved å bruke skalerbarhet kan du motta nye data hvert 30. minutt. Dette kan være tilstrekkelig for dine behov hvis du trenger sanntidsovervåkingsvisualisering. I dette tilfellet anbefales det å bruke applikasjoner som Grafana jeg nevnte. I tillegg beskriver Microsoft-dokumentasjonen muligheten til å sende metrikk, logger og hendelsestabeller ved hjelp av SIEM-verktøy til visualiseringssystemene Splunk, SumoLogic, ELK og IBM radar.
23:40 min
Fortsettelse snart...
Noen annonser 🙂
Takk for at du bor hos oss. Liker du artiklene våre? Vil du se mer interessant innhold? Støtt oss ved å legge inn en bestilling eller anbefale til venner, , en unik analog av entry-level servere, som ble oppfunnet av oss for deg: (tilgjengelig med RAID1 og RAID10, opptil 24 kjerner og opptil 40 GB DDR4).
Dell R730xd 2x billigere i Equinix Tier IV datasenter i Amsterdam? Bare her i Nederland! Dell R420 - 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB - fra $99! Lese om
Kilde: www.habr.com