Baslinje med hög tillgänglighet zonredundant webbapp

Den här artikeln innehåller en baslinjearkitektur för att köra webbprogram i Azure App Service i en enda region. Den beskriver vägledning för att utforma ett säkert, zonredundant och högtillgängligt webbprogram i Azure. Arkitekturen exponerar en offentlig slutpunkt via Azure Application Gateway med brandväggen för webbprogram. Den dirigerar begäranden till Azure App Service via Private Link. App Service-programmet använder integrering av virtuella nätverk och Private Link för att kommunicera säkert med Azure PaaS-tjänster som Azure Key Vault och Azure SQL Database.

Arkitektur

Bild 1: Azure App Service-arkitektur för baslinje

Ladda ned en Visio-fil med den här arkitekturen.

Komponenter

• Microsoft Entra ID är en molnbaserad identitets- och åtkomsthanteringstjänst. Det ger ett enda identitetskontrollplan för att hantera behörigheter och roller för användare som har åtkomst till din webbapp. Den integreras med App Service och förenklar autentisering och auktorisering för webbappar.
• Application Gateway är en layer 7-lastbalanserare (HTTP/S) och webbtrafikhanterare. Den använder URL-sökvägsbaserad routning för att distribuera inkommande trafik mellan tillgänglighetszoner och avlasta kryptering för att förbättra programmets prestanda.
• Web Application Firewall (WAF) är en molnbaserad tjänst som skyddar webbappar från vanliga kryphål som SQL-inmatning och skript för flera webbplatser. WAF ger insyn i trafiken till och från webbappen så att du kan övervaka och skydda ditt program.
• App Service är en fullständigt hanterad plattform för att skapa, distribuera och skala webbprogram.
• Azure Key Vault är en tjänst som lagrar och hanterar hemligheter, krypteringsnycklar och certifikat på ett säkert sätt. Det centraliserar hanteringen av känslig information.
• Azure Monitor är en övervakningstjänst som samlar in, analyserar och agerar på telemetridata i distributionen.
• Virtuellt Azure-nätverk är en tjänst som gör att du kan skapa isolerade och säkra privata virtuella nätverk i Azure. För ett webbprogram i App Service behöver du ett undernät för virtuellt nätverk för att använda privata slutpunkter för nätverkssäker kommunikation mellan resurser.
• Private Link gör det möjligt för klienter att komma åt PaaS-tjänster (Plattform som en tjänst) direkt från privata virtuella nätverk utan att använda offentliga IP-adresser.
• Azure DNS är en värdtjänst för DNS-domäner som tillhandahåller namnmatchning med hjälp av Microsoft Azure-infrastrukturen. Privat DNS zoner är ett sätt att mappa en tjänsts fullständigt kvalificerade domännamn (FQDN) till en privat slutpunkts IP-adress.
• Azure SQL Database är en hanterad relationsdatabastjänst för relationsdata.

Nätverk

Nätverkssäkerhet är kärnan i App Services-baslinjearkitekturen (se bild 2). Från en hög nivå säkerställer nätverksarkitekturen följande:

1. En enda säker startpunkt för klienttrafik
2. Nätverkstrafik filtreras
3. Data under överföring krypteras från slutpunkt till slutpunkt med TLS
4. Dataexfiltrering minimeras genom att trafik hålls i Azure med hjälp av Private Link
5. Nätverksresurser grupperas logiskt och isoleras från varandra via nätverkssegmentering

Nätverksflöden

Bild 2: Nätverksarkitektur för azure App Service-baslinjeprogrammet

Följande är beskrivningar av det inkommande flödet av Internettrafik till App Service-instansen och flödet från App Service till Azure-tjänster.

inkommande flöde

1. Användaren skickar en begäran till den offentliga IP-adressen för Application Gateway.
2. WAF-reglerna utvärderas. WAF-regler påverkar systemets tillförlitlighet positivt genom att skydda mot olika attacker, till exempel korsplatsskript (XSS) och SQL-inmatning. Azure Application Gateway returnerar ett fel till beställaren om en WAF-regel överträds och bearbetningen stoppas. Om inga WAF-regler överträds dirigerar Application Gateway begäran till serverdelspoolen, vilket i det här fallet är App Service-standarddomänen.
3. Den privata DNS-zonen privatelink.azurewebsites.net är länkad till det virtuella nätverket. DNS-zonen har en A-post som mappar App Service-standarddomänen till den privata IP-adressen för den privata App Service-slutpunkten. Med den här länkade privata DNS-zonen kan Azure DNS matcha standarddomänen med IP-adressen för den privata slutpunkten.
4. Begäran dirigeras till en App Service-instans via den privata slutpunkten.

App Service till Azure PaaS-tjänstflöde

1. App Service skickar en begäran till DNS-namnet på den nödvändiga Azure-tjänsten. Begäran kan vara till Azure Key Vault för att hämta en hemlighet, Azure Storage för att hämta en publicerande zip-fil, Azure SQL Database eller någon annan Azure-tjänst som stöder Private Link. Integreringsfunktionen för det virtuella Nätverket i App Service dirigerar begäran via det virtuella nätverket.
2. Precis som steg 3 i det inkommande flödet har den länkade privata DNS-zonen en A-post som mappar Azure-tjänstens domän till den privata IP-adressen för den privata slutpunkten. Återigen gör den här länkade privata DNS-zonen att Azure DNS kan matcha domänen till tjänstens privata slutpunkts-IP-adress.
3. Begäran dirigeras till tjänsten via den privata slutpunkten.

Ingress till App Services

Application Gateway är en regional resurs som uppfyller kraven för den här baslinjearkitekturen. Application Gateway är en skalbar, regional lastbalanserare på nivå 7 som stöder funktioner som brandvägg för webbprogram och TLS-avlastning. Tänk på följande när du implementerar Application Gateway för ingress till Azure App Services.

• Distribuera Application Gateway och konfigurera en WAF-princip med en Microsoft-hanterad regeluppsättning. Använd förebyggande läge för att minska webbattacker, vilket kan göra att en ursprungstjänst (App Service i arkitekturen) blir otillgänglig.
• Implementera TLS-kryptering från slutpunkt till slutpunkt.
• Använd privata slutpunkter för att implementera inkommande privat åtkomst till din App Service.
• Överväg att implementera automatisk skalning för Application Gateway för att enkelt anpassa till dynamiska trafikflöden.
• Överväg att använda ett minsta antal skalningsinstanser på inte mindre än tre och använd alltid alla tillgänglighetszoner som din region stöder. Även om Application Gateway distribueras på ett sätt med hög tillgänglighet kan det ta upp till sju minuter att skapa en ny instans vid ett fel, även för en enskild skalningsinstans. Om du distribuerar flera instanser över Tillgänglighetszoner ser du till att en instans körs när en ny instans skapas vid ett fel.
• Inaktivera åtkomst till offentligt nätverk i App Service för att säkerställa nätverksisolering. I Bicep åstadkommer du detta genom att ange publicNetworkAccess: 'Disabled' under egenskaper/siteConfig.

Flöde från App Services till Azure-tjänster

Den här arkitekturen använder integrering av virtuella nätverk för App Service, särskilt för att dirigera trafik till privata slutpunkter via det virtuella nätverket. Baslinjearkitekturen aktiverar inte all trafikroutning för att tvinga all utgående trafik genom det virtuella nätverket, bara intern trafik, till exempel trafik som är bunden till privata slutpunkter.

Azure-tjänster som inte kräver åtkomst från det offentliga Internet ska ha privata slutpunkter aktiverade och offentliga slutpunkter inaktiverade. Privata slutpunkter används i hela den här arkitekturen för att förbättra säkerheten genom att låta Din App Service ansluta till Private Link-tjänster direkt från ditt privata virtuella nätverk utan att använda offentliga IP-adresser.

I den här arkitekturen har Azure SQL Database, Azure Storage och Key Vault alla inaktiverade offentliga slutpunkter. Azure-tjänstbrandväggar används endast för att tillåta trafik från andra auktoriserade Azure-tjänster. Du bör konfigurera andra Azure-tjänster med privata slutpunkter, till exempel Azure Cosmos DB och Azure Redis Cache. I den här arkitekturen använder Azure Monitor inte en privat slutpunkt, men det kan det.

Baslinjearkitekturen implementerar en privat DNS-zon för varje tjänst. Den privata DNS-zonen innehåller en A-post som mappar mellan tjänstens fullständigt kvalificerade domännamn och den privata slutpunktens privata IP-adress. Zonerna är länkade till det virtuella nätverket. Privat DNS zongrupper ser till att DNS-poster för privata länkar skapas och uppdateras automatiskt.

Tänk på följande när du implementerar integrering av virtuella nätverk och privata slutpunkter.

• Använd konfigurationsvägledningen för DNS-zonen i Azure-tjänster för att namnge privata DNS-zoner.
• Konfigurera tjänstbrandväggar för att säkerställa att lagringskontot, nyckelvalvet, SQL Database och andra Azure-tjänster endast kan anslutas till privat.
  • Ange standardregeln för nätverksåtkomst för lagringskonto för att neka all trafik.
  • Aktivera Key Vault för Private Link.
  • Neka åtkomst till offentligt nätverk till Azure SQL.

Segmentering och säkerhet för virtuella nätverk

Nätverket i den här arkitekturen har separata undernät för Application Gateway, App Service-integreringskomponenter och privata slutpunkter. Varje undernät har en nätverkssäkerhetsgrupp som begränsar både inkommande och utgående trafik för dessa undernät till precis vad som krävs. I följande tabell visas en förenklad vy över NSG-reglerna som baslinjen lägger till i varje undernät. Tabellen ger regelnamnet och funktionen.

Tänk på följande när du implementerar segmentering och säkerhet för virtuella nätverk.

• Aktivera DDoS-skydd för det virtuella nätverket med ett undernät som ingår i en programgateway med en offentlig IP-adress.
• Lägg till en NSG i varje undernät där det är möjligt. Du bör använda de striktaste reglerna som aktiverar fullständiga lösningsfunktioner.
• Använd programsäkerhetsgrupper. Med programsäkerhetsgrupper kan du gruppera NSG:er, vilket gör det enklare att skapa regler för komplexa miljöer.

Ett exempel på ett virtuellt undernätsschema kan vara:

Referera till Azure-Samples\app-service-baseline-implementation

Tillförlitlighet

App Services-baslinjearkitekturen fokuserar på zonredundans för viktiga regionala tjänster. Tillgänglighetszoner är fysiskt separata platser i en region. De tillhandahåller zonredundans för stödtjänster när två eller flera instanser distribueras i stödregioner. När en zon drabbas av stilleståndstid kan de andra zonerna fortfarande vara opåverkade.

Arkitekturen säkerställer också tillräckligt många instanser av Azure-tjänster för att möta efterfrågan. Följande avsnitt innehåller vägledning om tillförlitlighet för viktiga tjänster i arkitekturen. På så sätt hjälper tillgänglighetszoner dig att uppnå tillförlitlighet genom att tillhandahålla hög tillgänglighet och feltolerans.

Application Gateway

Distribuera Azure Application Gateway v2 i en zonredundant konfiguration. Överväg att använda ett minsta skalningsinstansantal på inte mindre än tre för att undvika starttiden på sex till sju minuter för en instans av Application Gateway om det uppstår ett fel.

App Services

• Distribuera minst tre instanser av App Services med stöd för tillgänglighetszoner.
• Implementera slutpunkter för hälsokontroll i dina appar och konfigurera funktionen App Tjänststatus kontrollera för att omdirigera begäranden från instanser som inte är felfria. Mer information om App Service Health-kontroll finns i Övervaka App Service-instanser med hjälp av hälsokontroll. Mer information om hur du implementerar slutpunkter för hälsokontroll i ASP.NET program finns i Hälsokontroller i ASP.NET Core.
• Överetableringskapacitet för att kunna hantera zonfel.

SQL Database

• Distribuera Azure SQL DB Generell användning, Premium eller Affärskritisk med zonredundans aktiverad. Nivåerna Generell användning, Premium och Affärskritisk stöder zonredundans i Azure SQL DB.
• Konfigurera SQL DB-säkerhetskopieringar så att de använder zonredundant lagring (ZRS) eller geo-zonredundant lagring (GZRS).

Blobb-lagring

• Azure Zone-Redundant Storage (ZRS) replikerar dina data synkront över tre tillgänglighetszoner i regionen. Skapa Standard ZRS- eller Standard GZRS-lagringskonton för att säkerställa att data replikeras mellan tillgänglighetszoner.
• Skapa separata lagringskonton för distributioner, webbtillgångar och andra data så att du kan hantera och konfigurera kontona separat.

Skalbarhet

Med skalbarhet kan program hantera ökningar och minskningar av efterfrågan samtidigt som prestanda och kostnader optimeras. I följande avsnitt beskrivs skalbarhet för viktiga komponenter i den här arkitekturen.

Application Gateway

• Implementera automatisk skalning för Application Gateway för att skala in eller ut för att möta efterfrågan.
• Ange det maximala antalet instanser till ett tal som är högre än ditt förväntade behov. Du debiteras bara för de kapacitetsenheter som du använder.
• Ange ett minsta antal instanser som kan hantera små trafiktoppar. Du kan använda genomsnittlig beräkningsenhetsanvändning för att beräkna det minsta antalet instanser.
• Följ riktlinjerna för att ändra storlek på Application Gateway-undernätet.

App Service

• Använd Standard- eller högre abonnemang med tre eller flera arbetsinstanser för hög tillgänglighet.
• Aktivera Autoskalning för att se till att du kan skala upp och ned för att möta efterfrågan.
• Överväg att öppna ett supportärende för att öka det maximala antalet arbetare till två gånger antalet instanser om din App Service konsekvent använder hälften av det maximala antalet instanser. Det maximala antalet instanser är som standard upp till 30 för en Premium App Service-plan och 10 för en Standard-plan.
• Överväg att distribuera flera stämplar för programmet när din App Service börjar nå de övre gränserna.
• Välj rätt Azure App Service-plan som uppfyller dina arbetsbelastningskrav.
• Lägg till Azure CDN i Azure App Service för att hantera statiskt innehåll.
• Överväg App Service-miljön om bullriga grannar är ett problem.

SQL Server

Skalning av databasresurser är ett komplext ämne utanför omfånget för den här arkitekturen. Tänk på följande resurser när du skalar din databas.

• Dynamisk skalning av databasresurser med minimal stilleståndstid
• Skala ut med Azure SQL Database
• Använda skrivskyddade repliker för att avlasta skrivskyddade frågearbetsbelastningar

Andra riktlinjer för skalbarhet

• Granska prenumerationsgränser och kvoter för att säkerställa att tjänsterna skalas efter efterfrågan.
• Överväg att cachelagra följande typer av data för att öka prestanda och skalbarhet:
  • Delvis statiska transaktionsdata.
  • Sessionstillstånd.
  • HTML-utdata. Detta kan vara praktiskt i program som återger komplexa HTML-utdata.

Säkerhet

App Service-baslinjearkitekturen fokuserar på viktiga säkerhetsrekommendationer för din webbapp. Att förstå hur kryptering och identitet fungerar på varje lager är viktigt för att skydda din arbetsbelastning.

App Service

• Inaktivera lokala autentiseringsmetoder för FTP- och SCM-platsdistributioner
• Inaktivera fjärrfelsökning.
• Använd den senaste TLS-versionen.
• Aktivera Microsoft Defender för App Service.
• Använd de senaste versionerna av plattformar, programmeringsspråk, protokoll och ramverk som stöds.
• Överväg App Service-miljön om du behöver högre isolering eller säker nätverksåtkomst.

Kryptering

En produktionswebbapp måste kryptera data under överföring med HTTPS. HTTPS-protokollet förlitar sig på TLS (Transport Layer Security) och använder offentliga och privata nycklar för kryptering. Du måste lagra ett certifikat (X.509) i Key Vault och tillåta att Application Gateway hämtar den privata nyckeln. För vilande data krypterar vissa tjänster automatiskt data och andra kan du anpassa.

Data under överföring

I baslinjearkitekturen krypteras data under överföring från användaren till webbappen i App Service. Följande arbetsflöde beskriver hur kryptering fungerar på en hög nivå.

1. Användaren skickar en HTTPS-begäran till webbappen.
2. HTTPS-begäran når programgatewayen.
3. Programgatewayen använder ett certifikat (X.509) i Key Vault för att skapa en säker TLS-anslutning med användarens webbläsare. Programgatewayen dekrypterar HTTPS-begäran så att brandväggen för webbprogram kan inspektera den.
4. Programgatewayen skapar en TLS-anslutning med App Service för att kryptera om användarbegäran. App Service har inbyggt stöd för HTTPS, så du behöver inte lägga till ett certifikat i App Service. Programgatewayen skickar den krypterade trafiken till App Service. App Service dekrypterar trafiken och webbappen bearbetar begäran.

Tänk på följande rekommendationer när du konfigurerar datakryptering under överföring.

• Skapa eller ladda upp certifikatet till Key Vault. HTTPS-kryptering kräver ett certifikat (X.509). Du behöver ett certifikat från en betrodd certifikatutfärdare för din anpassade domän.
• Lagra den privata nyckeln i certifikatet i Key Vault.
• Följ riktlinjerna i Bevilja behörighet till program för att få åtkomst till ett Azure-nyckelvalv med hjälp av Azure RBAC och hanterade identiteter för Azure-resurser för att ge Application Gateway åtkomst till certifikatets privata nyckel. Använd inte Key Vault-åtkomstprinciper för att ge åtkomst. Med åtkomstprinciper kan du bara bevilja breda behörigheter, inte bara till specifika värden.
• Aktivera kryptering från slutpunkt till slutpunkt. App Service är serverdelspoolen för programgatewayen. När du konfigurerar serverdelsinställningen för serverdelspoolen använder du HTTPS-protokollet via serverdelsporten 443.

Vilande data

• Kryptera känsliga data i Azure SQL Database med transparent datakryptering. Transparenta data krypterar hela databasen, säkerhetskopior och transaktionsloggfiler och kräver inga ändringar i webbprogrammet.
• Minimera svarstiden för databaskryptering. För att minimera krypteringsfördröjningen placerar du de data som du behöver skydda i sin egen databas och aktiverar endast kryptering för den databasen.
• Förstå inbyggt krypteringsstöd. Azure Storage krypterar automatiskt vilande data med hjälp av kryptering på serversidan (256-bitars AES). Azure Monitor krypterar automatiskt vilande data med hjälp av Microsoft-hanterade nycklar (MMK:er).

Identitets- och åtkomsthantering

App Service-baslinjen konfigurerar autentisering och auktorisering för användaridentiteter (användare) och arbetsbelastningsidentiteter (Azure-resurser) och implementerar principen om minsta behörighet.

Användaridentiteter

• Använd den integrerade autentiseringsmekanismen för App Service ("EasyAuth"). EasyAuth förenklar processen med att integrera identitetsprovidrar i din webbapp. Den hanterar autentisering utanför webbappen, så du behöver inte göra några större kodändringar.
• Konfigurera svars-URL:en för den anpassade domänen. Du måste omdirigera webbappen till https://<application-gateway-endpoint>/.auth/login/<provider>/callback. Ersätt <application-gateway-endpoint> med antingen den offentliga IP-adressen eller det anpassade domännamnet som är associerat med din programgateway. Ersätt <provider> med den autentiseringsprovider som du använder, till exempel "aad" för Microsoft Entra-ID. Du kan använda Azure Front-dokumentationen för att konfigurera det här flödet med Application Gateway eller konfigurera Application Gateway.

Arbetsbelastningsidentiteter

• Använd hanterad identitet för arbetsbelastningsidentiteter. Hanterad identitet eliminerar behovet av att utvecklare hanterar autentiseringsuppgifter.
• Använd användartilldelade hanterade identiteter. En systemtilldelad identitet kan leda till att distributioner av infrastruktur som kod misslyckas baserat på konkurrensförhållanden och driftordning. Du kan använda användartilldelade hanterade identiteter för att undvika några av dessa distributionsfelscenarier. Mer information finns i Hanterade identiteter.

Distribution

Distribution för apptjänstprogrammets baslinje följer riktlinjerna i CI/CD för Azure Web Apps med Azure Pipelines. Utöver den vägledningen tar App Services-baslinjearkitekturen hänsyn till att programmet och distributionslagringskontot är nätverksskyddade. Arkitekturen nekar offentlig åtkomst till App Service. Det innebär att du inte kan distribuera utanför det virtuella nätverket. Baslinjen visar hur du distribuerar programkoden i det virtuella nätverket med hjälp av lokalt installerade distributionsagenter. Följande distributionsvägledning fokuserar på att distribuera programkoden och inte distribuera infrastruktur- eller databasändringar.

Bild 3: Distribuera Azure App Service-program

Distributionsflöde

1. Som en del av versionspipelinen publicerar pipelinen en jobbbegäran för de lokalt installerade agenterna i jobbkön. Jobbbegäran är att agenten laddar upp kompileringsartefakten publicera zip-fil till ett Azure Storage-konto.

2. Den lokalt installerade distributionsagenten hämtar den nya jobbbegäran genom avsökning. Det laddar ned jobbet och byggartefakten.

3. Den lokalt installerade distributionsagenten laddar upp zip-filen till lagringskontot via lagringskontots privata slutpunkt.

4. Pipelinen fortsätter och en hanterad agent hämtar ett efterföljande jobb. Den hanterade agenten gör ett CLI-anrop för att uppdatera appInställningar WEBSITE_RUN_FROM_PACKAGE till namnet på den nya publicerings-zip-filen för mellanlagringsplatsen.

   az webapp config appsettings set -g MyResourceGroupName -n MyUniqueApp --slot staging --settings WEBSITE_RUN_FROM_PACKAGE=UriToNewZip
   

5. Azure App Service hämtar den nya publicerings zip-filen från lagring via lagringskontots privata slutpunkt. Mellanlagringsinstansen startas om med det nya paketet eftersom WEBSITE_RUN_FROM_PACKAGE har angetts till ett annat filnamn.

6. Pipelinen återupptas och kör eventuella röktester eller väntar på godkännande. Om testerna godkänns eller godkänns byter pipelinen mellanlagrings- och produktionsplatserna.

Riktlinjer för distribution

Följande belyser viktiga distributionsvägledning för baslinjearkitekturen.

• Använd kör från paket för att undvika distributionskonflikter. När du kör appen direkt från ett paket i Azure App Service kopieras inte filerna i paketet till katalogen wwwroot. I stället monteras själva ZIP-paketet direkt som den skrivskyddade wwwroot-katalogen. Detta eliminerar fillåskonflikter mellan distribution och körning och säkerställer att endast fullständigt distribuerade appar körs när som helst
• Inkludera versionsnummer i de distribuerade zip-paketfilerna. WEBSITE_RUN_FROM_PACKAGE Om du uppdaterar appSetting till distributionspaketet med ett annat filnamn kan App Services automatiskt hämta den nya versionen och starta om tjänsten.
• Använd Distributionsfack för elastiska koddistributioner.
• Överväg att använda en blandning av hanterade och lokalt installerade agenter.
  • Använd lokalt installerade agenter för att ladda upp zip-paketfilen till lagringskontot via den privata slutpunkten. Agenten initierar kommunikation till pipelinen via avsökning så att det inte krävs för att öppna nätverket för ett inkommande anrop.
  • Använd hanterade agenter för de andra jobben i pipelinen.
• Automatisera infrastrukturdistributioner med IaC (Infrastructure as Code).
• Validera kontinuerligt arbetsbelastningen för att testa prestanda och motståndskraft för hela lösningen med hjälp av tjänster som Azure Load Testing och Azure Chaos Studio.

Konfiguration

Program kräver både konfigurationsvärden och hemligheter. Använd följande vägledning för konfiguration och hantering av hemligheter.

• Kontrollera aldrig hemligheter som lösenord eller åtkomstnycklar i källkontrollen.
• Använd Azure Key Vault för att lagra hemligheter.
• Använd App Service-konfigurationen för programkonfigurationen. Om du behöver externalisera konfigurationen från programkonfigurationen eller kräva stöd för funktionsflaggan kan du överväga att använda Azure App Configuration.
• Använd Key Vault-referenser i App Service-konfigurationen för att på ett säkert sätt exponera hemligheter i ditt program.
• Skapa appinställningar som håller sig till ett fack och inte byts ut om du behöver olika produktions- och mellanlagringsinställningar. När du växlar en distributionsplats kommer appinställningarna att växlas som standard.
• Ange lokala miljövariabler för lokal utveckling eller dra nytta av programplattformsfunktioner. App Services-konfigurationen exponerar appinställningar som miljövariabler. Med Visual Studio kan du till exempel ange miljövariabler i startprofiler. Du kan också använda App Inställningar och användarhemligheter för att lagra lokala programinställningar och hemligheter.

Övervakning

Övervakning är insamling och analys av data från IT-system. Målet med övervakning är observerbarhet i flera lager för att spåra webbappens hälsa och säkerhet. Observerbarhet är en viktig aspekt av apptjänstarkitekturens baslinje.

För att övervaka din webbapp måste du samla in och analysera mått och loggar från programkoden, infrastrukturen (körning) och plattformen (Azure-resurser). Mer information finns i Azure-aktivitetslogg, Azure-resursloggar och programloggar.

Övervaka plattformen

Plattformsövervakning är insamling av data från Azure-tjänsterna i din arkitektur. Överväg följande vägledning om plattformsövervakning.

• Lägg till en diagnostikinställning för varje Azure-resurs. Varje Azure-tjänst har en annan uppsättning loggar och mått som du kan samla in. Använd följande tabell för att ta reda på de mått och loggar som du vill samla in.

  Azure-resurs	Beskrivningar av mått och loggar
  Application Gateway	Application Gateway-mått och loggbeskrivningar
  Brandvägg för webbaserade program	Brandväggsmått för webbprogram och loggbeskrivningar
  App Service	Beskrivningar av App Service-mått och loggar
  Azure SQL Database	Beskrivning av Azure SQL Database-mått och -loggar
  CosmosDB	Azure Cosmos DB-mått och loggbeskrivningar
  Key Vault	Key Vault-mått och loggbeskrivningar
  Blob Storage	Azure Blob Storage-mått och loggbeskrivningar
  Programinsikter	Application Insights-mått och loggbeskrivningar
  Offentlig IP-adress	Offentliga IP-adressmått och loggbeskrivningar

• Förstå kostnaden för att samla in mått och loggar. I allmänhet, ju fler mått och loggar du samlar in, desto mer kostar det. Mer information finns i Log Analytics-kostnadsberäkningar och alternativ och Priser för Log Analytics-arbetsytan.

• Skapa aviseringar. Du bör skapa aviseringar för alla Azure-resurser i arkitekturen och konfigurera Åtgärder för att åtgärda problem. Välj vanliga och rekommenderade aviseringsregler att börja med och ändra över tid efter behov. Mer information finns i:

  • Översikt över Azure Monitor-aviseringar
  • Application Gateway-aviseringar
  • App Service-aviseringar
  • Azure SQL Database-aviseringar
  • Blob Storage-aviseringar
  • Key Vault-aviseringar

Application Gateway

Application Gateway övervakar hälsotillståndet för resurser i serverdelspoolen. Använd Application Gateway-åtkomstloggarna för att samla in information som tidsstämpeln, HTTP-svarskoden och URL-sökvägen. Mer information finns i Standardhälsoavsökning för Application Gateway och Serverdelshälsa och diagnostikloggar.

App Service

App Service har inbyggda och integrerade övervakningsverktyg som du bör aktivera för bättre observerbarhet. Om din webbapp redan har telemetri- och övervakningsfunktioner ("in-process instrumentation") bör den fortsätta att fungera på App Service.

• Aktivera automatisk instrumentering. App Service har ett instrumentationstillägg som du kan aktivera utan kodändringar. Du får synlighet för övervakning av programprestanda (APM). Mer information finns i Övervaka Azure App Service-prestanda.
• Aktivera distribuerad spårning. Automatisk instrumentering är ett sätt att övervaka distribuerade molnsystem via distribuerad spårning och en prestandaprofilerare.
• Använd kodbaserad instrumentation för anpassad telemetri. Azure Application Insights stöder även kodbaserad instrumentering för anpassad programtelemetri. Lägg till Application Insights SDK i koden och använd Application Insights-API:et.
• Aktivera App Service-loggar. App Service-plattformen stöder ytterligare fyra loggar som du bör aktivera för felsökning. Dessa loggar är programloggar, webbserverloggar, detaljerade felmeddelanden och misslyckad spårning av begäranden.
• Använd strukturerad loggning. Lägg till ett strukturerat loggningsbibliotek i programkoden. Uppdatera koden för att använda nyckel/värde-par och aktivera programloggar i App Service för att lagra loggarna på Log Analytics-arbetsytan.
• Aktivera App Service Health-kontrollen. Hälsokontrollen omdirigerar begäranden från instanser som inte är felfria och ersätter de instanser som inte är felfria. Din App Service-plan måste använda två eller flera instanser för att hälsokontroller ska fungera.

Databas

• Användardatabasinsikter. För Azure SQL-databaser bör du konfigurera SQL Insights i Azure Monitor. Database Insights använder dynamiska hanteringsvyer för att exponera de data som du behöver för att övervaka hälsa, diagnostisera problem och justera prestanda. Mer information finns i Övervaka Azure SQL Database med Azure Monitor.
• Om din arkitektur innehåller Cosmos DB behöver du inte aktivera eller konfigurera något för att använda Cosmos DB-insikter.

Kontroll

Webbappar drar nytta av Azure Policy genom att framtvinga beslut om arkitektur och säkerhet. Azure Policy kan göra det (1) omöjligt att distribuera (neka) eller (2) enkelt att identifiera (granska) konfigurationsavvikelser från önskat tillstånd. Detta hjälper dig att fånga upp IaC-distributioner (Infrastruktur som kod) eller Ändringar i Azure-portalen som avviker från den överenskomna arkitekturen. Du bör placera alla resurser i din arkitektur under Azure Policy-styrning. Använd inbyggda principer eller principinitiativ där det är möjligt för att framtvinga grundläggande nätverkstopologi, tjänstfunktioner, säkerhet och övervakningsbeslut, till exempel:

• App Service bör inaktivera åtkomst till offentligt nätverk
• App Service bör använda integrering av virtuella nätverk
• App Service bör använda Azure Private Link för att ansluta till PaaS-tjänster
• App Service bör ha lokala autentiseringsmetoder inaktiverade för FTP- och SCM-platsdistributioner
• App Service bör ha fjärrfelsökning inaktiverat
• App Service-appar bör använda den senaste TLS-versionen
• Microsoft Defender för App Service ska vara aktiverat
• Brandväggen för webbaserade program (WAF) ska vara aktiverad för Application Gateway

Se fler inbyggda principer för viktiga tjänster som Application Gateway och nätverkskomponenter, App Service, Key Vault och Övervakning. Det är möjligt att skapa anpassade principer eller använda community-principer (till exempel från Azure-landningszoner) om inbyggda principer inte helt täcker dina behov. Föredrar inbyggda principer när de är tillgängliga.

Nästa steg

Relaterade resurser

• Guide till Private Link i Virtual WAN
• Skala upp en app i Azure App Service
• Migrera App Service till stöd för tillgänglighetszoner
• Skala Application Gateway v2 och WAF v2