Saznajete za pad aplikacije od korisnika? Nadzor .NET aplikacije s Application Insights

Za pad aplikacije saznajete od kupca? Što Application Insights pokazuje, kako se postavlja, pet alarma koje treba svaka aplikacija i kako da ne pojede račun.

Vlado Pandžić

Vlado Pandžić · Osnivač · Senior .NET arhitekt
Objavljeno · 4 min čitanja

Ponedjeljak, 9:15. Zove kupac: “Ne radi.” Tim otvara server i prekopava logove, a sat vremena kasnije netko shvati da je veza prema bazi pukla u tri ujutro. Aplikacija je šest sati bila napola mrtva, a vi ste to saznali od kupca.

Pitanje nije hoće li se to dogoditi, nego hoćete li saznati prvi.

Što vidite kad je nadzor postavljen

Application Insights je Microsoftov alat za nadzor aplikacija na Azureu. Kad je uključen, razlika izgleda ovako:

Pitanje Bez nadzora S Application Insights
Radi li aplikacija upravo sad? Netko je otvori i pogleda Test dostupnosti svakih nekoliko minuta i alarm ako padne
Zašto je spora? Nagađanje Točan ekran, upit u bazi i koliko traje
Što je puklo u tri ujutro? Traženje po logovima na serveru Greška s cijelim tragom, na jednom mjestu
Koliko je korisnika pogođeno? Nitko ne zna Broj zahtjeva i korisnika s greškom
Je li kriv vanjski servis? Prebacivanje krivnje Svaki poziv prema bazi i vanjskim API-jima, s trajanjem i ishodom

Za šefa to znači dvije stvari: o problemu saznaje prije kupca, a kad dođe do sastanka o tome što se dogodilo, na stolu su brojke, a ne dojmovi.

Postavljanje: nekoliko redaka koda

Za ASP.NET Core aplikaciju dovoljno je dodati Microsoftov paket Azure.Monitor.OpenTelemetry.AspNetCore i jednu liniju u Program.cs:

builder.Services.AddOpenTelemetry().UseAzureMonitor();   // zahtjevi, greške, pozivi baze i vanjskih servisa

var app = builder.Build();

app.MapHealthChecks("/health");                          // adresa koju provjerava test dostupnosti

Veza prema Application Insightsu ide kroz postavku APPLICATIONINSIGHTS_CONNECTION_STRING u App Serviceu, a ne kroz kod. Od tog trenutka se automatski bilježe svi zahtjevi, greške i pozivi prema bazi i vanjskim servisima.

To je lakši dio. Teži je dio odlučiti što će vas probuditi u tri ujutro, a što može čekati jutro.

Pet alarma koje treba svaka aplikacija

  1. Test dostupnosti je pao. Azure svakih nekoliko minuta s više lokacija u svijetu otvori vašu aplikaciju. Ako ne odgovori, alarm.
  2. Naglo više neuspjelih zahtjeva. Kad greške skoče iznad uobičajene razine, nešto se promijenilo, obično nova verzija ili vanjski servis.
  3. Odgovori postaju spori. Vrijeme odgovora iznad dogovorenog praga dulje od nekoliko minuta.
  4. Pucaju pozivi prema bazi ili vanjskim servisima. Najčešći uzrok “aplikacija ne radi” koji nije u vašem kodu.
  5. Server je na granici. Procesor ili memorija dugo iznad, recimo, 80 %. Upozorenje prije nego postane pad.

Alarm mora doći do čovjeka koji će reagirati, na mail, SMS ili u Teams. Alarm koji ode u sandučić koji nitko ne čita isto je kao da ga nema.

Ako koristite stare testove dostupnosti: rok je 30. rujna 2026.

Microsoft gasi stare URL ping testove u Application Insightsu 30. rujna 2026. Ako ih još koristite, prebacite ih na standardne testove. Inače će nadzor dostupnosti tiho prestati raditi, a to je upravo ona vrsta kvara za koju biste htjeli alarm.

Da nadzor ne pojede račun

Application Insights se naplaćuje po količini podataka koje bilježi. Zato se nekim firmama račun za nadzor popne iznad računa za samu aplikaciju. Tri stvari to drže pod kontrolom:

  • Uzorkovanje. Ne treba zapisati svaki uspješan zahtjev. Dovoljan je reprezentativan dio, a greške se bilježe sve.
  • Razina logova. U produkciji ne treba sve što se ispisuje tijekom razvoja. Detaljni logovi uključuju se kad se nešto istražuje, a zatim se opet isključe.
  • Dnevni limit. Gornja granica kao osigurač, ako neka greška odjednom počne pisati tisuće zapisa u minuti.

Kako to uvodimo

  1. UključitiPaket, postavka, test dostupnosti
  2. AlarmiPet alarma, pravim ljudima
  3. PregledJedan ekran za zdravlje aplikacije
  4. RedovitoTjedni pogled na trendove

Kad nadzor radi, sljedeći korak je koristiti ga: koji su ekrani najsporiji i koje greške se ponavljaju. To je isto mjerenje o kojem smo pisali u članku o sporim aplikacijama, samo što sad podaci stižu sami.

Kako mi radimo

ProCoding je .NET studio iz Splita, a Azure za .NET aplikacije jedna je od naših specijalnosti. Nadzor, alarme i pregled troškova postavljamo kao dio Azure health checka ili zajedno s vašim timom. Prvi korak je besplatni razgovor od 30 minuta.

Izvori

Povezani članci

© 2026 ProCoding — Sva prava pridržana.Impresum i privatnostSplit, Hrvatska