For nylig åbnede David O'Brien sit eget firma Xirus (https://xirus.com.au) med fokus på Microsoft Azure Stack cloud-produkter. De er designet til konsekvent at opbygge og implementere hybride applikationer i datacentre, på edge-lokationer, i fjernkontorer og i skyen.
David træner enkeltpersoner og virksomheder i alt, hvad der har med Microsoft Azure og Azure DevOps (tidligere VSTS) at gøre, og arbejder stadig med praktisk rådgivning og infrastrukturkodning. Han har været Microsoft MVP (Most Valuable Professional) i 5 år og modtog for nylig MVP Azure-prisen. Som medarrangør af Melbourne Microsoft Cloud og Datacentre Meetup taler O'Brien regelmæssigt ved internationale konferencer, hvor han kombinerer sin interesse for at rejse verden rundt med sin passion for at dele IT-historier med samfundet. Davids blog findes på , og han udgiver også sine online kurser på Pluralsight.
Indlægget handler om vigtigheden af metrikker for at forstå, hvad der sker i din miljø, og hvordan din applikation fungerer. Microsoft Azure har en kraftfuld og enkel måde at visualisere metrikker for alle typer arbejdsbyrder, og foredraget beskriver, hvordan du kan bruge dem alle.
Klokken 3 om natten, om søndagen, bliver du pludselig vækket af en sms-advarsel: "kritisk applikation svarer ikke igen". Hvad sker der? Hvorfor er der 'problemer'? I dette foredrag vil du lære om de tjenester, som Microsoft Azure tilbyder kunderne for indsamling af logs og i særdeleshed metrikker for dine cloud-arbejdsbyrder. David vil forklare, hvilke metrikker der bør interessere dig, når du arbejder på cloud-platformen, og hvordan du kan få adgang til dem. Du vil lære om open-source værktøjer og opbygning af dashboards, således at du erhverver dig tilstrækkelig viden til at skabe dine egne dashboards.
Og hvis du bliver vækket klokken 3 om natten af en besked om en kritisk applikations nedbrud, kan du hurtigt finde årsagen.
Goddag, i dag skal vi tale om metrikker. Mit navn er David O’Brien, jeg er medstifter og ejer af det lille australske konsulentfirma Xirus. Tak for at tage dig tid til at være her med mig. Så, hvad er vi her for? For at tale om metrikker, eller rettere sagt, jeg vil fortælle dig om dem, og før vi gør nogle ting, lad os starte med teorien.
Jeg vil forklare, hvad metrikker er, hvad man kan gøre med dem, hvad man skal være opmærksom på, hvordan man indsamler og inkluderer indsamlingen af metrikker i Azure, samt hvad visualisering af metrikker er. Jeg vil vise dig, hvordan disse ting ser ud i Microsofts cloud, og hvordan man arbejder med denne cloud.
Før vi går i gang, vil jeg bede dem, der bruger Microsoft Azure, om at række hånden op. Og hvem arbejder med AWS? Jeg kan se, at det er få. Og Google? ALI Cloud? Én person! Fantastisk. Så, hvad er metrikker? Den officielle definition fra det amerikanske National Institute of Standards and Technology lyder: «En metrik er en målestandard, der beskriver betingelserne og reglerne for måling af en given egenskab og tjener til at forstå resultaterne af målingen.» Hvad betyder det?
Lad os tage et eksempel med metrikken for ændring af ledig diskplads på en virtuel maskine. For eksempel får vi tallet 90, og dette tal betyder procent, dvs. at mængden af ledig diskplads er 90%. Jeg bemærker, at det ikke er særlig interessant at læse en beskrivelse af definitionen af metrikker, som fylder 40 sider i pdf-format.
Men metrikken siger ikke, hvordan resultatet af målingen er opnået, den viser kun dette resultat. Hvad gør vi så med metrikker?
For det første måler vi værdien af noget for derefter at bruge resultatet af målingen.
For eksempel har vi lært om mængden af ledig diskplads, og nu kan vi bruge det, bruge denne hukommelse osv. Efter at vi har fået resultatet af metrikken, skal vi fortolke det. For eksempel gav metrikken resultatet 90. Vi skal vide, hvad dette tal betyder: mængden af ledig plads eller den optagne diskplads i procent eller gigabyte, netværkslatens på 90 ms, og så videre, hvilket betyder, at vi skal fortolke betydningen af metrikværdien. For at metrikker overhovedet giver mening, efter at vi har fortolket en metrikværdi, skal vi sikre indsamlingen af mange værdier. Dette er meget vigtigt, da mange mennesker ikke er klar over behovet for at indsamle metrikker. Microsoft har gjort det meget nemt at få metrikker, men du skal selv sørge for indsamlingen. Disse metrikker opbevares kun i 41 dage og forsvinder på den 42. dag. Derfor, afhængigt af egenskaberne ved dit eksterne eller interne udstyr, skal du tage ansvar for, hvordan du opbevarer metrikker i mere end 41 dage — i form af logs, journaler osv. Så efter indsamlingen skal du placere dem et sted, der gør det muligt at hente hele statistikken om ændringer i metrikresultaterne, hvis nødvendigt. Ved at placere dem der, kan du begynde at arbejde effektivt med dem.
Kun efter at du har fået metrikværdierne, fortolket dem og indsamlet dem, kan du oprette en SLA – Service Level Agreement. Denne SLA kan ikke have meget betydning for dine kunder; den er mere vigtig for dine kolleger, ledere, dem, der sikrer systemets drift og er bekymret for dets funktionalitet. Metrikken kan måle antallet af tickets — for eksempel får du 5 tickets om dagen, og i dette tilfælde viser det hastigheden for at svare på brugerforespørgsler og hurtigheden af fejlrettelser. Metrikken skal ikke bare meddele, at din hjemmeside indlæses på 20 ms eller at svartiden er 20 ms; metrikken er mere end blot én teknisk måling.
Så formålet med vores samtale er at præsentere dig for et detaljeret billede af metrikker. Metrikken tjener til, at du, ved at kigge på den, kan få et komplet billede af processen.
Når vi har fået metrikken, kan vi med 99% sikkerhed garantere systemets drift, fordi det ikke blot er et blik på logfilen, der siger, at systemet fungerer. En 99% driftssikkerhed betyder, at API'et for eksempel svarer med den normale hastighed på 30 ms i 99% af tilfældene. Det er netop det, der interesserer dine brugere, kolleger og ledere. Mange af vores kunder overvåger logs for webservere og bemærker ikke, at der er fejl i dem og tror, at alt er i orden. For eksempel ser de en netværksspeed på 200 mb/s og tænker: „fint, alt er godt!“ Men for at opnå disse 200, har brugerne brug for en responstid på 30 millisekunder, og det er netop den metrik, der ikke måles og ikke indsamles i logfilerne. Samtidig undrer brugerne sig over, at siden indlæses meget langsomt, fordi de, uden at have den nødvendige metrik, ikke kender årsagen til denne adfærd.
Men da vi har en SLA, der garanterer 100% drift, begynder kunderne at udtrykke utilfredshed, for i virkeligheden er det meget svært at bruge siden. Derfor er det nødvendigt at se hele billedet af processen, der skabes af de indsamlede metrikker, for at kunne oprette en objektiv SLA. Dette er genstand for min konstante debat med nogle udbydere, der ved udarbejdelsen af SLA'en ikke forstår betydningen af termen „uptime“ og i de fleste tilfælde ikke forklarer deres kunder, hvordan deres API fungerer.
Hvis du har skabt en service, for eksempel et API til en tredjepart, skal du forstå, hvad den opnåede metrik 39,5 betyder – et svar, et vellykket svar, et svar med en hastighed på 20 ms eller 5 ms. Det er dig, der skal tilpasse deres SLA til din egen SLA, til dine egne metrikker.
Når alt dette er afklaret, kan vi begynde at oprette et fantastisk overvågningspanel. Sig mig, har nogen allerede brugt Grafana til interaktiv visualisering? Fantastisk! Jeg er en stor fan af denne open source, fordi det er gratis, og det er nemt at bruge.
Hvis du ikke har brugt Grafana før, vil jeg fortælle dig, hvordan man arbejder med det. Dem, der er født i 80'erne og 90'erne, husker måske de omsorgsfulde bjørne, CareBears? Jeg ved ikke, hvor populære disse bjørne var i Rusland, men når det kommer til metrics, skal vi være lige så "omsorgsfulde" som bjørnene. Som jeg sagde, har du brug for et omfattende billede af hele systemets funktion, og det bør ikke kun fokusere på din API, din hjemmeside eller den service, der kører på en virtuel maskine.
Du skal organisere indsamlingen af de metrics, der bedst afspejler hele systemets funktion. De fleste af jer er softwareudviklere, så jeres liv ændrer sig konstant for at tilpasse sig nye produktkrav, og ligesom I tænker på kodningsprocessen, bør I også tænke på metrics. I skal vide, hvordan metrics forholder sig til hver eneste linje af kode, I skriver. For eksempel, hvis I næste uge starter en ny marketingkampagne, og I forventer, at jeres hjemmeside får mange besøg, vil I have brug for metrics til at analysere denne begivenhed, og det kan være nødvendigt at have et helt dashboard til at overvåge disse menneskers aktivitet. Metrics vil være nødvendige for at finde ud af, hvor effektiv jeres marketingkampagne er, og hvordan den faktisk fungerer. De vil hjælpe jer med at udvikle en effektiv CRM — et system til kundehåndtering.
Lad os nu dykke ned i vores cloud-tjeneste, Azure. Det er meget enkelt at finde og organisere indsamlingen af metrics, fordi Azure Monitor er tilgængeligt. Denne monitor centraliserer styringen af din systems konfiguration. Hver af Azure's elementer, som du ønsker at anvende i dit system, har mange metrics aktiveret som standard. Det er en gratis applikation, der fungerer direkte "out of the box" og kræver ingen forudgående opsætning, du skal ikke skrive noget eller "feste" det til dit system. Vi vil bekræfte dette, når vi ser det næste demo.
Derudover er der mulighed for at sende disse metrikker til tredjepartsapplikationer såsom loglagrings- og analyssystemet Splunk, den skybaserede logadministrationsapp SumoLogic, logbehandlingsværktøjet ELK, IBM Radar. Der er dog nogle små forskelle, der afhænger af de ressourcer, du bruger – virtuelle maskiner, netværkstjenester, Azure SQL-databaser, så brugen af metrikker varierer afhængigt af funktionerne i dit arbejdsmiljø. Jeg vil ikke sige, at disse forskelle er alvorlige, men desværre er de til stede, og det bør tages i betragtning. Aktivering og videresendelse af metrikker kan ske på flere måder: via Portal, CLI/Power Shell eller ved hjælp af ARM-skabeloner.
Før vi går videre til den første demonstration, vil jeg besvare eventuelle spørgsmål, I måtte have. Hvis der ikke er spørgsmål, så lad os komme i gang. På skærmen kan du se, hvordan siden Azure Monitor ser ud. Kan nogen af jer sige, at denne monitor ikke fungerer?
Så nu er alt i orden, I kan se, hvordan overvågningsservicerne ser ud. Jeg kan fortælle, at dette er et fremragende og meget enkelt værktøj til dagligt arbejde. Det giver mulighed for overvågning af applikationer, netværk og infrastruktur. For nylig blev overvågningsgrænsefladen forbedret, og hvis tjenesterne tidligere var placeret forskellige steder, så er al information om tjenesterne nu konsolideret på monitorens startside.
Metrikskemaet er en fane under stien HomeMonitorMetrics, som du kan besøge for at se alle tilgængelige metrikker og vælge de nødvendige. Men hvis du skal aktivere indsamling af metrikker, skal du bruge stien HomeMonitorDiagnostic settings og kontrollere afkrydsningsfelterne for metrikker Aktiveret/Deaktiveret. Som standard er stort set alle metrikker aktiveret, men hvis du skal aktivere noget ekstra, skal du ændre diagnosesstatus fra Deaktiveret til Aktiveret.
For at gøre dette skal du klikke på rækken for den valgte metrik og på den åbne fane aktivere diagnosemodus. Hvis du planlægger at analysere den valgte metrik, skal du efter at have klikket på linket Tænd for diagnose markere afkrydsningsfeltet Send til Log Analytics i det vindue, der vises.
Log Analytics ligner lidt på Splunk, men koster mindre. Denne service giver dig mulighed for at indsamle alle dine metrikker, logfiler og alt hvad du behøver, og placere dem i et Log Analytics arbejdsområde. Servicen bruger et særligt forespørgselsprog kaldet KQL – Kusto Query Language, som vi vil gennemgå i den næste demo. Indtil videre skal jeg bemærke, at du med dette kan formulere forespørgsler om metrikker, logfiler, termer, tendenser, mønstre osv. og oprette dashboards.
Så vi markerer afkrydsningsfeltet Send til Log Analytics og afkrydsningsfelterne på LOG-panelet: DataPlaneRequests, MongoRequests og QueryRuntimeStatistics, og nedenfor på METRIC-panelet – afkrydsningsfeltet Requests. Derefter giver vi det et navn og gemmer indstillingerne. I kommandolinjen er det repræsenteret af to linjer kode. For resten minder Azure Cloud-shellen om Google, som også tillader dig at bruge kommandolinjen i din webbrowser. AWS har ikke noget lignende, så Azure er i denne forbindelse meget mere brugervenligt.
For eksempel kan jeg køre en demo gennem webgrænsefladen uden at bruge nogen kode på min bærbare computer. For dette skal jeg gennemgå autentificering med min Azure-konto. Derefter kan jeg for eksempel bruge terrafone, hvis du allerede bruger det, vente på at oprette forbindelse til servicen og få et Linux-miljø, som Microsoft bruger som standard.
Dernæst bruger jeg Bash, der er indbygget i Azure Cloud Shell. En meget nyttig ting er den indbyggede IDE i browseren, en let version af VS Code. Derefter kan jeg få adgang til min skabelon for fejlmetrikker, ændre den og tilpasse den til mine behov.
Når du har konfigureret indsamlingen af metrikker i denne skabelon, kan du anvende den til at oprette metrikker for hele din infrastruktur. Efter at vi har anvendt metrikkerne, indsamlet og gemt dem, skal vi visualisere dem.
Azure Monitor arbejder kun med metrikker og giver ikke mulighed for at få et samlet billede af din systems tilstand. Du kan have en række andre applikationer, der kører uden for Azure-miljøet. Så hvis du har brug for at overvåge alle processer og visualisere alle indsamlede metrikker ét sted, så er Azure Monitor ikke egnet til dette.
For this task, Microsoft offers the Power BI tool – a comprehensive software for business analysis that includes visualization of various data. It is quite an expensive product, and its cost depends on the set of features you require. By default, it provides 48 types of processed data and is connected to SQL Azure data warehouses, Azure Data Lake Storage, Azure machine learning services, and Azure Databricks. Using scalability, you can obtain new data every 30 minutes. This may be sufficient for your needs or may not be enough if you require real-time monitoring visualization. In this case, applications like Grafana that I mentioned are recommended. Additionally, Microsoft’s documentation describes the ability to send metrics, logs, and event tables using SIEM tools to visualization systems like Splunk, SumoLogic, ELK, and IBM radar.
23:40 min
Fortsættelsen kommer snart…
Lidt reklame 🙂
Tak fordi du bliver hos os. Kan du lide vores artikler? Ønsker du at se flere interessante materialer? Støt os ved at bestille eller anbefale os til dine bekendte, , en unik analog til entry-level servere, som vi har designet til dig: (tilgængelige muligheder med RAID1 og RAID10, op til 24 kerner og op til 40 GB DDR4).
Dell R730xd til halv pris i datacenteret Equinix Tier IV i Amsterdam? Kun hos os i Holland! Dell R420 - 2x E5-2430 2.2GHz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB - fra 99 $! Læs om hvordan
Kilde: habr.com
