Hoort u van storingen via uw gebruikers? Monitoring van een .NET-applicatie met Application Insights

Maandag, 9.15 uur. Een klant belt: “Het werkt niet.” Het team logt in op de server en graaft door de logs, en een uur later beseft iemand dat de databaseverbinding om drie uur ’s nachts is weggevallen. De applicatie was zes uur half dood, en u hoorde het van een klant.

De vraag is niet of dit gebeurt. De vraag is of u het als eerste weet.

Wat u ziet als monitoring is ingericht

Application Insights is de monitoringtool van Microsoft voor applicaties op Azure. Staat het aan, dan ziet het verschil er zo uit:

Vraag	Zonder monitoring	Met Application Insights
Draait de applicatie op dit moment?	Iemand opent hem en kijkt	Een beschikbaarheidstest om de paar minuten, en een alert als hij faalt
Waarom is hij traag?	Gokken	Het precieze scherm, de databasequery en hoe lang die duurt
Wat ging er om drie uur ’s nachts kapot?	Zoeken in de logs op de server	De fout met het volledige spoor, op één plek
Hoeveel gebruikers waren getroffen?	Niemand weet het	Het aantal mislukte verzoeken en getroffen gebruikers
Ligt het aan een externe dienst?	Naar elkaar wijzen	Elke aanroep naar de database en externe API’s, met duur en resultaat

Voor het management betekent dat twee dingen: u hoort van een probleem voordat de klant het merkt, en als u later bespreekt wat er gebeurde, liggen er cijfers op tafel in plaats van indrukken.

De inrichting: een paar regels code

Voor een ASP.NET Core-applicatie is het genoeg om het Microsoft-pakket Azure.Monitor.OpenTelemetry.AspNetCore toe te voegen en één regel in Program.cs:

builder.Services.AddOpenTelemetry().UseAzureMonitor();   // verzoeken, fouten, database- en externe aanroepen

var app = builder.Build();

app.MapHealthChecks("/health");                          // het adres dat de beschikbaarheidstest controleert

De koppeling met Application Insights loopt via de instelling APPLICATIONINSIGHTS_CONNECTION_STRING in App Service, niet via de code. Vanaf dat moment worden alle verzoeken, fouten en aanroepen naar de database en externe diensten automatisch vastgelegd.

Dat is het makkelijke deel. Het moeilijke deel is bepalen wat u om drie uur ’s nachts wakker mag maken en wat tot de ochtend kan wachten.

Vijf alerts die elke applicatie nodig heeft

1. De beschikbaarheidstest is mislukt. Azure opent uw applicatie om de paar minuten vanaf meerdere locaties in de wereld. Reageert hij niet, dan volgt een alert.
2. Plotseling meer mislukte verzoeken. Als fouten boven hun gebruikelijke niveau springen, is er iets veranderd, meestal een nieuwe versie of een externe dienst.
3. Antwoorden worden traag. De responstijd ligt langer dan een paar minuten boven een afgesproken grens.
4. Aanroepen naar de database of externe diensten mislukken. De meest voorkomende oorzaak van “de app werkt niet” die niet in uw eigen code zit.
5. De server zit aan zijn limiet. Processor of geheugen lange tijd boven, zeg, 80%. Een waarschuwing voordat het een storing wordt.

Een alert moet terechtkomen bij iemand die erop reageert, per e-mail, sms of in Teams. Een alert in een inbox die niemand leest, is hetzelfde als geen alert.

Als u de oude beschikbaarheidstests gebruikt: de deadline is 30 september 2026

Microsoft stopt op 30 september 2026 met de oude URL-pingtests in Application Insights. Gebruikt u ze nog, zet ze dan om naar standaardtests. Anders stopt uw beschikbaarheidsmonitoring stilletjes, en dat is precies het soort storing waarvoor u een alert zou willen.

Zodat monitoring de rekening niet opeet

Application Insights wordt gefactureerd naar de hoeveelheid data die het vastlegt. Daarom betalen sommige bedrijven meer voor monitoring dan voor de applicatie zelf. Drie dingen houden dat in de hand:

• Sampling. U hoeft niet elk geslaagd verzoek vast te leggen. Een representatief deel is genoeg, en fouten worden allemaal bewaard.
• Logniveau. In productie is niet alles nodig wat tijdens de ontwikkeling wordt weggeschreven. Gedetailleerde logs gaan aan tijdens een onderzoek en daarna weer uit.
• Een daglimiet. Een bovengrens als vangnet, voor het geval een fout plotseling duizenden regels per minuut begint te schrijven.

Zo voeren we het in

1. AanzettenPakket, instelling, beschikbaarheidstest
2. AlertsVijf alerts, naar de juiste mensen
3. OverzichtEén scherm voor de gezondheid van de app
4. RoutineWekelijks een blik op de trends

Als de monitoring werkt, is de volgende stap om hem te gebruiken: welke schermen zijn het traagst en welke fouten komen steeds terug? Het is hetzelfde meten waarover we schreven in het artikel over trage applicaties, alleen komt de data nu vanzelf binnen.

Hoe wij werken

ProCoding is een .NET-studio uit Split, Kroatië, en Azure voor .NET-applicaties is een van onze specialisaties. Monitoring, alerts en een kostenreview richten we in als onderdeel van een Azure health check, of samen met uw team. De eerste stap is een gratis gesprek van 30 minuten.

Bronnen

• Beschikbaarheidstests in Application Insights, Microsoft Learn
• Azure Monitor OpenTelemetry inschakelen voor .NET-applicaties, Microsoft Learn