Logging er en fundamental komponent i moderne applikationsudvikling, og i ASP.NET Core er det implementeret gennem en fleksibel og kraftfuld infrastruktur, centreret omkring ILogger-interfacet. Dette interface udgør et centralt værktøj til at registrere og analysere applikationens adfærd i realtid, hvilket både understøtter fejlsøgning og systemovervågning.

ILogger tillader logning i flere detaljeringsniveauer, hvilket skaber en præcis og struktureret forståelse af, hvordan applikationen kører. Disse niveauer spænder fra Trace, som giver lavniveaudetaljer anvendelige under fejldiagnosticering, over Debug og Information, som viser applikationens normale flow, til Warning, Error og Critical, der signalerer henholdsvis potentielle problemer, faktiske fejl og systemnedbrud. Det er denne granularitet, der gør logging til et operationelt værktøj snarere end blot en simpel meddelelse i konsollen.

Logmeddelelser genereres gennem en række convenience-metoder som LogTrace(), LogDebug(), LogInformation() og så videre. Disse metoder accepterer formaterede strenge og understøtter parameterindsættelse, hvilket giver mulighed for præcise og kontekstuelle beskeder uden at miste performance. Dertil kommer brugen af scopes via BeginScope(), som introducerer et kontekstuelt domæne for logningen. Det muliggør gruppering af logposter, hvilket er særlig nyttigt i asynkrone eller komplekse operationer, hvor korrelation mellem hændelser er kritisk.

Eksempler på implementering afslører, hvordan ILogger typisk injiceres via dependency injection og bruges som en serviceklasse, hvilket sikrer løskobling og testbarhed. En klasse som MyService kan modtage en instans af ILogger og bruge den til at logge ved opstart, under kørsel og ved fejl. Denne tilgang placerer logging centralt i applikationens livscyklus i stedet for som et eftertænkt appendiks.

Yderligere tilbyder ASP.NET Core ILoggerFactory, som abstraherer og centraliserer oprettelsen af logger-instancer. Ved at modtage en ILoggerFactory gennem dependency injection kan en klasse oprette en specifik logger til sig selv ved hjælp af CreateLogger(), hvilket kategoriserer logningen og letter filtrering og analyse. En tydelig forskel mellem brugen af ILogger og ILoggerFactory ligger netop i denne kategorisering – logmeddelelser grupperes efter den angivne kontekst, typisk klassens navn, hvilket giver strukturel gennemsigtighed.

Et afgørende element i ASP.NET Cores logging-infrastruktur er understøttelsen af forskellige logproviders. Disse providers, som konfigureres centralt under applikationens opstart, bestemmer hvor og hvordan logmeddelelser gemmes eller vises. Det kan være i konsollen, i en logfil, i Visual Studio’s debug-vindue, eller eksternt i tjenester som Azure Application Insights eller Elasticsearch. Kodeeksempler fra Program.cs illustrerer, hvordan man kan rydde de standardproviders og tilføje egne som AddConsole(), AddDebug() og AddEventSourceLogger() – hvilket tillader fuld kontrol over logningsflowet.

Når ILogger anvendes til at logge en fejl, eksempelvis via _logger.LogError(ex, "An error occurred"), distribueres meddelelsen automatisk til de konfigurerede providers. Dermed bliver logningen et kraftfuldt, distribueret system, der både understøtter fejlfinding under udvikling og overvågning i produktion.

Det er vigtigt at forstå, at logging ikke blot er en teknisk detalje, men en strategisk komponent i softwarearkitektur. Det muliggør retrospektiv analyse, incident response, performanceoptimering og endda audit trail, afhængigt af hvordan logdata bruges. Loggerens struktur skal derfor afspejle applikationens forretningsdomæne og tekniske opbygning. Dette indebærer at vælge de rette logniveauer, udforme konsistente meddelelser og sikre, at logningen ikke kompromitterer ydeevne eller sikkerhed.

Samtidig må logging aldrig blive en erstatning for fejlhåndtering. Det skal komplementere exception handling, ikke erstatte den. Logning skal give indblik, ikke blot støj. En velfungerende loggingstrategi bygger derfor på konvention, disciplin og værktøjsunderstøttelse – alle elementer som .NET Core-platformen til fulde understøtter.

Hvordan publicere en applikation og håndtere databaser i en skyinfrastruktur

For at kunne implementere en applikation korrekt i et cloud-miljø, er det nødvendigt at forstå, hvordan man opretter forbindelser til databaser, sikrer adgangen til ressourcer og offentliggør applikationen. Denne proces involverer flere skridt, som kræver både praktisk erfaring og viden om de teknologier, der anvendes.

Først og fremmest skal vi finde den ressourcegruppe, der er blevet oprettet for applikationen – i dette tilfælde "rg-aspnetcore8". Når du åbner denne ressourcegruppe, vil du se en liste over de ressourcer, der er blevet oprettet. En af disse ressourcer vil være den database, som applikationen skal bruge, i dette tilfælde kaldet "UrlshortenerDB". Ved at søge efter og tilgå denne database, kan du finde nødvendige forbindelsesoplysninger, som er vigtige for at konfigurere applikationen korrekt.

Når du har fundet denne ressource, går du til "Connection Strings"-sektionen i indstillingsmenuen. Her vil du kunne finde en forbindelsesstreng, som typisk vil se ud som følger:

pgsql
Server=tcp:urlshortener-db-server-tanure.database.windows.net,1433;Initial Catalog=UrlshortenerDB;Persist Security Info=False;User ID=urlshortener-db-server-tanure-admin;Password={your_password};MultipleActiveResultSets=False;Encrypt=True;TrustServerCertificate=False;Connection Timeout=30;

En af de vigtigste parametre at bemærke i forbindelsesstrengen er "Password={your_password}". Dette skal du erstatte med den adgangskode, du kopierede, da du oprettede dine applikationstjenester. Når dette er gjort, skal du kopiere forbindelsesstrengen fra ADO.NET (SQL Authentication)-feltet og åbne din applikations appsettings.json-fil. Her skal du opdatere "DefaultConnection"-egenskaben til den kopi, du netop har lavet. Det bør se sådan ud:

json
"Logging": { "LogLevel": { "Default": "Information", "Microsoft.AspNetCore": "Warning" } }, "ConnectionStrings": { "DefaultConnection": "Server=tcp:urlshortener-db-server-tanure.database.windows.net,1433;Initial Catalog=UrlshortenerDB;Persist Security Info=False;User ID=urlshortener-db-server-tanure-admin;Password=XL6l61uv9t4$K4Q6;MultipleActiveResultSets=False;Encrypt=True;TrustServerCertificate=False;Connection Timeout=30;" }, "AllowedHosts": "*"

Når dette er opdateret, skal du gemme filen. Herefter skal du konfigurere adgangen til database-serveren. Dette gøres ved at gå tilbage til ressourcegruppen "rg-aspnetcore8" og vælge "urlshortener-db-server"-ressourcen. Under "Security" skal du vælge "Networking" og herefter klikke på muligheden "Add your client IPv4 address", hvilket gør det muligt for databasen at blive tilgået fra din nuværende IP-adresse. Det er vigtigt at være opmærksom på, at hvis din IP-adresse ændrer sig, skal du følge de samme skridt for at tilføje den nye adresse.

Når adgangen er konfigureret, klikker du på "Save". På dette punkt har du opdateret applikationen til at bruge den rigtige forbindelsesstreng og sikret adgangen til databasen fra din nuværende IP.

Nu er det tid til at opdatere databasen. For at gøre dette skal du åbne terminalen på dit operativsystem, navigere til mappen med din URLShortener-applikation og køre følgende kommando:

pgsql
dotnet ef database update

Når denne proces er færdig, kan du kontrollere, om tabellen er blevet oprettet korrekt ved at tilgå Azure-portalen. Gå til ressourcegruppen "rg-aspnetcore9", vælg "UrlShortenerDB" og brug Query Editor til at få adgang til databasen med de credentials, du tidligere har oprettet.

Denne proces demonstrerer en af fordelene ved at bruge Entity Framework Core-migrationer. Ved at bruge migrationer kan ændringer i databasen nemt implementeres både lokalt og på servere, samtidig med at de forbliver i overensstemmelse med applikationens kode.

Når databasen er opdateret, er det tid til at publicere applikationen. Dette kan gøres nemt ved at bruge Visual Studio Code og Azure Tools-udvidelsen. Hvis du har konfigureret Azure Tools-udvidelsen korrekt, kan du følge disse enkle trin:

  1. Åbn applikationens bibliotek og kør kommandoen: code .

  2. Klik på Azure Tools-udvidelsen i Visual Studio Code, og du vil få vist en liste over de abonnementer, som du har adgang til.

  3. Højreklik på applikationen og vælg "Deploy to Web App".

  4. Bekræft de indstillinger, der vises, og vent på, at deployment-processen afsluttes.

  5. Når deployment er fuldført, vil en meddelelse poppe op, og du kan åbne den publicerede hjemmeside.

Azure Tools-udvidelsen automatiserer mange af de tekniske processer, som normalt ville kræve manuel indsats, som f.eks. at gendanne pakker, kompilere applikationen, generere et publiceringspakke og uploade dette til Azure. Hver gang du vælger at publicere via Azure Tools, vil disse skridt blive udført automatisk.

Når applikationen er publiceret, kan den køres i Azure-miljøet og blive tilgængelig offentlig. Dette gør det muligt for applikationen at køre effektivt og pålideligt, og samtidig udnytter du de robuste funktioner i Azure til at håndtere og skalere din applikation.

Det er vigtigt at forstå, at cloud-løsninger som Azure ikke kun giver dig en platform til at hoste dine applikationer, men også tilbyder en bred vifte af værktøjer og muligheder for at skalere dine løsninger i fremtiden. Hosting af applikationer i skyen har den fordel, at den kan håndtere ændringer og skaleres efter behov. Desuden åbner det op for brugen af containerteknologi som Docker, hvilket gør det muligt at skabe en ensartet udviklings-, test- og produktionsmiljø. Dette sikrer, at applikationen kører uden fejl, uanset hvor den er hostet.