Får du höra om driftstopp från dina användare? Övervakning av en .NET-applikation med Application Insights

Måndag, kl. 9.15. En kund ringer: ”Det fungerar inte.” Teamet loggar in på servern och gräver i loggar, och en timme senare inser någon att databasanslutningen bröts klockan tre på natten. Applikationen var halvdöd i sex timmar, och du fick veta det från en kund.

Frågan är inte om det här kommer att hända. Frågan är om du blir den som får veta det först.

Det här ser du när övervakningen är på plats

Application Insights är Microsofts verktyg för applikationsövervakning i Azure. När det är påslaget ser skillnaden ut så här:

Fråga	Utan övervakning	Med Application Insights
Är applikationen uppe just nu?	Någon öppnar den och tittar	Ett tillgänglighetstest med några minuters mellanrum, och ett larm om det misslyckas
Varför är den långsam?	Gissningar	Exakt vilken skärm, vilken databasfråga och hur lång tid den tar
Vad gick sönder klockan tre på natten?	Grävande i loggar på servern	Felet med hela spårningen, på ett ställe
Hur många användare drabbades?	Ingen vet	Antalet misslyckade förfrågningar och drabbade användare
Är det en extern tjänst som bär skulden?	Fingerpekande	Varje anrop till databasen och externa API:er, med tid och resultat

För en chef betyder det två saker: du får veta om ett problem innan kunden gör det, och när ni sätter er ner för att gå igenom vad som hände ligger det siffror på bordet, inte intryck.

Så sätter du upp det: några rader kod

För en ASP.NET Core-applikation räcker det att lägga till Microsofts paket Azure.Monitor.OpenTelemetry.AspNetCore och en rad i Program.cs:

builder.Services.AddOpenTelemetry().UseAzureMonitor();   // requests, errors, database and external calls

var app = builder.Build();

app.MapHealthChecks("/health");                          // the address the availability test checks

Anslutningen till Application Insights går via inställningen APPLICATIONINSIGHTS_CONNECTION_STRING i App Service, inte via koden. Från och med då registreras varje förfrågan, varje fel och varje anrop till databasen och externa tjänster automatiskt.

Det är den enkla delen. Den svåra delen är att bestämma vad som ska väcka dig klockan tre på natten och vad som kan vänta till morgonen.

Fem larm som varje applikation behöver

1. Tillgänglighetstestet misslyckades. Med några minuters mellanrum öppnar Azure din applikation från flera platser i världen. Om den inte svarar får du ett larm.
2. En plötslig ökning av misslyckade förfrågningar. När felen hoppar över sin vanliga nivå har något ändrats, oftast en ny version eller en extern tjänst.
3. Svaren blir långsamma. Svarstid över en överenskommen gräns i mer än några minuter.
4. Anrop till databasen eller externa tjänster misslyckas. Den vanligaste orsaken till att ”appen inte fungerar” som inte ligger i din egen kod.
5. Servern är vid sin gräns. Processor eller minne över till exempel 80 % under lång tid. En varning innan det blir ett driftstopp.

Ett larm måste nå en person som agerar på det, via e-post, sms eller i Teams. Ett larm som hamnar i en inkorg som ingen läser är detsamma som inget larm alls.

Om du använder de gamla tillgänglighetstesterna: sista dag är 30 september 2026

Microsoft pensionerar de gamla URL-pingtesterna i Application Insights den 30 september 2026. Om du fortfarande använder dem, flytta dem till standardtester. Annars slutar din tillgänglighetsövervakning tyst att fungera, och det är precis den sortens fel du skulle vilja ha ett larm för.

Så hindrar du övervakningen från att äta upp budgeten

Application Insights debiteras efter mängden data som registreras. Därför betalar vissa företag mer för övervakningen än för själva applikationen. Tre saker håller det under kontroll:

• Sampling. Du behöver inte registrera varje lyckad förfrågan. En representativ andel räcker, och alla fel sparas.
• Loggnivå. I produktion behövs inte allt som skrivs ut under utvecklingen. Detaljerade loggar slås på när något utreds och stängs sedan av igen.
• Ett dagligt tak. En övre gräns som skyddsnät, ifall ett fel plötsligt börjar skriva tusentals poster i minuten.

Införande i fyra steg

1. Slå påPaket, inställning, tillgänglighetstest
2. LarmFem larm, till rätt personer
3. ÖversiktEn skärm för applikationens hälsa
4. RutinEn titt på trenderna varje vecka

När övervakningen fungerar är nästa steg att använda den: vilka skärmar är långsammast och vilka fel återkommer. Det är samma mätning som vi skrev om i artikeln om långsamma applikationer, fast nu kommer data av sig själv.

Så arbetar vi

ProCoding är en .NET-studio från Split i Kroatien, och Azure för .NET-applikationer är en av våra specialiseringar. Det här är precis vad vi gör: vi sätter upp övervakning, larm och en kostnadsgenomgång som en del av en Azure-hälsokontroll, eller tillsammans med ditt team. Det första steget är ett kostnadsfritt samtal på 30 minuter.

Källor

• Tillgänglighetstester i Application Insights, Microsoft Learn
• Aktivera Azure Monitor OpenTelemetry för .NET-applikationer, Microsoft Learn