Den gode logning (systemlog)

Følgende beskriver tekniske retningslinjer for hvorledes der logges til systemloggen fra STARs applikationer.

Hvornår skal der logges?

Se beskrivelse af systemloggen her:

Hvor skal der logges?

Data skal logges til en særskilt database så logdata holdes adskilt fra øvrig produktionsdata. Logdata skal behandles som al anden personfølsom data.

Disse data skal logges

Følgende informationer (kolonner) logges:

Kolonnenavn

Type

Beskrivelse

Kolonnenavn

Type

Beskrivelse

Timestamp

DateTime

Logningens tidsstempel

ApplicationName

String

Applikationens navn

Thread

String

Den tråd der logger

Level

String

Level (Debug, Trace, Info, Warning, Error, Fatal)

Severity

String

Error, Warn, Info, Debug, Trace

Message

String (5000 tegn)



Exception

String



ServerId

String

Server Name

IP Address

String

Server IP address

Identification

String

CPR, CVNumber, CVR eller lignende identifikation.

Best practices 

  1. Alle data ind og ud af hver applikation/system logges (excl. databasetrafik), væsentlige forretningshændelser logges.

  2. Opslag på borgere påføres om muligt CPR som identifikation for så enkelt som muligt at kunne samle log om tilgang til en borger ved revision.

  3. Alle logninger skal foretages som et asynkron kald af performance hensyn.

  4. Alle Log4Net levels understøttes, dog skal ’Debug' level som udgangspunkt kun benyttes i test-miljøer og skal kunne slås fra via konfigurationsfil.

  5. Log skal opbevares i 1/2 år jf .Systemforvalter. Der skal tages stilling til database-partitionering/arkivering ( ikke et absolut krav )

  6. Store request og response beskeder klippes.

  7. Vedhæftninger/dokumenter logges ikke.

  8. Der skal logges oplysninger om den kaldende bruger/myndighed, input parameter til service kald samt start og slut tidspunkt for request.

Logningsniveauer

Følgende er beskrivelse af de enkelte logningsniveauer og hvad der logges under disse:

  • error: systemet er fejlramt, brugerne bliver sikkert ramt (snart) og rettelse kræver formentlig menneskelig indgriben. Der kan trigges alarmer ud fra "error" logninger, dvs. at hvis en servicetekniker skal vækkes så log på "error" niveau.

  • warn: en uventet teknisk eller forretningshændelse er opstået, brugere bliver muligvis berørt, men der er ikke behov for menneskelig indblanding. Servicetekniker skal ikke tilkaldes, men supporten bør kigge disse igennem.

  • info: det normale loglevel som anvendes hvis vi ønsker at se hvad der er sket, det kan være system-lifecycle events (system start, stop), "session" lifecycle events (login, logout, etc.) osv. Væsentlige snitfladehændelser kan også placeres her, f.eks. service, api og måske databasekald. Normale forretningsexceptions kan også logges her som f.eks. inputvalideringsfejl, login-fejl osv. En hver anden hændelse som du ønsker skal logges i produktion placeres her.

Disse anvendes normalt kun på test- og udviklingsmiljøer:

  • debug: alt det andet som ikke skal logges under info. Det kan være hændelser som er hjælpsomme for at se kald ned igennem kodestakken. Det kan også være logning på indgang/udgang af komplekse metoder.

  • trace: bruges sjældent, det er detaljerede trace logninger, der f.eks. bruges under udvikling til logning af hele objekthierarkier og kaldestak, eller et trace der gentages i et loop osv.

Teknikken

Logkomponenten Log4net benyttes til logning, via asynkron database-connector. Har applikationen adgang til DFDG Foundation, skal logkomponenten herfra anvendes.