Arkitekturstrategier för övervakning av arbetsbelastningsprestanda

Gäller för den här rekommendationen för checklista för prestandaeffektivitet i Azure Well-Architected Framework:

Utan prestandadata går underliggande problem och optimeringsmöjligheter obemärkt förbi, vilket leder till försämrad användarupplevelse.

Den här artikeln beskriver designstrategier för att implementera prestandamätningar i flera lager som fångar upp svarstid, dataflöde och resursbeteende för att upprätta baslinjer och identifiera prestandaförsämring i arbetsbelastningen.

De viktigaste strategierna i den här artikeln bygger på den grundläggande driftspraxis som beskrivs i OE:07-arkitekturstrategier för att utforma ett övervakningssystem. Vägledning om hur du implementerar övervakningspraxis finns i designguiden för övervakning. Vi rekommenderar att du granskar dessa resurser först. Rekommendationerna i den här guiden är begränsade till prestanda. Information om tillförlitlighet finns i RE:10-arkitekturstrategier för att utforma en tillförlitlig strategi för övervakning och aviseringar.

Definitioner

Använda percentilbaserade mått

Mät prestandamått, till exempel svarstid, svarstid eller inläsningstider, med percentiler (p50, p95, p99), inte medelvärden. Medelvärden kan vara vilseledande. Om de flesta begäranden är snabba men några få är extremt långsamma döljer genomsnittet den dåliga upplevelsen.

Percentiler visar tail-beteendet, vilket är viktigt för att förstå användarupplevelsen. p50 representerar typisk prestanda, p95 visar vad de flesta användare upplever under belastning, och p99 fångar sämsta prestanda eller avvikande värden.

Samla in prestandadata med dina övervakningsverktyg och representera dem som percentiler över definierade tidsfönster. Använd dessa som baslinje för övervakning, aviseringar och prestandaanalys.

Definiera gränserna för prestandaförbättringar

Definiera tydliga prestandagränser så att du vet exakt vad som ingår i dina mått. Dela upp svarstiden i systemet i stället för att behandla den som ett enda tal. Till exempel, tilldela tid till varje lager som omfattar kanttjänster, gateway-enheter, beräkning och beroenden, för att identifiera var fördröjningar faktiskt uppstår.

Separera det du styr från det du inte gör: din kod, dina tjänster, infrastruktur och direkta beroenden jämfört med externa faktorer som villkor på klientsidan, DNS-matchning, ISP-svarstid eller enhetsbegränsningar. Den här skillnaden förhindrar felattribution och håller optimeringen fokuserad på områden där du kan göra ändringar, samtidigt som den återspeglar den fullständiga användarupplevelsen från slutpunkt till slutpunkt.

Utvärdera när och var prestandaproblem påverkar användarupplevelsen. Kompensera försämringen genom design eller minska genom förbättringar i de kontrollerbara delarna av systemet.

Segmentera signaler efter miljö och syfte

Segmentera prestandadata så att varje signal återspeglar en tydlig kontext. Separera efter miljö och syfte för att undvika att blanda signaler som beter sig annorlunda eller tjänar olika beslut.

Håll produktions- och icke-produktionsdata åtskilda. Produktionsdata återspeglar verklig användarpåverkan och bör driva övervakning och aviseringar. Icke-produktionsdata är användbara för testning och justering, men att blanda dem med produktion förvränger resultaten och döljer verkliga problem.

Separera prestandamått från affärsmått. Prestandamått spårar systemets beteende och arbetsbelastningshälsa, medan affärsmått spårar resultat. Även när de överlappar håller du dem i distinkta strömmar så att var och en kan analyseras och användas oberoende av varandra.

Skapa omfångs- och åtgärdsbara prestandaaviseringar

Målet med aviseringar är tidig identifiering av prestandaförsämring innan den blir användar synlig eller påverkar verksamheten. Skapa aviseringar på två nivåer: användarupplevelsen från slutpunkt till slutpunkt och grundläggande interna transaktioner som representerar kritiska systemsökvägar under belastning.

Använd en enda, konsekvent datauppsättning i varje miljö för både mål och aviseringar. Om aviseringar baseras på andra data än dina prestandamål blir de opålitliga och svåra att lita på.

Skapa aviseringar som är användbara och tydligt knutna till prestandaresultat. Varje avisering bör ange vilket tröskelvärde som hade en ihållande överträdelse, den potentiella effekten och de komponenter som berörs, så det är tydligt var du ska undersöka och vad som påverkas. Börja med vanliga, välkända tröskelvärden och förfina dem sedan över tid baserat på observerat systembeteende och arbetsbelastningsegenskaper.

När direkt aviseringar om ett externt beroende inte är möjligt kan du använda indirekta signaler som varaktighet för beroendeanrop, felfrekvenser eller timeoutbeteende för att beräkna dess inverkan på systemets prestanda.

Övervaka elasticitet

Mät hur systemet svarar på ändringar i efterfråge- och skalningshändelser.

Spåra svarstiden för kallstart och initiering för att förstå hur startkostnader påverkar svarstiden, särskilt vid utskalningshändelser. Övervaka utskalnings- och inskalningsbeteende för att utvärdera hur snabbt systemet anpassar sig till ändringar i belastningen och om skalningsåtgärderna håller jämna steg med efterfrågan.

Spåra prestanda över tid

Spåra hur prestanda utvecklas med ändringar i din design och dina externa faktorer.

Upprätta baslinjer som representerar förväntade systemprestanda och jämför sedan aktuellt beteende med dem för att identifiera drift, inklusive regressioner och förbättringar.

Ansluta prestandaändringar till drifthändelser som distributioner, konfigurationsuppdateringar och skalningsåtgärder. Kommentera tidslinjer med dessa händelser så att förändringar i beteendet har tydlig kontext och kan spåras tillbaka till troliga orsaker.

Använd den här kontinuerliga synligheten som en feedbackloop för tekniska beslut. Mata in prestandainsikter i planering och prioritering och behandla dem som indata till vanligt arbete i stället för bara incidenthantering.

Förfina prestandamålen kontinuerligt när systemet utvecklas. Justera serviceavtal, tröskelvärden och förväntningar baserat på observerade beteende- och användningsmönster så att målen förblir realistiska och anpassade till den faktiska användarupplevelsen.

Samla in prestandadata för program

Du måste ha programmets prestandamått, till exempel dataflöde, svarstid och slutförandetider, främst insamlade via instrumenteringskod.

Instrumentkritiska körningsvägar där prestanda är mest synliga: nyckelbegäransflöden, resursintensiva åtgärder och punkter där externa beroenden eller återförsök sker. Se till att end-to-end-transaktionssynlighet säkerställs så att totala köretiden och dess bidragande steg kan mätas.

Samla in tre kärntyper av prestandasignaler:

• Mått för aggregerat prestandabeteende (svarstidsfördelningar, dataflöde, felfrekvenser)
• Spår för att förstå hur tiden fördelas över förfrågningsvägar och systemkomponenter
• Loggar för detaljerad körningskontext vid specifika steg eller händelser

Använd konsekventa metadata för dessa signaler så att prestandadata kan korreleras mellan lager i systemet och mellan tjänster.

Undvik att duplicera prestandasignaler på lägre nivå som redan exponeras av plattformen om inte ytterligare kornighet krävs för att förklara arbetsbelastningsspecifikt beteende eller flaskhalsar.

Samla in resursprestandadata

Samla in prestandadata på resursnivå för att förstå hur infrastrukturkomponenter beter sig under belastning och hur de bidrar till övergripande arbetsbelastningsprestanda.

Varje tjänst exponerar plattformsspecifika mått som återspeglar dess hälso- och prestandaegenskaper. Använd diagnostikinställningen för att exportera dessa data så att de kan nås för aviseringar, instrumentpaneler och långsiktig analys utöver kortsiktig kvarhållning av plattformar.

Samla in mått och loggar för alla resurser. Spåra beräknings- och lagringsanvändningen mot förväntade intervall för att bekräfta att underetablering inte introducerar svarstid och försämrad prestanda under belastning. Överetablering kan också identifieras med dessa datauppgifter genom att analysera P99-användning och jämföra med kvarvarande kapacitet på dina resurser.

Övervaka nätverkstrafik som en del av resursprestanda. Analysera trafikflödet mellan undernät och tjänstgränser för att förstå svarstider, överbelastning och dataöverföringsmönster som kan påverka arbetsbelastningens prestanda.

Samla in databas- och lagringsdata

Databas- och lagringssystem producerar specialiserade prestandasignaler för att identifiera flaskhalsar, validera kapacitet och förstå arbetsbelastningsbeteende. Dessa signaler kommer vanligtvis från inbyggda övervakningsverktyg och systemgenererade loggar.

Fokusera på viktiga prestandadimensioner:

För databaser utökar du övervakningen till arbetsbelastningsspecifikt beteende:

Använd dessa signaler tillsammans för att skilja mellan långsamma frågor, resursmättnad och strukturell ineffektivitet. Detta möjliggör riktad optimering i både lagringssystem och databasarbetsbelastningar.

Samla in prestandadata för operativsystemet

För infrastrukturbaserade arbetsbelastningar samlar du in mått på operativsystemnivå för att förstå hur beräkningsresurser används och var resursbegränsningar kan uppstå.

Sampla operativsystemets prestandaräknare med jämna mellanrum för att fånga systemets tidsbaserade beteende under belastning.

Använd dessa signaler för att identifiera resursmättnad på operativsystemnivå och för att skilja mellan ineffektivitet på programnivå och infrastrukturbegränsningar.

Generera syntetiska data vid behov

Om systemet inte används konsekvent är det svårt att avgöra om det fungerar bra när trafiken returneras.

Du kan åtgärda detta genom att använda syntetiska transaktioner som skickar automatiserade begäranden via systemet. Dessa simulerar verklig användning utan att påverka faktiska användare eller data. Detta hjälper till att hålla delar av systemet aktivt, generera konsekventa prestandamått och avslöja mönster (till exempel problem med tid på dagen) som oregelbunden användning kan dölja.

Azure-förenkling

Azure Monitor tillhandahåller en enhetlig plattform för att samla in, analysera och svara på prestandadata i hela arbetsbelastningen. Den aggregerar data från program, infrastruktur och externa källor till en gemensam dataplattform.

Datainsamling och lagring: Använd Log Analytics-arbetsytor för att centralisera dina prestandadata med konfigurerbara kvarhållningsprinciper. Skapa flera arbetsytor för att segmentera data efter miljö- eller efterlevnadskrav.

Programövervakning: Application Insights samlar in telemetri på programnivå, inklusive begärandefrekvens, svarstider och undantag. Aktivera distribuerad spårning för att korrelera prestanda mellan distribuerade komponenter.

Infrastrukturövervakning: Aktivera diagnostikinställningar för alla Azure-tjänster för att samla in plattformsloggar och mått. Använd Azure Diagnostics-tillägget för detaljerade prestandadata för virtuella datorer. Utforska telemetrialternativ för din specifika plattform. Kubernetes-kluster genererar till exempel omfattande prestandatelemetri via Prometheus-integreringar .

Databas och lagring: Azure Monitor tillhandahåller inbyggd övervakning för Azure SQL Database, MySQL, PostgreSQL och lagringstjänster. Azure Storage Analytics spårar viktiga prestandaindikatorer som dataflöde och svarstid i Blob, Table och Queue Storage.

Aviseringar och analys: Skapa aviseringsregler med anpassningsbara tröskelvärden, tidsfönster och åtgärder (e-post, webhooks, Azure Functions). Använd Azure Monitor-loggar för att korsfråga och korrelera prestandadata. Prisinformation finns i Prissättning för Azure Monitor.

Exempel

• Baslinje med hög tillgänglighet för webbprogram för zonredundanta apptjänster
• Övervaka ett mikrotjänstprogram i Azure Kubernetes Service (AKS)
• Övervaka komponenter i landningszonen för Azure-plattformar

Relaterade länkar

• Plattformsmetrik
• Diagnostikinställningar
• Granskningsloggar

Checklista för prestandaeffektivitet

Se den fullständiga uppsättningen med rekommendationer.