David O'Brien lanserade nyligen sitt eget företag, Xirus (https://xirus.com.au), med fokus på Microsoft Azure Stack molnprodukter. De är designade för att konsekvent bygga och köra hybridapplikationer i datacenter, kantplatser, fjärrkontor och molnet.
David utbildar individer och företag i allt som rör Microsoft Azure och Azure DevOps (tidigare VSTS) och gör fortfarande praktisk rådgivning och infrakodning. Han har vunnit Microsoft MVP (Microsoft Most Valuable Professional) Award i 5 år och fick nyligen Azure MVP Award. Som medarrangör av Melbourne Microsoft Cloud and Datacentre Meetup talar O'Brien regelbundet på internationella konferenser och kombinerar sitt intresse för att resa världen runt med en passion för att dela IT-berättelser med samhället. Davids blogg finns på , publicerar han också sin onlineutbildning på Pluralsight.
Föredraget talar om vikten av mått för att förstå vad som händer i din miljö och hur din applikation presterar. Microsoft Azure har ett kraftfullt och enkelt sätt att visa mätvärden för alla typer av arbetsbelastningar, och föreläsningen förklarar hur du kan använda dem alla.
Klockan 3 på en söndag, medan du sover, väcks du plötsligt av ett textmeddelande: "superkritisk app svarar inte igen." Vad pågår? Var och vad är orsaken till "bromsarna"? I det här föredraget kommer du att lära dig om de tjänster som Microsoft Azure erbjuder kunder för att samla in loggar och i synnerhet mätvärden från dina molnbelastningar. David kommer att berätta vilka mätvärden du bör vara intresserad av när du arbetar på en molnplattform och hur du kommer till dem. Du kommer att lära dig om verktyg med öppen källkod och konstruktion av instrumentpaneler och sluta med tillräckligt med kunskap för att skapa dina egna instrumentpaneler.
Och om du väcks igen klockan 3 av ett meddelande om att en kritisk applikation har kraschat, kan du snabbt ta reda på orsaken.
God eftermiddag, idag ska vi prata om mått. Jag heter David O'Brien, jag är medgrundare och ägare till ett litet australiensiskt konsultföretag, Xirus. Tack igen för att du kom hit för att spendera din tid med mig. Så varför är vi här? För att prata om mått, eller snarare, jag kommer att berätta om dem, och innan vi gör några saker, låt oss börja med teorin.
Jag ska berätta för dig vad mätvärden är, vad du kan göra med dem, vad du behöver vara uppmärksam på, hur du samlar in och aktiverar insamling av mätvärden i Azure och vad mätvärdesvisualisering är. Jag ska visa dig hur dessa saker ser ut i Microsofts moln och hur du arbetar med detta moln.
Innan vi börjar kommer jag att be dem som använder Microsoft Azure en handuppräckning. Vem arbetar med AWS? Jag ser få. Hur är det med Google? ALI moln? En man! Bra. Så vad är mått? Den officiella definitionen av US National Institute of Standards and Technology är: "Ett mått är en mätstandard som beskriver villkoren och reglerna för att mäta en fastighet och tjänar till att förstå mätresultaten." Vad betyder det?
Låt oss ta ett exempel på ett mått för att ändra det lediga diskutrymmet på en virtuell maskin. Till exempel får vi siffran 90, och denna siffra betyder procent, det vill säga mängden ledigt diskutrymme är 90%. Jag noterar att det inte är särskilt intressant att läsa beskrivningen av definitionen av mått, som tar 40 sidor i pdf-format.
Mätvärdet säger dock inte hur mätresultatet erhölls, det visar bara detta resultat. Vad gör vi med mått?
Först mäter vi värdet på något för att sedan använda mätresultatet.
Till exempel fick vi reda på mängden ledigt diskutrymme och nu kan vi använda det, använda det här minnet osv. När vi har fått det metriska resultatet måste vi tolka det. Till exempel returnerade måtten ett resultat på 90. Vi måste veta vad detta nummer betyder: mängden ledigt utrymme eller mängden använt diskutrymme i procent eller gigabyte, nätverkslatens lika med 90 ms, och så vidare, det vill säga måste vi tolka innebörden av det metriska värdet. För att mätvärden överhuvudtaget ska vara meningsfulla, efter att ha tolkat ett enda mätvärde, måste vi se till att flera värden samlas in. Detta är mycket viktigt eftersom många människor inte är medvetna om behovet av att samla in mätvärden. Microsoft har gjort det väldigt enkelt att samla in mätvärden, men det är upp till dig att se till att de samlas in. Dessa mätvärden lagras endast i 41 dagar och försvinner den 42:a dagen. Därför, beroende på egenskaperna hos din externa eller interna utrustning, bör du ta hand om hur du sparar mätvärden i mer än 41 dagar - i form av loggar, loggar, etc. Så efter insamlingen bör du placera dem på någon plats som låter dig ta fram all statistik över förändringar i metriska resultat om det behövs. När du väl har lagt dem där kan du börja arbeta med dem effektivt.
Först efter att du har erhållit mätvärdena, tolkat dem och samlat in dem, kan du skapa ett SLA - servicenivåavtal. Detta SLA kanske inte är av stor betydelse för dina kunder, det är viktigare för dina kollegor, chefer, de som underhåller systemet och är bekymrade över dess funktionalitet. Mätvärdet kan mäta antalet biljetter - till exempel får du 5 biljetter per dag, och i det här fallet visar den hastigheten för svar på användarförfrågningar och hastigheten för felsökning. Ett mått ska inte bara säga att din webbplats laddas på 20 ms eller att din svarshastighet är 20 ms, ett mått är mer än bara en teknisk indikator.
Därför är uppgiften för vårt samtal att ge dig en detaljerad bild av essensen av mått. Mätvärdet tjänar till att genom att titta på det kan du få en komplett bild av processen.
När vi väl har mätvärdet kan vi till 99 % garantera att systemet fungerar, eftersom det inte bara tittar på en loggfil som säger att systemet fungerar. En 99 % upptidsgaranti innebär att till exempel 99 % av tiden API:n svarar med en normal hastighet på 30 ms. Det är just detta som intresserar dina användare, dina kollegor och chefer. Många av våra kunder övervakar webbserverloggar, men de märker inga fel i dem och tycker att allt är bra. Till exempel ser de en nätverkshastighet på 200 Mb/s och tänker: "ok, allt är bra!" Men för att uppnå dessa 200 behöver användarna en svarshastighet på 30 millisekunder, och det är just den indikatorn som inte mäts och inte samlas in i loggfiler. Samtidigt är användarna förvånade över att webbplatsen laddas mycket långsamt, eftersom de inte har de nödvändiga mätvärdena och vet inte orsakerna till detta beteende.
Men eftersom vi har en 100 % upptid SLA börjar kunderna klaga eftersom sajten faktiskt är väldigt svår att använda. För att skapa en objektiv SLA är det därför nödvändigt att se den fullständiga bilden av processen som skapas av de insamlade mätvärdena. Detta är ett pågående problem jag har med vissa leverantörer som när de skapar SLA:er inte har någon aning om vad termen "upptid" betyder och i de flesta fall inte förklarar för sina kunder hur deras API fungerar.
Om du skapade en tjänst, till exempel ett API för en tredje person, bör du förstå vad det resulterande måttet 39,5 betyder - svar, framgångsrikt svar, svar med 20 ms hastighet eller 5 ms hastighet. Det är upp till dig att anpassa deras SLA till din egen SLA, till dina egna mätvärden.
När du har listat ut allt detta kan du börja skapa en fantastisk instrumentpanel. Säg mig, har någon redan använt den interaktiva visualiseringsapplikationen Grafana? Bra! Jag är ett stort fan av denna öppen källkod eftersom den här saken är gratis och enkel att använda.
Om du inte har använt Grafana än så ska jag berätta hur du arbetar med det. Någon född på 80- och 90-talet minns säkert CareBears? Jag vet inte hur populära dessa björnar var i Ryssland, men när det kommer till mätvärden borde vi vara samma "vårdbjörnar". Du behöver som sagt en stor bild av hur hela systemet fungerar, och det ska inte bara handla om ditt API, din webbplats eller tjänsten som körs i en virtuell maskin.
Du måste organisera insamlingen av de mätvärden som bäst återspeglar driften av hela systemet. De flesta av er är mjukvaruutvecklare, så ert liv förändras ständigt, anpassar er till nya produktkrav, och precis som ni är intresserade av kodningsprocesser bör ni bry er om mätetal. Du måste veta hur måtten relaterar till varje kodrad du skriver. Nästa vecka startar du till exempel en ny marknadsföringskampanj och förväntar dig att ett stort antal användare besöker din webbplats. För att analysera den här händelsen behöver du mätvärden, och du kan behöva en hel instrumentpanel för att spåra dessa personers aktivitet. Du behöver mätvärden för att förstå hur framgångsrik din marknadsföringskampanj är och hur den faktiskt fungerar. De hjälper dig till exempel att utveckla ett effektivt CRM – kundrelationshanteringssystem.
Så låt oss komma igång med vår Azure molntjänst. Det är väldigt enkelt att hitta och organisera mätinsamling eftersom den har Azure Monitor. Denna monitor centraliserar din systemkonfigurationshantering. Vart och ett av Azure-elementen som du vill tillämpa på ditt system har många mätvärden aktiverade som standard. Detta är en gratis applikation som fungerar direkt ur lådan och som inte kräver några preliminära inställningar; du behöver inte skriva eller "skruva" något till ditt system. Vi kommer att verifiera detta genom att titta på följande demo.
Dessutom är det möjligt att skicka dessa mätvärden till tredjepartsapplikationer, såsom Splunk-logglagrings- och analyssystemet, den molnbaserade logghanteringsapplikationen SumoLogic, ELK-loggbearbetningsverktyget och IBM Radar. Det är sant att det finns små skillnader som beror på de resurser du använder - en virtuell maskin, nätverkstjänster, Azure SQL-databaser, det vill säga användningen av mätvärden skiljer sig beroende på funktionerna i din arbetsmiljö. Jag kommer inte att säga att dessa skillnader är allvarliga, men tyvärr finns de fortfarande kvar, och detta bör beaktas. Aktivering och sändning av mätvärden är möjligt på flera sätt: genom Portal, CLI/Power Shell eller genom att använda ARM-mallar.
Innan jag börjar min första demo kommer jag att svara på alla frågor du kan ha. Om det inte finns några frågor, låt oss börja. Skärmen visar hur Azure Monitor-sidan ser ut. Kan någon av er säga att denna bildskärm inte fungerar?
Så nu är allt bra, du kan se hur monitortjänsterna ser ut. Jag kan säga att detta är ett utmärkt och väldigt enkelt verktyg för vardagsarbete. Den kan användas för att övervaka applikationer, nätverk och infrastruktur. Nyligen har övervakningsgränssnittet förbättrats, och om tidigare tjänster var placerade på olika platser, konsolideras nu all information om tjänster på monitorns hemsida.
Mätvärdestabellen är en flik längs HomeMonitorMetrics-sökvägen, som du kan gå till för att se alla tillgängliga mätvärden och välja de du behöver. Men om du behöver aktivera insamling av mätvärden måste du använda katalogsökvägen för HomeMonitorDiagnostic-inställningar och markera kryssrutorna Aktiverade/Inaktiverade mätvärden. Som standard är nästan alla mätvärden aktiverade, men om du behöver aktivera något ytterligare måste du ändra diagnosstatusen från Inaktiverad till Aktiverad.
För att göra detta, klicka på raden för det valda måttet och på fliken som öppnas, aktivera diagnostikläge. Om du ska analysera det valda måttet måste du efter att ha klickat på länken Aktivera diagnostik markera kryssrutan Skicka till logganalys i fönstret som visas.
Log Analytics påminner lite om Splunk, men kostar mindre. Den här tjänsten låter dig samla in alla dina mätvärden, loggar och allt annat du behöver och placera dem i Log Analytics-arbetsytan. Tjänsten använder ett speciellt KQL-frågebehandlingsspråk - Kusto Quarry Language, vi kommer att titta på dess arbete i nästa demo. För tillfället kommer jag att notera att med dess hjälp kan du skapa frågor om mätvärden, loggar, termer, trender, mönster, etc. och skapa instrumentpaneler.
Så vi markerar kryssrutorna Skicka till logganalys och kryssrutorna i LOG-panelen: DataPlaneRequests, MongoRequests och QueryRuntimeStatistics, och nedan på METRIC-panelen – kryssrutan Requests. Sedan tilldelar vi ett namn och sparar inställningarna. På kommandoraden representerar detta två rader kod. Förresten, Azure Cloud-skalet påminner i denna mening om Google, vilket också låter dig använda kommandoraden i din webbläsare. AWS har inget sådant, så Azure är mycket bekvämare i den här meningen.
Till exempel kan jag köra en demo genom webbgränssnittet utan att använda någon kod på min bärbara dator. För att göra detta måste jag autentisera med mitt Azure-konto. Då kan du använda till exempel terrafone, om du redan använder det, vänta på anslutningen till tjänsten och få Linux-arbetsmiljön som Microsoft använder som standard.
Därefter använder jag Bash, inbyggt i Azure Cloud Shell. En mycket användbar sak är IDE inbyggd i webbläsaren, en lätt version av VS Code. Därefter kan jag gå in i min felmätningsmall, redigera den och anpassa den för att passa mina behov.
När du har ställt in mätvärdesinsamling i den här mallen kan du använda den för att skapa mätvärden för hela din infrastruktur. När vi har tillämpat mätvärdena, samlat in dem och lagrat dem, måste vi visualisera dem.
Azure Monitor hanterar bara mätvärden och ger ingen övergripande bild av ditt systems tillstånd. Du kan ha ett antal andra program som körs utanför Azure-miljön. Så om du behöver övervaka alla processer, visualisera alla insamlade mätvärden på ett ställe, så är Azure Monitor inte lämpligt för detta.
För att lösa detta problem erbjuder Microsoft Power BI-verktyget, en omfattande programvara för affärsanalys som inkluderar visualisering av en mängd olika data. Detta är en ganska dyr produkt, vars kostnad beror på vilken uppsättning funktioner du behöver. Som standard erbjuder den dig 48 typer av data att bearbeta och är länkad till Azure SQL Data Warehouses, Azure Data Lake Storage, Azure Machine Learning Services och Azure Databricks. Genom att använda skalbarhet kan du ta emot ny data var 30:e minut. Detta kan eller kanske inte är tillräckligt för dina behov om du behöver visualisering av övervakning i realtid. I det här fallet rekommenderas det att använda applikationer som Grafana jag nämnde. Dessutom beskriver Microsofts dokumentation möjligheten att skicka mätvärden, loggar och händelsetabeller med hjälp av SIEM-verktyg till visualiseringssystem Splunk, SumoLogic, ELK och IBM radar.
23:40 min
Fortsättning snart...
Några annonser 🙂
Tack för att du stannar hos oss. Gillar du våra artiklar? Vill du se mer intressant innehåll? Stöd oss genom att lägga en beställning eller rekommendera till vänner, , en unik analog av ingångsservrar, som uppfanns av oss för dig: (tillgänglig med RAID1 och RAID10, upp till 24 kärnor och upp till 40 GB DDR4).
Dell R730xd 2 gånger billigare i Equinix Tier IV datacenter i Amsterdam? Bara här i Nederländerna! Dell R420 - 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB - från $99! Läs om
Källa: will.com